| ??? 04/20/10 11:45 Read: times |
#175168 - Re: The Atmel Scheduler Responding to: ???'s previous message |
Michael Karas said:
1) It does not appear to be too heavy weight. But it does add inefficiency into your program execution. Glad to hear the is not so heavy. I am aware that it adds inefficiency to my programm execution, but I think is a good tradeoff. The idea is that, I didn't had to deal with USB protocol very much. I had studied USB protocol, but everytime I started something the cruel reality is that is not so simple, so for me it was pretty good. Michael Karas said:
2) Using this thing does add a layer of abstraction to the programming for a project which, in my opinion, adds more complexity to your sources and to the debugging process. I would _not_ be willing to accept this extra complexity for one of my projects. About complexity as I said we speak about tradeoffs, about the debuggin I fully agree that it was/is a pain in the ass. And somehow I had been forced to digg in somebodyelse's code, which is not always a pleasant thing to do. Michael Karas said:
3) There appear to be several scheduler functions to which I could see no source code. Two examples are Scheduler_call_next_task() and Scheduler_new_schedule(). I would be loath to apply code from a "free" web page into a commercial project without full source for everything. I am sure that you have the code, please look in scheduler directory: scheduler.h and scheduler.c, and is quite clear. Michael Karas said:
If it turns out that your application is good enough with a 10Hz to 16.6Hz sample rate (100 msec -> 60 msec) then using this "scheduler" is probably going to be ok from a performance standpoint. On the other hand if you were trying to build something that wanted to use a sample rate that was 10x or 20x as fast then I would suggest direct coding the algorithms instead of hiding them inside the fuzz of this scheduler. So, for a 12MHz is good, this is a good news for me. So far I had pushed the page write routine to timer 2 interrupt function and from my first tests I've seen that is much better. I am thinking to move also the sensor routine from user_application task to ISR routine. If the time slice is 60ms, sensor routine execution takes 7.5ms and page write memory routing 27ms I think is ok for the moment. Again I just want to get something stable, after I am going to refactor and redesign the application once again. |
| Topic | Author | Date |
| I2C page write and interrupts | 01/01/70 00:00 | |
| Some Important Things to Consider | 01/01/70 00:00 | |
| Re: Some Important Things to Consider | 01/01/70 00:00 | |
| You just buffer things | 01/01/70 00:00 | |
| ISR + superloop normally enough | 01/01/70 00:00 | |
| A Quick Reply | 01/01/70 00:00 | |
| Re: A Quick Reply | 01/01/70 00:00 | |
| Confirmation | 01/01/70 00:00 | |
| The Atmel Scheduler | 01/01/70 00:00 | |
| Re: The Atmel Scheduler | 01/01/70 00:00 | |
| Your times seem quite long | 01/01/70 00:00 | |
| Re: Your times seem quite long | 01/01/70 00:00 | |
| The problem seems to be different | 01/01/70 00:00 | |
| Time to closely read data sheet. | 01/01/70 00:00 | |
| Re: Time to closely read data sheet. | 01/01/70 00:00 | |
Write a generic function. | 01/01/70 00:00 | |
| Paged operation very common | 01/01/70 00:00 |