Il 19/12/2019 01:07, Dave Nadler ha scritto:
> On Tuesday, December 17, 2019 at 5:30:48 AM UTC-5, pozz wrote:
>> Il 16/12/2019 14:57, Dave Nadler ha scritto:
>>> Second, you probably will need to rewrite ST drivers to properly
>>> use OS facilities instead of idiotic timer-based polling etc.
>>
>> Do you know of projects with those drivers rewritten in a better way?
>> Mainly: UART, SPI and I2C.
>>
>>> Especially USB, which is incomplete, buggy, and not integrated with OS.
>>> I still have to track down and fix periodic dropping of 64-byte packets
>>> during USB-CDC transmission to host, aaarrrggg...
>>
>> Same question as before.
>>
>>
>>> Third, you may find ST drivers non-performant due to above issues
>>> plus bizarre number of layers and pointers to pointers to static structures.
>>
>> Yes I know. At the moment, I'd like to leave with them. Optimization can
>> be done later.
>>
>> Another question related to STM32 world. What is the main community
>> site? Official ST community appears very bad initially. I posted two
>> times for wrong, because I thought that was a search form, not a new
>> post form.
>>
>> ST Community website has two sections: Communities, that seem not
>> frequented, and Q&A taht seem much more updated.
> 
> The community is helpful but the forum software is pathetic and constantly complained about. ST staff are haphazard about responding to bugs or questions.

what a pity!


> As far as a good set of drivers, there are many isolated examples,
> but not from ST, and of course they are different for different chip families.
> 
> ARM Embed claim to have a complete, solid, debugged RTOS and stack (Ethernet, file system, USB, some drivers). I haven't tried it but if I'd known how much time I'd waste with ST stuff maybe I'd have gone that route, but who knows if its really better.
> 
> Hope that helps!

It doesn't really help, anyway thank you.

Most probably I will post some other questions related to ST code in 
this ng. Please help me, if you can.

On Tuesday, December 17, 2019 at 5:30:48 AM UTC-5, pozz wrote:
> Il 16/12/2019 14:57, Dave Nadler ha scritto:
> > Second, you probably will need to rewrite ST drivers to properly
> > use OS facilities instead of idiotic timer-based polling etc.
> 
> Do you know of projects with those drivers rewritten in a better way? 
> Mainly: UART, SPI and I2C.
> 
> > Especially USB, which is incomplete, buggy, and not integrated with OS.
> > I still have to track down and fix periodic dropping of 64-byte packets
> > during USB-CDC transmission to host, aaarrrggg...
> 
> Same question as before.
> 
> 
> > Third, you may find ST drivers non-performant due to above issues
> > plus bizarre number of layers and pointers to pointers to static structures.
> 
> Yes I know. At the moment, I'd like to leave with them. Optimization can 
> be done later.
> 
> Another question related to STM32 world. What is the main community 
> site? Official ST community appears very bad initially. I posted two 
> times for wrong, because I thought that was a search form, not a new 
> post form.
> 
> ST Community website has two sections: Communities, that seem not 
> frequented, and Q&A taht seem much more updated.

The community is helpful but the forum software is pathetic and constantly complained about. ST staff are haphazard about responding to bugs or questions.

As far as a good set of drivers, there are many isolated examples,
but not from ST, and of course they are different for different chip families.

ARM Embed claim to have a complete, solid, debugged RTOS and stack (Ethernet, file system, USB, some drivers). I haven't tried it but if I'd known how much time I'd waste with ST stuff maybe I'd have gone that route, but who knows if its really better.

Hope that helps!
Best Regards, Dave

Il 16/12/2019 14:57, Dave Nadler ha scritto:
> On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote:
>> At the moment, it seems the only solution is to use two different hw
>> timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste
>> of resources, but there isn't another immediate solution.
>>
>> I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can
>> be done with UART, SPI and similar simple peripherals. But it takes time
>> and anyway I will never rewrite USB or other complex driver.
>>
>> What is your solution?
> 
> First, use systick for FreeRTOS and a different timer for HAL.

