Archive for the ‘ARM’ Category

New STM32F4 Discovery Boards

September 15, 2013

I am a big fan of ST Micro’s STM32 Discovery boards. They are usually low-cost, often under 10 (GBP), and usually go beyond buttons and LEDs to include fun chips like accelerometers, gyroscopes, e-compasses, MEMS microphone, audio-codec, and speaker or headphone amplifiers.

ST Micros has announced two new Discovery boards at the same time as announcing volume shipment of new members of the STM32F4 family of microcontrollers.

The 32F401CDISCOVERY has a new low-end STM32F4. The MCU is a STM32F401VCT6 which runs at 80MHz, and has 256 KB of Flash memory and 64 KB of RAM in a 100pin package. The board has 3-axis digital  gyroscope, 3D digital accelerometer, 3D digital compass, omnidirectional digital microphone, and audio DAC with speaker amp, as well as four user LEDs and two pushbuttons. So this looks like tremendous fun! Future Electronics are listing it at $15 (USD), though they have no stock, so this price may change.

The 32F429IDISCOVERY has a new high-end STM32F4. The MCU is a STM32F429ZIT6 which runs at 180MHz, and has 2 MB of Flash memory, 256 KB of RAM in a 144pin package. The board adds 8MiB RAM, 2.4″ QVGA TFT LCD,  3-axis digital gyroscope, and a couple of user LEDs and buttons. ST are listing it at $24 (USD), but I haven’t found distributers listing it.

I remember our DEC Vax 750 (Systime 8750) only had 4MB memory, ran BSD UNIX, with a clock speed of a few MHz, and supported about a dozen users. IIRC it cost about £60,000 (in 1983)! So that 32F429IDISCOVERY would be quite a lot of computer for under £20.

One of the good things about the STM32 Discovery boards is they have hardware debuggers. Those boards have a cut down ST-LINK/V2, which provides hardware debugging for the STM32 on the same Discovery boards, and can also be used to debug the MCU on our own STM32 boards. So we can get off the ground, developing our own hardware, for less than the cost of an Arduino UNO. Of course, price isn’t the only criteria, Arduino does give us an easy to use IDE with libraries and examples, an amazing, supportive, community, a wide variety of compatible hardware, and Open Source hardware and software.

The ST-LINK.V2 will work with gdb. I’ve had success on my Mac using the Open Source ST-LINK server at github.com/texane/stlink which also provides a free-standing application for program upload. Windows users have other choices from ST directly, and the tools vendors have have support. So one option is to use a free version of e.g. Keil, which friends at Micromouse have used.

Now that ARM is supporting gcc and the gnu tools directly, through GNU Tools for ARM Embedded Processors, there is a relatively straightforward, free toolchain available for anyone to get hacking. Of course, those same tools work on my Orone-mini boards, as well as LeafLab’s Maple boards. There is some work on the LeafLabs Arduino compatible IDE going on too, So there may be an even easier path to using those boards in the future.

Improving Maple Mini (part 2)

March 31, 2013

Tekwizz colleagues gave me feedback on Orone-mini, my current attempt to improve Maple-mini. They suggested that the board should focus more on being practical for people, especially relatively inexperienced makers, to assemble by hand, and less on being small. We agreed this mainly means using larger SMD parts which are easier to handle. Hence, I have made the components even larger than Orone-mini, which itself already uses much larger components than Maple-mini.

Another change to help make the board easier to assemble is using bigger pads and wider tracks. This is not about making a ‘DIY’ Printed Circuit Board (PCB), but about soldering parts onto it. I’ve recently worked with a lot of people who are beginners to soldering, and they have started with through hole parts. They are making a quite finely detailed board (not designed by me:-). This experience proved it is easy to overheat pads and tracks with a soldering iron, melting the glue, and detaching the copper from the board. This can be very awkward to fix or workaround. So the Orone-mini board has wider pads and tracks around through-hole soldered parts, increasing the area of copper, and hopefully making it more robust for people to assemble.

Increasing the size of parts means increasing from the Maple-mini’s 0402, and Orone-mini’s 0805, to 1206 size Surface Mount Devices (SMD). This means all of the Maple-mini 0402 size parts, that is 0.04 inch x 0.02 inch, or approximately 1mm x 0.5mm, are now 1206 size parts, which are 0.12″ x 0.06″, or approximately 3mm x 1.5mm. So each part increase to nine times the area of the Maple-mini part. I also increased the size of the protection diodes to twice their previous size. The transistor, regulators and Integrated Circuits (ICs) are the same as before. The transistor and small regulator are about the same size as a 1206 part, and there is no other package for either IC. The through hole parts are unchanged in size; I’ve used some of them with beginners, and they seem to be okay.

