3 ms·

Not knowing for this particular device, but generally for MCUs? Install a manufacturer-specific toolchain, often based on some minimally changed Eclipse IDE an

Not knowing for this particular device, but generally for MCUs? Install a manufacturer-specific toolchain, often based on some minimally changed Eclipse IDE and gcc, Write your software in as old a C dialect you can, sprinkle some generous helping of assembly in. To know which registers to use, dig through thousands of pages of documentation, some more, some less helpful. Most functions are just accessible by flipping bits in specific registers. Afterwards, build the software and flash it with a dongle on it, then run the code. For debugging, you mostly have SWD or JTAG which allows you to poke and change at all registers and any memory, and stop the code when and wherever you want. Which is desperately needed, as most MCUs are riddled with weird edge cases and undocumented behavior. Source: Development on ATmega, STM/SPC

tormeh 4y ago
Can confirm. Embedded development (this sort of development) kinda sucks, IMO. It has a certain sort of simple old-school charm, but it's mostly pain, although opinions probably differ.
- mindslight 4y ago
  Maybe I've just got rosy memories, but small microcontroller development felt a lot nicer than large microcontroller development. For PIC development, you could (and would) be in touch with the entire code base, precisely allocate how your interrupt(s) were used, know exactly how the hardware was configured at the bit register level, etc. Whether to use a multitasking system was a choice depending on the project, as was using a C compiler. If you did use a C compiler, you generally knew how your code was going to translate to assembler. Especially when you were writing routines where the cycle count mattered (interrupt routines, bit banging, processing throughput, etc) The first thing I saw looking at STM32 land is a whole heap of suggested manufacturer libraries that do who-knows-what behind the scenes. The timing properties feel more like using a general purpose OS rather than always having deterministic control over what the CPU was doing. The peripherals are still documented at the register level, but the scope is much larger and it seems you'd be likely to run into undiscovered errata if you attempted to use them in a different way from the manufacturer libraries. Maybe I never got familiar enough with STM32 to appreciate and really understand it. That project was several years back and I got interrupted and have yet to return. I especially look forward to seeing what the Rust community has enabled on ARM microcontrollers in the mean time - I feel like there's a lot more hope for sanity on a ground-up implementation, rather than leaning on whatever the manufacturer dumps. And obviously modern languages are sorely needed, rather than C being considered the "high level" option. But if I were going to start a hardware project today that needed to be reliable, I'd likely still base the core around an 8-bit micro (probably AVR to go with the flow), with an ESP32 as an afterthought for wifi connnectivity.

tormeh 4y ago

Can confirm. Embedded development (this sort of development) kinda sucks, IMO. It has a certain sort of simple old-school charm, but it's mostly pain, although opinions probably differ.

mindslight 4y ago
Maybe I've just got rosy memories, but small microcontroller development felt a lot nicer than large microcontroller development. For PIC development, you could (and would) be in touch with the entire code base, precisely allocate how your interrupt(s) were used, know exactly how the hardware was configured at the bit register level, etc. Whether to use a multitasking system was a choice depending on the project, as was using a C compiler. If you did use a C compiler, you generally knew how your code was going to translate to assembler. Especially when you were writing routines where the cycle count mattered (interrupt routines, bit banging, processing throughput, etc) The first thing I saw looking at STM32 land is a whole heap of suggested manufacturer libraries that do who-knows-what behind the scenes. The timing properties feel more like using a general purpose OS rather than always having deterministic control over what the CPU was doing. The peripherals are still documented at the register level, but the scope is much larger and it seems you'd be likely to run into undiscovered errata if you attempted to use them in a different way from the manufacturer libraries. Maybe I never got familiar enough with STM32 to appreciate and really understand it. That project was several years back and I got interrupted and have yet to return. I especially look forward to seeing what the Rust community has enabled on ARM microcontrollers in the mean time - I feel like there's a lot more hope for sanity on a ground-up implementation, rather than leaning on whatever the manufacturer dumps. And obviously modern languages are sorely needed, rather than C being considered the "high level" option. But if I were going to start a hardware project today that needed to be reliable, I'd likely still base the core around an 8-bit micro (probably AVR to go with the flow), with an ESP32 as an afterthought for wifi connnectivity.