ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[captbill]

If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming.

I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

With Oberon you not only can work at the "bare metal" but you can literally carve the metal yourself, if you like, just like Magnus has done here:

https://github.com/Saanlima/Pepino/blob/master/Projects/RISC5Verilog_Pepino_I2C/src/I2C.v

How is this not the OPPOSITE of 'obscure'? Where do you see any code being hidden behind 'unknowns'?

Seeing is believing...here is the thread where you see a complete I2c get built in 2 days...and adapting it for Astrobe was a 40 minute task:

http://saanlima.com/forum/viewtopic.php?f=14&t=1289

Fantastic work - I can hardly believe it! I have just completed the following:

•Uploaded your bitstream to the Pepino
•Connected an HMC6352 I2C Compass chip to the Pepino
•Modified two Oberon source code files to port the code from ARM Cortex-M3 to RISC5 using your I2C register addresses.
•Fixed a number of compilation errors
•Uploaded the compiled modules to the Pepino
•Executed the application

and it worked first time!!!!!

Not only that, the whole process only took 40 minutes from start to finish...

_________________
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5

[richardman]

"Code size limited to 128K bytes of flash"

https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&product_id=55

Is it a commercial decision ?

The refers to a specific version, we sell different versions. Our most expensive version though (PRO), at $499, is less than what other commercial compiler vendors charge for their annual maintenance. The non-commercial version is just $50, for example.

[Karel]

For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...

Do you write your own Linux?

Your kidding, right? No need to write my own Linux. The average code quality of Linux kernel is much better than
what STM (or Microchip & Atmel for that matter) provides.

[dannyf]

No need to write my own Linux. The average code quality of Linux kernel is much better than
what STM (or Microchip & Atmel for that matter) provides.

So you agree that there are bugs in Linux? Since you didn't write Linux, you are living with other people's bugs by using Linux.

I was simply pointing out the hypocrisy of your supposedly "not living with other people's bugs".

[Kjelt]

Linux has a tremendous amount of bugs, vulnerabilities are reported weekly and that is not so strange with up to 1Mlocs code change a year 
No one can review or certify that, compared to Linux the ST std peripherals are easy to check and certify that it works and as long as people report bugs on their forum it will be ok-ish.

[dannyf]

Linux has a tremendous amount of bugs,

Absolutely true.

Unless you are a caveman living in the stone ages, you live in an environment operated by countless lines of code written by others and definitely full of bugs. And your life depends on it.

It is just non-sense to think at this time and age anyone can live in a world of your own bugs.

[splin]

Code review!  This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"

Code: [Select]

      if(huart->Init.WordLength == UART_WORDLENGTH_9B)
       {...}
      else    /* is 8 bit data - 8 bit no parity OR 7 plus parity */
      {
        if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
          return HAL_TIMEOUT;
        if(huart->Init.Parity == UART_PARITY_NONE)
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
        else
        {
          *pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits.  8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
        }
      }


Actually that code looks OK to me - the STM32F1 UART only supports 8 or 9 bit data. If you enable parity it replaces bit 7 or 8 with the parity. You don't have the options of 9 bit + parity or 7 bit no parity.

From the reference manual describing USART_DR:

When transmitting with the parity enabled (PCE bit set to 1 in the USART_CR1 register),
the value written in the MSB (bit 7 or bit 8 depending on the data length) has no effect
because it is replaced by the parity.
When receiving with the parity enabled, the value read in the MSB bit is the received parity
bit.

[Sal Ammoniac]

You don't have to agree with the compromise they made but you have to appreciate the compromise they made.

I do appreciate the compromise some people make by choosing to use vendor libraries.

I'd appreciate it even more if I were still doing commercial development. Sure, they'd get products to market faster, but mine would be more robust and less buggy and, despite the proliferation of Wal*Mart and other retailers that cater to those to whom price is the only thing that matters, there are still enough people around who value quality to ensure that I'd do well.

[jnz]

With Oberon you not only can work at the "bare metal" but you can literally carve the metal yourself, if you like, just like Magnus has done here:

How is this not the OPPOSITE of 'obscure'? Where do you see any code being hidden behind 'unknowns?

A. Unless this magic language and lib turn the STM32 into an FPGA, you are WILDLY mistaken about what "the metal" is, and what "literally carve" it would mean.

B. I think you are mistaken about what OBSCURE means. Your wonder-language is obscure, it's not well known.

C. Yes, I posted it already. TX.READY*() is some opaque nonsense. You posted compared to STM's HAL that bad or terrible - is actual detail code. And not just the highest level call that has the guts somewhere else.

I'm not trying to pick on you, but that's great that you like this obscure language and trust that someone else wrote very complex code to make it easy on newbs... But that is NOT a winning strategy when you are dealing with micros. That's how PC programmers with Ghz/Gigs get by.

Trust me, you are on the wrong path if you are interested in embedded.

[westfw]

the STM32F1 UART only supports 8 or 9 bit data. If you enable parity it replaces bit 7 or 8 with the parity. You don't have the options of 9 bit + parity or 7 bit no parity.

I guess that would explain it.  What a weird UART implementation!
So all the bugs I thought I saw have been shown to be OK after all.  I can deal with that...

[richardman]