Not too surprisingly, I couldn’t fit the bigger-size components onto a Maple-mini size PCB. So the PCB has increased in size by 0.2 inches in each direction. The 0.1 inch pitch header pins are also 0.2 inches further apart, so now at 0.8 inches. It is still quite small at 2.3 inches x 1 inch. I am currently calling this ‘Orone-wide-mini’, though I quite like ‘Orone-mini-w’, or ‘Orone-mini-08’ (to identify the header spacing). Any suggestions?

Increasing the board size creates quite a lot of unused area on the bottom of the PCB, which is really the ‘Top’, because it’s the side people will see when using it. This bigger area gives more space for the ‘Top’ silkscreen, so that is slightly bigger. However, it also provided enough space to fix two other Maple-mini deficiencies; Orone-wide-mini has a ‘Power On’ LED, and a two-pin Molex socket for ‘External Power’.

The ‘External Power’ 2-pin Molex socket is on the same 0.1 inch grid as the boards main pin headers. So hopefully anyone intending to use Orone-wide-mini on their own strip-board circuits should find it practical to use 0.1 inch pin headers in the External Power holes and provide their own external power.

Finally, the component-side silk screen, which carries the names of components, has been increased in size, hopefully making it easier to use while assembling the board, and reducing the need for a separate assembly guide ‘component map’.

