-
I am not allowed to share the real numbers, and the negotiations were back in 2018, so worthless now.
I shared the results from back then , take it or leave I don't care if you believe me or not, I know what I know.
Currently with the chips shortage all bets are off and you may be thankfull to get any allocation.
-
I am not allowed to share the real numbers, and the negotiations were back in 2018, so worthless now.
I shared the results from back then , take it or leave I don't care if you believe me or not, I know what I know.
I believe you (personally). You negotiated very good price with ST. Is it possible that if you negotiated with a different vendor (or vendors) you would get even better price?Currently with the chips shortage all bets are off and you may be thankfull to get any allocation.
So true. It's hard to predict prices (or even availability) when the shortages are over.
-
I believe you (personally). You negotiated very good price with ST. Is it possible that if you negotiated with a different vendor (or vendors) you would get even better price?
For arm cortex M3 and M4 cores (f2 and f4) we were not able to get better prices from other vendors. You have to understand that with these large procurements of half a million chips every $0.01 is $5000
For the f0 we did get a good deal with Atmel however after Microchip aquired Atmel the prices were almost doubled
-
There is a lesson here somewhere, about SUPPORT.
I don't know how good or bad the current STMCube stuff is. I looked at STPLIB a long time ago (~2014), and then I think the first HAL library. Both were significantly unimpressive: bloated, poor code, incorrect code, not substantially readable, etc. (You can see one specific complaint here: https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg516710/#msg516710 (and some more following in that thread.))
And then there was a NEW ST library. And another new one. And in between the initial impressions and the "churn", I have been unmotivated to see if things have gotten any better. (ST isn't the only guilty party. Atmel did libsam->asf->start, with similar complaints.
I think that means:- The first released version of what is supposed to be a vendor library needs to be very good. It should be largely correct, make sense from an abstract point of view, and not produce horrible code. (this, of course, is difficult. I think HW vendors specifically tend to underestimate just how difficult it is.)
- Support - fixing bugs, improving functionality, and broadcasting info about what has been done - needs to be very aggressive, especially early in the release cycle. The answer to "your BRG divisor calculation sucks; here is better code" ought to be "thank you; we've replace our code with your suggestion", not "There will be a new library soon. Maybe we'll fix it then."
- Libraries are a product (whether they "generate income" or not.) You need customer input on how they should look. And testing/evaluation across all of your target markets.
- Churn is bad. Abandoning older versions is worse. Design your APIs REALLY CAREFULLY.
-
For arm cortex M3 and M4 cores (f2 and f4) we were not able to get better prices from other vendors. You have to understand that with these large procurements of half a million chips every $0.01 is $5000
For the f0 we did get a good deal with Atmel however after Microchip aquired Atmel the prices were almost doubled
I've never came across such volumes
-
" every $0.01 is $5000 "
That way of looking at life is going to lead to a disaster.
The same company will be shafting its suppliers, with an aggressive buyer who (metaphorically) bangs his fist on the table while threatening to terminate the relationship unless there are NO price increases, ever, not even 0.1%. This is while the company is buying a $50M private jet. Ask me how I know
It will also be a really sh1tty company to work for, at every level.
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
Anyway, a digression from ST Cube IDE bugs
-
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
This is absolutely not the case. The biggest companies out there negotiate fractions of a cent, not just a cent. And smaller companies wish they can do the same. And yes, it is better to negotiate a smaller price and buy a jet on the saved money than just give away the price of a jet just just because you were to lazy to negotiate a better price.
If you are a car maker and you need 200 MCUs in a car, then every cent start to matter.
And MCU is not the only thing in the system. Once you are done with "one cent does not matter here" tactic, your board is a few dollars more expensive all of a sudden. -
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
This is absolutely not the case. The biggest companies out there negotiate fractions of a cent, not just a cent. And smaller companies wish they can do the same. And yes, it is better to negotiate a smaller price and buy a jet on the saved money than just give away the price of a jet just just because you were to lazy to negotiate a better price.
If you are a car maker and you need 200 MCUs in a car, then every cent start to matter.
And MCU is not the only thing in the system. Once you are done with "one cent does not matter here" tactic, your board is a few dollars more expensive all of a sudden.
+1 on this one, fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM. -
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
That was how I saw it once and I understand your way of thinking.
I also then had the impression, why not buy the biggest chip so we can grow the firmware over the years without having to optimize everything or again refactor pieces of code so it fits?
The answer is all in the numbers, if you sell over half a million products each year for ten years and you do the math it turns out that it is a lot of money that makes the profit for that business but also allows the salespersons to put the product at a lower pricepoint in the market. And that is what sometimes is needed to survive against asian competitors to make the first deal.
Even refactoring the platform to another chip manufacturer (3 SW eng + 2 HW eng for three to four months) can make a large profit if you do the math. The only time this really went sour was when the marketing dept had over estimated the sales with a factor of ten so yes it sometimes can go wrong. -
I don't know how good or bad the current STMCube stuff is. I looked at STPLIB a long time ago (~2014), and then I think the first HAL library. Both were significantly unimpressive: bloated, poor code, incorrect code, not substantially readable, etc.
Yeah, well. We've read that a lot everywhere, but it's not all that bad. At least not substantially worse than any other vendor library I've seen. I've worked with TI and NXP SDK and didn't find the code to be all that much better or more readable.
One thing to consider is that ST's code is MISRA-C compliant, which makes them use a certain code style, and a certain way of implementing things, that many will find cumbersome and less readable.
The other point is that vendor libraries are provided with source code these days, which is a good thing. But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism. Thats something inherent to software development, I think. It's very rare when a software developer actually likes someone else's code and has nothing negative to say about it.That's all separate from IDEs. Using a library shouldn't lock users into a particular IDE. For any IDE, there will be a significant number of users who HATE it. Libraries that are easy to integrate into "any" configurable IDE are much better than ones that assume a particular development environment.
Yes of course! Many people unfortunately shy away from doing that, because it's out of their comfort zone. They just use the vendor IDE, and then they're confident it will produce the result they expect - until, of course, they find the next horrible bug. Somehow they often seem to prefer fighting with the bugs of others, rather than configuring their own tools. Maybe because this way, they don't feel responsible for the bugs occuring in the tooling... -
I started a new project to see if I could figure out how to directly control the GPIO registers. I used STM32CubeIDE to setup the project. I used the IOC tool to configure the system clock and to configure GPIOC_13 as an output to flash the onboard LED at a 1 second rate using the HAL_Delay() function. Nothing else was configured. Code size came out to be 2968 bytes using HAL_GPIO calls.
I then used IOC to set GPIOC_13 back to its reset state. This results in no HAL_GPIO code being generated for GPIOC_13. I used the CMSIS libraries to setup the GPIOC port. I also manipulated the GPIOC registers using the GPIOC->BRR and GPIOC->BSRR to toggle the LED at the 1 second rate using the HAL_Delay() function. Code size came out to be 2476 bytes which is 492 bytes less than using the HAL_GPIO calls.
I guess this confirms bare metal programming generates smaller code than using the HAL calls. Using the system tick instead of HAL_Delay would probably reduce the code quite a bit with the added benefit of not stalling the MCU. More bare metal learning ahead. I will need to setup a bunch of macros and #defines to make my code more readable. -
A basic program for STM32G071 that sets up the clocks, reads a button, blinks an LED using a timer interrupt, reads and writes UART is 1052 bytes using pure bare metal code with no real attempts to optimize anything.
Same thing for STM32F4 is 1464 bytes, and significant part of the difference is interrupt table that is 428 bytes on F4 vs 192 bytes on G0. -
Quote
looking at someone else's source code almost ALWAYS triggers criticism.
Well, yeah.
But not understanding binary fractions, and rounding by multiplying by 10, adding 5, and dividing by 10... Does not inspire confidence. (Since the clock and baud rate are variables, all that math actually happens. I guess "a CM3 has a divide instruction, so who cares?" is somewhat valid. Sigh.
Code I originally complained about (2014):Code: [Select]integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));
tmpreg = (integerdivider / 100) << 4;
/* Determine the fractional part */
fractionaldivider = integerdivider - (100 * (tmpreg >> 4));
/* Implement the fractional part in the register */
tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);
/* Write to USART BRR */
USARTx->BRR = (uint16_t)tmpreg;
Code in current STM32F1 HLL driver library:Code: [Select]// .h file
#define USART_DIV(_PCLK_, _BAUD_) (((_PCLK_)*25U)/(4U*(_BAUD_)))
#define USART_DIVMANT(_PCLK_, _BAUD_) (USART_DIV((_PCLK_), (_BAUD_))/100U)
#define USART_DIVFRAQ(_PCLK_, _BAUD_) ((((USART_DIV((_PCLK_), (_BAUD_)) - (USART_DIVMANT((_PCLK_), (_BAUD_)) * 100U)) * 16U) + 50U) / 100U)
/* UART BRR = mantissa + overflow + fraction
= (UART DIVMANT << 4) + ((UART DIVFRAQ & 0xF0) << 1) + (UART DIVFRAQ & 0x0FU) */
#define USART_BRR(_PCLK_, _BAUD_) (((USART_DIVMANT((_PCLK_), (_BAUD_)) << 4U) + \
((USART_DIVFRAQ((_PCLK_), (_BAUD_)) & 0xF0U) << 1U)) + \
(USART_DIVFRAQ((_PCLK_), (_BAUD_)) & 0x0FU))
// .c file:
husart->Instance->BRR = USART_BRR(pclk, husart->Init.BaudRate);
Code that works equivalently:Code: [Select]Usart->BRR = pclk/baud;
(The F0 and U5 implementations are better. The F4 isn't, but it's different. I don't know if it's good that there are different implementations, or terrifying. Don't the developers talk to each other? (Oh, right. Probably someone who isn't there any more. Sigh. I once had my manager say something like "no one comes to work for xxxx wanting to develop infrastructure code." That's probably generally true, for most values of xxxx. :-( )
-
" fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM."
That is part of why so many bigger companies are sh*t places to work for, and are really sh*t to have as a customer
A fraction of a cent will never "make or break a company". But that's another topic
"Usart->BRR = pclk/baud;"
That pretty well hits the "Is CubeIDE crap" nail on the head
Many many lines, countless macros, countless definitions, countless abstractions, just to do a trivial function. They must have had a whole team coming up with all the bit definition names
-
" fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM."
That is part of why so many bigger companies are sh*t places to work for, and are really sh*t to have as a customer
Sure, but that is totally subjective. I personally enjoy fully optimizing something to the point where you can't make it any simpler/cheaper, there is a certain amount of satisfaction knowing you designed something "just right" with little to no waste or any vestigial parts. I can't fathom using some Raspberry Pi garbage to blink an LED or actuate a motor, which is what a lot of people seem to be doing nowadays and would much rather be doing optimized DSP/functional safety designs that cost a small fraction of that and are sold in the 100's of thousands.
For reference, my workhorse has been the STM32G4 series used in some UL991 and UL1998-compliant and power electronics designs and I have no strong opinions about STCubeIDE. ST provide a VDE certified class B safety library for free with it, so like, truly 0 complaints there. Sometimes the IDE is a piece of buggy crap, sometimes it's not, it really is on par with any other OEM offerings. -
Oh yeah, if you need Class B, MISRA-C and other crap like this, then you are in a wold of hurt. Your code quality will suffer no matter what you do.
-
AFAIK The point of Misra is safety and predictability of the execution of the code for automobile industry.
Not the most optimized code.
It has its purpose, remembering the leaked Toyota software from the start of the century
-
But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism.
Yes, and it's always considerable amount of work integrating other's code and libraries. Because it sucks, it has to provide something back. I.e., spend 10 hours to reuse work by others, save 100 hours by not having to do the work from scratch. That would be an acceptable ratio.
That is exactly why we use large libraries to do non-trivial things. This is why we use OpenCV to help with computer vision, or use existing BSD or linux networking stack.
But 99% of what STM32 HAL does, and what Cube autogenerates, is something that is written within minutes. Very typically less than 10 LoC per peripheral. And once you have done it a few times, you have already learnt the quirks. Sometimes it gets difficult but these are difficult edge cases anyway, something usually completely impossible using the HAL.
Same thing with every other vendor. westfw's requirement list above is a good one. No one ever really succeeded with it, regarding something as simple as microcontroller peripherals. The reason is, the peripherals are flexible devices offering gazillion features, but are still relatively simple to program. Worst combination for successful abstraction.
Abstraction and libraries work well when you have one simple goal, and achieving it takes a lot of difficult implementation details. This way, API is simple, like space_rocket.launch("Moon"), and doing the implementation from scratch instead would be a lot of work.
But abstracting all 57 configuration parameters of an UART through a library layer, when you can just write those parameters directly in the registers as explained in the only existing documentation. Not going to happen, so the library only exposes "a typical case" or two, causing massive limitations on what you can do with it. This would be an acceptable tradeoff if doing what it does was difficult, but since it isn't, I absolutely see no point. The typical case tends to be extremely simple anyway. You succeed in it using any vendors any borked library, bare metal, asm, writing ones and zeroes with a stick in sand and photographing it, whatever. This makes the reoccurring HAL discussion not worth anything. The claim that HAL somehow makes life super easy is just
because all the real challenges are elsewhere than getting UART to print characters.
-
MISRA is completely uninteresting. It's another tick in the box for Powerpoint managers, and completely depends on the case if it helps or hinders. Usually the latter.
It's not some holy grail of safe development practices, it's really just a small list of forbidden constructs that sometimes have caused problems. Look it up. It's a slightly more advanced and better formed version of "don't use goto". It's clearly a panic reply to actual problems.
It does not in any way help avoiding problems in all the remaining constructs. It isn't even designed to help in developing safe code (where specification of edge cases, testing, code coverage, verification and proving things come in). These are all difficult, and MISRA's purpose isn't to even comment on them.
At the same time, having to avoid large number of perfectly usable language constructs just because someone else have made mistakes with them increases risk of producing bugs using the less effective tools.
I.e., a screwdriver sometimes slips and causes damage. So forbid usage of a screwdriver. Hammer must be used instead. As a result, hammer hits your finger instead of the screw much more often. But that doesn't matter, because it's now formally on paper. Without validation of results getting better, such changes are meaningless.
Really, MISRA screams the classic "goto considered harmful" mindset, i.e., instead of getting competent programmers, limit the number of powerful tools so that fools don't make mistakes with them. This is quite OK in programming 101 class, but not in safety critical software industry (which is why actual safety-critical industry use something completely different paradigms than just MISRA; they might implement MISRA too if they consider it important box to tick).
But yeah, MISRA's great for the hobbyists role-playing safety critical aerospace industry. In this regard, I completely understand why STM32 HAL is written in MISRA compliant C. It hits the target. -
MISRA is completely uninteresting. It's another tick in the box for Powerpoint managers, and completely depends on the case if it helps or hinders. Usually the latter.
But all this is coming from the suggestion that every programmer should produce code without errors and is 100% dedicated to the job. The reality is that not every programmer is perfect or sees writing excellent code as a goal. Most go home at 5 and sit in front of the TV while drinking a beer after dinner. And that is perfectly fine.
It's not some holy grail of safe development practices, it's really just a small list of forbidden constructs that sometimes have caused problems. Look it up. It's a slightly more advanced and better formed version of "don't use goto". It's clearly a panic reply to actual problems.
It does not in any way help avoiding problems in all the remaining constructs. It isn't even designed to help in developing safe code (where specification of edge cases, testing, code coverage, verification and proving things come in). These are all difficult, and MISRA's purpose isn't to even comment on them.
MISRA is put into place to remove common pitfalls in C from the equation and make 2 average, low cost programmers produce more code than a rare (hard to find), highly paid expert programmer. Now multiple the number of average level programmers in a team by 10 and you'll see why MISRA makes producing code that doesn't suffer from common bugs more efficient in a financial sense.
I have put together a small course myself to teach junior programmers several pitfalls of C and how to avoid them in order to make them more productive. It is not as extensive as MISRA but does cover the basics.
-
MISRA fails to remove common C pitfalls. It addresses an uninterestingly small part of actual programming errors. The problem is deep in C. It is just a powerful but somewhat dangerous language. You can't fundamentally make it better by removing half of the power, and half of the pitfalls. Mistakes will be made regardless, and the key is to find and correct the mistakes. Even better, their root causes.
The problem in MISRA & friends is that the strict avoidance of many useful C constructs makes the code less maintainable spaghetti mess, increasing risk of human errors; in worst case, necessitating copy-paste practices. This again can be mitigated by adding automated testing and verification. It can all work out, but the burden of proof is for those claiming MISRA helps reduce bugs.
Yes, people make mistakes, but I'm sure there would be softer means of finding and correcting "typical C problems" than industry-wide removal of most powerful C features. -
But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism.
Yes, and it's always considerable amount of work integrating other's code and libraries. Because it sucks, it has to provide something back. I.e., spend 10 hours to reuse work by others, save 100 hours by not having to do the work from scratch. That would be an acceptable ratio.
That is exactly why we use large libraries to do non-trivial things. This is why we use OpenCV to help with computer vision, or use existing BSD or linux networking stack.
I will give one example where vendor-abstraction-libraries collide with "large libraries to do non-trivial things" -- USB.
Every vendor that offers processors with USB has a library and some standard device-class examples, and that library and those examples are all intertwined with their HAL. Like ataradov, I have an application I port to new processors. I use the USB MIDI class. It's simple and well-defined, but at the same time somewhat open-ended: it's up to the application to deal with data sent from the computer to the micro, and also to generate messages to send back to the host.
Some are good. One one hand, Silicon Labs offers a fairly straightforward USB library for their EFM8 and EFM32 parts. Once I got their tech support to explain how a particular case was handled ("what happens when the application doesn't read from the USB OUT endpoint FIFO because it's not ready to handle the data?" "The USB hardware NAKs the transaction" -- exactly what the spec says should happen!), implementing a standard class (MIDI) was straightforward. The library lets you set up a transfer-complete callback to which it passes the endpoint number and then you can handle the data as necessary. It's then a matter of the application deciding what to do with the data received, and also how to send data back to the host.
On the other hand is NXP. On-chip High Speed PHY and a faster core look great! But good D-g, their manuals and support say, "To implement an unsupported Device Class, copy an existing example and modify it." But the existing examples are all created with their overall code generator and once you start to modify it, it all breaks, and anyway you'll get the bends doing the deep dive into their code necessary to understand it and strip away a lot of the stuff needed to support the "example" class so you can implement your own thing. Why can't they just offer a callback and let the application programmer manage the data?
On the gripping hand is TI with their Tiva TM4C and MSP432 parts. They absolutely want you to use their libraries for everything. The USB library is overcomplicated in how they have goofy structures to handle composite devices. Part of it is that by "composite device" they mean a device with more than one instance of the same device class, for example two UARTs. But USB Audio and MIDI are composite classes because they use more than one Interface, not that there are two MIDI devices. Another complication is just how there are pointers to structures and their library wants to handle descriptors in a weird way. But I got it to work without too much fuss. The USB library code expects to use the rest of their HAL, so there's no real way around it. The chips have driver code in ROM, which is useful in that it saves flash, but less so because they can't update that code, so to use their library you have to use a "map" function which knows whether to use the ROM code or new source you compile in. Arrgh.
I follow the TinyUSB project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area. -
I follow the TinyUSB project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area.
TinyUSB seems pretty good. I have tested it both on the RP2040 and the NXP iMRT1062. First developed a small demo MIDI synth on the RP2040, then I ported it to the NXP MCU using TinyUSB (which supports both), and porting was a breeze. That was definitely the easiest path for designing a USB device that you can port with little effort to other MCUs.
Of course, it still supports only a "limited" (but decent) number of targets, and for USB HS, the number is even smaller (last time I checked I think HS was only supported on one or two targets only!). But it's an active project, so it's getting there.
-
MISRA fails to remove common C pitfalls. It addresses an uninterestingly small part of actual programming errors. The problem is deep in C. It is just a powerful but somewhat dangerous language. You can't fundamentally make it better by removing half of the power, and half of the pitfalls. Mistakes will be made regardless, and the key is to find and correct the mistakes. Even better, their root causes.
The way I understand it MISRA is not only about preventing coding mistakes but also about mitigating external effects (like memory corruption). One of the requirements is not to use function pointers. IIRC that has been altered to not to use function pointers stored in volatile memory in later versions. -
But yeah, MISRA's great for the hobbyists role-playing safety critical aerospace industry. In this regard, I completely understand why STM32 HAL is written in MISRA compliant C. It hits the target.
MISRA is certainly questionable, as most other coding rulesets or guidelines are, actually, but great for hobbyists? Are you serious?
It's de-facto in the automotive industry, and quite a few other safety-critical ones. Of course it's not the only thing that is done, but you can hardly avoid it in general. Whether you like it or not. ST is definitely not doing this for hobbyists - they are targetting those industries, for which it's a prerequisite if you intend on using any piece of code. Whether you like this or not, or whether it really is relevant or not, I'm sorry to say, absolutely doesn't matter.