Cosa: An Object-Oriented Platform for Arduino programming

It is important that young talented arduino users will grow - therefore ie. such TLAs like RTOS, OOP etc. shall attract them.. Veterans, like me, love 8bitters, especially when more powerful than Block II AGC.. :wink:

Lefty,

Let me explain serious from my point of view.

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

The LynxOS-178 RTOS is the first and only hard real-time DO-178B level A operating system to offer the interoperability benefits of POSIX® with support for the ARINC 653 APplication EXecutive (APEX).

This is professional level serious.

I have often used VxWorks, the system used in Mar Landers. Two of my former colleagues founded Wind River Systems and developed this RTOS. This is also a professional level serious RTOS.

I am now retired but do a little commercial development. I just don't find Arduino hardware/software reliable enough for this use. FreeRTOS and ChibiOS/RT fit this level of seriousness, they have support for commercial use.

I love playing with small programs on Arduino. I am a frustrated programmer want-to-be. Management forbid me from implementing any of my designs since a large programming staff was hired to do that. This is hobby fun level of seriousness and Arduino is great.

So the Arduino millisecond clock ticks every 1024 microseconds then does two ticks every 41-42 milliseconds to catchup. This is a hobby level system.

fat16lib:
Lefty,

Let me explain serious from my point of view.

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

The LynxOS-178 RTOS is the first and only hard real-time DO-178B level A operating system to offer the interoperability benefits of POSIX® with support for the ARINC 653 APplication EXecutive (APEX).

This is professional level serious.

I have often used VxWorks, the system used in Mar Landers. Two of my former colleagues founded Wind River Systems and developed this RTOS. This is also a professional level serious RTOS.

I am now retired but do a little commercial development. I just don't find Arduino hardware/software reliable enough for this use. FreeRTOS and ChibiOS/RT fit this level of seriousness, they have support for commercial use.

I love playing with small programs on Arduino. I am a frustrated programmer want-to-be. Management forbid me from implementing any of my designs since a large programming staff was hired to do that. This is hobby fun level of seriousness and Arduino is great.

So the Arduino millisecond clock ticks every 1024 microseconds then does two ticks every 41-42 milliseconds to catchup. This is a hobby level system.

I have no real issues of the subject and content that you and others in this thread have posted, but rather the tone and impression of the specific comments I listed. The arduino platform was well designed and build for the users it was aimed at, non technical users. It's also a continuously changing and improving platform that is evolving as people contribute more and more to it. The vast popularity of the platform and the huge membership of this forum kind of validates that there exists such a viable user base.

And there are many members here that come from professional background in software and/or hardware that like to contribute knowledge, share library contributions (as you certainly have), and otherwise encourage the less experienced members.

It just rubbed me (and maybe only me) the wrong way to read:

I don't use Arduino boards or the IDE for serious projects.

Followed with a supporting:

Hear, hear!

I know your contributions to the arduino platform do not reflect a person with an elitism attitude towards arduino projects or members using the platform, so don't take my comments as personal criticism of you, but rather just criticism of the comments that were posted.

Peace
Lefty

You may enhance your Cosa mcu collection with atmega32 (same pin layout as the 1284p, bootloader works, the core and variant of the mighty1284p works under 1.5.2.). The major diff is it has got only 4 PWM and single UART - maybe the UART setting needs a fix.

// MIGHTY ATMEL ATMEGA32
//                       +---\/---+
//           (D 0) PB0  1|        |40  PA0 (AI 0 / D24)
//           (D 1) PB1  2|        |39  PA1 (AI 1 / D25)
//      INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D26)
//       PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D27)
//        SS (D 4) PB4  5|        |36  PA4 (AI 4 / D28)
//      MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D29)
//      MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D30)
//       SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D31)
//                 RST  9|        |32  AREF
//                 VCC 10|        |31  GND 
//                 GND 11|        |30  AVCC
//               XTAL2 12|        |29  PC7 (D 23)
//               XTAL1 13|        |28  PC6 (D 22)
//      RxD (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//      TxD (D 9)  PD1 15|        |26  PC4 (D 20) TDO
//     INT0 (D 10) PD2 16|        |25  PC3 (D 19) TMS
//     INT1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//      PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//      PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//          (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                       +--------+
//

pito:
You may enhance your Cosa mcu collection with atmega32 (same pin layout as the 1284p, bootloader works, the core and variant of the mighty1284p works under 1.5.2.).

I will see if I get the time for this later this week. Dont like the idea of doing too many modifications I cant run through the tests. Thanks for the schematics. Will need to read up on the spec as well.
Cheers.

