[En-Nut-Discussion] devnut_m3n: Merging to trunk, the SVN way

[Harald Kipp]

On 23.08.2012 23:33, Ole Reinhardt wrote:
>>  static NUTRTC *reg_rtc;
>>
>> IMHO the extra parameter generates much more code than accessing a global variable.
>>
>> Beside that, it broke existing code, e.g. app/ftpd/. Although that had been marked deprecated, we should not do this without a good reason.
> 
> Sorry, but ftpd got broken only because it did access the driver API
> directly instead of using the RTC api, right?

That's how it was done at that time and you broke this and probably other custom code written at that time and I can't see why.


> So the question was how to implement this in a pretty way. I definitely
> did not want to reference any external global variable from my driver.
> So I decided to pass the rtc struct from the /dev/rtc.c api to each of
> my driver calls as parameter.

There still is the global reg_rtc and that confused me.

BUT, I fully agree, that your solution is better in long term.


> This would also allow to have more than one RTC at a time which might be
> an interesting option for some projects where you might have one RTC for

Mmmmhhh... forcing AVR users to spend significantly more code space just for the benefit of exotic systems with 2 RTCs?

Not really a good argument. BUT, I agree on your clean code argument.


> I know that you have a different opinion on this but I really would like
> to see this concept in much more drivers. E.g. for the UART drivers.

I had endless discussion about the UART driver and I'm not tired to repeat this over and over again:

In Nut/OS, the ATmega128 is able to keep up with 115200 Baud without handshake and without loosing characters. That's what the driver has been written for. Any new concept needs to prove, that it is able to maintain this performance on this platform.

The AVR is able to set or test a single bit of the UART0/1 hardware in one cycle. Later drivers for other platforms are simple copies, and they do not have any benefit from defining constant I/O addresses. That's why I call them dumb copies.


> This would help a lot to minimize flash usage if you could pass the
> device struct (wich could e.g. hold the BASE address of the used
> peripheral) to each driver api call instead of using the current c-file
> includes.

You are trying to mix topics to make an old man confused. But I'm not that demented yet. ;-)

Using structures for I/O access introduces other problems and should be discussed separately.


> This would also be needed to register more than one EMAC driver for
> example.

Are you sure, that registering more than one EMAC driver fails? My impression was, that the problem of more than one network interface lies in the IP code.

Again, another topic.


> If you have better ideas to implement this smoothly I'm open for every
> idea. But I really would like to keep some abstraction level and to be
> able to have more than one device of the same type registered at a
> time. 

As far as the RTC driver is the topic, I can confirm, that your solution makes sense to me now.

Regards,

Harald