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

[uprinz2 at netscape.net]

Hi Thiago!


Sorry not to mention that before, but sure, I didn't want to rip needed features. Modem control lines that are not provided by the hardware need still to be handled in software. But with the advanced GPIO access this could be done faster than with the indirect GPIO control.
Devices like the STM32F10x series provide several USARTs with hardware RTS/CTS not only one.
That is a thing that makes nutconf descriptions very complex.


For instance you can decide to have one usart configured to use 2..4 different pin layouts. But these pins change depending on the chips sub type and case. To avoid having very large tables for that I just let the user select one of the four alternate pin configurations and tell him to check the chips documentation where to find the signals.

Ah, and another thing: I don't want to break up existing configurations. So as the ARM and the AVR32 support the indirect way of GPIO addressing, I don't throw it out.


Thanks for the ideas,
I'll respect it.



-----Original Message-----
From: Thiago A. Corrêa <thiago.correa at gmail.com>
To: Ethernut User Chat (English) <en-nut-discussion at egnite.de>
Sent: Wed, Sep 1, 2010 11:49 pm
Subject: Re: [En-Nut-Discussion] Porting means breaking the rules?


Hi Ulrich,


     Are we talking just about ARM here?

On Wed, Sep 1, 2010 at 6:17 PM, Ulrich Prinz <uprinz2 at netscape.net> wrote:
>
> 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.

There are a few problems that I can see with this:
Some designs might stop working. Also, it's not uncommon to have
sillicon bugs in those advanced features.
Also, most chips I've seen doesn't offer flow control functionality in
all ports. It's also very uncommon to provide DTR, and again, if it
does, usually only in one port.

DTR is important to some devices, for example, some CNC drilling
machines use it and won't let you download the CNC program without a
DTR signal. It is sometimes desireable to be able to control that. The
atmega driver allows it using an ioctl call.

> 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.

Couldn't we do that and still keep GPIO controled uart signals?
The functions in the driver could be the same, and just pass a struct
with the device information, like base address to access registers and
port/pin numbers for the GPIO signals, if they are defined.

Kind Regards,
    Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion