Getting started with Jumpstart Microbox

Richard Man at Imagecraft recently offered a free Jumpstart Microbox to bloggers willing to review it.  The kit includes ST Nucleo board with a STM32F030R8 ARM MCU, an add-on board, the Imagecraft compiler, and a book on embedded C programming.  I've done a lot of 8-bit AVR development, and had intended to test out some of the STM32 MCUs, so I took Richard up on his offer.  The price point is much higher than a $4 Maple Mini clone with stm32duino, but Richard says they're trying to compete with IAR & Keil, not arm-gcc.

Before the hardware arrived I downloaded the IDE, which is based on Code::Blocks.  It includes an annoying license manager (I haven't found a licence manager I didn't hate).  On Windows 7E-64, the IDE identifies itself as Imagecraft 8.12.  Unlike gcc, Imagecraft is not a full C++ compiler.  Once the loads, the project options require you to pick your MCU, which defaults to the STM32F030R8.

For debug/download interface it only supports SWD.  All STM32 chips have a UART bootloader in ROM that allows flashing the chip without a SWD link, using software like stm32flash.  When I pointed this out to Richard he replied saying they would likely add support for it.  The project template includes a main.c with the implementation of putchar for printf to work.  I'll look at the compiler and Jumpstart libraries in more detail in a future post.

The jumpstart tutorial book is very basic.  I've been programming in C and C++ for 25 years, so there was nothing in it I didn't already know.  I didn't like the examples that included preprocessor directives (i.e. #define END 90) and code.  Good coding practice is to put preprocessor defines in a separate file like config.h.  The tutorial doesn't mention fixed-point, which I think should be preferred over floating point in embedded systems.  Richard responded that their compiler doesn't (yet) support fixed point (gcc does), so he hadn't mentioned it in the tutorial.  He said it will eventually be added to the compiler, but no promises as to the release date.

I'll finish this first part of my review with saying that I think, on one hand, that it would be better to have noobs reviewing the Jumpstart Microbox since the target market is not old C programmers like me that live by bash, vi, gcc, and objdump.  On the other hand, noobs aren't going to know about the UART ROM bootloader, so I suppose I make a good (and cheap) beta tester for Imagecraft.

Using a 74HC595 as a 74HC164 shift register

The 74595 and 74164 serial-in parallel-out shift registers are a popular way of adding extra outputs to a MCU.  There's lots of good guides online about how to use these shift registers such as this one by Ido Gendel.  I recently found a great deal on a bunch 74595s, and wondered if there is an easy way to modify circuits intended for a '164 to use the '595.  The solution turned out to be as simple as connecting two pins with a resistor.

There's actually a bit more than just connecting two pins together with a resistor, but the other requirements are simple and obvious.  Pin 13 on the '595 is Output Enable, and is active low, so it should be tied to ground.  Pin 10 is the clear pin (like MR on the '164), and should be tied high to keep the shift register from clearing.  As a small aside, when doing this on a breadboard you may want to connect pin 10 to Vcc with a 1K resistor.  That way if you accidentally connect to pin 9 (Qh') instead of pin 10 you won't risk shorting out the chip and damaging it.  I got my batch of '595s for about 2c ea, so I'm not concerned about frying one of them.  The key part of this solution is the resistor between pin 11 (SRCLK) and 12 (RCLK).  RCLK is what updates the 8 outputs, and it needs to be clocked high at least 19ns after SRCLK (Ti datasheet table 7.6).

The resistor, when combined with the parasitic capacitance of the RCLK input forms an RC circuit which delays the clock pulse.  If this delay is at least 19ns, then the outputs will be automatically updated (almost) instantly after data is clocked in, just like it is on the 74164.  The input high level for the '595 is 0.7 times the supply voltage.  The RC time constant is based on the time to charge (or discharge) by 63%, so after adding a bit to go to 70% and a safety margin for slower operation down to 3.3V, R*C should be at least 50ns.  The datasheet says the pin capacitance is typically 3pF, and a maximum of 10pF, so something in the 10-15K Ohm would probably work.  The first resistor I tried was 11.3K, and the scope trace above shows the rise time on RCKL in blue compared to SRCLK in yellow.  The delay to 3.5V is around 250ns, and based on the 200ns delay to reach 3.15V (63%), the total capacitance is about 18pF.  Subtracting the 13pF capacitance of my scope probe leaves a total of 5pF for the pin and resistor parasitic capacitance.  The net 5pF capacitance with a 11.3K would mean RCLK reaching 3.5V around 70ns after SRLK.

With this simple modification you can turn a 74HC595 into a 74HC164, and avoid having to stock your parts bin with both kinds of chips.  Since the RCLK and SRCLK pins are adjacent to one another, a surface mount chip resistor could be soldered between the pins if you want the modification to be permanent.  I did something similar with on-chip decoupling capacitors.  SMD 0805 parts work fine with the 0.1" (2.54mm) DIP spacing, and 0603 will just work with 1.27mm SOP pin spacing.  Although 0402 would be a more ideal fit for 1.27mm SOP, soldering those tiny 0402 parts is not something you'll see me doing!

ATmega328p bandgap voltage reference

All modern AVRs have a bandgap voltage reference that can be used with the ADC instead of AVCC.  On most AVRs it is around 1.1V, and allows for improved ADC resolution when measuring voltages below 1V.  The bandgap is also used as the reference for the internal temperature sensor.  Although the datasheet says the bandgap can vary between 1.0 and 1.2V, I was curious to see how much it actually varied in practice.  I found many other people posting in forums looking for information on real-world bandgap measurements, but couldn't find anyone who tested more than one MCU.  Since I have several ATmega328p MCUs in my electronics collection now, I decided to take some measurements.

I used the technique mentioned on Martin's blog of setting the ADC reference to the internal bandgap reference, turning on ADC, and measuring the voltage at the AREF pin.  Here are my results, taken at an ambient temperature of about 20C, and using my 0.1% calibrated meter.
Pro Mini #1 (qfn): 1.045V
Pro Mini #2 (qfn): 1.058V
Generic Uno (qfp): 1.055V
Nano (qfp): 1.089V

I also measured a Pro Mini 168pa, and found it had a much lower reference voltage of 0.994V.  With the measurements being all much lower than the "typical" values from the datasheet, I wondered if I might be affecting the voltages by measuring them.  Searches for information on the output impedance of the bandgap reference were fruitless, though I did find a stackexchange discussion about the 32KOhm pulldown for the ADC reference.  So to get an idea of the output impedance, I measured the voltage with and without a 1.4KOhm external pulldown.  The AREF voltage dropped by 6mV, so even a meter with 1MOhm input impedance would affect the voltage reading by less than 10uV.

