[En-Nut-Discussion] Which is the latest greatest branch

[Ulrich Prinz]

Hi!

On 28.10.2011 10:55, Harald Kipp wrote:
> Hi,
> 
> On 28.10.2011 06:19, Henrik Maier wrote:
>> On 28/10/2011 3:54 AM, Thiago A. Corrêa wrote:
>>>> Instead of dividing arch into arch/arm and arch/cm3, I propose to use
>>>>>  arch/armv4t, arch/armv5t and arch/armv7_m. The first two should contain
>>>>>  the ARM7TDMI and ARM9EJ-S architectures we currently have in arch/arm
>>>>>  and the latter will take the Cortex-M4. Code, which is valid for all ARM
>>>>>  architectures can be left in arch/arm.
> 
>>> What about borowing linux tree layout:
>>> arm/boot
>>> arm/include
>>> arm/march-at91
>>> arm/march-cortex
>>> arm/march-s3c24xx
> 
>> So something like:
>>
>> arch/arm                  [generic ARM stuff like context.c]
>> arch/arm/at91       [stuff for all AT91 devices]
>> arch/arm/at91/sam9  [specific to this series]
>> arch/arm/at91/sam7
>> ...
>> arch/arm/cortex     [stuff which can be shared across all Cortex MCUs]
>> arch/arm/cortex/cmsis [latest version of the CMSIS]
>> arch/arm/cortex/m0
>> arch/arm/cortex/m3  [not sure if we would need those "m" subdirs...]
>> arch/arm/cortex/m4
>> ...
>> arch/arm/stm32      [generic STM32 stuff]
>> arch/arm/stm32/f1   [specific to this series]
>> arch/arm/stm32/f2
>> arch/arm/stm32/f4
>> ...
>> arch/arm/lpc/lpc2xxx
> 
> The main idea is to avoid as much duplicated code as possible, right?

No, I think Henrik ( and I) prefer it exactly the other way round. I
would be happy if there are some drivers duplicated across different
architectures but they work perfectly.

Now you stumble over dev/dm9000.c dev/dm900e.c dev/avr_d9000.c.... (just
an example). So you have no idea which of them is actually in your code
if you build nutos.
To make chaos complete you cannot even be sure which lines of a single
file are in your libraries after you compiled it as there are many
#ifdes in them.

I would prefer a dm900e.c that may be a 99% copy of an existing one but
it works and is there where I expect it.

And then, if I see that there is only one line different, or if I fix
something in my architecture interface I don't need the copy with the
one line fix, I can move it from the chip level to the arch level or to
the general devices...

Example:
I add KSZ8851-16MLL driver to STM32. I test it only with STM32 so I can
only release it for that architecture.

Now you think, nice Chip but I need it for SAM7S. In actual structure
you take my driver and modify it until it works with SAM7S. But you
cannot test if it still works on STM32 and I have no time to do so.

Ole comes in and sees, hey cool! I need this chip with STM32, tries it
and fails. Ouch!

So with Henriks directory architecture, you copy my driver from STM32 to
SAM7S, modify it and it works. It then doesn't matter if a third guy
needs this chip with one or the other architecture, it works.

As we might then still be freinds, we two talk to each other and commit,
that we would unify this driver. So we merge the code, test it and then
we delete the two separate ones and add the unified into ARM tree.

Again, this duplicates files but it guarantees a more working system
with less inter-architecture or inter-chip dependencies.

> 
> IMHO, the problem with Ulrich's and Thiago's suggestions is, that they
> didn't properly distinguish between CPU architecture and peripheral
> architecture. Your suggestion goes in this direction, but...
> 
> AT91SAM3 and STM32 are based on Cortex-M3, while AT91SAM7 is based on
> ARM7TDMI. Would you suggest arch/arm/at91/sam3?

I never said that I couldn't differentiate between the correct core
architectures :) I said that I don't like this as it will bother the
newbies and makes them giving up their newly discovered hobby.
Name the childs by their names and not by their tax number codes.
> 
> Cortex-M0 and Cortex-M1 are almost the same, providing a thumb2 subset.
> Cortex-M3 and Cortex-M4 are similar too, they have a full thumb2
> instruction set.

That is something the Makefile and compiler gurus have to know and to
set up properly in them. It is even important to know for the porting
guys and architecture maintainers. But it is definitely nothing for a
simple application programmer.
> 
> When looking to the peripherals, some SAM7 and SAM9 devices are more
> similar than a new SAM7 compared to an older SAM7. The funny thing is,
> that many peripherals of the ARM-SAM CPUs are available in AVR32 as well.
> 
That isn't funny that is logical. ATMEl designed IPs that connect to a
cores bus. So they just license the core from ARM and assemble it with
their already designed or bought/licensed IPs.

If you look at the more complicated protocol IPs like MMC, Ethernet or
USB, you find that these have in many chips more or less the same
registers and bits inside the registers. And many chips means regardless
of the name on the top of the chip or the manufacturer logo.

Could be that you can write an EMAC driver that works on STM32 and TI
DSP and Pic32 and even AVR32... Its the same IP licensed from the same
company. Nobody invents the wheel a second time :)

> Ulrich's implementation of  __CORTEX__ is needless, because the GNU
> compiler automatically provides __ARM_ARCH_7M__, when using option '-m
> cpu=cortex-m3'. Other compilers will use similar predefined macros.
> 
This was not the case at the time I started with cortex or it was pretty
good hidden in the gcc specs. Thank you for that hint, I'll modify that
in a later state of the merge.

> Let's assume, that all architecture dependent simply got
> 
>  #include <arch/arm.h>
> 
> then this header will will simply contain
> 
>  #if defined(__ARM_ARCH_4T__)
>  #include <arch/arm/armv4t.h>
>  #elif defined(__ARM_ARCH_7M__)
>  #include <arch/armv7_m/cortex_m3.h>
>  ...
>  #else
>  #error ARM architecture unknown or not specified
>  #endif
> 
> The compiler automatically selects the right one.

That is good to know, I only was aware of the __ARM__ token that is
already existent in nutos code in many places. So we should generally
exchange this by the real
> 
> Right now, I'm quite confident, that my solution is the most simple one.
> Though, I must admit, that I haven't really checked all side effects. So
> I'm curious about your responses.
> 
> P.S.:
> 
>> dev  [device drivers which can be compiled for any architecture (wishful 
>> thinking?)]

Yes, but preferably not as it is today. Allow duplicated drivers, let
them climb the stages and rise to a unified driver if possible.

And some times they will never be unified as the specialized version
will be much more effective.

Good example may be the EMAC or MMC drivers again, as they could and
should be written with a unified interface. The even work internally the
same way... But one chip uses a single IO address for sending the
packets while others use a shared memory or even a designated RAM area.
Probably the same code can be used for all of them but it differs in
some single lines.
In the stage of developing today, the driver may pop up as dev/mmc.c in
nutos. Now everyone sees it and thinks 'great, I need it for my CPU' and
it fails. So he modifies/fixes/adopts it and probably kills the original
creators code and it doesn't work on his CPU...
So we start playing ping-pong.

That's it so far with my opinion.

Ah, and then there might be a great advantage for you, Harald:
You could name maintainers for different architectures and other parts
of nutos. Give that AVR32 to Thiago and STM32/CortexMx to me and you
don't have to do all that integration things alone anymore.
Automated script compiling tells you only if there are code errors a
compiler could find. It doesn't tell you if there is something addressed
wrong. You only find that if you have a kit to run the code on.

Best regards
Ulrich