What is the real reason to proceed in this way? Does HAL code really use 
ticks in ISRs, that would block forever if the HAL ticking timer has the 
lowest priority (as the ticking timer of FreeRTOS)?

> Second, you probably will need to rewrite ST drivers to properly
> use OS facilities instead of idiotic timer-based polling etc.

Do you know of projects with those drivers rewritten in a better way? 
Mainly: UART, SPI and I2C.

> Especially USB, which is incomplete, buggy, and not integrated with OS.
> I still have to track down and fix periodic dropping of 64-byte packets
> during USB-CDC transmission to host, aaarrrggg...

Same question as before.

> Third, you may find ST drivers non-performant due to above issues
> plus bizarre number of layers and pointers to pointers to static structures.

Yes I know. At the moment, I'd like to leave with them. Optimization can 
be done later.

Another question related to STM32 world. What is the main community 
site? Official ST community appears very bad initially. I posted two 
times for wrong, because I thought that was a search form, not a new 
post form.

ST Community website has two sections: Communities, that seem not 
frequented, and Q&A taht seem much more updated.

I think I have found a bug in MX initialization code. HAL_InitTick() is 
called two times: first during HAL_Init() and second during 
SystemClock_Config()/HAL_RCC_ClockConfig() [*].

The first time HAL_InitTick(TICK_INT_PRIORITY) is used. Second time 
HAL_InitTick(uwTickPrio) is used.

If timebase source is Systick, HAL_InitTick() in stm32l4xx_hal.c updates 
the variable uwTickPrio.
If timebase source is TIM1, HAL_InitTick() in stm32l4xx_hal_tim.c 
doesn't update uwTickPrio. So the second time HAL_InitTick() is called, 
the value of uwTickPrio is the initialization value that is an invalid 
priority.

When HAL_NVIC_SetPriority() is called the second time, an assert is 
fired if the priority number is invalid.

void HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, 
uint32_t SubPriority)
{
   uint32_t prioritygroup = 0x00;

   /* Check the parameters */
   assert_param(IS_NVIC_SUB_PRIORITY(SubPriority));
   assert_param(IS_NVIC_PREEMPTION_PRIORITY(PreemptPriority));

   prioritygroup = NVIC_GetPriorityGrouping();

   NVIC_SetPriority(IRQn, NVIC_EncodePriority(prioritygroup, 
PreemptPriority, SubPriority));
}

[*] I don't know exactly why initialization code needs to initialize 
ticks two times. I imagine the first time ticks are initialized with the 
default/startup clock configuration, so ticks can be used *before* clock 
is configured. After clocks are configured, the ticks are re-initialized 
again with the final configuration.

On Mon, 16 Dec 2019 13:42:57 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 16/12/2019 09:31, raimond.dragomir@gmail.com ha scritto:
>> luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris:
>>> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto:
>>>   >> [...]
>>>>> What is your solution?
>>>>
>>>> If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes".
>>>> CubeMX or not.
>>>
>>> Oh yes, I know. Anyway starting with a fully-functional project thanks
>>> to CubeMX is very good. I use the next time to improve CubeMX code and
>>> my question regarding Systick was born from this goal.
>> 
>> CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX.
>
>I understood LL is somewhat "register level" mode, even if I'm using HAL


I generated a project in LL mode recently and when I looked at the
generated C code, it looked very similar to HAL generated code.

Since I have a hard time trying to follow the HAL code, I just use the
HAL code which I am semi-familiar with and leave it at that.

Then, of course, use low level register code of my own after things
are initialized.

 
>yet.
>
>> Do you understand the init code generated by CubeMX?
>
>Yes, it's not difficult to follow the code with a debug.
>
>> How much documented is the HAL, LL whatever?
> > How easy it is to cross-reference the HAL, LL to the real user manual 
>of the chip?
>
>I don't know, I will check when I use them. At the moment I'm working on 
>a code already written by someone else.
>
>
>> Do you really know what to do next AFTER the CubeMX generated his code?
>
>Build and test.
>Write the main application.
>
>> Or, how easy it is to continue and write your own application AFTER the CubeMX?
>
>In my experience, nothing is easy.
>
>
>> You need to answer these questions first. I think it's too early to improve the CubeMX code.

On 16.12.19 15:57, Dave Nadler wrote:
> On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote:
>> At the moment, it seems the only solution is to use two different hw
>> timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste
>> of resources, but there isn't another immediate solution.
>>
>> I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can
>> be done with UART, SPI and similar simple peripherals. But it takes time
>> and anyway I will never rewrite USB or other complex driver.
>>
>> What is your solution?
> 
> First, use systick for FreeRTOS and a different timer for HAL.
> 
> Second, you probably will need to rewrite ST drivers to properly
> use OS facilities instead of idiotic timer-based polling etc.
> Especially USB, which is incomplete, buggy, and not integrated with OS.
> I still have to track down and fix periodic dropping of 64-byte packets
> during USB-CDC transmission to host, aaarrrggg...
> 
> Third, you may find ST drivers non-performant due to above issues
> plus bizarre number of layers and pointers to pointers to static structures.
> 
> Hope that helps,
> Best Regards, Dave


Both ST and Atmel hardware-builder created code is not worth
the trouble needed to debug it.

I'd like instead have honest hardware descriptions.

I lost 3 weeks on clock initialization, as the hardware description
did not tell that only one control field can be changed at any one
time, or the wait-for-ready functionality does never get ready.

-- 

-TV

On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote:
> At the moment, it seems the only solution is to use two different hw 
> timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste 
> of resources, but there isn't another immediate solution.
> 
> I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can 
> be done with UART, SPI and similar simple peripherals. But it takes time 
> and anyway I will never rewrite USB or other complex driver.
> 
> What is your solution?

First, use systick for FreeRTOS and a different timer for HAL.

Second, you probably will need to rewrite ST drivers to properly
use OS facilities instead of idiotic timer-based polling etc.
Especially USB, which is incomplete, buggy, and not integrated with OS.
I still have to track down and fix periodic dropping of 64-byte packets
during USB-CDC transmission to host, aaarrrggg...

Third, you may find ST drivers non-performant due to above issues
plus bizarre number of layers and pointers to pointers to static structures.

Hope that helps,
Best Regards, Dave

Il 16/12/2019 09:31, raimond.dragomir@gmail.com ha scritto:
> luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris:
>> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto:
>>   >> [...]
>>>> What is your solution?
>>>
>>> If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes".
>>> CubeMX or not.
>>
>> Oh yes, I know. Anyway starting with a fully-functional project thanks
>> to CubeMX is very good. I use the next time to improve CubeMX code and
>> my question regarding Systick was born from this goal.
> 
> CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX.

I understood LL is somewhat "register level" mode, even if I'm using HAL 
yet.

> Do you understand the init code generated by CubeMX?

Yes, it's not difficult to follow the code with a debug.

> How much documented is the HAL, LL whatever?
 > How easy it is to cross-reference the HAL, LL to the real user manual 
of the chip?

I don't know, I will check when I use them. At the moment I'm working on 
a code already written by someone else.


> Do you really know what to do next AFTER the CubeMX generated his code?

Build and test.
Write the main application.

> Or, how easy it is to continue and write your own application AFTER the CubeMX?

In my experience, nothing is easy.


> You need to answer these questions first. I think it's too early to improve the CubeMX code.

luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris:
> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto:
>  >> [...]
> >> What is your solution?
> > 
> > If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes".
> > CubeMX or not.
> 
> Oh yes, I know. Anyway starting with a fully-functional project thanks 
> to CubeMX is very good. I use the next time to improve CubeMX code and 
> my question regarding Systick was born from this goal.

CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX.
Do you understand the init code generated by CubeMX?
How much documented is the HAL, LL whatever?
How easy it is to cross-reference the HAL, LL to the real user manual of the chip?
Do you really know what to do next AFTER the CubeMX generated his code?
Or, how easy it is to continue and write your own application AFTER the CubeMX?

You need to answer these questions first. I think it's too early to improve the CubeMX code.