While I only have four samples (five counting Martin's), I would say that typical bandgap reference voltages are a bit lower than 1.1V.  I would also guess that if I had more samples, 9/10 would be within 3% of 1070mV.  If anyone has done their own measurements, please post them in the comments.

I've read a couple forum and blog posts about calibrating the bandgap reference to a known VCC, but haven't seen any code.  With oversampling, it would not be difficult to measure the bandgap within 1mV (0.1% accuracy).  I could use the same technique of using init sections that I did with the internal temperature sensor, so this will likely find it's way on my list of projects to work on.

beta picoWiring Arduino compatible library

Before getting into the technical details, I'm going to start with a bit of history of Arduino.  No, I won't be talking the arduinogate dispute over who makes the hardware, it's the software I want to talk about.  From the way Arduino LLC's mouthpiece Marchese Banzi talks, he and his Arduino team came up with all the ideas that now many others have copied.  However the Arduino library was copied (or forked for those who prefer to speak git) from Wiring.  Wiring also took some ideas from MIT's Processing.  Although there have been a lot of changes to the Arduino library over the past four years, staying compatible with pre-1.0 Arduino has meant staying (mostly) compatible with Wiring.

I suspect if I had not mentioned Wiring, most people would mistake the above screenshot as coming from the Arduino IDE.  But it is actually Wiring 1.0.1.  Both Wiring and Arduino add a lot of code bloat and have examples of bad interface design, but I will use them for quick tests.  Between the two of them I prefer Wiring, since after the Arduino fork, Wiring implemented an optimized digitalWrite that is much faster than Arduino.

While it is the rare Arduino library that is well written, when it comes to testing new electronics the convenience of having something that works is worth holding your nose over the poor coding.  Although digitalWrite may not be the best way to abstract IO, it can be implemented efficiently as demonstrated by Wiring.  The same API can be used on the esp8266 with CHERTS or the esp8266 Arduino core.  For command-line development of Arduino code for the AVR Ino is an option, however the lack of optimization is still a problem.  Therefore I have written a library that has very little overhead and is compatible with the Arduino/Wiring API.

My goals were to make the library as small and as fast as possible, while supporting the ATmega168/328 series.  Since it has the fast digitalWrite, I started with some of the code from the Wiring AVR 8-bit core.  I removed the millis() timer, and implemented delay() using _delay_ms.  I modified the SPI class so it is a static class - instance variables unnecessarily take up memory when only one instance of the SPI class is created.  The Serial class took a lot of work to minimize.  Like the SPI class, I removed instance variables to make it a static class AKA singleton.  The AVR UART has a hardware FIFO, so removed the software FIFO the Serial class was using.

I've posted the code, which I still consider beta, to my github account.  I've done some testing with my (beta as well) piggy-prog project.  Both picoWiring and my dmbs fork are git submodules, so I can easily keep piggy-prog synced with bug fixes and improvements to picoWiring.  For piggy-prog, the code size improvement is significant.  Building piggy-prog with the 1.6.3 Arduino IDE results in a program that requires 4.5KB of flash.  Compiled with avr-gcc 4.9.2 with picoWiring, the flash size is just 1772 bytes.

Parasitic capacitance of AVR MCU pins

Parasitic capacitance of MCU pins is not something I've seen discussed much.  Look in the electrical characteristics of an AVR datasheet, and you can find input current leakage, but not parasitic capacitance.  Over a year ago I did some experiments to see how long a floating pin would stay high after switching from output high to input mode.  The result, which is a factor of both leakage and capacitance, was in the tens of seconds.  Now that I have a Rigol 1054Z, I can do some tests to try to specifically measure the input capacitance.

The above screen shot shows the rise time of an unconnected pin on a Pro Mini with the internal 35K pullup enabled.  The Pro Mini has female headers attached (much like the full-size Arduino), and running some simple code that toggled the pullups for PORTB.

The RC time constant means that a capacitor will charge to 63% in R*C seconds.  So a 1 Farad capacitor charging through a 1 Ohm resistor will take 1 second to charge to 63% of the input voltage.  I'm running the Pro Mini at 5V, so 63% of that is 3.15V.  The Pro Mini pin takes ~700ns to reach just over 3V.  Knowing that the internal pullup on the AVR is 35K, we start with 35K * C = 700ns, and solve for C to come up with 20pF.  I've read that 10pF is a typical value for IC pins, so something probably isn't right with my 20pF measurement.  After a bit more searching through datasheets I found table 29-19 of the ATmega328p datasheet, in the TWI section, which says 10pF max.

I tested an Arduino Nano compatible board with no headers attached that used a QFP ATmega328p instead of the QFN chip used on the Pro Mini.  The measurements equate to a parasitic capacitance of about 25pF.  A second Pro Mini with male headers measured at 20pF, indistinguishable from the first Pro Mini.

After a bit of pondering, I realized my scope probe is going to have some capacitance, and after digging out the spec sheet for the Rigol RP2200 probes, I found a specification of 17 +- 5pF.  So it seems most of the 20pF capacitance I measured is from my scope probes, but I wasn't sure how much.  My next idea was to test an 11K resistor connected to a pin on the Pro mini which cycled between output high and output low.  Here's the screen shot from the end of the resistor that was left floating:

Measuring the 63% rise time and solving for C this time gives 14pF for the capacitance.  This means at least 6pF of the previous 20pF measurement is the parasitc capacitance of the AVR pin.  The measured 14pF consists of the probe capacitance plus the parasitic capacitance of the resistor, so there is still the problem of measuring one or the other.  You may notice the sharp 4-5ns rise at the beginning before the rise turns into a steady logarithmic curve.  After seeing it on my first measurement, I repeated it to make sure it wasn't a glitch.  This EDN article explains that resistors are complex components with inductance, capacitance and resistance.  Charging of the small series capacitance of the carbon resistor I used may explain this initial fast rise.

Back to the problem of measuring my scope probe capacitance, I found a pdf document from Keysight that offers the simple solution of attaching two probes and comparing to the measurements from one probe.  I attached two probes, solved for C again, with a result of 27pF this time.  The 13pF increase should be the probe capacitance, with 1pF from the resistor lead.  The EDN article said resistors with 1/4" leads have a capacitance of 1-2pF, so the 1pF measurement from the resistor I used (with 10mm leads) is reasonable.

Taking 13pF for the scope leads from the 20pF measurement of the QFN AVR pin gives a net parasitic capacitance of about 7pF.  The measurement from the Nano with the QFP chip indicate a net parasitic capacitance of 12pF.  Considering the datasheet specification of 10pF max per pin for the ATmega328p, the extra capacitance on the nano likely comes from the board design, as things such as the distance between traces and a ground plane can affect capacitance.  For the chips themselves, both QFP and QFN, the parasitic capacitance is lower than 10pF, perhaps as low as 6-7pF per pin.

$2 esp8266 4MB ESP-12-E module

One of the recent goodies to arrive in the mail was a new esp8266 module.  When I ordered it, the price was 208c, but as of the time of this writing it has gone up.  Although it is advertised as an ESP-12-E module, the module I received is labeled ESP-12-Q, as can be seen in the photo above.  Other vendors are selling the same modules for 201c now.

One of the reason I ordered the module is because I intend to test the ADC function, and the ADC pin is not broken out on my ESP-01 module.  The other reason is that I read a couple postings from people that had received ESP8266 modules with a larger 4MB flash instead of the 512KB flash typical of the first ESP8266 modules released.

Since the modules have pads at 2.0mm spacing, I made an adapter board with some protoboard.  I just hot glued the module to the protoboard, and soldered short wires from the pads to the 0.1" spaced pin headers.  It is a bit more tedious work than using one of the pre-made adapter boards on the market, but I didn't have to wait for an adapter board, and my solution leaves more available space for connections on a breadboard.  Aside from the wire connecting EN with VCC, the rest of the connections are wired to the respective protoboard header pins.

After connecting power and Tx/Rx to a USB-TTL module, and pulling down GPIO15 to ground with a 1K resistor (to select boot from serial flash), I opened a terminal program to 9600bps, pulsed the reset line with a brief 1K short to ground, and got the following output:
NodeMcu 0.9.6 (Doit.am Version) build 20150701  powered by Lua 5.1.4

ESP8266 Started
Start soft AP
>

I also did a wifi scan with my phone and found an SSID named DoItWifi.  Since eLua was pre-flashed to the module, I could easily check the flash size with the node.info() function:
> =node.info()
0       9       6       16398478        1458400 4096    2       40000000

The 4096 indicates 4096KB (4MB) of flash.  The 512KB of flash on the ESP-01 module had been enough for the kind of progams I was writing using esp8266/Arduino, but now with a 4MB module I have plenty of memory to start experimenting with the ESP RTOS.

I measured the power consumption of the module at idle and with a wifi client connecting.  Idle consumption was consistently around 60mA, and with a wifi client connecting power consumption was around 90mA with a couple peaks to 140mA.

With this module I also decided to do some tests on the boot modes.  While the boot modes are reasonably well documented, there is little documentation on the default state of GPIO0, 2, & 15 at boot time.  This posting on the espressif bbs states they all have weak pullups, and my testing confirms this.  I held reset low with a 1K resistor to ground, and measured the voltage on the pins.  TXD0, RXD0, GPIO0, 2, & 15 all read 3.26V, while GPIO4 & 5 were 0V.  Connecting a 10K resistor to GPIO0, 2 & 15 caused the voltage to drop to 0.8V for each of them.  Calculating for the voltage divider ratio results in an internal pullup resistor value of around 33K Ohms.

I also tested the pins after booting from the on-board flash.  GPIO15 was low, GPIO0 was still pulled high, however GPIO2 was in output high state (a 10K resistor to ground resulted in a voltage drop of less than 100mV).  I also did some tests without GPIO15 pulled low, which, according to the documentation, should put it in the boot from SD card mode.  Every time I reset the module without GPIO15 pulled low, the module started outputting a 26Mhz signal on GPIO0.  Some googling indicates that this is what some people are calling the "zombie" mode.  Perhaps all that is required to avoid the zombie mode is to ensure GPIO15 is pulled low.

The final thing I tested was the deep sleep wakeup pin, GPIO16.  By connecting this to RST, it is possible to reset the module out of deep sleep.  I had previously tried connecting GPIO16 to RST on a ESP-03 module, but then had problems resetting the module.  The module was faulty in other ways, so I wasn't certain of the problem.  With the ESP-12-Q module, GPIO16 is driven high during reset and after reset.  Perusing the ESP8266 GPIO control files in the SDK indicates that GPIO16 does not have an internal pullup available, explaining why it is in output high mode.  This means that in order to be able to manually reset the module, a diode or a resistor of about 1K should be used between GPIO16 and RST.  Otherwise connecting RST to ground with a 1K resistor will not result in enough of a voltage drop to reset the module, and a dead short from RST to ground could result in enough current through GPIO16 to damage the chip.

With the 4MB ESP modules available for $2, I think they will now be my preferred choice for projects requiring an MCU.  The modules use too much power to work from a CR2032 coin cell, so for such things I'd likely use an AVR.