Hey kowalski,First, I echo others' recent kudos for your continued great work on this platform!

Now for a hopefully simple question that I'm almost embarrassed to ask:How do I use the additional hardware serial ports on the Arduino Mega2560?I perused through the UART.hh and UART.cpp files, and I see code for what looks like uart1,2,3 inside of: #elif defined(__ARDUINO_MEGA__)But simply calling uart1.begin(9600); didn't compile.

I did get this blip of code to compile at least (not sure if it really works or not):

...but I wasn't sure if all of that was necessary if there is built-in support for simply calling: uart1.begin(9600);, etc.Also, I had to use "uart11" as "uart1" complains about: "multiple definition of `uart1'"Am I missing something simple?

Also, I'm curious as to the status of SoftwareSerial-like support... :-)

Please forgive my ignorance, but may I ask why the design principle is that the additional UART instances/buffers are not pre-allocated? Is it to save memory? If so, I would "think" that the MEGA certainly has enough memory to handle them being pre-allocated in the #elif defined(__ARDUINO_MEGA__) block so they can simply be used like the default uart. After all, multiple hardware UARTs was my primary reason for purchasing a MEGA

Please forgive my ignorance, but may I ask why the design principle is that the additional UART instances/buffers are not pre-allocated? Is it to save memory?

Great questions! I want to leave as much memory as possible to applications. Preallocation of buffers is actually difficult as it depends on the amount of "speed adjustment" needed. The buffer should be as large as possible to allow the application to continue processing. But small enough to leave as much memory as possible. The UART can be viewed as an extra processor. The goal is to get as many of the AVR hardware resources to run in parallel with the processor core.

An example: for a given output stream (bytes per second, in burst) the buffer size depends on the speed of the transmission (baud-rate). The faster the baud-rate the shorter the buffer for a fixed output rate but at least the size of a burst. If the buffer is too small the application will stall due to waiting on the UART.

Nearly all memory allocation in Cosa is configurable and/or input parameters as the IOBuffer's.

The support macro UART_SETUP() is used for binding the UART instance to the ISR handler. The extern variables are now refactored (static class members) and defined in the UART.hh file. The macro does the job. I also took the opportunity to change the strange constructor parameter order of IOBuffer. Had missed that :-)

Please use the issue handling on github. It allows me and others follow these types of great improvement ideas.

1. Extended Virtual Wire Interface The Cosa Virtual Wire Interface (VWI) has been updated with support for node addresses, address match and message types. In extended mode a header is added to the payload. The header contains the Transmitter node address, message sequence number and message type. The receiver(s) will match the address by masking and comparing with its own node address. The full message with header and message is returned to the receiver for further dispatch. The interface change is backward compatible. Please see the example sketches CosaVWItempsensor.ino, https://github.com/mikaelpatel/Cosa/blob/master/examples/VWI/CosaVWItempsensor/CosaVWItempsensor.ino, and CosaVWItempmonitor.ino, https://github.com/mikaelpatel/Cosa/blob/master/examples/VWI/CosaVWItempmonitor/CosaVWItempmonitor.ino.

3. IO-vector supportThe type iovec_t (see Cosa/Types.h) is a struct with buffer/size pair. A null terminated vector of iovect_t is a convenient method of allowing scattered buffer elements that are gathered for instance on send. a. New VWI::send(vec) member function to allow additional buffers on send. Allows additional headers without code change.b. New IOStream::Device::writev(vec) member function.

4. Template classesThe Cosa Queue and IOBuffer classes have been refactored to template classes. This allows additional performance and improved memory allocation. An example of ripple effect; The Cosa FSM benchmark measurement of sending messages between finite-state machines was improved by 50% (20 us per message dropped to 10 us).

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.

Mikael,This is really interesting what you are doing.I have peeked into your Cosa OOP documentation over the past weeks and can see you have put a tremendous amount of work into this.It looks looks to be a highly organised, well thought out and useable framework.

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.

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.

I am writing a modest lib myself that is only for advanced users and targets to minimize ram usage (at the expense of using more prog-mem) and allow total control. I got frustrated with the stupid Arduino lib implementations that seem to be the standard -they are great for demo's and simple prototypes, but will fight you when you want to do some real work. I also use mainly template classes and no virtual functions to accomplish my goals. I intentionally leave out/do not use certain OO/C++ features in order to keep it small.

What do you think of this (to me, this looks very logical):ViewPort<TextLcd<LcdDriver<..pin io..>, ..physical size..>, ..virtual size..>

This demonstrates: - separation of concerns: the actual hardware driver can be swapped out for different types of LCDs, or any one of the template classes- extensablility: if you don't like the impl. of some part, replace with your own.- No ram: all parameters are compiled into the code and the template classes do not use virtuals. This assumes you will not add/change LCD displays dynamically.

The library looks nice, but I don't get 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.

...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.

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.

Although my code is not as elaborate as your lib (yet! XD) I have not found any need to have virtuals. I basically put the class hierarchy upside down and that eliminates the need for virtuals - also eliminates polymorphism. My reasoning is that in small embedded systems you have more use for control than abstraction (so not for beginners). As in the LCD example I gave previously, I am also looking to separate concerns/logic. The logic of how to write to an LCD display is always the same (for the same type of LCD displays). But the way you hooked it up to your MCU can differ for each design (directly on the pins, shift regs, etc). This approach leaves the door open to change the driver code and still reuse the LCD code, something I have never seen in other libs.

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).