2 ms·
The only thing that I did for STM32 was writing drivers for dual FLASH quad SPI external memory. Since I didn't know much about STM32 and there was no sample dr
by nec4b 6y ago
The only thing that I did for STM32 was writing drivers for dual FLASH quad SPI external memory. Since I didn't know much about STM32 and there was no sample driver for the flash chip I was using, CubeMX helped quite a lot. It still took me a good week to get it working.
Usually when developing a new platform for our products, I/we need to bring to life: SDRAM, LCD, touch controller, external flash for code and data, SD card + FAT32, USB, ETH, plus a bunch of other components (ADC, DAC, BT, other uC, latches,...) using the usual peripherals (UART, SPI, I2C, timers,...). Keil provides a good compiler and linker, fast JTAG debugger, RTOS and a bunch of middleware libraries (some are quality, some are lacking). While I dislike its IDE for writing code, it is a lot better than VS code for debugging purposes. It also supports flashing and erasing MCUs with internal and external memory, which sometimes requires special programming algorithms.
For us stability, tooling and good library support is the most important part of doing our job. Language follows from there. C and C++ have the advantage of the GNU/Linux ecosystem of open source to draw from and they map to the hardware almost perfectly.
On higher level systems (Android, Linux) we use higher languages (with GC) which have even nicer tooling and better libraries for writing application code.
- the__alchemist 6y agoNice. It sounds like the time sink there is writing drivers for a range of peripherals. The silver lining is next time you use that periph, it's easier.