If I got my hands on a few of those it would be interesting to adapt Cosa :-) I use basically the same hardware for prototyping; Arduino Nano and the Nano IO Shield which has a NRF24L01+ and ZigBee socket. I am planning support for at least three major types of nodes; basic sensor nodes which should be scalable to ATtiny84/85, routing nodes for mesh communication and bridge nodes from NRF24L01+ and other small scale RFs to ZigBee/WiFi/Ethernet/LTE, etc. The last type of node will probably be Linux based. The others will typically be Arduino/AVR based. The Sparrow seems to be perfect for the two first types of nodes; sensor and routing nodes.

Right now I am working on improving the Cosa TWI/I2C bus handling so that it will be really easy to add Cosa/Arduino based slave units. This would allow partitioning and distribution of functionality when needed. A new level of shields such as LCD, Network, etc, would be interfaced through TWI instead of having to compile/link drivers into the sketch. Instead simple proxy libraries can be used and the code base becomes more scalable. With an AVR processor on each shield they can be used stand-alone or integrated over TWI. This was basically the foundation of the dtools research project at Stanford, http://hci.stanford.edu/research/dtools/ 

Cheers!

http://cosa-arduino.blogspot.se/
https://github.com/mikaelpatel/Cosa
http://forum.arduino.cc/index.php?topic=150299.0

Some news on the latest updates to Cosa.

1. ATtiny X5 and X4 is now supported. In reality only 8K devices, ATtiny84 and ATtiny85, are practical to work with. The others have too small memory size (SRAM). Most drivers have been ported to the ATtiny's; DHT11/22, OneWire DS18B20, LCD (PCD8544/ST7565), Virtual Wire, Ultra-sonic range module and more. More details: http://cosa-arduino.blogspot.com/2013/04/programming-attinyx5.html
2. Enhanced Virtual Wire Interface (VWI), VWI::Transceiver, with message acknowledgement, auto-retransmission and support for message type encoding/decoding. http://cosa-arduino.blogspot.com/2013/04/enhanced-virtual-wire-interface.html
3. Support for Home Automation NEXA/HomeEasy transmitter, receiver and "listener" objects. http://cosa-arduino.blogspot.com/2013/05/more-rf433-wireless-home-automation.html
4. Soft UART with IOStream integration. Mainly for debug trace output from ATtiny as this only requires a single pin for the TX.
5. Improved driver support for DHT11/22.
6. Cosa RTC includes three levels of "clocks"; micro-, milli- and second base. The millisecond timer base (Timer0/B) interrupt handling may be extended with a periodic callback for more accurate event timing.
7. BCD print support. May be used to avoid BCD-binary conversion when BCD data is not processed (such as when using the I2C Realtime Clock, DS1307, see DS1307::timekeeper_t::print(IOStream& stream, const char* format), https://github.com/mikaelpatel/Cosa/blob/master/Cosa/TWI/Driver/DS1307.cpp)
8. LCD ST7565 support. As PCD8544 the LCD driver is integrated with IOStream. Graphics is performed using the OffScreen Canvas. This driver also supports text scroll without using a memory buffer. Please see the example sketch; https://github.com/mikaelpatel/Cosa/blob/master/examples/LCD/CosaST7565P/CosaST7565P.ino  
9. New methods in the IOStream::Device interface; room(), number of bytes before output buffer is full, and peekchar(), access the next character in the input buffer without removing it. Updates to the implementations of the interface; UART, IOBuffer, etc.
10. Updated support for io vector buffers (iovec) and improved handling in communication drivers (TWI, SPI and VWI).
11. Major refactoring of Cosa TWI (I2C driver). Totally rewritten I2C/Two-Wire driver with higher level of application support. Reduced to less than 300 commented LOC.
12. Updated OffScreen Canvas to a template class. Improved robustness and performance.

Cheers!

The file is just text file with numbers (comma separated values):

Here is a sample line:

Code:

1363180287 "2013/3/13 13:11:27" 1223 32000 -1.51 -9.99 0 -0.02 0 0 0 0 0 0 0 5000 0 0 0 0 AR72000-0001 1

Yes this is the type of text data that DEFLATE loves. Only a fraction of the ASCII symbols are used and there are many common sequences.

As the number of symbols are low you could use BCD for numbers and the extra 10..15 value for special characters and run-length of zero which is very common. This way the compression rate should be 3-2:1 with a very simple algorithm. This will require a 8-bit binary format and a decoding program on the "other size".

As the symbols are known a simple version of DEFLATE could be constructed that used a much smaller encoding table. But still the limited memory in Arduino is a problem. A Mega could give enough to work with (8 Kbyte).

Cheers!

A new Cosa blog post is available. It presents the Cosa NEXA driver; RF433 transmitter and receiver for Home Automation with NEXA/HomeEasy remote and receivers. Driver and example sketches may be run on ATtiny.

http://cosa-arduino.blogspot.se/2013/05/more-rf433-wireless-home-automation.html

Cheers!

A new Cosa blog post is available. It presents the Cosa NEXA driver; RF433 transmitter and receiver for Home Automation with NEXA/HomeEasy remote and receivers. Driver and example sketches may be run on ATtiny.

http://cosa-arduino.blogspot.se/2013/05/more-rf433-wireless-home-automation.html

Cheers!

Thanks for the link, didn't know that lib. I will look into it.
...
I am currently testing a way for lightweight cooperative mutlitasking. Once I figured out how to do async time delays I can go to town on supporting other typical devices (I2C, LCD etc).

You are welcome. Here are a few links to Proto-threads which is a style of implementing coroutines. These are actually from the comment block in Cosa/Thread.hh, http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d0/d51/classThread.html and https://github.com/mikaelpatel/Cosa/blob/master/Cosa/Thread.hh.

[1] Adam Dunkels et al, Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems, SenSys'06, November 1-3, 2006, Boulder, Colorado, USA.
[2] Larry Ruane, protothread: An extremely lightweight thread library for GCC, http://code.google.com/p/protothread/
[3] http://en.wikipedia.org/wiki/Protothreads

It is possible to avoid the "switch" problem by using gcc local labels and label address. The Cosa implementation is object-oriented and fully integrated with the Cosa periodic timer queue.

Cheers!

I have large files (several MB) and somehow my WiFi transfer is only up to 15KB/s. I wonder if doing DEFLATE compression is possible at all on Arduino:

What type of data? There might be easier ways to compress it; Huffman, Run-length, DPCM, etc. Otherwise porting one of the many implementations of DEFLATE is an interesting challenge as they often use many times the memory (SRAM) available in a typical Arduino  ;-)

