Sunday, November 16, 2014

As Easy as ABC (and D)

The Arduino has definitely been a major force behind the open hardware movement, democratising hardware and making it much easier to develop microcontroller based gizmos.

However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.

The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market.  However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.

A great YouTube about the "AVR Story"

So how would you design a better "Arduino" ?  Here's some of my thoughts:

1. A smaller footprint  60 x 20mm  (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6.  More I/O  -  32 pins, as opposed to 20
7.  Higher resolution ADCs:  12bit and 16 bit available.  2 DAC channels
8.  More UARTS, SPI and PWM
9.  Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace

Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package.  This is nice and compact, but not easy to prototype with.  So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint.  A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.

Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:



As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal.  The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.

Now this was based on the STM32F303, a great little ARM Cortex M4 device.  But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.

The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout  - rather than in a logical manner where pins were grouped by function.  The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.

I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.

Here's a neat diagram to illustrate this point:

ATmega1284 - a great layout for a 40 pin DIL package


Notice how the power pins are at the centre - so if you did plug this in the wrong way it wouldn't fry - it just wouldn't run. Also, see how the ports are more or less symmetrical - at the corners of the package.  The 4 ports are PA, PB, PC and PD.

Now whilst PA is exclusively for the ADC inputs, ports B, C and D are a bit of a mixture.  It's a good layout, but not perfect.

So I came up with the idea of 4 generic ports, A, B, C, D - each which has a specific function.  


Here's the key point of this post:

Any microcontroller, of 48 pins or less, from any manufacturer,  could be fashioned onto a 40 pin carrier pcb. Regardless of the specific micro, the boards would be interchangeable.


I like to keep things simple, so here's the naming scheme:

A  Analogue
B  
C  Communications
D  Digital

Ok, Port B does not have an easy to remember name yet, but A,C and D are pretty much memorable.

Port A  - 8 Channels of A-D converter
Port B  -  Plan B - all the pins that don't go with the flow
Port C  -  UART (Tx, Rx), SPI (MOSI, MISO, SCK & /CS),  I2C (SCL, SDA).
Port D  -  General purpose digital I/O, timers, PWM etc

Port B is a bit tricky to define at the moment.  In the case of the STM32F373, it would be 8 channels of 16-bit high resolution ADC, but in the case of the STM32F103 in would just be 8 consecutive pins that constitute part of GPIO PortB.

I know this is a bit of a cop-out - but bear with me. 

What about AVR devices - can they be moulded into this common format?  

The 32 pin LQFP ATmega328-MU certainly can be pinned out into the common format.  It has 8 ADC channels to route to Port A,  the UART, I2C and SPI can be routed to Port C - the communications port, and the remaining digital I/O routed to Port D.

Here's our old friend the ATmega328P-PU

As you can see, the power pins are in the centre of the package and the ports are generally arranged in the corners - not perfect, but manageable.

Here's the SMT part - the ATmega328-AU





This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins   TXD, RXD, MOSI, MISO, /SS and SCK map to Port C.  The PWM channels map to Port D etc.

This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.



Summary.

This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.

More on this next time.......


No comments: