Pages: 1 ... 13 14 [15] 16 17 ... 30   Go Down
Author Topic: Cosa: An Object-Oriented Platform for Arduino programming  (Read 86272 times)
0 Members and 2 Guests are viewing this topic.
Offline Offline
Newbie
*
Karma: 2
Posts: 19
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the response, Kowalski!

Before adding this line (563) to CC1101.hh:
  Board::ExternalInterruptPin irq = Board::EXT4)
would it have fallen through and used EXT0?

For some reason, I originally used the documentation in NRF24L01P.hh since I knew the two chips were supposed pinout-compatable, so I had the IRQ connected to pin D2 at first.  After not seeing any traffic, I perused CC1101.hh and thought that the logic alleged that EXT0 was going to be used for the Mega.  Still nothing.

After seeing your response, I switched the pin back to D2 and still wasn't having any luck.  The two transceivers were sitting within a few inches of each other, but I didn't have antennas plugged into the sma connectors.  Apparently these boards/chips have zero range without antennas, as I finally saw some messages to appear on the CosaWirelessReceiver board after putting the two sma connectors right against each other.  After attaching some antennas, things started working consistently.  So that was likely my problem from the start. Doh!  I thought they should be able to reach a couple feet without antennas though... oh well.

After getting this to work fairly reliably, I have run into a situation where the CosaWirelessReceiver appears to stop receiving data after going out of range and then coming back.  Simply pushing the reset button on the CosaWirelessReceiver board causes data to start flowing again.  Have you run into this?

Thanks for verifying my configuration and taking the time to setup your own test -- I greatly appreciate it!
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Before adding this line (563) to CC1101.hh:
  Board::ExternalInterruptPin irq = Board::EXT4)
would it have fallen through and used EXT0?

For some reason, I originally used the documentation in NRF24L01P.hh since I knew the two chips were supposed pinout-compatable, so I had the IRQ connected to pin D2 at first.
@sirhax

Thanks for the feedback. Yes, the update was to avoid this problem and make the pin-out symmetrical for these types of CC1101 and NRF24L01P modules. You were on the right track. I ran into the same problem with the antenna when first testing the CC1101 modules ;-/

After getting this to work fairly reliably, I have run into a situation where the CosaWirelessReceiver appears to stop receiving data after going out of range and then coming back.  Simply pushing the reset button on the CosaWirelessReceiver board causes data to start flowing again.  Have you run into this?
No, havn't seen that. Need to rig up the test boards again and see if I can force that to happen. There is basically only one wait loop in CC1101::recv() that could cause this and it waits for either a receive interrupt or a timeout. See if I get some time later this week. Off to Stockholm for a few days.

Cheers!
« Last Edit: November 12, 2013, 05:22:56 am by kowalski » Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Previously I have presented some of the details on the object-oriented nature of Cosa and how this helps achieve higher performance (X2-X10 compared to Arduino/Wiring). There are actually more important differences regarding the software architecture and development principles.

One big difference between Cosa and other Arduino cores is that Cosa is a single source code baseline for a large set of boards,  processors (e.g. Uno, Mini Pro, Nano, LilyPad, Might, Mega, Tiny), modules and hardware devices. Over 25 different hardware module/devices are supported, not counting different adapters. Variant handling is built-in and may be extended without duplicating or forking the baseline. This allows you to retarget your sketches and move seamlessly between the supported targets. The main difference and restrictions are the available hardware resources (memory, hardware modules, etc) and performance (clock frequency, instruction set, etc). http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d5/d1f/classTWI_1_1Driver__inherit__graph.png

The Cosa support classes for SPI and TWI have the same interface for all targets. On ATtiny they are implemented with the USI hardware support. The same interface allows all the SPI and TWI device drivers to be reused on all targets without changing a single line of code. Both SPI and TWI classes implement a higher level of support for protocols and make device driver implementation easier (see iovec_t). The SPI interface also handles multiple SPI devices correctly even if the devices use the bus in different modes and/or speed. The ATtiny USI SPI implementation supports all modes; clock polarity and phase. http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/df/dea/classIOStream_1_1Device__inherit__graph.png

This style of handling variability is also used for some of the abstract device classes such as IOStream, LCD and Wireless. Implementations of these are also interchangeable. For some of the implementations there is yet another layer of adaptation to reduce the source code baseline and make it easy to move between different wiring/connections. The LCD driver implementation for HD77480 contains its own adapter abstraction seven different methods of connecting to the LCD device.  The same LCD interface is also implemented for PCD8544 and ST7565. http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/d0/d5f/classHD44780_1_1IO__inherit__graph.png

Another big difference is that Cosa has low power support built-in. Cosa uses an event-driven implementation strategy to avoid busy-waiting. This reduces power consumption dramatically (from 10-50 mA range down to 1-10 uA range and below).

Cheers!

Resources:
1. Installing Cosa, http://cosa-arduino.blogspot.com/2013/02/installing-cosa.html
2. Github, https://github.com/mikaelpatel/Cosa
3. On-line documentation, http://dl.dropboxusercontent.com/u/993383/Cosa/doc/html/index.html
Logged

Rapa Nui
Offline Offline
Edison Member
*
Karma: 60
Posts: 2073
Pukao hats cleaning services
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
that Cosa is a single source code baseline for a large set of boards,  processors (e.g. Uno, Mini Pro, Nano, LilyPad, Might, Mega, Tiny), modules and hardware devices
Any port to M0+, M3, M4 or something like that in planning? smiley
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Any port to M0+, M3, M4 or something like that in planning? smiley
Got my hands on a few TI MSP430 LaunchPads but I can't say when I would have time for that. I still have to figure out the tool-chain and the hardware details before porting. There is an Arduino port so some of the work is already done.

For ARM (e.g. Arduino Due) I would like to reduce the amount of tuning for AVR 8-bit (int8_t/uint8_t) and go for more generic and portable (int/unsigned int). Also I would like the toolchain to become more stable.

Still the amount of work is fairly large so I need to dig into the details before doing a plan (to answer your question in classical Dilbert style smiley-wink). Anyway this will not be happening this year as the focus right now is wireless networking protocols including a version of Google Protocol Buffer for data encoding/decoding .

Cheers!
Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 129
Posts: 8530
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Any port to M0+, M3, M4 or something like that in planning?
I've done quite a lot of work porting the Arduino core stuff to an M0 (LPC1227), I probably won't continue with it partly because other projects like Cosa seem to be 1000% better smiley

I have half a mind to port Cosa to LPCs but don't really have the time at present.

I guess the actual chip is more important than the ARM core though given that (I would assume) once you get the sysTick worked out almost all the code deals with peripherals.

_____
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I think I need to add a line or two regarding porting to other processors.

Cosa is right now very much adapted/optimized for 8/16-bit MPUs with very limited memory (SRAM). Moving to something with 8 Kbyte SRAM or larger I would redesign the core towards a true micro RTOS with threads, semphore, message queues, the works  smiley. There is no way to scale upwards without that.  The device driver layer would be rewritten. And the programming model moved towards active objects (actors).

Cheers!
Logged

Rapa Nui
Offline Offline
Edison Member
*
Karma: 60
Posts: 2073
Pukao hats cleaning services
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

And a HAL might help as well..
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Some news on the latest improvements and addition to Cosa:

1. Update of Cosa Networking Protocol draft (RETE)
https://github.com/mikaelpatel/Cosa/blob/master/RETE.txt

2. Added a template class for bitsets. See interface and example sketch.
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/BitSet.hh
https://github.com/mikaelpatel/Cosa/blob/master/examples/Sandbox/CosaBitSet/CosaBitSet.ino

3. Support for encoding and decoding Google Protocol Buffers protocol.
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/ProtocolBuffer.hh
https://github.com/mikaelpatel/Cosa/blob/master/examples/Sandbox/CosaProtocolBuffer/CosaProtocolBuffer.ino

Cheers!
Logged

nr Bundaberg, Australia
Offline Offline
Tesla Member
***
Karma: 129
Posts: 8530
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I would redesign the core towards a true micro RTOS with threads, semphore, message queues, the works
That would be a lot of fun to do but is all that necessary, could turn into bloatware.

I admit that some simple scheduling would be nice, and once you do that semaphores etc tend to follow. And event queues would be nice especially if usable with an FSM....

Ok maybe it is necessary smiley

_____
Rob
« Last Edit: November 15, 2013, 02:03:58 am by Graynomad » Logged

Rob Gray aka the GRAYnomad www.robgray.com

Offline Offline
Jr. Member
**
Karma: 2
Posts: 59
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I think by using ChibiOS / NilRTOS (use same HAL as of v3) as the RTOS, adapting COSA is not to much work.

I already can use parts of COSA using ChibiOS without any problems (for instance the whole digital/analogue pin OO implementation) and it does make my software a lot easier to read and maintain.

In some parts (for instance SPI / TWI stuff), I have to add locks (semaphores) to make sure things won't lock up or crash. Furthermore I don't use the events, as this does not play nice with ChibiOS, but that's about it...

If that synchronization functionality is implemented in COSA by a sync object that either does nothing (default COSA) or calls the underlying RTOS, the user of the COSA objects won't even notice the RTOS.

The only problem I see is that COSA disables interrupts on a lot of places...
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

After getting this to work fairly reliably, I have run into a situation where the CosaWirelessReceiver appears to stop receiving data after going out of range and then coming back.  Simply pushing the reset button on the CosaWirelessReceiver board causes data to start flowing again.  Have you run into this?
@sirhax

I have been able to force this behaviour and found what I think was the problem. Pushed a fix for this. See https://github.com/mikaelpatel/Cosa/commit/19b2f9e6f0bac13a61530c854529d26a9066a05c. Basically the receive fifo could contain incomplete messages as the interrupt is only generate for complete messages (correct address, length, crc). I had assumed that this was done automatically and illegal frames discharged.

Need to check if the NRF24L01P also has this behaviour.

Cheers!
« Last Edit: November 19, 2013, 02:28:37 pm by kowalski » Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The only problem I see is that COSA disables interrupts on a lot of places...
@MarsWarrior

The Cosa synchronized blocks are used to achieve consistent updates and are very short (in the range of 10-50 us). Long interrupt disabled blocks are avoided as Cosa is interrupt and event driven. Very few of these block would or should be replaced by semaphores (or rw_locks). It is consistency on another level of abstraction.

Anyway this is an important issue how to use a RTOS and write code that is still bare-metal and uses very little resources (SRAM). Would like to know more about your experience with this. Great job!

Cheers!
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 452
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

After getting this to work fairly reliably, I have run into a situation where the CosaWirelessReceiver appears to stop receiving data after going out of range and then coming back.
Need to check if the NRF24L01P also has this behaviour.
@sirhax

The Cosa NRF24L01P driver works as expected and does not show this behaviour. Message are retransmitted until the retransmit limit(15) is exceeded and then flushed. Getting back into range starts up the transmission/ack again without any problems.

Cheers!
« Last Edit: November 20, 2013, 06:29:34 pm by kowalski » Logged

Offline Offline
Newbie
*
Karma: 2
Posts: 19
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I have been able to force this behaviour and found what I think was the problem. Pushed a fix for this. See https://github.com/mikaelpatel/Cosa/commit/19b2f9e6f0bac13a61530c854529d26a9066a05c. Basically the receive fifo could contain incomplete messages as the interrupt is only generate for complete messages (correct address, length, crc). I had assumed that this was done automatically and illegal frames discharged.

Thanks Kowalski.  I finally got around to testing your latest commits and agree that the CC1101 transceivers appear to be much more reliable now.  Nice work!

I don't believe that the CC1101 has hardware message ACK and retransmission like the NRF24.  Do you have any plans to implement these features in the CC1101 driver?  If not, I may pursue it in my own applications.  

Also, the CC1101 has an "Integrated Analog Temperature Sensor" and was wondering if you have any plans to make that component available/accessible in the CC1101 driver?

I'm anxious for some cheap and readily available CC1200 boards to start popping up on ebay.

Thanks again and keep up the great work!
« Last Edit: November 21, 2013, 06:59:32 pm by sirhax » Logged

Pages: 1 ... 13 14 [15] 16 17 ... 30   Go Up
Jump to: