Re: Removal of 8-bit AVR support (Re: STM32L051 and LPUART)

Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Tue, 25 Oct 2016 11:19:45 +0200
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Message-ID <[email protected]>
>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz-gM/[email protected]> writes:

    Ulrich> Hi Jonathan!  Do _not_misunderstand that!

    Ulrich> I would _never_ design out AVR from the original NutO/S
    Ulrich> repositories, I _forked_ to github and started to plan how to
    Ulrich> keep the CortexM system consistent with the original NutO/S.
    Ulrich> But it is too much work to do that, so I stay on NutO/S and I do
    Ulrich> _not_ design out AVR.

    Ulrich> Why did I thought about forking:

    Ulrich> 1) CortexM3 and higher supports unaligned addressing so it does
    Ulrich> not need more memory to handle 8-bit values. But it is a waste
    Ulrich> of capabilities as the R0 register is always used as first
    Ulrich> parameter in a function call but also always used as the return
    Ulrich> value. So you can always return a result in a function without
    Ulrich> any cost of code.

That is what uint_fastX_t and friends are for.

    Ulrich> 2) CortexM3 and higher have commands like rotate while load or
    Ulrich> shift while load. Complex bit manipulation does not cost any
    Ulrich> additional line of assembler code. But in AVR only a single
    Ulrich> shift or rotate is available resulting I very hand-trimmed code
    Ulrich> to avoid heaps of rotate loops and such. With CortexM there is
    Ulrich> no special attention to take.

This code should be in the nut/arch path and not in nut/dev. The uart_dma
code you have in hand is an attempt to have better division between those
things.
E.g. the /nut/arch code has a much better possibilities no know the fill
grade of the queue than the /nut/dev path has.

Another thing is the protection of 2 and 4 byte variables with a Critical
section. This is not needed with 32-bit systems. But a look at nut/dev/
shows that only the old u(s)art driver use it. So it is legacy, but does not
hamper us beside carrying old code around.

...

Bye
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion