But I could not find a way to dynamically enable / disable the other kinds of events e.g. AnalogEvent or ButtonEvent. So I cannot enable / disable these other kinds of events as my app goes through different states. Would it make sense to consider either start()/stop() methods, or removeX() methods corresponding to the addX() methods for these other event types? It would make FSM-style programming easier.
Well, Sophie. Timers are usually needed to be started and stoped, but it did not make sense with buttons and similars when theses classes were done. However your idea for FMS logic made sense and I will think in something to solve it within next days.
Although I am a relative newbie with Arduino, I used to program in Visual Basic. There are lots of events in VB. I have found these event driven routines you wrote extremely helpful for my project. I'd like to see a "serial data available" event for serial 1 or 1-4(mega) .
Jim, I will try to think in something for it as well, but I will never be able to test if it worked because I don't have a mega board. Are you willing to be a tester for it?
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.
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.
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´.
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.
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.
Bainesbunch, I'm also interested to add more capabilities to the library. My main problem is that I don't have abundant access to electronics components. But feel free to colaborate. New members are realy needed for this project.
Hello, Terry... It's a bit boring to debug an serial application when the only interface to it is the same serial port. The IDE's Serial Monitor holds an exclusive access to serial port and does not permit things to work toguether.
Send me an email when you feel ready to get back our discussion. OK?
The lastest ebl-arduino release (r52) brings to Arduino's users an easy way to exchange comands and data between PC and Arduino using .Net, being also easy to port to another languages and transports (TCP and so on).
A new class that implements a serial protocol to make easier the communication between PC applications and Arduino sketches.
It is an example of sketch that receive commands from PC to control an LCD display:
Once you've uploaded the LCDWriter sketch from AdvancedSerial examples (IDE menu: File/Examples/AdvancedSerial/LCDWriter) to your Arduino board the LCDWrite.exe client API example (IDE directory: libraries\AdvancedSerial\clientapi\dotnet\Release) will be able to control the backlight and text shown in LCD display.
In closing, a short demonstration of this example running:
This project has their own repository with more information about the classes, usage instructions and download options. It could be accessed through the URL http://code.google.com/p/ebl-arduino/.