[En-Nut-Discussion] Porting means breaking the rules?

[Ulrich Prinz]

Hi all!

I am still porting Nut/OS to CortexM3 and some of the things are going 
well now, others don't.

Keeping the structures that where built for AVR means producing a lot of 
code, slowing it down and increasing its size.

Example one:
The reason for having lots of #ifdef in the USART code of an AVR was, 
that you had to do a lot of things manually like handshake and direction 
switching of RD485 drivers.
With modern ARM7..11 and Cortex this is supported by the hardware.
Pro: keeping the option for using GPIO driven handshake signals enables 
the designer to use any pin for that intention.
Contra: Unreadable code, slow down of the system, one has to respect 
some cases where things have to be atomic.

My intention:
Keep an eye on the alternate pin functions while designing a layout and 
use the dedicated pins for the operation. The times, where TX and RX are 
positioned in opposite of the chip are over.

Second thing:
With moving the above functionality to the silicon, it doesn't make 
sense to encapsulate any optional feature into #ifdef conditions. So it 
is possible to write more or less one single driver for one peripheral 
having most of the peripherals features available. It is not e matter of 
the code, it is just programming of the right bits in the chip one time.
Together with the fact, that all ARM and Cortex CPU unified their 
peripheral register layout, this means, that you have a single driver 
and just exchange the base address of the device.
So a construct like
usart1_driver.c defines some things and includes usart_driver.c and then 
usart2_driver redefines them again and includes usart_driver again is 
not needed anymore. You have one usart_driver and with NutRegisterUsart 
you just pass the base address and the interrupt over to the one and 
only usart_driver.c.

But, you're right, this way means to loose some comfort, as the 
usart_dcb and so one are lost. So I'd like to get some ideas from you:

My idea, your comments:
NUTDEVICE devUsart_1
should define the usart for Nut/OS.
base_address:
The formerly not used base_address will take the devices base address 
for the unified driver.

first_interrupt:
This also not used entry will take the interrupt function handler for 
the usart, if configured.

dev_icb:
This things was not used before too. It can now be used to describe the 
interface features of the usart and the connected GPIO pins.
Why?
The devices on an ARM/Cortex/AVR32 can be configured to use different 
pins on the chip. There are up to 4 different sets of pins that can be 
assigned to work for the device or as GPIOs.
Putting these information into dev_icb enables two things at once:
in nutconf you can select the configuration with a simple drop down list.
Giving the right values, in a lot of CPUs pins and bits can be handled 
by special instructions making them atomic what saves some IRQ switching.

Third thing
There is a lot of troubles with the GPIO control interface.
There are defines that address the physical base address of a port. Then 
there are defines that address a logical port number.
Some functions like to see the first one, some the other. I can 
understand that on AVR, the address of a port might be smaller if there 
is only one byte used for addressing. On all other systems it doesn't 
matter as the architecture fits the byte into a word leaving the unused 
byte(s) free. What a waste if the address of a port could be used for 
atomic operation, using the CPUs setbit/clearbit functions.
With Cortex this again gets new options as any adddress of portions of 
the RAM and all device control registers have a bit-mirror in an virtual 
upper RAM. This means that one can address a bit of a device or a 
variable in the RAM directly for setting, clearing or comparison.
This allows bit manipulation in a single assembler instruction but the 
need is to have the bit manipulation definitions of Nut/OS done in 
another way.

So, please take a minute to post your guesses on these topics. Otherwise 
you'll get what I design :)

Best regards
Ulrich