A new blog posting is now available with some details on how the Pin classes work in Cosa.

Cheers!

I spent most of my career as an architect for large embedded systems. I did some of the initial architecture for one of the LHC experiments that discovered the Higs Boson at CERN.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

Just to present a counter-argument, I spent most of my career as a developer at cisco Systems, which helped create The Internet As We Know It Today. A cisco router is a fairly large embedded system that uses a home-built OS that is not certified, not realtime, and not particularly (certainly not inherently) reliable. I remember way back when BBN announced that they had gotten their fancy multicore "butterfly" router to reliably switch packets within 1ms. At the time, cisco routers were switching most of the packets in about 12 us... (but we couldn't do ALL of them within 1ms.)

The other interesting part involved cisco's experiments (and products) that WERE/ARE based on real-time kernels. It turns out that effectively using a modern RT kernel is a pretty complex undertaking, and it's really easy to shoot yourself in the foot...

I am not sure what your point is?

Just to present a counter-argument,

Yes, Cisco is a great company and we have used many of their products in physics. Some of the network research done at LBL was used by Cisco. One of my colleagues, Van Jacobson, was Chief Scientist at Cisco for a few years.

It turns out that effectively using a modern RT kernel is a pretty complex undertaking, and it's really easy to shoot yourself in the foot...

Today students in courses like "Introduction to Embedded Systems" http://chess.eecs.berkeley.edu/eecs149/ learn to use an RTOS in the first weeks.

I don't understand why hobbyists can't use an RTOS as a useful tool. Hobbyists design circuits and pcbs.

I agree that hobbyists won't build systems like LHC detectors, projects like LHC also design there own semiconductor parts to achieve performance.

The detector generates large amounts of raw data: about 25 megabytes per event (raw; zero suppression reduces this to 1.6 MB), multiplied by 40 million beam crossings per second in the center of the detector. This produces a total of 1 petabyte of raw data per second.

There are three trigger levels. The first is based in electronics on the detector while the other two run primarily on a large computer cluster near the detector. The first-level trigger selects about 100,000 events per second. After the third-level trigger has been applied, a few hundreds of events remain to be stored for further analysis. About 15 petabytes of data per year are saved for further analysis.

Systems like this are implemented with a certified reliable RTOS. LHC used LynxOS.

I was talking about serious professionally designed systems, not hobby projects.

Today students in courses like "Introduction to Embedded Systems" http://chess.eecs.berkeley.edu/eecs149/ learn to use an RTOS in the first weeks.

Is that a required class for either EE or CS degree programs? It doesn't seem to be. Which means that you can graduate with one of the most prestigious engineering degrees in the country without having been taught how to use an RTOS...

My point is that an RT operating system is NOT a requirement for a serious commercial embedded system. A useful tool, probably. Most people will probably get more out of multitasking than they do out of "real time", but if a RTOS is the easiest way to mutitasking, that's fine...

My point is that an RT operating system is NOT a requirement for a serious commercial embedded system.

Yes, but you old timers are retiring. At one time no computer ran an OS. No embedded system used a compiled language.

Mentor Graphics Nucleus RTOS (Real-time Operating System), Deployed on over 3 Billion Devices.

VxWorks and LynxOS are also in billions of devices.

westfw,

Please don't write-off courses like UCB EECS149, hundreds of universities are developing this type of course and thousands of engineers around the world are taking these courses.

A large effort and substantial funding is going into improving engineering education for what we call embedded systems. NSF funds this area under "Cyber-Physical Systems". Google for this phrase to see the level of activity.

Remember, you will be sharing the road with autonomous vehicles these engineers design. These won't be just any old vehicles, NSF wants:

Automation for Truck Platooning.

A short update: I recently added an object-oriented refactoring of the VirtualWire library to Cosa, and extended it with a Manchester Phase Encoder (MPE) as an alternative codec.

https://github.com/mikaelpatel/Cosa/blob/master/Cosa/VWI.hh
https://github.com/mikaelpatel/Cosa/blob/master/Cosa/MPE.hh

Please see the example code for VWI and MPE.

There is also an IOStream driver for the Virtual Wire Interface (VWI) which allows simple binding of an iostream to the wireless connection and printouts over the connections. Note that there is no retransmission so printouts may be lost. Retransmission has to be implemented on the next level (ie protocol stack or message protocol). Sending messages over VWI and MPE is a bit like UDP but without addressing.

https://github.com/mikaelpatel/Cosa/blob/master/Cosa/IOStream/Driver/VWIO.hh

Have fun().

Hi Kowalski,
I cant resist saying how your work is great with Cosa, lot of work and lot of good ideas in there to make the lib powerfull and exhaustive !
may I suggest 3 things for it success or adoption :

  • make it modular : dont force any body, by its structure, to use a module they dont need. for example, I could use iemdiately Pins and event, but I m not interested by other HAL around SPI or TWI. of course youd say it is possible, but we have to make this "choice" and interoperatibility with Arduino.h as simple as possible. in that respect the config file from chibios is a potential idea here.
  • make sure you end up with a team of adopter/contributor to support the Cosa project. before starting using and deep diving with a new core we want to be sure it will be supported further
  • please prepare and organize so that the library can be used one day or another with ARM boards like Teensy3 and Due ! should put plenty of #ifdef arm/AVR, doing this during coding will also force you to find a data model and a code structure which is not closed to the ARM

amazing job again

A new blog posting is now available with a short presentation of the Benchmarking of the Pin classes with some details on how the Trace/IOStream classes work in Cosa.

This posting will be expanded with more details.

Cheers!

fabriceo:
Hi Kowalski,
I cant resist saying how your work is great with Cosa, lot of work and lot of good ideas in there to make the lib powerfull and exhaustive !

Hi Fabriceo, thanks for you encouraging remarks to this project. Your suggestions are all very relevant and some of them are on the "agenda" while others will take some time to achieve.

fabriceo:

  • make it modular : dont force any body, by its structure, to use a module they dont need. for example, I could use iemdiately Pins and event, but I m not interested by other HAL around SPI or TWI.

Users should be able to get started with only a sub-set of Cosa without adapting to the whole execution model. Even if Cosa is compiled by the Arduino build system only the parts included in a sketch will be used. But I am not sure if this is what you mean? Would be great with an example of how you would like to configure.

fabriceo:

  • make sure you end up with a team of adopter/contributor to support the Cosa project. before starting using and deep diving with a new core we want to be sure it will be supported further

This is the toughest as it takes both time and critical mass. First I hope for a group that are willing to test and evaluate Cosa but later on a team with contributors are needed to allow it to scale to other boards, etc. There is still some refactoring to be done to improve the class hierarchy, reduce the memory footprint further and allow usage from ATtiny to Mega and later on to ARM, etc.

For now I have focused on main-stream Arduino and scaling to ATtiny 44/85, multi-board configurations and wireless communication and supporting middleware tools. My next focus is a routing node for communication to sensor data clouds.

Thanks again!

Hey Kowalksi,
I stumbled on this thread and Cosa in my search (over the past 3 months) for some VirtualWire code that is compatible with the AtTiny85. I was able to get the VWIsender example to run on an AtTiny85 and successfully send messages to an Arduino Micro running VirtualWire over simple 433tx/rx components. YAY! At first, I didn't understand why you went through the trouble to "objectify" the standard Arduino functions into your own object-scheme, but after reading your blog posts and digging through quite a few of the samples, I now have a better understanding of the platform and that it is a complete replacement/alternative to the Arduino code base.

I have a few questions though.
The first one is in regards to sleeping. Is it possible to permanently sleep an AtTiny85 and wake on INT0=LOW with COSA? I saw that ON_CHANGE and FALLING/RISING were implemented in the InterruptPin class, but the AtTiny85 only supports LOW to bring it out of sleep mode. I'm wanting to control the sleep state with a reed switch and am not interested in the Watchdog timer for this project.
Here is a simple Arduino code block that I have used successfully: (mostly stolen from the samples here: Gammon Forum : Electronics : Microprocessors : Power saving techniques for microprocessors)

set_sleep_mode(SLEEP_MODE_PWR_DOWN);  
sleep_enable();
attachInterrupt(0, wake, LOW);
sleep_cpu ();

And second, I see that you have uploaded some Manchester Encoding libraries to the project. Would you recommend using those over the standard VWI libraries?

Any help is greatly appreciated!
Thanks!

sirhax:
Hey Kowalksi,
I stumbled on this thread and Cosa in my search (over the past 3 months) for some VirtualWire code that is compatible with the AtTiny85. I was able to get the VWIsender example to run on an AtTiny85 and successfully send messages to an Arduino Micro running VirtualWire over simple 433tx/rx components. YAY!

Hi Sirhax, great news! Getting the example running requires some "engineering" as the ATtiny85 need programming, etc. Real fun reducing a sketch all the way down to an ATtiny85. BW did the Micro run the original VirtualWire library? I havn't tested that scenario but it should be possible as the protocol has not been changed in the refactoring to C++.

You should use the same power down strategy as in your snippet with the Cosa InterruptPin. Let me check the details on the ATtiny85.

I added the Manchester Phase Encoder with a Ethernet-like frame mostly as a homage to historical coding methods. The original VirtualWire 4 to 6 bits encoding is 25% more efficient as Manchester Phase encoding is 4 to 8 bits. You could actually use the VWI/MPE class to communicate over wire instead of an UART. This can be of interest if using the ATtiny internal 8 MHz clock. My intention is to merge the two classes into a common Codec class in a later stage. The bit encoding will be a parameter or sub-class selection.

It would be nice to know what other examples you have successfully run and on what hardware.

Thanks for your interest in this project.

sirhax:
The first one is in regards to sleeping. Is it possible to permanently sleep an AtTiny85 and wake on INT0=LOW with COSA? I saw that ON_CHANGE and FALLING/RISING were implemented in the InterruptPin class, but the AtTiny85 only supports LOW to bring it out of sleep mode.

Got it! Pushed a fix for that. I forget that mode for the InterruptPin. The new mode is ON_LOW_LEVEL_MODE(0).
https://github.com/mikaelpatel/Cosa/blob/master/Cosa/Pins.hh

Try the below snippet:

InterruptPin IRQ(Board::EXT0, InterruptPin::ON_LOW_LEVEL_MODE);
...
IRQ.enable();

If you need your own interrupt handler use a sub-class and implement the virtual member function on_interrupt(). The default pushes an Event::CHANGE_TYPE(this) and requires an event loop for the processing. With a sub-class you can override this with an empty interrupt handler if you are only going to use this for wakeup.

Cheers!

Hi kowalski,
Thanks for the responses and the quick code updates!

BW did the Micro run the original VirtualWire library?

Yes, I was running the mikem's original VirtualWire on the Micro.

as the ATtiny85 need programming, etc. Real fun reducing a sketch all the way down to an ATtiny85

I originally used this guide to program the ATtiny85 with my Uno as the ISP: http://hlt.media.mit.edu/?p=1695
And I didn't really have to "reduce" the sketch to get it the sample to work...

I guess I still don't understand how to cause the controller to sleep with Cosa without using the watchdog timer. I want it to sleep indefinitely until the INT0 pin goes LOW.
I'll have to see if I can figure out how to how to implement my own interrupt handler sub-class (some sample code might be helpful :wink: )

One other question :slight_smile: -- Do you have a Cosa equivalent to SoftwareSerial? http://arduino.cc/en/Reference/SoftwareSerial

Thanks again for the help so far and the timely responses!

Ok, I pushed a new example where the InterruptPin on an ATtiny85 is used to wakeup after a power-down sleep. On wakeup a message is send using the VWI transmitter. The example uses the same message format as the CosaVWIreceiver so you can use that for testing. I think this is what you are looking for.
https://github.com/mikaelpatel/Cosa/blob/master/examples/VWI/CosaVWIkey/CosaVWIkey.ino

Actually this got me thinking that I might change the default interrupt handler to an empty function instead of pushing an event.

sirhax:

BW did the Micro run the original VirtualWire library?

Yes, I was running the mikem's original VirtualWire on the Micro.

Thanks for verifying that, appreciated. Nice to know that I did not "refactor" too much :wink:

sirhax:
I originally used this guide to program the ATtiny85 with my Uno as the ISP: http://hlt.media.mit.edu/?p=1695
And I didn't really have to "reduce" the sketch to get it the sample to work...

Yes, this is also the method that I have been using to test the sketches and Cosa on ATtiny.

sirhax:
One other question :slight_smile: -- Do you have a Cosa equivalent to SoftwareSerial? http://arduino.cc/en/Reference/SoftwareSerial

Thanks again for the help so far and the timely responses!

There is a very simple soft UART for the ATtiny but this will be replaced by a port of the SoftwareSerial when I come around to that.

Have fun() and thanks for the feedback!

2013-03-06 23.13.57.jpg

Man, kowalski, you have been quite the busy bee!
Originally, I wasn't sure if you had your own Cosa method for putting the boards to sleep versus just calling the built-in functions. And now, I see that you have created the Power class to support Sleep.
Thank you for going the extra mile to provide a sample with exactly what I needed. Also, I have been monitoring your numerous commits to the project! I am impressed with the progress and definitely plan to use this platform for future projects! Kudos on all of the hard work!