Cheers!

Thanks for the fast answer. Handing the event in the dispatch loop would become a bit messy on the long run.

Just to depict my problem: I'm planning to use a rotary encoder which uses two pins. Therefore subclassing the ExternalInterruptPin as in the IR::Receiver example is not possible. So probably I would have to subclass the pin in order to be able to delegate the event handling to some other class/function.

You are welcome! This is an interesting design problem.

The solution you are sketching is similar to the pattern used in the NRF24L01P driver where a sub-class of ExternalInterruptPin is defined within the class itself and posts events back to the "parent", i.e. container.
Below is a snippet from the driver.

Code:

class NRF24L01P : private SPI::Driver {
private:
  ...
  class IRQPin : public ExternalInterruptPin {
    friend class NRF24L01P;
  private:
    NRF24L01P* m_nrf;
  public:
    IRQPin(Board::ExternalInterruptPin pin, Mode mode, NRF24L01P* nrf) :
      ExternalInterruptPin(pin, mode),
      m_nrf(nrf)
    {}
    virtual void on_interrupt(uint16_t arg = 0);
  };
  IRQPin m_irq;
  ...
};

void
NRF24L01P::IRQPin::on_interrupt(uint16_t arg)
{
   ...
   Event::push(Event::RECEIVE_COMPLETED_TYPE, m_nrf, status);
   ...
}

You could have several InterruptPins defined within a container class which post events to the same target object (i.e. the container).

Cheers!

Code:

