Go Down

Topic: Cosa: An Object-Oriented Platform for Arduino programming (Read 176788 times) previous topic - next topic


The latest updates of Cosa includes:

1. Fixed Arduino Mega synchronized port access (OutputPin/GPIO).

2. Improved Cosa Debugger.
a. Allow abbreviated commands.
b. New command, backtracks, for call stack walk through registered variables.
c. Restructuring of source code to allow easy configuration.
d. Example sketch CosaDebug.ino.

3. Improved performance measurement support (Trace.hh)
Allow both micro- and milli-seconds level block execution time measurement.

4. Additional Job example sketch (CosaJobs.ino)
Added example of hierarchical periodic jobs; controller to reschedule time/step limited periodic job.

5. Additional SD/FAT16 example sketch (CosaFAT16logger.ino)
A simple data logger (analog channel samples) to binary or text file (CSV).



The latest update of Cosa includes a Custom Board template. The template demonstrates how to add a new board without modifying the Cosa core. Custom boards must be based on one of the supported AVR MCUs.

As full examples the Pinoccio Scout and PJRC Teensy/Teensy++ 2.0 board definitions have been moved to separate repositories. These also serve as examples of how to install extended custom boards for Cosa.

The new structure will allow board specific libraries and example sketches.



Some news on the latest update in Cosa.

1. All supported custom boards has been restructured to separate repositories:

2. The Cosa command line build has been updated to handle the new custom board structure. Please see install description.

3. Support for Arduino IDE 1.6.7.
The master branch contains support for Arduino IDE 1.6.7. Available in the ZIP file download from github. A new package manager release is planned for January.

4. Device driver for I2C Real-Time Clock/Calender PCF8563.



Hello Mikael,

First off, thanks for your impressive work on Cosa; I've been using it for more than 1 year now and I'm always impressed by what I discover of it everyday.

I have a question on optimizing the code size of Cosa-based program on ATtiny.

To put this into context, I am working on a small (well, I wish it was smaller...) program for ATtiny84 (8K flash) which mainly uses the following Cosa parts:

  • Watchdog
  • Alarm
  • NRF24L01
  • PinChangeInterrupt
  • AnalogPin (bandgap() only)

I needed to add OWI (I use a DS18B20) for a simple fact: getting a unique ID.
Unfortunately, the minimal OWI code needed to get that information was too much amount, in combination with my current program, to fit ATtiny 8K flash.

Hence, I have removed the OWI dependency and rewritten a single function to just read the DS18B20 ROM, with as little code as possible. This worked so far: today my program is using 8018 bytes of flash.

However, the amount of bytes remaining won't be enough for what I still need to add to my program (namely, sending the ROM code, with NRF24L01, to a "server" device in order to initiate future communication with that server).

For information, I use my own build makefile (I have set it up on netbeans) but it is mostly inspired from Cosa build command-line arguments:

avr-g++ -c -std=gnu++11 -mmcu=attiny84 -DF_CPU=8000000L -DARDUINO=166 
        -Wall -Wextra
        -fno-exceptions -felide-constructors
        -Os -ffunction-sections -fdata-sections -flto -mcall-prologues  
        -I<include paths here>
        -MMD -MP -MF <file.o.d>
        -o <file.o>

avr-g++ -mmcu=attiny84 
        -Os -ffunction-sections -fdata-sections
        -Wl,--gc-sections -Wl,--relax -flto
        -o <target>
        <object files paths...>
        <cosa library path>

Note that cosa library above was obtained through the same compile options and archived with the following command lines:
ar -rv <cosalib.a> <object files...>
ranlib <cosalib.a>

I use Arduino 1.6.6 toolchain on Windows and latest Cosa source code from github.

So far these were the best options I could find, to reduce code size to the minimum.

Now, when I check the <target.map> produced by the linker, I still find some functions  which I don't understand why they are still linked, as I don't call them and I don't think they're called internally by Cosa:

Wireless methods:
  • Wireless::Driver::wakeup_on_radio()
  • Wireless::Driver::room()
  • Wireless::Driver::broadcast(uint8_t port, const iovec_t* vec)
  • Wireless::Driver::broadcast(uint8_t port, const void* buf, size_t len)
  • Wireless::Driver::is_broadcast()
  • Wireless::Driver::input_power_level()
  • Wireless::Driver::link_quality_indicator()

NRF24L01 methods:
  • NRF24L01P::powerup()
  • NRF24L01P::powerdown()
  • NRF24L01P::end()

Other methods:
  • Job::Scheduler::stop(Job*)
  • ExternalInterrupt::enable()
  • ExternalInterrupt::disable()
  • ExternalInterrupt::clear()
  • PinChangeInterrupt::disable()

All this unused code amounts to 348 wasted bytes.

