5 ms·
One other way to observe these steps a bit more clearly is to look at the startup code provided by a chip's manufacturer or generated by an IDE that targets the
by leggomylibro 8y ago
One other way to observe these steps a bit more clearly is to look at the startup code provided by a chip's manufacturer or generated by an IDE that targets the chip, such as Keil.
Most will put this type of code in '.S' startup assembly files, which often also contain information like the memory addresses for hardware interrupts to use, and linker scripts for telling the compiler about the memory available on the chip.
For example, ST's 'CubeF0' package has some example projects for their simpler ARM chips:
http://www.st.com/en/embedded-software/stm32cubef0.html http://www.st.com/en/embedded-software/stm32cubef0.html
I think that it is good practice with microcontrollers to tell GCC not to include generic startup logic in order to ensure that you are doing the right thing for your particular chip, by using flags such as --specs=nosys.specs, and even -nostdlib with -lgcc and -lc only if necessary.
- monocasa 8y agoIt's not just "good practice", but instead the startup code is so specific to the platform that there really isn't "generic" startup code.
- makomk 8y agoThe generic compiler-provided startup code is fine for AVRs under most circumstances, since they're only produced by a single manufacturer and don't have fancy features like PLLs which need to be initialized. It's the more complicated chips where it gets a little hairy, especially if you have to deal with things like external RAM.
- monocasa 8y agoI guess I rarely see the case for an AVR when you're not prototyping on an Arduino. You can get chips that are an order of magnitude more powerful per $/watt/and any other metric you'd want to use.
- Bromskloss 8y agoHave you read "The Amazing $1 Microcontroller" [0], which might have been posted here before? It's a survey of available microcontrollers, with the intent of helping you choose one. If you have read it, are you in agreement with the article, for example on how AVRs compare to others? [0] https://jaycarlson.net/microcontrollers/ https://jaycarlson.net/microcontrollers/
- monocasa 8y agoYeah, he put a lot of work into that, and I love that he published all of the information. My biggest complaint though is that he expresses GPIO cycle time and interrupt latency in cycles, rather than normalized on real time. Particularly when comparing a STM32F0 to an AVR, the perf looks almost even, until you realize that the STM32F0 is clocked 2.5x faster.
- Bromskloss 8y agoGood point. Have you, or someone else, mentioned this to the author?
- kevin_thibedeau 8y agoLow latency IO and computational performance isn't always needed.
- monocasa 8y agoIf it's not, you can drop the cost. There are AVR like 8051s that you can get for 10 cents.
- thethirdone 8y agoI can't find any 8051 less than 30 cents and I digikey sells attinys for 17 cents.
- 8y ago
- emilfihlman 8y agoThere actually isn't any reason STM or NXP or whatever ARM vendor couldn't provide AVR-like usability and awesome libc. For example the assembly blobs used on most STM32s are very simple. It's simply that they want to push people to their propietary IDEs (to increase vendor lock in). STM used to provide an okayish libc implementation but then decided to bury it inside CUBE (MX). If your design becomes complicated enough sure go ahead and change the startup code. But that's quite a small portion of all uses and for those we should have AVR like ease of use.
- monocasa 8y agoThe choice of board support stuff like crystal frequency is stuff that needs to be tweaked per board really early in the boot process.