> On 2/12/19 8:39 pm, pozz wrote:
>> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel
>> SAM D20/C21.
>>
>> I didn't like Atmel Software Framework so I extracted a buch of
>> low-level files from ASF (mainly headers to manipulate registers) and
>> rewrite the high-level drivers for peripherals I used (UART, ADC,
>> Timers, ...)
>> It wasn't a simple task, I spent many days to understand what ASF
>> really do, decide what to import in my project, what to exclude and
>> what to refactor.
>> Anyway I now have a simpler and more understandable sources for my
>> projects with SAM MCUs.
>
> Did you publish any of your ASF rewrite? Some of the Arduino libs are
> buggy (e.g. USB re-connect) and ASF works but has the problems you noted.
Nope. Anyway I only extracted include files and clock configurations and
initialization routines. No more.
I rewrote every peripheral driver, starting from initialization.
>> Now I need to start a project with STM32 and I noticed the usual
>> thing: the silicon vendor releaes two ready-to-use libraries:
>> low-level (for manipulating registers) and high-level drivers
>> generated automatically from CubeMX tool.
>> I'm wondering if it's worth to give a possibility to CubeMX code or to
>> stay with low-level files and make personal high-level drivers.
>>
>> What is your experience with CubeMX high-level generated code?
>
> None, but I wouldn't trust this kind of code generator. Switch to an
> RTOS platform (ChiBios, Nuttx, etc) or use libopencm3 to write your own,
> would be my policy.
Reply by boB●December 12, 20192019-12-12
On Thu, 12 Dec 2019 09:04:08 +0100, pozz <pozzugno@gmail.com> wrote:
>Il 12/12/2019 07:50, boB ha scritto:
>> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
>> wrote:
>>
>>> On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
>>>> What is your experience with CubeMX high-level generated code?
>>>
>>> Only a boob would use Cube?
>>> Only a blockhead?
>>> I can't remember which is more popular.
>>>
>>> I've been using RubeMX for around 18 months.
>>> During that time I've reported dozens of bugs, a few of which have been fixed.
>>> The HAL and LL libraries (high and low level drivers) are bloated and buggy.
>>> USB stack has bad bugs and no RTOS integration.
>>> FreeRTOS integration is broken (see http://www.nadler.com/embedded/newlibAndFreeRTOS.html)
>>> LwIP integration is broken and out-of-date; Ethernet drivers buggy.
>>> Support for F7 series is especially buggy.
>>> My workflow is:
>>> - create the initial project using CubeMX, under source control.
>>> - patch all the errors in the generated project files
>>> - patch bugs I know about in the generated code.
>>> - commit to source control frequently
>>> - if I need to regenerate the project from Cube (pin assignment changes etc),
>>> - always commit prior regenerating
>>> - review all changed files: replace from repository or merge fixes
>>>
>>> The ST chips have some interesting hardware issues (F4 anyway):
>>> - SPI is brain-dead; chip-selects must be done with SW or timers, no
>>> support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
>>> - DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
>>>
>>> So, better than Microchip and their absurd "Harmony",
>>> similar to Freescale parts (now NXP), similar to Gecko tools,
>>> not as good as current NXP part support (MCUxpresso).
>>>
>>> Hope that helps!
>>> Best Regards, Dave
>>
>>
>> I uses CubeMX for STM32F4xx to help with the initialization and
>> choosing pins and peripherals and alternate function I/O and generate
>> code for IAR EWARM IDE.
>>
>> After I fixed the HAL init code,
>
>Why? Was it buggy?
It did not enable the IO pins for the timer PWM outputs.
I think the newer CubeMX is better but the older version I used did
not have all possible implementations of peripherals available.
For instance, you cant tell the DMA initialization several things
about how its channels and streams are used in CubeMX. There is
always code to add to get things to do what you want to do. This is
expected and I don't have a problem with that I guess... Especially
now that I have things working.
>
>> I never go back to HAL (LL to me is
>> kinda like HAL, awful to work with).
>
>I understood you can generate LL or HAL/LL drivers. If you don't use HAL
>drivers, I think it's better to select only LL drivers.
I did try in LL generation mode. Gave me the same feeling as HAL code
did because of how they call the functions. How I like to set bits
and fields is like this for example...
GPIOA->BSRR = (0x0001 << 8);
Gets right to the point without hiding the operation by calling an
inline HAL batch or even worse, a HAL function. LL doesn't help me in
this manner. Nobody else probably cares. I come from time when
everything was done in assembler (but not ARM programming)
I still need to now assembly language for ARM to be able to debug
completely and understand the generated code. HAL and LL makes it
extremely difficult for me to follow the code through debugging.
>
>
>> But for initialization, Cube was
>> OK. At least it's just for init.
>
>Indeed it is what I use ASF (Atmel Software Framework) for.
Yes, a tool to help with the original pinout and initialization code.
I had a very bad experience with Atmel 13 years ago or so. (bad
silicon and denial from Atmel) Hopefully Microchip makes them a
better company to deal with now.
>
>
>> I definitely like the DMA for timers and A/D but haven't used it for
>> anything else yet.
>
>DMA for timers? What do you mean?
Loading Capture/Compare registers for making PWM waveforms.
>
>
>> Will find out about the SPI issues soon.
>
>Please, explain.
Dave mentioned that the STM32F4 chips has some issues he didn't like.
That is what I am using but haven't gotten to the SPI peripheral yet.
>> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com> >> wrote:
>>> The ST chips have some interesting hardware issues (F4 anyway):
>>> - SPI is brain-dead; chip-selects must be done with SW or timers, no
>>> support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
>>> - DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
I did see something in some documentation somewhere about using the
1ms timer tick for SPI when I was looking at removing its interrupt so
I left the tick timer interrupt enabled. I'm using almost every timer
there is in this part.
>
>
>> Not Ethernet or USB on this particular project.
>
>USB, how bad!! :-(
No Ethernet in my part but there is USB. Not using either one here
though.
Reply by pozz●December 12, 20192019-12-12
Il 12/12/2019 07:50, boB ha scritto:
> On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
> wrote:
>
>> On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
>>> What is your experience with CubeMX high-level generated code?
>>
>> Only a boob would use Cube?
>> Only a blockhead?
>> I can't remember which is more popular.
>>
>> I've been using RubeMX for around 18 months.
>> During that time I've reported dozens of bugs, a few of which have been fixed.
>> The HAL and LL libraries (high and low level drivers) are bloated and buggy.
>> USB stack has bad bugs and no RTOS integration.
>> FreeRTOS integration is broken (see http://www.nadler.com/embedded/newlibAndFreeRTOS.html)
>> LwIP integration is broken and out-of-date; Ethernet drivers buggy.
>> Support for F7 series is especially buggy.
>> My workflow is:
>> - create the initial project using CubeMX, under source control.
>> - patch all the errors in the generated project files
>> - patch bugs I know about in the generated code.
>> - commit to source control frequently
>> - if I need to regenerate the project from Cube (pin assignment changes etc),
>> - always commit prior regenerating
>> - review all changed files: replace from repository or merge fixes
>>
>> The ST chips have some interesting hardware issues (F4 anyway):
>> - SPI is brain-dead; chip-selects must be done with SW or timers, no
>> support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
>> - DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
>>
>> So, better than Microchip and their absurd "Harmony",
>> similar to Freescale parts (now NXP), similar to Gecko tools,
>> not as good as current NXP part support (MCUxpresso).
>>
>> Hope that helps!
>> Best Regards, Dave
>
>
> I uses CubeMX for STM32F4xx to help with the initialization and
> choosing pins and peripherals and alternate function I/O and generate
> code for IAR EWARM IDE.
>
> After I fixed the HAL init code,
Why? Was it buggy?
> I never go back to HAL (LL to me is
> kinda like HAL, awful to work with).
I understood you can generate LL or HAL/LL drivers. If you don't use HAL
drivers, I think it's better to select only LL drivers.
> But for initialization, Cube was
> OK. At least it's just for init.
Indeed it is what I use ASF (Atmel Software Framework) for.
> I definitely like the DMA for timers and A/D but haven't used it for
> anything else yet.
DMA for timers? What do you mean?
> Will find out about the SPI issues soon.
Please, explain.
> Not Ethernet or USB on this particular project.
USB, how bad!! :-(
Reply by boB●December 12, 20192019-12-12
On Mon, 2 Dec 2019 11:13:57 -0800 (PST), Dave Nadler <drn@nadler.com>
wrote:
>On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
>> What is your experience with CubeMX high-level generated code?
>
>Only a boob would use Cube?
>Only a blockhead?
>I can't remember which is more popular.
>
>I've been using RubeMX for around 18 months.
>During that time I've reported dozens of bugs, a few of which have been fixed.
>The HAL and LL libraries (high and low level drivers) are bloated and buggy.
>USB stack has bad bugs and no RTOS integration.
>FreeRTOS integration is broken (see http://www.nadler.com/embedded/newlibAndFreeRTOS.html)
>LwIP integration is broken and out-of-date; Ethernet drivers buggy.
>Support for F7 series is especially buggy.
>My workflow is:
>- create the initial project using CubeMX, under source control.
>- patch all the errors in the generated project files
>- patch bugs I know about in the generated code.
>- commit to source control frequently
>- if I need to regenerate the project from Cube (pin assignment changes etc),
> - always commit prior regenerating
> - review all changed files: replace from repository or merge fixes
>
>The ST chips have some interesting hardware issues (F4 anyway):
>- SPI is brain-dead; chip-selects must be done with SW or timers, no
> support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
>- DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
>
>So, better than Microchip and their absurd "Harmony",
>similar to Freescale parts (now NXP), similar to Gecko tools,
>not as good as current NXP part support (MCUxpresso).
>
>Hope that helps!
>Best Regards, Dave
I uses CubeMX for STM32F4xx to help with the initialization and
choosing pins and peripherals and alternate function I/O and generate
code for IAR EWARM IDE.
After I fixed the HAL init code, I never go back to HAL (LL to me is
kinda like HAL, awful to work with). But for initialization, Cube was
OK. At least it's just for init.
I definitely like the DMA for timers and A/D but haven't used it for
anything else yet.
Will find out about the SPI issues soon.
Not Ethernet or USB on this particular project.
Reply by Clifford Heath●December 11, 20192019-12-11
On 2/12/19 8:39 pm, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM
> D20/C21.
>
> I didn't like Atmel Software Framework so I extracted a buch of
> low-level files from ASF (mainly headers to manipulate registers) and
> rewrite the high-level drivers for peripherals I used (UART, ADC,
> Timers, ...)
> It wasn't a simple task, I spent many days to understand what ASF really
> do, decide what to import in my project, what to exclude and what to
> refactor.
> Anyway I now have a simpler and more understandable sources for my
> projects with SAM MCUs.
Did you publish any of your ASF rewrite? Some of the Arduino libs are
buggy (e.g. USB re-connect) and ASF works but has the problems you noted.
> Now I need to start a project with STM32 and I noticed the usual thing:
> the silicon vendor releaes two ready-to-use libraries: low-level (for
> manipulating registers) and high-level drivers generated automatically
> from CubeMX tool.
> I'm wondering if it's worth to give a possibility to CubeMX code or to
> stay with low-level files and make personal high-level drivers.
>
> What is your experience with CubeMX high-level generated code?
None, but I wouldn't trust this kind of code generator. Switch to an
RTOS platform (ChiBios, Nuttx, etc) or use libopencm3 to write your own,
would be my policy.
Reply by Dave Nadler●December 2, 20192019-12-02
On Monday, December 2, 2019 at 5:17:57 PM UTC-5, pozz wrote:
> Il 02/12/2019 20:13, Dave Nadler ha scritto:
> > On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
> > ...
> > The ST chips have some interesting hardware issues (F4 anyway):
> > - SPI is brain-dead; chip-selects must be done with SW or timers, no
> > support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
> > - DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
>
> Another question that is different than the original.
This is relevant to your question, as RubeMX and STM drivers do not address these issues...
Reply by pozz●December 2, 20192019-12-02
Il 02/12/2019 20:13, Dave Nadler ha scritto:
> On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
>> What is your experience with CubeMX high-level generated code?
>
> Only a boob would use Cube?
> Only a blockhead?
> I can't remember which is more popular.
>
> I've been using RubeMX for around 18 months.
> During that time I've reported dozens of bugs, a few of which have been fixed.
> The HAL and LL libraries (high and low level drivers) are bloated and buggy.
> LwIP integration is broken and out-of-date; Ethernet drivers buggy.
Seriously? Do you have fixed Ethernet driver?
> Support for F7 series is especially buggy.
> My workflow is:
> - create the initial project using CubeMX, under source control.
> - patch all the errors in the generated project files
> - patch bugs I know about in the generated code.
> - commit to source control frequently
> - if I need to regenerate the project from Cube (pin assignment changes etc),
> - always commit prior regenerating
> - review all changed files: replace from repository or merge fixes
>
> The ST chips have some interesting hardware issues (F4 anyway):
> - SPI is brain-dead; chip-selects must be done with SW or timers, no
> support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
> - DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
Another question that is different than the original.
Reply by Dave Nadler●December 2, 20192019-12-02
On Monday, December 2, 2019 at 4:39:42 AM UTC-5, pozz wrote:
> What is your experience with CubeMX high-level generated code?
Only a boob would use Cube?
Only a blockhead?
I can't remember which is more popular.
I've been using RubeMX for around 18 months.
During that time I've reported dozens of bugs, a few of which have been fixed.
The HAL and LL libraries (high and low level drivers) are bloated and buggy.
USB stack has bad bugs and no RTOS integration.
FreeRTOS integration is broken (see http://www.nadler.com/embedded/newlibAndFreeRTOS.html)
LwIP integration is broken and out-of-date; Ethernet drivers buggy.
Support for F7 series is especially buggy.
My workflow is:
- create the initial project using CubeMX, under source control.
- patch all the errors in the generated project files
- patch bugs I know about in the generated code.
- commit to source control frequently
- if I need to regenerate the project from Cube (pin assignment changes etc),
- always commit prior regenerating
- review all changed files: replace from repository or merge fixes
The ST chips have some interesting hardware issues (F4 anyway):
- SPI is brain-dead; chip-selects must be done with SW or timers, no
support for xfers other than 8-bit or 16-bit (and we use 20-bit ADC/DAC).
- DMA sometimes gives up under stress, very hard and non-performant to catch/resume.
So, better than Microchip and their absurd "Harmony",
similar to Freescale parts (now NXP), similar to Gecko tools,
not as good as current NXP part support (MCUxpresso).
Hope that helps!
Best Regards, Dave
Reply by Tauno Voipio●December 2, 20192019-12-02
On 2.12.19 11:39, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM
> D20/C21.
>
> I didn't like Atmel Software Framework so I extracted a buch of
> low-level files from ASF (mainly headers to manipulate registers) and
> rewrite the high-level drivers for peripherals I used (UART, ADC,
> Timers, ...)
> It wasn't a simple task, I spent many days to understand what ASF really
> do, decide what to import in my project, what to exclude and what to
> refactor.
> Anyway I now have a simpler and more understandable sources for my
> projects with SAM MCUs.
>
> A similar thing happens with NXP LPCOpen, even if they are *only*
> low-level libraries. The driver of LPCOpen is very simple and not
> directly usable by at application point-of-view.
>
> Now I need to start a project with STM32 and I noticed the usual thing:
> the silicon vendor releaes two ready-to-use libraries: low-level (for
> manipulating registers) and high-level drivers generated automatically
> from CubeMX tool.
> I'm wondering if it's worth to give a possibility to CubeMX code or to
> stay with low-level files and make personal high-level drivers.
>
> What is your experience with CubeMX high-level generated code?
I dropped it because of the bloat and poor code of the
libraries. It is about as bad as the Atmel foundation code,
and of the same reason: the code tries to fit all, and it
makes it a bad fit to everyone.
If you feel that you can write the hardware handling code
yourself, just drop CubeMX and do it yourself. However,
CubeMX can be a help to solve the puzzle of I/O pin setup
planning - it is a mess, as the pin multiplexing is far from
regular.
--
-TV
Reply by John Speth●December 2, 20192019-12-02
On 12/2/2019 1:39 AM, pozz wrote:
> I worked with NXP Cortex-M3 LPC1768 and similar and Microchip/Atmel SAM
> D20/C21.
>
> I didn't like Atmel Software Framework so I extracted a buch of
> low-level files from ASF (mainly headers to manipulate registers) and
> rewrite the high-level drivers for peripherals I used (UART, ADC,
> Timers, ...)
> It wasn't a simple task, I spent many days to understand what ASF really
> do, decide what to import in my project, what to exclude and what to
> refactor.
> Anyway I now have a simpler and more understandable sources for my
> projects with SAM MCUs.
>
> A similar thing happens with NXP LPCOpen, even if they are *only*
> low-level libraries. The driver of LPCOpen is very simple and not
> directly usable by at application point-of-view.
>
> Now I need to start a project with STM32 and I noticed the usual thing:
> the silicon vendor releaes two ready-to-use libraries: low-level (for
> manipulating registers) and high-level drivers generated automatically
> from CubeMX tool.
> I'm wondering if it's worth to give a possibility to CubeMX code or to
> stay with low-level files and make personal high-level drivers.
>
> What is your experience with CubeMX high-level generated code?
My experience with CubeMX is small, LPCOpen is none, SAM is high, and
STM32 high. I've learned by experience to stick to what the vendor SDKs
provide at the start of the project. Then I evaluate the drivers that
might not be performing at the high level that I need and customize
those drivers to suit my needs. It usually ends up (1) greatly
simplifying the driver after understanding the HW interface details and
(2) meeting the performance requirement turns out to be not much
additional programming work. You do end up putting in some time
deconstructing the bloaty driver but you successfully get to "done".
In other words, only optimize the code that needs it. Doing so for all
driver code is like swimming against the tide because SDK updates could
negate your efforts.
JJS