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

[Ulrich Prinz]

Hi!

On 27.10.2011 10:02, Harald Kipp wrote:
> Hi Ulrich,
> 
> On 26.10.2011 21:19, Ulrich Prinz wrote:
>> Just to be sure to have everything in:
>> What is the latest greatest Nut/OS in the repository?
> 
> While the trunk was frozen, I applied all fixes to the 4.10 branch. A
> few days ago I synced the trunk with this branch, except Ole's autotools
> changes. They require directory moving and I do not have much experience
> with svn merge. I was afraid, that moving directories with merge may not
> work as expected. Still not sure, if I should apply Ole's commits manually.
> 
If you're using Tortoise SVN you can right-click drag-drop and the
select move versioned files here.
Then leave the work to tortoise to commit that all right. It will result
in a controlled delete / add action.
> 
>> upgrade all other architectures  to a working combination in devnut_stm32
> 
> Great.
> 
> 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.

Hmm.. I doubt that the core architectures are clear to everyone.
And I don't see so much differences and benefit from those more cryptic
names.

For ARM you find lots of differences in the core things as this older
cores left lots of freedom to the silicon integrators. The Cortex core
now unifies lots of it and makes system startup easy.

Second, the most differences are in the device drivers. So you still
need to create sub directories that are per manufacturer.

I know, a Cortex is an ARM too but I'd prefer to keep the names like
they are used in the world and most people will speak of ARM for the
older chips and they use Cortex for the new Generation.

I didn't dig into CortexM0/M4 or even Ax. So I cannot give an idea of
how much additional subdirectories there are needed below Cortex.
But for CortexM3 I am sure that the startup can be handled by my CMSIS
implementation for all of them, STM32, NXP, ATMEL and TI.
> 
> While you will be moving a lot of files: Please try to avoid upper case
> letters and non-alphanumerical characters in file and directory names,
> except underline and dot. Upper case letters spoil sorting and should be
> used only, if this is intended, like with 'README'.

I do not remember that I used anything else for names and directories
but underscore and lower case letters. I hat uppercase and special
characters in dir-/filenames for the same reason you do and it will give
a pretty mess if you use this code under windows and linux.
> 
> Special characters introduce all kind of complications. To give an
> example: Consider the global definition 'cortex-m3' to be defined in the
> Configurator as a directory name and C makros. We will end up with
> 
I hope I didn't do that,
>  #define cortex-m3
> 
Nice compilation error if cortex and m3 are not defined as variables
that could be subtracted  :)

I use only one definitely needed define and that is __CORTEX__.
You need it to reuse lots of existing code but introduce some important
changes to some things.

The reason is that Cortex is an ARM but the code needs to be different
for both. So I made some includes like
#if defined (__ARM__) && !defined(__CORTEX__)
do this
#elif defined (__ARM__) && defined (__CORTEX__)
do that

Especially the startup code needs this as some things are the other way
round with cortex than with ARM or AVR.
Cortex fires up to the configured speed first, then sets up all
interrupts and copies over / clears data and bss segments. No assembler
code involved there. On ARM its pretty different.

Example two is the systick. The init code of the sysclock and PLL does
most of work automagically. You just set up the source clock and the
target sysclock speed you like to have. If the source is an xtal, you
set the frequency. Build nutos and you're done. No flags, no fuses no
bit hassling. Pretty plain easy.

But the systick is set up fixed to 1ms and that is done by the same code
from above in one step. But with ARM and AVR some routines where fired
that try to catch a counter and to recover the timer setup for that
counter by counting the sysclock cycles...

The only thing that I might have lost while porting is the delay loop...
I did something to it, but then I never checked if it really hits the
spot. I never needed it as all drivers work on interrupts or DMA or flags.

Everything else I #defined is special for STM32 architecture and it is
complicated to set up, but then hides from the users eyes. :)
Ok, the whole STM32F1xx Family is covered and so I needed to add an
STM32_xxx feature defines for almost every component of these chips
internal devices.
And then I needed another set of #defines that enables the switching of
all those devices to their different pin-sets.
It was a bit of horror to evaluate all this, but configuration of the
CPU to use the right Pins for your board is easy now. All is done in
qnutconf and it is saved along with the conf file.

But all those defines hide down low in the .nut files and the low level
device drivers. Normal user does not see them and if he likes to design
his own driver or support in the Cortex implementation, I tried to use a
naming convention for his comfort. So he will find his way or bomb me
with emails.

And then I need to discover the STM32F2xx too, I got the DevleKit month
ago but had no time...
I cries to be the next generation internet radio including software
decoding and some DLNA. Definitely.

Best regards
Ulrich