The header pins are as before; signal identical, and voltage identical with Maple-mini. So the existing Maple-mini-bootloader should ‘Just Work’ (TM 🙂

Here is a draft version of the ‘Orone-wide-mini’ board (or as pdf with comments Orone-wide-mini-v0Xr001):

Orone-wide-mini-v0Xr001
Here is the schematic with the new additions of Power-on LED and External Power Molex socket. (or as pdf Orone-wide-mini-v0Xr001.sch):

Orone-wide-mini-v0Xr001.sch
This rework has set me back a bit, and I have been ‘under the waether’, so I now hope to have checked and uploaded the CAD in a couple of days.

Summary: Orone-wide-mini uses larger components, along with bigger tracks and pads and better compnent-side silk screen to help make it ‘hand assembly friendly’. It adds a Power-on LED, an External Power 2-pin Molex socket, and larger ‘user side’ silk screen, hopefully making it more useable. It retains Maple-mini signal and voltage compatible pin headers.

WARNING: This has not yet been made, so please do not assume it even works.

Improving Maple Mini (part 1)

March 26, 2013

This is a quick post to show my progress on making an improved STM32F board inspired by LeafLabs Maple-mini, and Siy’s mini48. I’ll explain more about the changes and rationale in a future post. WARNING: this board has not been assembled and tested. So please don’t assume it’s finished and ready to be used.

The main aim was to be bootloader and code compatible with Maple-mini. I believe that’s satisfied by retaining the same signal pins, for the same purposes. All the signals on the pins are the same signal sources with the same names and positions.

One aim was to retain pin compatibility with Maple-mini. However, as I made changes, I decided that the one of the defects of Maple-mini is the power supply. So Maple-mini’s analogue output voltage (the av+ pin) has been replaced by a connection to the higher-capacity digital power regulator. I’ll explain the detail later, but the key point is, for most uses of Maple-mini the pin-change is transparent. So I hope it is close-enough to pin compatible.

The main differences are:

  • Redesign Maple-mini’s 4-layer PCB, as simpler, Double-sided PCB
  • Single-sided Surface Mount Devices (SMD), for simpler DIY assembly
  • Larger 0805 parts, replacing 0402 parts, easier (for me) to make
  • Much higher capacity Voltage regulator, aim is full power from 9V input
  • Polyfuse protecting Host’s USB-sockets power
  • USB Electro-Static Discharge (ESD) protection for Host-USB socket
  • More compact USB termination
  • Simplified USB ‘pull-up resistor’; signals ‘USB device type change’
  • Through-hole USB socket intended to be more robust than SMD socket

When I started, I didn’t expect to achieve Maple-mini’s useful 0.6″ row spacing of header pins. I was using relatively modest PCB Design Rules of 8mil track and space (about 0.2mm track & space).

Siy wrote that he’d packed an 48 pin STM32F into a 0.5″ pitch board! He is amazingly good at this stuff.  Inspired by Siy, I tried using a finer 6mil track and cleaeence (just over 0.15mm).

Here’s the PCB. The header pins are the same pitch and distance apart as Maple-mini (or as a PDF: Orone-mini-T6-v0Xr001):

Orone-mini-T6-v0Xr001

Because the header pins are physically identical, and signal identical, it should ‘just plug in’ to a circuit using Maple-mini. The only change on the header pins is replacing ‘av+’ with the normal 3.3V ‘vcc’. As I wrote, I made this change to enable the board to safely run at higher input voltages (Vin) than Maple-mini. However, I would expect the change to be invisible for most users.

There are quite a lot of changes to the schematic. So here is the schematic, including some notes about changes (or as a PDF Orone-mini-T6-v0Xr001.sch):

Orone-mini-T6-v0Xr001.sch

I intend to post more explanation, and upload the Eagle CAD to github, soon. I hope this is useful to folks.

New Arduinos

September 25, 2011

The Arduino team announced some new Arduino’s:
http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/

The “Arduino Leonardo” is simpler, and should be significantly cheaper than an Arduino because it uses an ATmega with on-board USB. This looks pretty much like a “Teensy” from PJRC but with an Arduino UNO board layout.

The “Arduino Due” uses an ARM Cortex-M3 processor, in this case an Atmel SAM3U4. Unfortunately, that chip is quite big, 100-pin or 144 pin, so cost might be an issue. Atmel might give them good discounts,. We will see. It is forecast to be available by end of year.

From the brief spec, I think it is a 144-pin part, the SAM3U4E. That gives lots of Input and Output (I/O) pins. I am very interested in small robots, so that is quite big for a micromouse.

Compared to the ARM Cortex-M3 I am working with already, the ST Micro STM32F103, the exciting new feature of the Atmel SAM3U is high-speed USB (480Mbits) on-board, and it runs at 96MHz.

In other STM32F comparisons, I think the STM32F is slightly better for my areas of interest, though I would have to use a 144-pin STM32F part to get the full external memory interface.

The SAM3U does not have any Digital to Analogue Converters (DACs), whereas the comparable STM32F103xC (high density) part has two. Comparable STM32F has three 12-bit Analogue to Digital Converters (ADCs) which is slightly better than the SAM3U4 two ADCs. There is an interface to good quality audio chips called I2S. SAM3U4 has one I2S interface, while STM32F103 has two. What does this all mean? If you want to build audio projects, the STM32F might be a better starting point.

It is extremy useful for robots to keep track of their own position by measuring wheel movement (odometery). The technique often used is the same as older ‘ball’ mice. Internally a ball mouse has two orthogonal small wheels which rotate when the ball rotates. The two orthogonal wheels have slots. Light shines though the slots, and each time the light beam is broken, movement is detected. By using two beams and two sensors on each wheel, it can tell which direction the ball is moving. This technology is a quadrature encoder.

Quadrature decoders are very useful to track and time the quadrature encoder. STM32F103 timers can each implement a quadrature decoder, and hence some parts can provide upto 6. I had thought I’d misunderstood the SAM3U4 datasheet, but Atmel have confirmed it only has one quadrature decoder. This is not an issue, unless you want to build robots which ‘know’ where they are.

I am very pleased that the Arduino team are working on ARM Cortex-M3. I think this will encourage a lot more people to use the 32-bit ARM platform. Coretx-M3 is capable of so much more than the 8-bit ATmega, that I expect a significant flurry of new projects next year when the Arduino Due is fully developed.

Meanwhile, I’ll keep working on STM32F, and watch out for results from the Arduino Due .

Tutorials on USB, SPI, I2C, CAN, LIN, etc.

April 21, 2011

Thanks to the Arduino, and others including Maple, lots of new users, beyond traditional developers and engineers, are using microcontrollers. Microcontrollers are mind-boggling pieces of equipment, genuinely worthy of the moniker ‘only limited by your imagination’. Many users create amazing projects using the excellent libraries and existing electronics. Some need to go further. They want to understand how to make the hardware do even more and different things.

I have always been the type of person who likes to understand how things work. I like to read manuals. Even as a child I read the manuals for my brother’s HiFi so I knew how to do make it do pretty much anything possible. I like looking at low-level code, and digesting Microcontroller manufacturers manuals. I like reading technical stuff, especially over a balmy Holiday Weekend.

I sometimes work with folks with technical backgrounds in software not hardware or low-level embedded systems who want to do more. They have all the knowledge and skills to program the hardware, but the hardware manuals are too hard a place to start. It is surprisingly rare to find good introductory material for low-level technology which is both approachable and also detailed enough to enable non-specialists to go further.

I was pleased to stumble into a set of resources for embedded systems at “EE Herald”
http://www.eeherald.com/section/design-guide/index.html

It includes a section of “On line Courses” on common embedded communication interface ‘standards’. The tutorials include USB, I2C, SPI, CAN, LIN, Serial, and RS232. Those standards are used to communicate with individual chips such as accelerometer sensors, other microcontrollers, host PCs, SD memory, Wii controllers, controllers in manufacturing plant, and parts of cars. There are also section on ‘IEEE 802’ local area and wide area networking standards.

The sections I’ve skimmed seem to have good coverage and a decent level of details. The tutorials include some helpful diagrams, which helps folks like me a lot, and are written at useful level of technical detail without going down to the manufacturer specific hardware.

For example USB is covered in
http://www.eeherald.com/section/design-guide/esmod14.html

I have only skimmed it, but it reads as good coverage of USB 2.0 from history to physical hardware, electrical levels, signalling, end-points and protocol including packet formats. It isn’t as detailed as the USB specifications, but I don’t think many people would want to start their! I like to get a good overview of the way a system works before digging into the detail, and I like to have a broad technical understanding to stitch detail into.

The USB article at EE Herald isn’t perfect. It includes a very brief overview of USB On-The-Go (OTG), but not enough to feel I could properly understand the STM32F USB OTG hardware. USB On-The-Go includes the more complex host-side of USB, so it would be impressive if they had got that too. I feel that is a minor and common weakness.

It is a readable alternative to
USB in a NutShell at http://beyondlogic.org/usbnutshell/
USB made Simple at http://www.usbmadesimple.co.uk/

These won’t replace the manufacturers manuals (e.g. ST Micros STM32F RM0008), but they cover generic technical detail, and look pretty good. I’m hoping they may be enough overview for anyone who wants to read low-level code or hardware specific manuals like STM32F RM0008 or the Atmel ATmega 48/88/168/328 manual.

I briefly looked at some other articles in the EE Herald design guides, and they are not all good quality. I felt disappointed by the ‘MEMS based motion sensing design’. It had almost no useful detail; I thought it was weak even as marketing ‘puff’. I wouldn’t feel ready to tackle a manufacturers MEMS datasheet after reading that.

EE Herald have some links to other sites, including this useful looking article on 1-Wire Interfaces from Maxim which has a lovely list of 1-Wire Application Note links at the end. Ideal Holiday Weekend reading 🙂

OROne – Cortex-M3 robot controller (STM32F103)

April 6, 2011

I was lucky enough to get some financial support to design and prototype a robot controller. I got outstanding help and advice from Dr Tony Wilcox, Chris Evans and Roger Thomas of Birmingham City University. Chris did a lot of the PCB routing, and much of the board construction. Tony generously shared his wide experience of developing robot controllers, and embedded and electronic products. Roger was a font of knowledge on PCB design and manufacture, and electronics. Thanks also to Pete Harrison for his always helpful comments and suggestions.

I learned a huge amount from them. This is the result.

OROne STM32F Robot Controller

OROne STM32F103 Robot Controller - without 0.1" headers

It is based around an ST Micro STM32F103CB Cortex-M3 microcontroller. This version has 128K Flash, 20K RAM, USB, CAN, 3xUSART (serial),15xPWM, 16xADC, 2xI2C, 2xSPI, and JTAG in a 64-pin package, all ticking along at 72MHz.

The board adds dual DC-motor drive, seven LEDs, two buttons, two servo sockets, as well as sockets for six analogue input, two quadrature encoders, and headers for JTAG and Serial. The two 30-pin 0.1″ headers (missing from the photo) gives access to all of the microcontroller signals and power on a veroboard friendly grid. The microcontroller can be powered over USB, or via an external power supply or batteries. The board also has independent on-board voltage regulation for the servo’s and motor drive chip.

Like an Arduino, it is ‘self-programming’ over USB once the bootloader has been installed. I installed the bootloader over the microcontrollers on-board serial interface using an ordinary FTDI USB to serial cable. So it doesn’t need JTAG or an in-circuit programmer, ever.

It is based on the Maple from LeafLabs. LeafLabs have built an IDE using the same Processing-derived IDE as Arduino. It sits on top of GNU GCC. They have also implemented most of the Arduino base-libraries, so Arduino programs may move across to Maple with minimal or sometimes no changes. To top it all, they have developed a bootloader which enables the STM32F103 to program itself over USB. The whole software environment, libraries and bootloader are Open Source, and runs on Windows, Linux and Mac OS X.

Maple is a magnificent piece of work. My board ‘came up’ in a couple of hours (after we found and fixed a couple of my PCB errors).

Chris did much of the construction; he has a very steady hand. We used the ‘Mini-oven SMD technique’. Paul Gardiner of Finham Park school in Coventry did a workshop a while ago, and this is the biggest board I’ve made using it.

I’ll describe some of our experiences, and where-to-next over my follow-up blogs.

A lower-cost, ARM-based Arduino alternative?

December 15, 2009

I stumbled across this NXP press release for the LPC134x which is based on the ARM Cortex-M3. The press release says “The on-chip USB drivers support both the Mass Storage Class (MSC) and Human Interface Device (HID) class. Furthermore, these drivers are incorporated in ROM, saving customers approximately 5-6 K bytes of user code”

Looking at this presentation, (slide 25), the chip shows up under Windows (and they say Linux) as a Flash drive to provide “Drag and Drop Flashing”. It has this capability built in at manufacture! No need for a bootloader, JTAG, or a second chip, like the FTDI USB to serial interface on an Arduino. Put an LPC134x on a board, connect USB, and it should ‘just work’ (TM :-))!

An entire USB-based micro-controller board only needs an LPC1342 or LPC1343, a crystal, voltage regulator, a few passives and PCB. The LPC1342 is available from Farnell for £2.20 and LPC1343 for £2.70 or £3.30. So a board could be smaller than an Arduino-Nano, and lower-cost.

I haven’t read the datasheet in detail, but overall these micro-controllers are more powerful than Arduino’s comparable Atmel ATmega168 or ATmega328, with 16K or 32K of program memory, so this is the best I’ve found to achieve the goal of sub-$10 micro-controller (at one-off prices).

The NXP parts have plenty of advantages over the Atmel parts. The LPC134x runs at 72MHz vs the ATmega’s 16MHz, and both execute instructions in one or two cycles. The LPC134x is a genuine 32-bit processor, whereas the ATmega is an 8-bit processor, so this means some calculations will go much faster on the ARM. I don’t think this is a huge benefit, as my Arduino’s spend most of their time waiting around for something to happen, but it may mean some programs are smaller on the LPC134x.

The LPC134x looks like it has much faster (40x) Analogue to Digital Conversion (ADC), opening up a range of interesting sensors and experiments. The LPC134x has significantly more RAM; LPC1342 has 4KB vs the ATmega168’s 1KB, the LPC1343 had 8KB vs ATmega328’s 2KB.