[quote author=obiwanjacobi link=topic=150299.msg1227898#msg1227898 date=1367654559]
Just stumbled onto this. Nice lib!

Thanks obiwanjacobi I had a quick look at your library. Many interesting ideas! While I started off not using templates, your approach is not using virtual.

I have introduced a few templates for some of the basic classes (such as Queue and IOBuffer) to allow additional compiler optimization and strangely higher performance. I use virtual mainly for callbacks and abstract interfaces with code reuse.

Using functions as callbacks often requires additional parameters and state. In these cases an instance/object is a nice way to handle this. It scales better than callback functions and global variables. Virtual also allows reuse of a lot of code and reduces the program memory footprint. A good example is the IOStream::Device class and the default implementation which is reused many time by both IOBuffer, UART, SUART, etc. The extra SRAM cost for the virtual table handling is only 2 bytes (per instance). For 20-40 instances this is only 40-80 byte in total. If the target is a ATtiny with less than 0.5Kbyte then this might seem a lot.

Have you seen Rick Kimball's library https://github.com/RickKimball/msp430_code. This is a full fledged template based library. And uses a lot of the template tricks. Very modern and nice coding style.

Cheers!

...how I can subscribe to an event (for example of an ExternalInterruptPin) when subclassing is not an option? The class pushes an event but I do not see how I it can be handled from outside.

Hi Ferio. Thanks for your interest in this project. The short answer to your question is that you can always handle the event directly instead of calling dispatch(). Below is snippet from CosaFSMBlink which uses the dispatch-method.

Code:

void loop()
{
  // The basic event dispatcher
  Event event;
  Event::queue.await(&event);
  event.dispatch();
}

And below is a snippet from the CosaNEXAreceiver sketch which handles the event instead of calling the on_event() method.

Code:

void loop()
{
  // Wait for the next event
  Event event;
  Event::queue.await(&event);
  uint8_t type = event.get_type();
  Event::Handler* handler = event.get_target();

  // Check that the event is an read completed and from the correct source
  if ((type != Event::READ_COMPLETED_TYPE) || (handler != &receiver)) return;
  ...
}

The flow of control is:

• The event.await() will perform a sleep while waiting for events
• The ExternalInterruptPin::on_interrupt() method is called when an interrupt occurs. The default implementation will push a changed event onto the event queue
• The event.await() returns with the event
• If event.dispatch() is called the event target on_event() method is called, otherwise decode the event type and target

You can find more details about this on the blog, http://cosa-arduino.blogspot.se/2013/03/the-analog-pin-classes-introduction-to.html and http://cosa-arduino.blogspot.se/2013/03/object-oriented-interrupt-handling.html

Cheers!

A new Cosa blog post is available. It presents the basic working procedure for getting Arduino Cosa sketches working on ATtiny. Special focus is on how to use the Cosa Soft UART and PCD8544 LCD driver for trace output from ATtiny.

http://cosa-arduino.blogspot.com/2013/04/programming-attinyx5.html

Cheers!

A new Cosa blog post is available. It presents the basic working procedure for getting Arduino Cosa sketches working on ATtiny. Special focus is on how to use the Cosa Soft UART and PCD8544 LCD driver for trace output from ATtiny.

http://cosa-arduino.blogspot.com/2013/04/programming-attinyx5.html

Cheers!

A new Cosa blog post is available. It presents the basic working procedure for getting Arduino Cosa sketches working on ATtiny. Special focus is on how to use the Cosa Soft UART and PCD8544 LCD driver for trace output from ATtiny.

http://cosa-arduino.blogspot.com/2013/04/programming-attinyx5.html

Cheers!

Paul, thanks for your comments and encouragement.

Cosa as a project is great fun and I have lots on the agenda. It is very much a bottom-up process to build a framework and I want/need to get feedback early on to move in the right direction. Obviously more support for Wireless, Ethernet, USB, and many more sensor drivers are needed. Also the host part of Ciao/Cosa Fai is also needed before becoming really useful.

If you get the time to test Cosa I would very much appreciate feedback.

Cheers!

A new Cosa blog post is available. It presents the Cosa Enhanced Virtual Wire Interface; reliable wireless RF433 module communication with message acknowledgement and auto-retransmission. The VWI classes may be used with ATtinyX5.

http://cosa-arduino.blogspot.se/2013/04/enhanced-virtual-wire-interface.html

Cheers!