[En-Nut-Discussion] STM32L051 and LPUART

[Ulrich Prinz]

Hi Uwe!

yes, you may send me personal / direct email at any time to my full
name divided by a dot to the google mail service ending with com :)

I haven't really turned away from NutO/S but I wanted to see if it is
manageable to cut the deprecated and small systems out of the code. We
are designing out AVR completely and so it doesn't make sense to keep
complex build systems and 8-bit downwards compatibility for the cost
of complex code.
However there was not enough time to finish this work and to find a
way to merge updates from one side to the other in an easy way.

But I liked the flexibility of NutO/S and the option to do high-speed
hard interrupt software underneath the system while the system itself
works still stable very attractive. As I need to run software
controlled buck regulators, it is handy to have these options.

So I am back with some new devices that like to be redesigned for this
O/S and I was just checking my options. Looks like I need to design in
the STM32L051T8Y6 as it is completely missing right now. I am still
crawling through the .nut files to collect all options needed.

For the UART / LPUART, I was sure that ST did just recycle the
standard register setup as they did this in the past for the reduced
debug UART in the same way. There should only be some special clock
setup as it's clock is derived from the low power tree, I bet.

For the new approach, I'd love to se a simple terminal. Just send the files :)

Kind regards
Ulrich

2016-10-23 14:28 GMT+02:00 Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de>:
>>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:
>
>     Ulrich> Hi!  before starting an implementation myself, I wonder if
>     Ulrich> someone already prepared some code to add the STM32L051 series
>     Ulrich> of chips and especially the LPUART device that can be found on
>     Ulrich> all STM32L devices.
>
>     Ulrich> If not, I am gonna implement it now.
>
> (It seems that appended message did not get out. Maybe it was rejected
>  because of the appended file. This try with file not appended. Ulrich, mau
>  I send you the file in direct mail?)
>
> No, I have not yet worked with the LPUART. Beside custom board for the
> STM32F3, I have only disco and nucleo boards. To my knowledge, these boards
> don't bring out the LPUART. So developping for the LPUART is not as handy as
> for devices used on these boards.
>
> If I remember right, at some point you turned away from Nut/OS partly
> because most drivers at that time used multiple driver instances for
> multiple device entities inside one MCU.
>
> Harald tried a new approach with the usart_cb driver. However this approach
> queries queue fill level in the device independant code. To not interfere
> with the IRQ routines, the device independant code can only disable/enable
> IRQs global and does not work at all with DMA.
>
> However I have some approach for a uart driver that does the query in the
> device dependant code, using a common driver for all entities. I intend to
> add this code to SVN Head at some point.
>
> Find the code appended.
>
> LPUART and UART register map look quite similar. So getting LPUART basic
> functionality should not be too hard. If you need more special functionalty,
> i would be glad if you consider to implement it in a way that it also will
> work with my new approach.
>
> --
> Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion