First hints of forthcoming troubles with insufficient FLASH memory size of the STM2F103CB MCU’s started to peek out near the end of the last year’s season. With the ongoing development of new features my experimental CUBE was running short of program storage. With such expansion the codebase was about to hit the memory ceiling by the end of the year at the latest. Some thoughts were already thrown in the direction of yet another change in architecture design and which MCU shall all the existing code be migrated to. This is a story of the core MCU transition that took place during the last Xmas and spanning long into new years’ days.
As mentioned earlier in one of the previous posts the first OGN CUBE tracker prototype was born on then the all-possible-requirements-fulfilling 8-bit Atmel’s ATMEGA8-16PU RISC microcontroller. Five(!) years ago I managed to squeeze a working tracker code to 8 kB of FLASH and incredible 1024 bytes (BYTES!) of SRAM – a feat I cannot imagine today anymore. Very shortly, however, MORE memory was needed. Hence the first migration naturally went to ATMEGA328P – now widely known as the “Arduino” chip. Just imagine the unlimited possibilities of four times as much of FLASH a twice as much RAM! 32K Ought to be Enough for Anyone, right? 🙂 Well, not really but this tracker still proudly flies across the skies bearing the livery ‘PK‘.
The third migration was natural – I already had some experience with the STM32 ecosystem (F042 and F303 in particular), own stable set of SPL I/O libraries and also some hard time with HAL (which I strongly recommend to avoid). Hence it had to be a chip with a bright future, SPL support and some other reasonable parameters. After a long thought oscillation and numerous coin flips, the CUBE’s heart became the ubiquitous STM32F103CB IC, mainly due to its availability (at that time I even had no idea the other OGN trackers were based on the STM32F103C8). With 128kB of flash (C8 has only a half of it) and 32kB of RAM new way into bright future was paved. Are you now asking what was the other option? Wait for it..
The first Überraschung peeked out already after the first successful compilation – the binary size for equal code was twice as much in size on ARM as on the good old AVR MCU! It was a luck the -CB had been chosen instead of the -C8. But also during this new ‘ARM age’ the code was growing in size. Some optimisations had to be applied and features taken off – like for example the little-fs based SD card flight logging. The remaining FLASH was considerably quickly running out. But I am not indicating the ARM period is over 🙂
With new support of the other protocol B-) next huge leap was inevitable. Well, but in which direction? I needed the same footprint (LQFP48; the PCBs were already made) and ideally something from ST with SPL support (which is unfortunatelly left orphaned with their new MCUs), mainly because using HAL is a quick shortcut to HELL. Or .. could I possibly tease my imagination a little bit more?
Nordic’s NRF52 seems to be very popular with some folks. This bluetooth-equipped chip would also let me to throw away the standalone bluetooth module and save some power & space! But the ecosystem looks a bit odd to me. MSP430 from Texas Instruments? For some completely unknown reason I am being attracted to this micro but no, this would probably be a step in a wrong direction. A PIC? Oh, come on! (do you remember the Microchip vs. Atmel wars? B-) ) What about ESP8266? Not enough I/O. ESP32? FCC certified, a bit more I/O pins (still not enough), with on-chip/module Wi-Fi & bluetooth would be fantastic .. but its power consumption? Oh man! Something with RISC-V? There is nothing really useful and ‘production ready’ out there yet. And last but not least – what do you think about Teensy? .. it was getting wild! 🙂 But even after all these daydreams the CUBEs will have to remain in marriage with ST. It’s not a bad micro after all, really. So I went on a shopping spree..
One of the long-lasting temptations was to migrate to higher-end ST micros like the L4 (no SPL support ;( ) or F4 (SPL supported, with a floating-point unit, how sweet!). At the same time reduction in power was also one of my strong requirements. Unfortunately, they don’t make F4s in LQFP48 with 256kB of FLASH. Bugger! I had spend so many nights and even more spare time with the ST’s MCU Finder app (which has so much potential but they cannot keep it working reliably between updates; shame to you, ST!) until the final and only choice went to the same chip as two years ago when then eventually picking F103 – the STM32L152CC. It sports 256kB of FLASH, clocks up to 32 MHz (which is still ~ ok), 32kB RAM, some EEPROM to store user configuration and hopefully also some longer future 🙂
After an entire month (mostly December) of porting the code to the L152 (there really are some nasty differences and not only the the SPL; feel free to compare the block diagram of the MCU with the F103 in the datasheet) and hunting down the very last quirk in the I/O timings I can boldly announce the new MCU of choice for the oncoming OGN CUBE generation is the ST’s L152CC!
Long live the chip! 🙂