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

[Ole Reinhardt]

Hi Harald,

> After 5 months ;-), I do have a question.
> 
> In r3998 a pointer to NUTRTC has been added as a parameter to all RTC driver functions. From what I can see, we have a single registered RTC only, stored in
> 
>  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?

> So, here's my question: What was the reason for this change?

I implemented the alarm feature.

The alarm feature works like this (currently only implemented for LPC)

struct _tm gmt;

gmt.tm_hour = 22;       
gmt.tm_min  = 34;
gmt.tm_sec  = 6;
gmt.tm_mday = 16;
gmt.tm_mon  = 2;
gmt.tm_year = 2012;

NutRtcSetAlarm(0, &gmt, RTC_ALARM_SECOND);   

/* Wait for an alarm */

if (NutEventWait(&(RTC_CHIP.alarm), 10000) == 0) {
    NutRtcGetTime(&gmt);
    printf("Got an RTC alarm: [%02d:%02d:%02d on %02d/%02d/%04d]:
Succeeded!\r\n", gmt.tm_hour, gmt.tm_min, gmt.tm_sec, gmt.tm_mday,
gmt.tm_mon, gmt.tm_year);    
} else {
    printf("RTC alarm timed out: Failed!\r\n");    
}



As you see I added the alarm event queue to the NUTRTC struct. But now
my interrupt function (alarm interrupt of the RTC) needs to know about
this even queue to be able to signal it.

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.

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
the system time and another one (e.g. with calendar and alarm options)
to be used with a synchronized time of some server. I also would like to
be able to later add more alarm resources.


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

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

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. 

Best regards,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280