The Digispark > Digispark Libraries

Set of libraries to manage RC incoming and outgoing pulses (RC Rx/Servos/ESC)

(1/3) > >>

RC Navy:
Hi all,

Please find attached a set of asynchronous (non blocking) libraries dedicated to RC validated for the Digispark.

It manages:
- incoming pulses from standard Receivers -> <SoftRcPulseIn>: nice to read pulses from receivers
- outgoing pulses -> <SoftRcPulseOut>: nice to control servo and ESC

<SoftRcPulseIn> relies on another (also provided) library <TinyPinChange>.

All these libraries are provided with examples.

I have some other librairies to test with the Digispark before releasing them. Currently, they are only validated for UNO, ATtiny84 and ATtiny85 with the official arduino 1.03 (not the Digistump version for the Digispark).
As soon as I will have validated them for the Digispark, I will share them.

If you are curious, you can have a look to my RC dedicated (UNO/84/85 ready) libraries: http://p.loussouarn.free.fr/arduino/asynchrone/asynchrone.html.
Sorry, my site is in french, but if there is some interest with my librairies, I may translate to english...

Enjoy,

RC Navy

Bluebie:
These are really cool! TinyPinChange is an awesome addition too. I think we should include it in the digispark software, not just as a library, but build it right in to the attachInterrupt system! What do you think of this idea? Otherwise I think the TinyPinChange library should at least be built in to the Digispark software so all open source digispark projects can use it without people having to download. It's just too useful!

RC Navy:
Bluebie,


--- Quote --- I think we should include it in the digispark software, not just as a library, but build it right in to the attachInterrupt system!
--- End quote ---
I provide this library "as is". You are completely free to tweak it as you need (I can give some support if needed). I created it because I wanted to use some pin change pins along with <SoftwareSerial>, but this one monopolizes the "pin change interrupt vector". That's why I also created a variant of <SoftwareSerial> but which relies on <TinyPinChange>: <SoftSerial>. Now, all the pin change is centralized into <TinyPinChange> as depicted below:


If you are not familiar with french language:
"Broches d'entrée" stands for "Input pins"
"Broches de sortie" stands for "Output pins"
"Sketch Utilisateur" stands for "User sketch"

I know that this approach adds some code overhead, but sketches are easier to write/debug and most important: all the code is asynchronous.
It's very easy to make several actions/tasks which seems to run in parallel. 8)

I hate to see delay() or pulseIn() in a sketch: all the sketch is blocked with these kind of functions, yuck!  delay() or pulseIn() are very nice to start programming with arduino, but when the tasks have to run "in parallel", we have to use some "advanced" programming using "asynchronous" approach.

It's amazing what we can do with a tiny microcontroller such as an ATtiny!

I continue to port/test my other libraries for the Digispak...

Regards,

RC Navy

bjh:
Thanks for this!  I tried SoftRcPulseOut with a couple TowerPro SG90s and it seemed to basically work  :)   I still plan to finish my own (synchronous) library SimpleServo which jitters less in my testing, but it'll be nice to have options.


Being able to read input from an RC receiver has some intriguing possibilities, too.  Thanks again!

RC Navy:
Hi bjh,


--- Quote --- I still plan to finish my own (synchronous) library SimpleServo which jitters less in my testing
--- End quote ---
The trick I used in SoftRcPulseOut to cancel the jitter consists of masking interruptions juste before each edge (rising and falling) and unmasking interruptions just after  each edge (rising and falling). It's very easy for the rising edge because you know when this occurs, but more tricky for the falling edge. Knowing the pulse duration, I mask interruptions some timer ticks before the falling edge (anticipation). This means that all interruptions are delayed, but we have to deal with some compromise. For most of interruptions, it's not critical, but for some other which are time sensitive, it may be...
With this trick, interruptions are served between each edge, because they are not masqued (juste around the edges).
You can have a look inside the SoftRcPulseOut.cpp file.

Hope this helps to solve your jitter issue.
 
RC Navy

Navigation

[0] Message Index

[#] Next page