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!

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.

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

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

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

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

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.

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!

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.

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.