[En-Nut-Discussion] WG: Ethernut on 8051-architecture chip?

[Bengt Florin]

Hi all,

Back in the mid 80's I was a heavy user of the 51-family and I must
admit that in the ligth of the earlier single chips cpu's the
51 was really outstanding. This was however in the dark age of PL/M and
assembler.
Then C entered the embedded arena and a new way of thinking grew.
Now you code even the smallest chips hardly using any assembler at all and
this is really fine and beautiful.
To make it even more beautiful, you now also use small multithreading
executives
like Nut/OS or similar on these tiny machines.

However the 51 architecture was neither thought to be programmed by C nor
controlled
by multihreaders and that's why this increases the challange.
Of cause this can be done, it's all a matter of software, but it will also
make some
serious performance hit on a already outdated and slow cpu.

I recently ported a program running on a AVR to one of Analog Devices 51
chips, the
ADuC847, as I liked the idea of using 16 and 24-bit onchip ADC's.
I used no multithreading executive but rather my own event sheduler
optimised for
use in small cpu's by using only a single stack.
Running at the same clock, around 12MHz, the 847 seemed to be 4 to 5 times
slower.
Now the 847 is a fast one with one clock per cycle. Some of the 51's out
there
needs up to 12 clocks per cycle and that's not very impressive.
After this I said loud to myself, 'no more 51:s for you, old chap'.

BTW I used the Keil compiler for the 847 and gcc for the AVR.
The Keil compiler does a really good job, but you have to pay for the full
version (1000Euro?)
as the free limited version is way too limited.
The SDCC seem to be a promising alternative nowadays but I haven't tried it.

Oh well, performance isn't all in the world any longer, ease of use and
time-2-market,
sometimes dictates the rules we obey and using multithreaders certainly make
it easier to comply with those.

So in what ways may the 51 be a more challinging candidate to port NUT to?

1. The use of a limited hardware stack.
2. Function parameter passing in registers.
3. Harvard architecture.

Well, maybe the third point isn't really a multithreader problem but rather
a C one.
It forces you to write duplicate functions taking parameters from different
memory regions.
The AVR also posesses this 'problem', look at all the xx_P() functions and
this is a real
pain in the lower back IMHO.

The first point is the most limiting one. This forces one to either live
with the limited stack
and share it between all threads, or to to use stack swapping between
context switches.
As the stack is maximum 128B (or is it 256) the first alternative doesn't
sound too fancy.
Stack swapping means that you have to copy the whole, or at least the used
part, of the stack
for that thread to XDATA. XDATA is one of the 51'smemory regions and can be
up to
64KB, some of it, 2 to 4KB, is normally on the same chip.
So for every context switch we have not only to save all working registers
but the whole used stack
as well, up to 128B more that is.
This is probably not very good for the performance.
Also this most likely have to be done with interrupts disabled as well so
the interrupt stack is not corrupted.

The second point means that writing reentrant function isn't a walk in the
park.
Function parameters are normally in C passed on the stack, yes gcc for AVR
et al uses registers
for the first two or three parameters, but that's more an optimisation than
a requirement.
Besides the compiler handles all the reentrancy so you don't have to think
about it at all.
The 51's can't handle stack data very efficient so parameters are passed in
registers or
in fixed XDATA memory locations.
Some compilers however support a keyword to make functions reentrant.
Now, the NUT/OS is luckily cooperative so the use of reentrant functions
isn't that heavy,
but for all functions called from interrupts you must be really careful.

So, in my opinion there are loads of better candidates to port NUT/OS to,
but as Ernst say
there are a LOT of 51:s out there.

But if you have some time to kill and it sounds just like the right and fun
thing to do.
So go for it, glory is at the end of the tunnel!


A really HNY to all NUTs out there,
/bengan

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Ernst Stippl
Sent: den 29 december 2007 20:20
To: 'Ethernut User Chat (English)'
Subject: [En-Nut-Discussion] WG: Ethernut on 8051-architecture chip?

Hi!

Does anybody know about a port of Ethernut to an 8051-type chip?

I think I remember an email asking the same some years ago, but I did not
find any conclusive answers.
Yes, the 8051 architecture has its limits, and there is no GCC support for
it - SDCC seems to be an often used compiler. This would pose additional
challenges.
But looking at the sheer volume of 8051-architecture based chips still in
use - wouldn't such a port help Nut/OS to establish itself further in the
embedded market space? 

What do you think?

Regards & and a happy new year

Ernst

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion