-
This was mainly because many FIFOs had strange policies when it came to bytes received with framing errors (which is what I use to detect the start of frame for DMX-512).
Oh, yeah, been there, done that!
Definitely something you need to test as it's rarely mentioned in the datasheet.
ISTR some particularly fun times with a NXP part that had seperate ints for UART receive and UART errors, which only manifested with one Artnet device that put the break immediately after the last byte, so it ended up somewhere in the FIFO.
Latency on a FIFO's UARTs is very rarely an issue in practice - what I find more annoying is UARTs like the PIC32 which don't have a timeout mechanism to empty the FIFO at the end of a burst of data, so you end up needing to dedicate a hardware timer to do it.
-
For those impatient, looks like there's an archive.org copy of the long article / website here : https://web.archive.org/web/20171106070102/https://jaycarlson.net/microcontrollers/
-
Amazing
I have some render issues though (firefox 56.0.2 under win 7 pro, 1920x1080p)
as a long time PIC afficionado i'll make one note for the article:
for the PIC18F, the "K" series is the one which is actually being developed. the K42 and K83 families (the most recents, came out this year) are the real BEASTS in terms of PIC18 (DMA, vectored interrupt, fully routable PPS, more memory, 12 bit adc with good ENOB, channel scan, digital filters etc., the K83 also has CAN compared to the K42)
(and of course everything is pin-to-pin compatible between families.. from different PIC16s up to dsPICs, but with some minor adjustments from 8bit to 16 bit
)
-
It's a big thumbs up, I think you should have added the 1$ cortex M3 parts like STM32F103RBT6 to the list too, it would be more fair then
-
In case anyone was wondering if I ever got around to finishing this write-up, the answer is "Yes! Finally!"
Check out The Amazing $1 Microcontroller on my blog.
Great report! And nicely presented too. The overall impressions are similar to what I have got from personal experience or reading other people's experiences. It would be nice to see a ranking by price, even if rough/relative guidance. I have reasonable flexibility to select parts based on dev tools, IDE etc, but price is the #1 for the operations manager.
A couple very minor typos "choke-full" => "chock-full", "weary" => "wary", although the homophones are appropriate too. -
ISR latency is caused by prologue code (especially heavy on stack-based parts like AVR and Arm), core design, but also peripherals.
Prologue code is 80% (if not more) of the latency. So, the latency measurements are mostly the measure of efficiency of C optimizations of the particular compiler. BTW: toggle times too, to certain degree, evaluate the C compiler quality.
The UART module, if it includes hardware FIFO between the receiver and the MCU core, will produce interrupt not when the character is received, but when it is placed into FIFO, which comes later. So, ideally, if you want to measure interrupt latency per se, you must start your measurement from FIFO (which is not really possible). -
Congratulations on such a huge undertaking!
I noted that you included a Code Generator section. Do folk really use these for production code? OK, when you need to use complex peripherals, like USB, for some devices it’s the only thing the vendor offers, but for more mundane peripherals like SPI, I2C, UARTs, PWM, really? You’re going to have to understand the device at the peripheral register and hardware level anyway, so what value do they add perhaps beyond short term instant gratification?
The two I have the most experience with by a long chalk are Microchip’s MHC and MCC. Both are bug ridden, and both make code incredibly difficult to maintain as the programmer’s business logic (and code genrator bug fixes) are mixed in with the generated code. So if you change, say, a pin assignment, it regenerates the code and you risk it stamping all over your own code. Moving between versions often means you have to start from scratch too. I also despise the proprietary straightjacket directory and file structure it places you under.
Maybe others have better experiences of Code Generators than I do? -
I'm wondering why there is so much difference between the performance of STM32F0 and the LPC811. Given the small difference in clock frequency I'd expect them to be much closer. Is this due to compiler optimisation perhaps? What would be an interesting addition to this test is a comparison of code density and speed between the various compilers.
-
An awesome work! Thank you!
Not being a fanboy of PSOC myself, I tried to implement the 1wire master in UDBs in my spare time and went low-level on PSOC. Actually, the registers datasheet is public ("Register TRM", about 5500 pages!) and the bitstream is actually just an array of registers, not a black box. Getting to the bottom of it to understand what is where took about 1 week of evening reading. Each UDB has some registers in the configuration space and some in runtime space. But this is so complex, that the uc would be of very little use without the psoc creator software, developing on that without tools would be a nightmare. Also, the definitions of the runtime registers depend on the configuration set up at boot and thus the register datasheet is quite useless without decoding the inner workings of the generated peripherals (simple for SCB, a lot of reverse engineering for UDB). In addition, nothing stays put in that chip, things can be re-routed differently and absolute addresses are useless; at least have to use the auto-generated defines made by the placer. All in all, pretty useless going low level unless there is a niche application, that needs some kind of tricky interface and FPGA would be too large.
-
I'm wondering why there is so much difference between the performance of STM32F0 and the LPC811. Given the small difference in clock frequency I'd expect them to be much closer. Is this due to compiler optimisation perhaps? What would be an interesting addition to this test is a comparison of code density and speed between the various compilers.
In my testing, I discovered the big problem with the LPC811 is the lack of a flash accelerator/caching mechanism (or if it has one, it's not very good). Flash memory for these parts typically tops out at 25 MHz, so the nice 48 MHz Arm parts all have good caching capabilities (IIRC, the SAM D10 and Kinetis KL03 were the best, but the STM32F0 did well, too).
If you ever want to see if that's what's going on, reduce your core clock speed and count cycles — if your code magically takes fewer cycles at slower clock speeds, look at flash wait-states.
The higher-end LPC parts are lovely to work with — but I was stuck reviewing bottom-of-the-barrel parts due to the $1 price constraint. I like MCUXpresso a lot, and the NXP folks are helpful to work with — especially for start-ups/small players. I just wish they had some better entry-level parts.
Infineon, for what it's worth, has equally-bad (if not worse) flash-constricted performance on the XMC1100 — but the part has 16 KB of RAM, so you can just decorate your ISRs and any other performance-critical work with "place in RAM" attributes, and you'll be running at full speed — and with excellent power consumption. -
Congratulations on such a huge undertaking!
Thanks! Glad to see people are learning and starting conversations from it.I noted that you included a Code Generator section. Do folk really use these for production code? OK, when you need to use complex peripherals, like USB, for some devices it’s the only thing the vendor offers, but for more mundane peripherals like SPI, I2C, UARTs, PWM, really? You’re going to have to understand the device at the peripheral register and hardware level anyway, so what value do they add perhaps beyond short term instant gratification?
In my experience, I see start-ups and R&D teams using code generators all the time, because they're not an "Atmel shop" or an "Infineon shop" — and, for small-volume or R&D work, code generators let you get quick access to the stuff you selected the part for (say, the PIC16's NCO/CLC stuff), without having to futz around with UART baud-rate generator settings and clock-gating. This is especially true in the 32-bit space.
When engineering consultants can cost a company north of $200/hr, do you really want to pay an engineer to sit around and read datasheets, or do you want to use a slightly faster part that allows them to quickly build up the demo for the investors meeting?The two I have the most experience with by a long chalk are Microchip’s MHC and MCC. Both are bug ridden, and both make code incredibly difficult to maintain
I had admittedly limited surface-area contact with the code-gen tools in my review, but I didn't notice any outright bugs in the generated code for my DMX-512 receiver, which has to do UART, PWM, and any secondary function (pin muxing, clock gating, timer init, etc).
There are some design decisions I would probably change, but that's a give-and-take that different vendors land on.
The biggest bugs were with Atmel START on the SAM D10 — which didn't provide any modicum of error-checking, and statically displayed a "48 MHz" label under the DFLL, regardless of what it was actually configured to use.
As for the "hard to maintain" argument, the best code-gen tools had no issues with this. For example, Silicon Labs' Simplicity Configurator has no problems adding/modifying/removing ISRs in the same files that had my custom code. ST and Renesas, too --- albeit they cheat a bit and have comment blocks that define precise locations where you can and cannot put user code.
The worst offenders for what you were talking about were probably Microchip and Atmel — their code-gen tools seem incapable of merging their changes with custom-written code.
It sounds like you have experience with Microchip; one of my goals of this review is to illustrate how other ecosystems work, so people don't accidentally generalize their understanding of a function across every possible product line.
For what it's worth, the most efficient (in terms of speed and/or flash) code for the DMX-512 receiver was generated by code-gen tools, compared to those from just standard runtime peripheral libraries.
Intuitively, it seems to make sense: runtime libraries have to calculate a bunch of crap that's known at compile time. Theoretically, the optimizer should be able to get in there and eliminate a bunch of that stuff, but in practice, this doesn't happen as much as you'd think.
A code-gen tool that just spits out a bunch of raw register writes in an init function for a UART is always going to beat a run-time UART initialization library that calculates baud-rate generator registers on the fly, for example. -
This guide is awesome. Thank you!
I spent a couple of hours today reading. I'm definitely going to come back to this next project I do needing an 8-bit MCU.
By the way, I noticed a problem with the standard peripheral library code example on the STM8 page. It has HTML mixed into the code in a couple of places, e.g.:Code: [Select]while (!I2C_CheckEvent(I2C_EVENT_MASTER_ADDRESS_ACKED));
I2C_ClearFlag(I2C_FLAG_ADDRESSSENTMATCHED);
I2C_SendData<sup id="footnote_plugin_tooltip_1" class="footnote_plugin_tooltip_text" onclick="footnote_moveToAnchor('footnote_plugin_reference_1');">1</sup><span class="footnote_tooltip" id="footnote_plugin_tooltip_text_1">u8)(ReadAddr >> 8</span>%MINIFYHTML9299bf39575ecf70dee23834ee18551524%; /* MSB */
while (!I2C_CheckEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED));
Looks like your footnotes plug-in has run amok. -
Looks like your footnotes plug-in has run amok.
Nice catch! Fixed; should be pushed out soon.
I thought the (( )) footnote parsing syntax was too good to be true, and now I know... -
Quote
Thanks! Glad to see people are learning and starting conversations from it.
Indeed. This is a much more impressive result than what I was expecting from the initial discussions!
-
It's a big thumbs up, I think you should have added the 1$ cortex M3 parts like STM32F103RBT6 to the list too, it would be more fair then
They are only $1 in Shenzen... Typical western SMEs are ordering large volumes via reputable distributors such as Avnet, Arrow etc, smaller volumes from Digikey, Mousers (or national equivalent). Ordering via AliExpress or Taobao for production stock is simply not an option for the companies I work for.
The code is available, you can always port it to a STM32F103 board and create a report. It would be interesting to know how much an M3 buys over a M0. My suspicion is that M0 is just a market positioning to compete with 8 bitters, if you take an M3 and run it at lower clock speeds it will be nearly identical to an M0 in terms of performance and power consumption. I understand the license fees to silicon vendors for M0 core design are ridiculously cheap. -
It would be interesting to know how much an M3 buys over a M0.
Under the hood, there are huge differences between M0 and M3.
For example M0 is Neumann architecture, M3 is Harvard.
M0 has 2 stage pipeline M3 has 3 stage, and their DMIPS is like 1.5 times higher.
Sure, this doesnt matter for flipping bits and sending stuff through UART, because if that is all you do, then it is easy, just use an M0. -
My light hobbyist foray into the micro world scarred me. Expensive programmers and crazy toolchains. I expected everything to be supported by GCC and programmable via a simple protocol atop UART.
Haha. Ha. Ha. Avrdude you have spoiled me.
I now want to try one of those STC8's 8051 sounds like a nice option simply because of the interchangeability. I'll also give LCSC a go.
funkathustra: thankyou for your investigations and your writeup. I've previously looked for 8051 parts and only found ancient low-stock microprocessors. You have cleared several clouds for me.
-
funkathustra,
BTW, all MSP430 FRAM devices are with 20-bit CPUXv2, with some 20-bit / 1 cycle (address) assembler instructions. They are also limited by FRAM wait states, but code can be copied to RAM and executed at full speed.
I didn't noticed on your (remarkable) page any data regarding flashing erase/write rate. It is more comfortable to work with devices with faster operations, and there is significant difference between vendors. For example, some reference can be found here...
https://www.segger.com/products/debug-probes/j-link/technology/flash-download/#tab-3145-1
-
A code-gen tool that just spits out a bunch of raw register writes in an init function for a UART is always going to beat a run-time UART initialization library that calculates baud-rate generator registers on the fly, for example.
I think my favourite method would be for these code generators to just give me a set of code on demand that I can copy and paste into _my_ directory and file structure, not theirs. I don't see any value in being nanny-stated into a generic "framework" which will always be a compromise, being too complex for simple projects, and unnecessarily prescriptive for larger ones.
A code generator that dictates a framework must be able to manage and separate clearly between user code and its own code, and deal with bug fixes to generated code, MCC doesn't do that well at all.
There are many bugs in MCC, the worst I've encountered was that it initialised a particular peripheral's registers in the wrong order. This is quite common, where you cannot legally change certain peripheral settings after it's been turned on, but the ON bit is one of the first things it sets. The particular scenario I had was a little more complex, but you get the gist. I'd also prefer that there was an option for the generator write code as bitfields or mask macros, rather than a series of opaque hex blobs that each might cover a dozen or so configuration parameters that are not easy to match up with the datasheet when you're trying to figure out why it doesn't work.
A particular problem that afflicts MCC is that newly adopted devices tend to be left to the community to test on behalf of Microchip, there rarely seems to be any testing of any sort done, it's not uncommon to be unable to even start the oscillator.
I had one a few days ago where it failed to disable the JTAG interface that was shared with a number of GPIOs I was using as status LEDs, as a demonstration for someone on how to use MCC, even though I'd warned against it. Had I written the code myself, this simply would not have happened, and even it had, I'd have had transparency and understanding rather than second guessing some half baked code.
-
I recall every week there is at least one person reporting bugs created by Cube MX.
@funkathustra
Great report but the "timer points" dont reflect on timers ability to IRQ/DRQ which could be considered equally important as having a CC channel. F4 for instance are plagued by crappy IRQ/DRQ assignment which makes even simple DMA sequencing a pain and in many cases impossible (conflicting GPIO assignments and or Timers dont have DRQ at all or are assigned on the wrong DMA unit).
Another important factor are "pin routing ability" PIC24 excels STM32 in many cases for instance, even the F0 is quite crap at this. Just my 1/2 cent! -
Another important factor are "pin routing ability" PIC24 excels STM32 in many cases for instance, even the F0 is quite crap at this. Just my 1/2 cent!
This is one of most important things to me. That any port /peripheral / analog signal can be routed to any device pin. And that one peripheral output (for example timer pwm) can be routed to multiple device output pins. Didn't found vendor that support this on Cortex M0 / M0+ / M3 / M4 devices. -
NXP does on their LPC1500 series. Then again being able to route pins to any I/O is highly overrated. The pins which belong together are usually grouped anyway so if you think a bit about the PCB layout while drawing the schematic you can come up with a good component placement and thus easely routable PCB design.Another important factor are "pin routing ability" PIC24 excels STM32 in many cases for instance, even the F0 is quite crap at this. Just my 1/2 cent!
This is one of most important things to me. That any port /peripheral / analog signal can be routed to any device pin. And that one peripheral output (for example timer pwm) can be routed to multiple device output pins. Didn't found vendor that support this on Cortex M0 / M0+ / M3 / M4 devices. -
NXP does on their LPC1500 series. Then again being able to route pins to any I/O is highly overrated. The pins which belong together are usually grouped anyway so if you think a bit about the PCB layout while drawing the schematic you can come up with a good component placement and thus easely routable PCB design.
No, it is not related to PCB layout. Let say that I am using one port (with 8 IO lines) in one short period of time like input/output, and in another short period of time as timer pwm output, and switching between two mods. I want to read / write with one assembler instruction from / to all 8 IO lines, not in 5 instructions because timer pwm outputs are distributed on 5 different ports (addresses). I am spoiled with TI MSP430F5xx family that have one port (8 lines) with all peripherals mapped on it. On TI MSP432 there are 3 ports (24 lines) with all peripherals mapped on it. Unfortunately, didn't found similar thing on low cost M0+/M3 from other vendors. -
I still don't get why you can't solve your problem with carefully selecting the I/O lines. I know NXP ARM devices inside out and they have the I/O pins on a few ports which are packed with pins (except for the last port).