Electronic Design
Designing A Small Peripheral Module Standard

Designing A Small Peripheral Module Standard

Small peripheral modules (SPM) come in a range of form factors with an almost equal number of connectors and pinouts. Every microcontroller vendor has its own line of development boards with unique expansion support typically to provide access to all the chip's peripheral interfaces.

There are some platforms like Arduino that have garnered support from multiple vendors. Likewise, there are standards like PC/104 and many variations thereof. The problem with the latter is the form factor is rather large and the cost of these boards tends to be rather high.

These days it is relatively easy to pack a lot of logic into a square inch. It would be nice to have a low cost expansion module for the PC/104 crowd where add-on peripherals are often limited. The challenge is that most development kit modules tend to lack details like mounting holes necessary for rugged environments. On the other hand, many embedded standards like the Small Form Factor SIG's (SFF-SIG) SUMIT (see SUMIT Brings Big Improvements In Small Packages) provide high performance bus expansion but utilize rather expensive connectors. In many cases, performance is not necessary. For example, accessing serial flash or wireless interfaces can utilize lower speed interfaces like I2C or SPI. Even serial ports are can be handy.

So what kinds of modules are candidates for this platform? Just about everything from ADCs and DACs to serial memory.

So I've decided to propose my own SPM to get the discussion going. I have talked with a number of board and microcontroller vendors and many expressed interest. Many will ask their users about this issue but I figured it would be a good idea let everyone in on the discussion.

So here it is. Call it Bill's SPM Rev 0.1 (Fig. 1) for now. Keep in mind these initial premises:

  • Low cost
  • Suitable for rugged environment
  • Space for at least one external connector
  • Small form factor
  • Standard bus connectors
  • Low speed interfaces
  • Support for common microcontroller interfaces
  • Modules and host boards do not have to support all interfaces
  • Modules may only work with host boards that support a matching interface
  • Stacking is optional

The sample figure addresses some of these items. For example, the two headers would be standard 0.1-in center headers that would allow stacking. Some interfaces like I2C could be used on a number of boards in a stack. Alternatively, a board using SPI could be stack on top of another that uses I2C or a serial port. The four mounting holes might be overkill especially given rigidity the headers would provide but rugged environments would need at least one way to lock down a module.

Now for some of the signals.

Bank 1

  • SPI/Quad SPI (6)
  • I2C (2)
  • Serial port (4) - TX, RX, CTS, RTS
  • Interrupt (1)
  • Reset (1)
  • 3.3V power (1)
  • Ground (1)

Bank 2

  • Data (8)
  • Control (3) - Strobe, Busy, Ack or Vsync, Hsync, Pixel clock
  • USB (2)
  • Ground (1)
  • 5V power (1)
  • Unregulated power (1)


Some of the annotations highlight possible configurations. Parallel port aficiondos will recognize the Control handshake signals. Likewise, the Data lines could be used for an 8-bit camera chip.

The choice of 16-pin headers is arbitrary but provides for a wide range of options. It leaves out some interface like CAN (controller area network) and it might be worth adding or changing a couple pins to include this. Pins might be able to do double duty so CAN could replace USB. Developers would need to know these limitations but that is the case already since an SPI module would require a host with an SPI interface. The bigger question would be whether a stack would require USB and CAN at the same time.

I've include 3.3V and 5V power but that might be overkill. The unregulated power is one I would recommend keeping because it could go in both directions. It could be used to provide power to servos or a module might supply power. This could be done by putting batteries on the module or a power connector. It might also be possible to scavange power and provide it to the host.

Other areas of discussion include signal placement. For example, it would save a few cents if a carrier board could present half the header pins. This might be the case if the board did not support all of the interfaces. Requiring only the outer rows of pins could be a possibility. Of course, this means pins for power and ground should be on these rows.

Now for the discussion. Are these interfaces sufficient or are there too many? Is the form factor too big or too small? Does it cover enough types of peripherals to be useful? Would you use modules of this type?

Here are a few thoughts. The figure shows a large host board with two SPM sockets next to each other. One possiblity is a double wide SPM module. Another is to have a carrier board that is the same size as the SPM module. That would be a rather compact system. Add a battery to the top of the stack for a mobile prototype.

Another configuration I considered was a host processor board using a camera module mounted at a right angle to the host. A very low cost module is possible using a right angle header if the parallel camera interface is properly place. Of course, if the camera chip needs 3.3V then the current design might not be as amenable to this since that power is provided by the other header.

So what's another connector or circuit board in a design? For the designer, not much. For the supplier, it is added cost and lost profit.

An outfit like SFF-SIG might be a good place to formalize SPM but it definitely needs input from microcontroller vendors. Another major group are vendors that make boards for other form factors and purposes. This would be a useful platform for robotics.

So what do you think? Leave a comment or send me an email.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.