Both families have a set of timers. Timers are used to implement analogWrite, millis, micros, delay and delayMicroseconds in the Arduino language, but they are also used to control servo motors, stepper motors, modulate Infrared LEDs, and time external events.

The LPC134x have 2 × 32 bit timers, and 2 × 16 bit timers vs the ATmega’s 1 × 16 bit timer, and 2 × 8 bit timers. The LPC134x timers look more flexible than the Atmega168/328. The LPC134x comes in a package with more pins, so there are more PWM pins, and more pins to time external events.

The on-board LPC134x USB is 12Mbit/second vs 0.115Mbit/second for the FTDI chip on an Arduino.

The rest of the comparison between LPC134x shows similar peripherals to the Arduino’s on chip. They both have I2C, SPI and USART. So overall the LPC134x looks as good or better than comparably priced ATmega’s (at one-off prices).

There is a free, Open Source, GNU toolchain for the ARM, which is based on the same compiler as the Arduino IDE uses. So it looks like there are no real obstacles to making a lower-cost, ARM-based Arduino alternative. Of course, there is a plenty of work in porting the Arduino language libraries, like analogRead and analogWrite, but the core functions, which we use the most, would probably be only a few weeks.

I’ve ordered a low-cost NXP development board, LPCXpresso, to do some investigation. This is a similar price to Arduino’s, at £18.34 from Future, or £17.86 from Farnell (plus VAT). This is an encouraging price because the LPCXpresso contains much more technology than an Arduino. The LPCXpresso has a JTAG debugger which supports much more sophisticated debugging than available on an Arduino, and it probably costs as much or more than the LPC1343 itself.

There is a free downloadable LPCXpresso development environment available, so it should be practical to get a better understanding, and discover the disadvantages that datasheets never show for very little further cost. I’ll try to make some time to investigate this in more detail after Christmas.

Please don’t misunderstand. I love my Arduino’s, but the ability to significantly reduce its price, and make better technology available to an even wider audience is compelling.