Asynchronous Driver Design

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this post I explain an asynchronous approach to writing a proximity sensor driver.

 

http://oskit.se/asynchronous-pro...

 

I would appreciate constructive feedback on this approach and suggestions of what would work better (or suggestions regarding approaches that you guys use yourselves). Nonetheless this is my personal approach and it works great as an alternative to multitasking for projects that run on the AVR.

 

I think that on the avr, processor resources are scarce and so we don't want to waste cycles in delay loops using _delay_x() as would be done in a synchronous approach. Instead, it is better to write the whole application in a way that is completely event driven. It is a form of "static" multitasking where different processes are happening "simultaneously" by means of keeping track of the current state of what whatever each part of the application is currently doing.

 

I'm working also on a completely asynchronous kernel that I will be using in my own projects. It is on github if you follow the link to the code in the post.

LibK - device driver support for flash based microcontrollers: GitHub project

http://oskit.se - join me on my quest to become a better programmer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are aware of the issues of using callbacks in terms of reliability?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In relation to buffer overruns?

 

Other than that, what is your argument against using callbacks?

LibK - device driver support for flash based microcontrollers: GitHub project

http://oskit.se - join me on my quest to become a better programmer

Last Edited: Tue. Oct 7, 2014 - 12:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Other than that, what is your argument against using callbacks?

The compiler does not know what's going to be called so has to PUSH/POP all the call saved registers - it's very inefficient.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Other than that, what is your argument against using callbacks?

The compiler does not know what's going to be called so has to PUSH/POP all the call saved registers - it's very inefficient.

 

I have covered that in one of my posts on my website. I'm fully aware of this. I have also done benchmarking that showed exact differences. If I can remember right, plain call was 250ns and function pointer took 950ns. Also callbacks result in all code that is assigned to a callback, and all code that it calls, even if the code never runs, to be included into the final executable.

 

BUT, here is the catch. The overhead of calling a callback is CONSTANT time - it does not change. So if the overhead of calling a callback is 12 clock cycles and your callback code is 12 instructions then you have a 100% overhead, but if the code that gets invoked is 1200 instructions then the overhead is 1%. This is why it is justifiable to use this model in larger projects and you don't even have to worry about the overhead as long as you don't call A LOT of function pointers in some kind of tight loop. But yes it's true, if the timing is absolutely crucial then one may want to avoid using callbacks completely.

LibK - device driver support for flash based microcontrollers: GitHub project

http://oskit.se - join me on my quest to become a better programmer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Callbacks can be party to some nasty defects. If your function pointer gets corrupted due to physical or software means its destination is indeterminate. MISRA  had a rule against using them. If you're just flashing a led, then there is little consequence but if the application is more critical, then you might want to avoid callbacks.

 

Constant time is great for determinism, but if its constantly slow then it is not much use. On an AVR class app, you might want to avoid unnecessary delays. For a cortex m4 class app, the overhead is most likely minimal. On an AVR, ram, cpu clocks and flash are in short supply.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"MISRA  had a rule against using them."

 

I've always been somewhat curious about this. One could make an argument for using a system with no RAM at all, on the grounds that stacked return addresses could be corrupted. Come to think of it, why stop there? Since registers are probably implemented in the same way as RAM, probably best not to use them either. I suppose it all boils down to the corruption mechanism - are MISRA worried about corruption from RAM failure/alpha particles/power glitches/Uri Geller or are they worried about buggy programs stomping on RAM?

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

or are they worried about buggy programs stomping on RAM?

That one I think.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for a critical system, i'd be worried about all of them. Minimising sources of failure is a wise thing. I would suspect that badly computed or corrupted function pointers due to stack overflow or array bounds overflow are a common defect that MISRA was wanting to address. Environmental corruption can be mitigated by hardware. Space guys are particularly worried by high energy particles upsetting the execution of what might be perfectly good code.

Last Edited: Thu. Oct 9, 2014 - 12:18 PM