I guess those methods are linked because they're virtual, hence they appear in the class vtable...

Hence, my question: is there any link option (or another way) to force removing those symbols from the final exe?
I guess replies will be useful to anyone using Cosa library.



Thanks for your interest in Cosa and writing on blogs, forums, etc. Appreciated!!

It is some time since I focuses on ATtiny specific footprint reduce. Most of my projects have moved onto larger boards. And actually porting some of the Cosa libraries to the Arduino API such as the Simple Arduino Scheduler.

Have you checked that LTO is actually enabled in the compiler and linker that you are using? There was some issues with the tool chain version included. You might be able to locate the new version (link on the developer mailing list). LTO can actually help even if it sometimes increases SRAM usage. You should be able to see clone functions in the link map (if LTO is working).

From your list of member function that are added I see that many are actually virtual. These are difficult for the linker to eliminate as the virtual table contains a reference to them (just as you commented).

If I get the time I will see if there is some restructuring of the source code that might help the linker.



Hi Mikael,

Thanks a lot for your appreciated feedback.

For LTO, I have checked the following:
1. Remove -flto from compile/link command lines, rebuild and check size:
  • without LTO, the same program uses 8054 bytes
  • with LTO, it uses 8018 bytes
  • the SRAM size did not change though (230 bytes in both cases)
  • so I guess that means LTO works right?

2. I also checked the different kinds of symbols in the map, with LTO:
  • there are several clone symbols:
  •     7 text
  •     2 data (vtable)
  • there are many sections named .gnu.lto__...

So I guess LTO is effective in my current situation.

As discussed, the linker is probably limited in its options to remove a symbol that is referenced inside a vtable.

If I get the time I will see if there is some restructuring of the source code that might help the linker.
Please don't! In fact, I am not sure such an optimization would really be possible, except removing some virtual methods from Cosa classes, which could break compatibility to other people using it!

I think the only way would be to tell the linker to remove all those symbols for unused virtual methods by explicitly naming each of them; but I am not sure if the linker can do that (I could not find any option for that).

Maybe avr-strip is one option to check, but I am not sure how to integrate it into my build chain:
  • do it after link? this would be too late as linker fails if size is too big for target!
  • do it before link? more difficult to integrate as I would need to remove it from my cosa library archive file, which I don't want because it is shared across projects. Also I am afraid that would then fail the link trying to fnd removed symbols!

I need to further investigate the tools in the AVR toolchain to see what best fits the bill. Any suggestions are of course welcome as I am not an AVR toolchain wizard and not particularly acquainted to GNU dev tools either...

I will report here if I find some way to improve my build.



New release 1.2.0 available. Support for Arduino 1.6.7+. May be installed with the Boards Manager.



- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH


Is it possible use Cosa by AtmelStudio ?
Why not? That should be a question of configuration. I do not use that myself but this question has been asked before so there must be some Cosa users that have tested that.

If you are using Linux as a host machine I would recommend looking at the Cosa command line build.



Latest update of Cosa contains a TWI device driver for DS2482 I2C to 1-Wire Master Bridge. This is a low level device driver and not yet integrated with the Cosa OWI interface. Further integration will allow DS2482 to reuse all 1-Wire device drivers. An example sketch with basic benchmarks is available.



These might be really stupid questions but is it possible to use Arduino Uno + RFM69H(W) to control Nexa switches? I see there are different sections for Nexa and RFM69 but RFM69 can be used as 433MHz component?

Also if that is possible is there already some connections between arduino + cosa and OpenHAB? So I could control arduinos running Cosa from one place.


These might be really stupid questions but is it possible to use Arduino Uno + RFM69H(W) to control Nexa switches? I see there are different sections for Nexa and RFM69 but RFM69 can be used as 433MHz component?
The quick answer is no that is not possible as they do not use the same RF protocol (in the Cosa device driver library). RMF69 does support OOK so it might be possible to implement though there is a frame format to consider.

Also if that is possible is there already some connections between arduino + cosa and OpenHAB?
Not what I know of but there has been a some of activity in that area so may be there is something out there.





I recently got hold of a SIM900 GSM / GPRS Shield development board and plan to write a Socket driver for that. All the Cosa Ethernet (INET) classes such as MQTT can then be used with this transport layer.

Did you get to create the Socket driver for SIM900 Shield?  I've been looking for an example of how to send data to Thingspeak using the SIM900 GPRS shield but so far I haven't found anything.



Did you get to create the Socket driver for SIM900 Shield?
The quick answer is no.

The shield I received was faulty and I did not pursue that further in lack of a project. Adding a socket driver is quite straight forward. It is more or less translating to the corresponding AT commands plus some buffering for speed. Thingspeak is TCP/IP and HTTP (port 80).


Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131