I feel that this thread has spawned many arms and approaching thread-death ;-P

[jnz]

I feel that this thread has spawned many arms and approaching thread-death ;-P

Agreed, and while I have nothing against your wares, if you could slow your roll / stay in your lane on injecting your sales pitch of your JumpStart API that is dependent on using the tools your are selling in a discussion of HAL and how it can be fixed, that would be a helpful start.

[dannyf]

I for one don't mind knowing about alternatives, commercially or otherwise. And I think especially in the context of hal not working, having an alternative from imagecraft is a welcome.

What I'm interested in is people's perspectives on such alternatives. For example, I don't know why imagecraft offering is superior to an arduino user, given the free and unlimited alternative of stmduino, it's vast cost baase, user familiarity with tools and code libraries, etc.

[richardman]

In terms on "how to fix ST's software ecosystems", nothing ever written will be of use unless a) ST adopts it, or b) a user community builds around an alternative. No one has suggested on how to achieve either so anything said here is "useless" for the general users in that sense. Sure, we want to be #2, as would ChibiOS HAL, or Oberon HAL etc. The fact is that there is currently no Open Source alternative free to use with no restrictions from anyone, which I believe is what jnz is looking for. Obviously many people who have commented on the thread could do so, based on what they have said, but no one steps up.

As for describing the specifics of our advantages, I would be happy to answer any further questions via PM, email, or on a separate thread.

[donotdespisethesnake]

I feel that this thread has spawned many arms and approaching thread-death ;-P

Yes, you managed to turn it into an advertising thread for your products, well done sir. 

[richardman]

Bob, how about addressing my last post? What's YOUR contribution to solving the "ST's terrible ecosystem problem"? I see westfw putting out some code on public domain. Danny is writing some blog with code examples, and you...?

[richardman]

BTW, the MAIN IDEA that I am promoting is the concept of FUNCTIONAL API, and not just a simple layer of hardware register access, which is what ST's SPL and HAL are. The Ring buffer, the easy to use I2C objects etc. are just concepts. If anyone chooses to write an API replacement, just I would advise them to look into that direction. So anyone who wants such replacement, please go on and contribute 

[Sal Ammoniac]

Bob, how about addressing my last post? What's YOUR contribution to solving the "ST's terrible ecosystem problem"? I see westfw putting out some code on public domain. Danny is writing some blog with code examples, and you...?

Why does he need to contribute anything? Maybe he doesn't even use the STM32...

We all welcome your contributions to this topic, Richard, but I'll echo what Bob said: Please tone down the commercial for your product. It's getting a little overripe in the sun.

[richardman]

We all welcome your contributions to this topic, Richard, but I'll echo what Bob said: Please tone down the commercial for your product. It's getting a little overripe in the sun.

Noted

[dannyf]

For the record, I was never bother by the layering in STD periph library. Layering comes to me as AA huge advantage, as I most worked in a corporate environment where layering is a requirement for certification and documentation purposes.

I never thought the STD periph library is meant to be used without a user layer - to me it is nothing but a C representation of hardware registers. As such, it is meant to be layered, or customized, by the user in a way that suits his or her programming style.

That applies to even simpler things like port operations. Even on an 8bit mcy, I have never written a line like

PORTD |= portVal;

Instead, I have always used

IOSET(TXPORT, portVal);

With layering, I can write code that is almost entirely hardware dependent - for someone who sells code that runs on user-specified hardware, that's a must.

Taking on a new project for me many times is mostly redefining pins, or settig some macros, and linkingnin the right modules for the target, hit compile and I'm mostly there.

I charge lots of money, without ever worrying about lossing business to someone on prices, because I can deliver quality code quickly, thanks to layering.

Si layering to me is a huge competitive advantage, a huge asset. To me, if you cannot afford to layering, you are in the wrong business.

I often laugh, silently, at those fools who brag abbout writting hardware specific code to shave off 18 bytes. The more code like that you write, the more time you have to spend deciding if you should pay your rent or your cable bills,

[Sal Ammoniac]

With layering, I can write code that is almost entirely hardware dependent - for someone who sells code that runs on user-specified hardware, that's a must.

Freudian slip?

[obiwanjacobi]

So...
Perhaps if we first concentrate on the what and not the how...?
What requirements would a ideal HAL have to meet?
(be specific)
[2c]

[JPortici]

i can usually achieve the same just by using defines.. and when i port to another mcu i just adjust the defines.
i suppose you could use a function that then call the hal for the specific hardware.. but the hal has no need to be another subset of functions in almost all the cases

[Kjelt]

What requirements would a ideal HAL have to meet?

I guess that differs per user. I do really think that we never can accomodate or satisfy the "Arduino style" copy,paste,compile&play group unless STM Cube becomes much much better.
As you saw in this topic some companies answer is to abstract the lower levels and creating a thick fancy gluelayer, taking care of a lot of stuff but also adding to the program size and if there is something not working properly you depend on that company.
Personally i prefer the ST stdperipheral lib and think that is good enough for any reasonably experienced embedded software engineer to get going, as numerous succesfull examples were also mentioned by many users in this topic.

[dannyf]

I think the future is likely programming by GUI, as shown by cypress. Just need to figure out the packaging of it so you can build with layers or modules.