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

[Thiago A. Corrêa]

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