Go Down

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

fat16lib

#30
Mar 05, 2013, 03:11 am Last Edit: Mar 05, 2013, 03:15 am by fat16lib Reason: 1
I am not sure what your point is?
Quote

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.

Quote

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

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.



Quote

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

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

westfw

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

fat16lib

#32
Mar 05, 2013, 04:45 am Last Edit: Mar 05, 2013, 07:17 pm by fat16lib Reason: 1
Quote

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.

Quote

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:
Quote
Automation for Truck Platooning.


kowalski

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

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

kowalski

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.

http://cosa-arduino.blogspot.com/2013/03/benchmarking-pin-classes.html

This posting will be expanded with more details.

Cheers!

kowalski


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.


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


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

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!  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: http://gammon.com.au/power)
Code: [Select]

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!

kowalski

#38
Mar 06, 2013, 04:25 pm Last Edit: Mar 06, 2013, 11:28 pm by kowalski Reason: 1

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.

kowalski


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:

Code: [Select]

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!

sirhax

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

Quote
BW did the Micro run the original VirtualWire library?

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

Quote
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  ;) )

One other question :-) -- 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!

kowalski

#41
Mar 06, 2013, 11:00 pm Last Edit: Mar 06, 2013, 11:22 pm by kowalski Reason: 1
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.


Quote
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 ;-)


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.


One other question :-) -- 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!

sirhax

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!

kowalski

#43
Mar 09, 2013, 12:08 pm Last Edit: Mar 09, 2013, 12:47 pm by kowalski Reason: 1

Kudos on all of the hard work!

Thanks for the encouragement and providing some interesting challenges.

The power down mode was actually a very common pattern in the Cosa code so there was a real need to introduce the Power class and collect this in one place. The Power class must have saved a lot of program memory for larger applications.
https://github.com/mikaelpatel/Cosa/blob/master/Cosa/Power.hh

Your question on which encoder to select got me thinking about if there other more bit efficient codecs to consider. Also refactoring VWI and allowing extension with different codecs. After thinking awhile I introduced the VWI::Codec abstract class and collected both the original VirtualWire and the Manchester Phase Encoder in the same framework. This actually allows multiple codecs at runtime. They could be selected on the start symbol.
https://github.com/mikaelpatel/Cosa/blob/master/Cosa/VWI.hh

For fun I went looking for additional codecs and read up on CAN and USB bitstuffing. This gave me some ideas for a new codec; fixed bitstuffing, 4 to 5 bit encoding where bit(0) is the complement of bit(1) after left shift of the 4-bit data. It allows a higher application bit-rate but is a bit more vulnerable to noise. Please see the FBS examples in the VWI examples directory.

Last, I have ported VWI back to Arduino. You can find this C++ version of the VirtualWire library at:
https://github.com/mikaelpatel/Sketchbook/tree/master/VirtualWire

Cheers and thanks again!

sirhax

Hey Kowalski,

I ran into an issue trying to compile the latest CosaVWIsender example when targeted for the AtTiny85.  It compiles fine for the Uno.

Here are the errors I'm getting:
d:/temp/downloads/arduino-1.0.3-windows/arduino-1.0.3/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr25/crttn85.o: In function `__vector_default':
(.vectors+0x14): relocation truncated to fit: R_AVR_13_PCREL against symbol `__vector_10' defined in .text.__vector_10 section in core.a(RTC.cpp.o)

d:/temp/downloads/arduino-1.0.3-windows/arduino-1.0.3/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr25/crttn85.o:(.init9+0x2): relocation truncated to fit: R_AVR_13_PCREL against symbol `exit' defined in .fini9 section in d:/temp/downloads/arduino-1.0.3-windows/arduino-1.0.3/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/avr25\libgcc.a(_exit.o)


I wish my low-level knowledge of the avr platform was advanced enough to offer some assistance...

As always, any help is greatly appreciated!

Go Up