Event-Based Library for Arduino

That's the kind of thinking I meant when I said:

and is especially useful for timer based events.

Basically, if you have an RTC or other interrupt line, you can either set a flag which is checked in the timer's fire method or directly call the execute method from the ISR, depending on the nature of the event and exactly what all needs to be done. Always possible for further divide the ISR into a slow/fast split mechanism.

EDIT: Also want to add that it opens the door for IRQ dispatch via message passing too - again depending on design decisions and goals.

Bainesbunch, are you thinking about XML parsing using Arduino? I'm not sure if it will be good. XML is good when you want an easy to implement and humam readable way to exchange information, but in my opinion it's realy hard to parse and requires much memory space and processing power. I still prefer to use memory spaces that matches C structs.

gerg, you're right when say that avr memory allocation is buggy, but I also tried the new library version and it's still having a bad behaviour. I've added a method to pre-allocate a memory space to avoid sucessive reallocs, but I was not confident that it would be good and I just not commited it yet to source tree. I think that the Arduino/AVR has many memory issues, what make me avoid the idea of creating a new class to control the common functions like loops because it will spend more stack space and so on. It's a very limited environment when compared to PC programming. Everything needs to be simple as possible.

I liked the suggestion about keeping the next timer to avoid the checking of all array items everytime, I agree that many things may be optimized in this loop (and in the rest of library). I'm only not sure about how much it will improve the precision because if you set tight intervals to hard jobs the timer will never match anyway. And I prefer don't use interrupts because time elapsed measurements are needed for some functions and I also worry about losing serial data.

Be assured that the new versions will bring all your good sugestions. And feel free to submit patches for main source, documentation, examples, etc etc.

Rferreira:
Bainesbunch, are you thinking about XML parsing using Arduino?

Not exactly no. I was thinking more on the lines of using XML to store data for configuration and non volatile data from the application in XML on the CF card.

For configuration this would have that advantage of being able to write an XML based configuration for the application to a CF card in an eye readable format that in then converted into its types by the parser when the application loads. so the XML File might read

<Name="My Variable" Type="INT" Value="100">
<Name="My Variable" Type="STRING" Value="A Sample String">
<Name="My Variable" Type="REA" Value="123.456">

The parser would be able to find the element in the XML file by name and convert the value into its correct type on the Arduino, this would not be wasteful of memory.

To conserve memory further we only read one line of the XML file at a time to process. I think a full XML document reader is to memory hungry four our little toys.

Cheers Pete.

Sounds like a job for JSON, rather than XML.

It's not the same thing, oscarBravo. IMHO, if you can't take advantages of reusability, syntax validation, high level libraries for read/write operations, binary data encoding and so on, XML does not make any sense for me due to it's huge storage and performance overhead. XD

Hi again, Renato,

Sorry for the delay; I have been travelling and now settled back in Vermont USA for the summer.

((I am using a temporary logon/userid because I am locked out of the forum with my regular ID and no one responds to emails :0 ))

I have been thinking more about issues of "Scheduling", tasks, events etc. I need to read thru the discussion completely before saying too much. I have my own viewpoint and "terminology" in mind from my past experience with other RTOS systems like IBM's EDX. I even read thru the code of the RTOS I wrote long, long ago for the 6502. So a slow 8-bit micro can definitely do this :slight_smile:

So, more to come...

First pass "Scheduler" ideas: A scheduler simply is another source of "Events" in a system. The scheduler periodically compares the Real Time Clock with it's list of scheduled events, and if the time has arrived, it posts that event. I don't think the events posted by a scheduler need to be any different than events posted by other sensor-based or timer-based or counter-based "checkers"..

Maybe...

OK, back soon. Thanks for your work on this. Let me know what hardware you would like to test things and I'll get it to you.

Regards, Terry King terry@terryking.us

Hello, Terry! I have no idea where you really live. XD

The RTCTimedEvent class is already working here at home and the usage is similar to Unix cron. I will commit it within 2 or 3 days when doc, example, etc, is finally ready.

Thank you for your contribution!

[]s
Renato

Hi Renato and Everyone,

I am from rural Vermont, USA and this is 'Home', but My wife Mary Alice and I have been working/living overseas last 7 years in Africa, China, Middle East and next year: Genoa, Italy. Couple more years and we will stay home in Vermont. She builds Libraries. I work online from anywhere.

Renato, I feel strongly that your ideas and software are key to doing more interesting and complex things with Arduino. I would like to help with that and support your work in any way I can.

Interesting and important applications need the kind of organized "multi-tasking" and Event-Driven actions you are talking about:

  • Home/Building Automation/Energy Management
  • Application-specific Automation, from Machines to Fish Farming, etc., etc.
  • Robotics, especially Autonomous Vehicles.

All of these need to handle and coordinate a variety of Sensors, Timers and Counters, Communications, and a variety of actuators.

Many Arduino projects get difficult and bogged down trying to make multiple things work together. An organized way of building this kind of Arduino application is needed. I hope to write some examples soon...

Arduino, especially the 2560 variants, is perfectly capable of doing these applications. I built significant automated machinery 20 years ago with big rack-mounted IBM Series/1 etc. But guess what? They had no more processor power or memory and less I/O capability than Arduino!

Let's figure out how to effectively collaborate and get this working.

Regards, Terry King
...In The Woods In Vermont
terry@yourduino.com

(STILL locked out of primary account here!)

You can also use templates.
http://www.artima.com/weblogs/viewpost.jsp?thread=84958
http://www.artima.com/weblogs/viewpost.jsp?thread=85301

Terry, I already created a project for it on google code, but I'm avoid speaking about in this topic to preserve it's focus. Unfortunately I'm needing to priorize some other small activities in these days, but I will try to keep you updated by email. I'm not receiving any reply from you. I'm not sure if it's because you're not receiving my messages or just not understanding my `brazilian english´.

PING --> ACK!

Hi Renato, I'm working on some definitions about Timers and Counter for discussion.

I'm In!

Regards, Terry King
...In The Woods In Vermont
terry@yourduino.com

:smiley:

Guys...I love where this project is going. Count me in for testing, debugging, contributions. I have a project that I want to test these libs out on...things that need to eat timers and throw multiple events. It will be a good test. I'll get back with you on the results.

Be welcome, mdrunk. XD

Hi Everyone,

Also thinking about how Communications and it's Event-oriented property fits with this effort.

I have been working on low-cost Transceivers and software support for them. The RF24 library and approach looks good.
I have some How-to and pointers here: http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

Renato, how should I start thinking about this? How would communications integrate with your Event Based Library?

Actually a more generic question is something like "What are the guidelines for writing Tasks/Functions that integrate well with EBL"??

I would like to try to integrate some RF24 support with some EBL example soon...

Regards, Terry King
...In The Woods In Vermont
terry@yourduino.com

AdvancedSerial class and their C# client API was the first idea about how to proceed with communication between devices or PC software. It was written with a simple message validation, handshake and, of course, events for arriving messages. The ideia is to abstract all message handling in one class to permit it's logic to be implemented over any transport layer. AdvancedSerial has not yet their message handling abstracted from transport layer because I had some doubts about how to properly handle includes between Arduino library files and I also thought that should be better to decide it while implementing a second transport, but if you see the C# code will note that it's already well implemented there.

I've planned before to add a TCP support for ethernet and wifi shields as a next step for it because I realy believe in an full integration for PC and mobile devices as a more promising way to control a wide set of Arduino devices. And I like the mesh support from zigbee as well.

Well, if this device permits to send and receive data in a serial style, It should be easily added to our library. I never read about this device before you post it here, it really appears to be powerful and cheap.

Hi Renato,

I think maybe there are two different things to consider here:

  • Communications between Arduino and the typical USB-connected host computer.

  • Communications between Arduinos

It would be easier if these were all serial oriented. But RF Radio Wireless communications has retries and error checking and actually sends packets of data. I will try to see if there's a way for RF24 library to support 'serial stream' type transfers, or perhaps we can write that on top of the packet-transmission. I THINK that's what Xbee does.

...details :slight_smile:

I need to try out AdvancedSerial myself and get used to it...

Regards, Terry King
...In The Woods In Vermont
terry@yourduino.com

There is nothing special in this "serial oriented" way. If I can "sendByte" here and then "readByte" there it will work independent of transport layer. It's only an validation sequence as explained bellow:

  1. If there is nothing in buffer, I just wait for an STX byte because it tells me that a message is arriving;

  2. Once a message started to arrive, I will first read its header. In case of AdvancedSerial it has a fixed size and it also brings the payload size;

  3. If I have a valid payload size I start to fetch it from buffer;

  4. When I finish reading the payload, then the next byte must be an ETX telling me that's the message ended.

If anything went wrong on validation we loose the message, otherwise we send back an ACKNOWLEDGE message. Once we combined ACK messages with a timeout+retry algorithmic we have a well reliable communication.

Maybe you need talk to arduino using USB, ethernet, TX/RX or whatever. The idea is to fit any project requirement as possible with the same protocol implementation, being it an offline configurator or even an real-time monitor.

Would be good if there was a RF24 hub or a usb dongle for it as well. The last one I think that we can quickly build by ourselves.

Finaly, using a common protocol implementation over any transport layer permit us to use different transport layers at same communication through converters like Serial2Ethernet and so on. Then one part can use their serial support while another one use the ethernet support and achieve a transparent communication.

Would be good if there was a RF24 hub or a usb dongle for it as well. The last one I think that we can quickly build by ourselves.

Hi Renato,

I've been looking for one. Take a look at this:
http://arduino-direct.com/sunshop/index.php?l=product_detail&p=192

I found this at a supplier but don't have one yet.. and very little data.

Also Nordic site says their System-On-Chip with nRF24L01 can have USB ??

I'll try to find more info...

Regards, Terry King
...In The Woods In Vermont
terry@yourduino.com

Hmmm! Looks good... 8) It made me curious...