just the fact that you mention that
my ARM chops are easily transferable to any number of other vendors
makes me wonder if you are serious.
You're of course right in that peripherals are not transferable between vendors. I was speaking more specifically about the architecture itself. My ability to debug and understand Cortex devices (and even "common" peripherals like NVIC) are transferrable between vendors. The debug interface (ETM/ITM if available) is also pretty standard, although admittedly it's very, very infrequent that I have to dig around in there.
In the case of STM they aren't even interchangeable between -some- families. You'll have to rewrite the code anyway, the lie that ARM was interchangeable between vendors so it was easier to migrate from one family to another was just a lie.
I don't find this at all. Anyone claiming that the peripherals are vendor-agnostic is a damned liar for sure, but I don't think I've heard anyone seriously claim that.
ST is by far the worst in this aspect. ATMEL, NXP and any other vendor is more consistent in peripheral configuration and libraries, microchip is the most consistent i could find. A project was ported from dsPIC to PIC32MX in mere minutes, everything was the same. only the atomic writes to registers such as interrupt flag clear were rewritten.
I won't argue that ST has had some issues between families (STM32L vs STM32F) but I really do think you're blowing it out of proportion. MOST of their peripherals are code compatible, and that has also gotten better as the family matures. There's almost no difference between peripherals between STM32F and H, for instance, and even *most* peripherals between F and L. There absolutely are some gotchas but they aren't very common.
It's been my experience that devices which are pin compatible are also code compatible.
Then STM documentation is by far the worst i've ever had to read. Incomplete, information scattered between part datasheet, peripheral manual, library manual, library example, errata and forum. For example, if you set up SPI by following the reference manual it won't work. the HAL initialiation function -which will work- has a slightly different sequence for peripheral initailizaition.
This is my exact argument with Microchip's documentation. I can't stand it. Nordic's is way worse, and NXP's somewhere between Microchip and STMicro IMO. I think that TI takes the cake when it comes to bad datasheets though, and Microchip appears to be taking notes from TI when it comes to "Let's publish each chapter as a separate file". This isn't the day of 2400 baud modems anymore. Give me one 3000 page reference manual and let me at it.
My biggest gripe with the STMicro docs is that the pin muxing is up at the front of the datasheet, and the peripheral documentation is in the RM. I wish the muxing were duplicated in the RM, but understand the demarcation point.
As far as HAL documentation -- I've never ever looked at it. It's horrible. For someone not familiar with HAL it's by far the worst part of it. With experience I understand how the naming and call conventions work, and for anything more specific I literally look at the source. I do *not* claim that this is a good thing, but it is fast once you understand the library.
Then ST Link was no better than ICD or even PK3, Eclipse based IDEs were always a thorn in my foot. A pain to work with.
i can't comment on IAR or Keil of course, but i like MPLAB X waaaaaaaay better than any free IDE based on eclipse or visual studio.
STLink is garbage. JLink all the way. I fought against JLink for a long time because it was closed and proprietary but man it's nice to have a system that just works. I hate IDEs as a general rule, and Microchip practically forces you to use their Eclipse/netbeans/whatever based garbage.
propertary compilers? hello? XC16 and XC32 are GCC. the stupid "license" is bypassed with a simple txt file (kudos to the EEVBLOG member who found out how to bypass the license without patching the compiler) but still, comparing -Os with -O1 (which is available on the free version), the negligible performance improvement in -Os is outshadowed by the easier debugging offered by -O1. very critical sections are always assembly anyway.
-Og is ideal for debugging. I'm aware that Microchip uses a closed fork of gcc for xc16 and xc32, which is my complaint about it. You're selling me the chips, you don't need to make money off me for the tools as well. 100% agreed on critical sections being assembly.
the only peripherals that are better on STM are FSCM and MIPI. the rest? microchip is probably the most flexible... in the ADC, DMA, PWM, CLC, almost anything.
I think the peripherals are comparable, and on the parts with DMA most of these tasks can be automated with very little or no CPU overhead at all. This is actually one area where Nordic has them all beat: Peripherals generate events and accept tasks, and another peripheral called the PPI can be used to connect any event on any peripheral to any task on any other peripheral; the CPU can be completely shut down and asleep for a long time. Some peripherals have internal "short circuits" (Nordic's term) to connect an event from a peripheral back to a task on the same peripheral as well.
STMicro has a lot of this same inter-peripheral functionality between their timers and other peripherals, and IMO their timers are one of the best implementations I've come across on any MCU, almost to the point of being overwhelming to configure.
Microchip has come a long way in terms of pin muxing, way better than ST for sure; Only Nordic and Cypress have them beat as far as I'm concerned.
the parts? a STM32 with the same peripherals than a dsPIC will cost at least the same, if not more. It will give me a lot more headaches because of crappier documentation.
Also, i can get a dsPIC with 15 IC and 15 OC, USB, dual CAN and a bunch of PWMs which i will all use. find a STM32 part that has all of that, for less than double the price. and that in a real world scenario has the same performance. i don't expect an answer because i couldn't find it.
on an STMicro, 30 timer channels for capture and compare would have to be done with 7 or 8 timers, depending on specifics. Adding PWM on top of that would increase the timer count as well. Perhaps dsPIC's archtecture has more channels per timer, but USB and dual CAN is hardly difficult to find in their product family. My use cases are generally more about simultaneous ADC, usually with CAN or ethernet and some IC/OC/PWM. A quick look at the dsPIC family seems to indicate that it's all 16-bit data path and significantly smaller amounts of RAM compared to even the smallest STMs.
At the end of the day everyone's got their own favourites and priorities. I am happy that you took the time to write about yours. I enjoy learning about others' experiences. No vendor's perfect and I appreciate the candid discussion. :-)
Home
Help
Search
Login
Register
