[En-Nut-Discussion] Removal of 8-bit AVR support (Re: STM32L051 and LPUART)

[Ulrich Prinz]

Hi Jonathan!

Do _not_misunderstand that!

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

Why did I thought about forking:

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

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

3) In CortecM0 things get worse as this ARM core has a very reduced
instruction set. If you nor use AVR 8-bit optimized code, the
resulting code may be less effective and bigger in size. We need to
check that when the initial project push is over and we have more time
for analysis and optimization.

However, it was no plan to rip out the AVR from the original NutO/S!
THe only thing I would really appreciate would be to move completely
to git instead of this SVN. However until then I use git svn
extentions.

Hope I saved you day :)

Cheers!
Ulrich

2016-10-25 0:18 GMT+02:00 Jonathan Woithe <jwoithe at atrad.com.au>:
> Hi Ulrich
>
> On Mon, Oct 24, 2016 at 02:17:53PM +0200, Ulrich Prinz wrote:
>> 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.
>
> This is worth knowing since we will be continuing to rely on the 8-bit AVR
> capability for some time to come - it works well for our application and we
> can't justify redesigning our systems for an alternative microcontroller at
> this stage since it won't gain us anything practically.  I hadn't heard
> about this AVR removal plan until now (however, I often only skim the
> mailing list so I could easily have missed something earlier).  It means
> we'll end up sticking with the last NutOS release to include AVR support,
> whatever that turns out to be.  At present we are on 5.1.0.
>
> I can understand the motivation behind the removal.  Aside from any security
> fixes which crop up, a NutOS for 8-bit AVR has been complete for some time
> now, and maintaining it within the larger NutOS context is therefore not
> gaining anyone much.  The biggest changes recently have been to support
> newer versions of gcc.  It doesn't mean it's not still useful though.  :-)
>
> Is there any indication as to when 8-bit AVR will be removed from NutOS?
> Presumedly the feature removal will be noted in the release notes at the
> time.
>
> Regards
>   jonathan
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion