[En-Nut-Discussion] Unified GPIO implementation

[uprinz2 at netscape.net]

Hi!


I added this to the wiki. 


The intention of GpioApi is to provide easy to understand functions for general purpose use.
Anyone who needs to use Gpios as fast as possible will write direct access functions.


I access architecture specific GPIO ports directly in any architecture specific driver I write. That is never a problem for anything that is in nut/arch/...
But general drivers need to respect that they are called by different architectures. So in this case it will be a problem if the general GPIo drivers are not optimized to a good compromize of speed and size.


Ah, no I didn't say uint_fast16_t as Cortex do support half word arithmetics. But you're right, it might be the better choice as ARM does 16 bit only in thumb mode and may produce overhead if in ARM mode.


On the other side it is senseless to talk about uint_fastX_t as I asked for using the header-file wrapper.
gpio.h only includes the right architecture specific xxxx_gpio.h.


The unification of Gpio functions is not done by the defines and headers in gpio.h but by the whitepaper that should be transformed into a red-book some day in near future.


So a AVR will use 
void GpioPinSet( uint8_t port, uint8_t pin, uint_fast8_t val);
an AVR32/ARM will use
void GpioPinSet( uint32_t port, uint32_t pin, uint32_t val);
and the Cortex may use

void GpioPinSet( uint32_t port, uint32_t pin, uint_fast8_t val);


With declaring the definitions by paper instead by preset defines we are open for:


AVR:
#define NUTGPIO_PORTA   0
ARM
#define NUTGPIO_PORTA   0
Cortex
#define NUTGPIO_PORTA  0x40010800


Actually now I use one simple table to transform the Nut/OS way of port addressing into Cortex conveniant way. Doing this reduced the original STM driver to less than 1/3 of its former size by increasing speed over 4 times.


Using the above way of directly accessing the ports will again reduce the code by around 25% and might rise speed by over 40%. Some functions will probably double their speed.


For the normal Nut/OS user this stays fully transparent. He doesn't need to know that behind NUTGPIO_PORTx are totally different values on the different architectures.


Ok, the rest of the proposals I already wrote into the wiki. Feel free to modify and / or comment it there or here in the list.



Best regards
Ulrich



-----Original Message-----
From: Harald Kipp <harald.kipp at egnite.de>
To: en-nut-discussion at egnite.de
Sent: Thu, Oct 7, 2010 10:04 am
Subject: Re: [En-Nut-Discussion] Unified GPIO implementation


On 06.10.2010 20:46, Ulrich Prinz wrote:

> But for easy 
> code reading, portability and others I could agree to either 
> uint_fast8_t or uint16_t.

You probably meant uint_fast16_t.


> I don't know about AVR32 but with ARM/Cortex it would produce overhead 
> as you have to recalculate from pin number back to address of port.
> That produces much more overhead than to pass over a second parameter.

In a way, you are right. But...


> I would like to remind that we have two entry ways into Nut/OS:
> 1) High portability
> 2) High optimization

2.1) Minimal code size
2.2) Maximum performance

... this extra overhead is introduced in the called API function only.
The callers will benefit from the reduced number of parameters. I'm
quite confident, that using pin numbers instead of port/pin pairs will
significantly reduce the overall size of today's Nut/OS libraries.

I'm not sure about the number of instruction, that are required to set a
specific port pin. They may indeed increase. (The ARM's barrel shifter
can handle the required shift within a single instruction, but this is a
special case.)

Anyway, IMHO the GPIO API never intends to provide performance, just
portability. For fast execution, no portable library will ever
outperform machine specific code.


> I will add my proposals now for GPIO into the Wiki and now with respect 
> for AVR32.

Thanks,

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