Go Down

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

sirhax

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!

kowalski

#211
Nov 12, 2013, 11:21 am Last Edit: Nov 12, 2013, 11:22 am by kowalski Reason: 1

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!

kowalski

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

pito

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? :)

kowalski


Any port to M0+, M3, M4 or something like that in planning? :)

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 .

Cheers!

Go Up