Go Down

Topic: mini RTOS [sic] (Read 4 times) previous topic - next topic

MartinFick

Well, I know that you seemed to think that inclusion in the core was not an important question, but a non user-definable method to allocate space for these Alarms/event seems unreasonable if this library is ever going to be a part of the core.  Mem has done a good job of keeping resource usage (RAM) very low for users of his suggested library, but it still uses 60 bytes!  That seems unacceptable to me for core inclusion considering that some people may never even want to use these Alarms.  Choosing a lower default number of Alarms does not seem like a good core solution either, and neither does making things compile time options.  So, if this is ever going to be considered for core inclusion I would suggest a different approach for allocation memory.  However since Mem did do a good job of minimizing RAM usage, any core implementation would probably take up more RAM and therefor as a standalone library his solution may be better.

If libraries are never going to be core solutions, compile time options may well be good solutions, especially if the library does something very specialized that could greatly benefit from compile time options to either save RAM or to increase speed.  For example: I am working on an LED TDM library and have come to the conclusion that speed is paramount.  Although I would like to create a library that could be easily used without recompiling, I have determined that this would potentially mean a significant (3x) speed decrease.  Since this might very well push the library utility out of the problem space that it is trying to address in the first place, this does not seem worth it.  I will probably leave certain things compile time options for this TDM library.

While I certainly agree that the programing interface is important to keep simple, the target user audience is also somewhat dependent on whether a library is meant for core inclusion or not.  Obviously we want to keep interfaces simple, but often times a sacrifice in simplicity is warranted for better performance or flexibility.  Sometimes the only way to make good decisions about which of these tradeoffs to make is by deciding who the likely target audience is.

mem

#16
Aug 06, 2008, 06:16 pm Last Edit: Aug 06, 2008, 06:17 pm by mem Reason: 1
Allowing the user to create his own callbacks is easy and probably not much more complicated for a newbie to use (it would look similar to the way attachInterrupt works). Only uses two more bytes per instance so nothing to worry about there.

Creating instances of alarms (or whatever they will be called) at runtime to minimize RAM usage to the minimum needed has also been implemented, I started out with a version of the library that allows the user to create instances of the timers he needs so memory is only consumed when needed, but it seemed a less friendly to newbies then the simpler version posted earlier.

Here is a fragment from one of my test sketches that creates three instances

Code: [Select]


AlarmClass Timer1;  
AlarmClass Timer2;
AlarmClass Timer3;

void setup(){
 // you can register time of day Alarms at any time but really shouldn't enable them until the internal clock is set

  if( dtAlarms.registerTimer( &Timer1 ) ) {        
    Timer1.value = DateTime.now() + 11;   // fire at the time of day 11 seconds from now
    Timer1.Mode.isTimeOfDay = true; // the value given above is a time of day
    Timer1.onTickHandler = &OnTimer1Tick;
    Timer1.enable();  
 }
  if( dtAlarms.registerTimer( &Timer2 ) ) {        
    Timer2.value = AlarmHMS(12,30,0)    // this is 30 minutes after 12 noon
    Timer2.onTickHandler = &OnTimer2Tick;
    Timer2.Mode.isTimeOfDay = true;
    Timer2.enable();  
 }
  if( dtAlarms.registerTimer( &Timer3 ) ) {        
    Timer3.Mode.isTimeOfDay = false; // the timer value is treated as a delay in seconds, not absolute time
    Timer3.value =  13;   // delay in seconds from the time this alarm is enabled
    Timer3.onTickHandler = &OnTimer1Tick;
    Timer3.enable();  
 }

}

void OnTimer1Tick(void *Sender){

 if( Sender ==  &Timer1)
     Serial.print("Timer1 event: ");            
  else  if( Sender ==  &Timer3)
     Serial.print("Timer3 event: ");      
 timeDisplay();    
}

void OnTimer2Tick(void *Sender){
   Serial.print("Timer2 event: ");  
}

hotcarrier

mem,
can you tell me what to modify to get your dateTimeAlarm library to run with 0012? I am seeing the
same kind of library compile errors others have seen with moving to 0012

mem

#18
Sep 25, 2008, 06:07 am Last Edit: Sep 25, 2008, 06:08 am by mem Reason: 1
Quote
can you tell me what to modify to get your dateTimeAlarm library to run with 0012? I am seeing the
same kind of library compile errors others have seen with moving to 0012

In the DateTimeAlarm.h file comment out the following line:

[font=Courier New]//#include <wiring.h> // this line must be commented out or removed for 0012
[/font]

hotcarrier

mem,
Did you mean TimerAlarms.h ? I tried commenting out the include in TimerAlarms.h but it did not work. Same kind of errors at compile time. Any other ideas? I am using the Mac version.

Go Up