Pages: 1 ... 11 12 [13] 14 15 ... 22   Go Down
Author Topic: Cosa: An Object-Oriented Platform for Arduino programming  (Read 51033 times)
1 Member and 1 Guest are viewing this topic.
Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@englund

Sorry for the delay.

I looked into your first post again and I think that you have got Cosa installed correctly to allow mixing Arduino and Cosa code. What I need to figure out and understand is what your sketch is including and if you have organized your code with additional class files in your sketch folder.

Best thing to do is to track down compiler errors. Let us first step back to the install procedure just to verify. As I mentioned Cosa is now an Arduino core and much easier to install. The drawback is that Arduino/Wiring functions will not be available (in this installation variant). The work-around is to install as you already have done. That is, from the unzipped Cosa folder move the cores/cosa/Cosa folder to the arduino/hardware/arduino/cores/arduino folder.

If you move the examples folder from the Cosa unzipped folder to your Sketch book they will become available and you can verify that you can build the Cosa example sketches. I am assuming you are using Windows. If you are using Linux replace the moving of folders with symbolic links to the directories instead.

Now back to your compiler errors. To go further on this you will have to post or send me a copy of the include section of your sketch. This will give a hint on how to work-around the conflicting symbols. Even better is to locate the pre-processed file (ino => cpp file) as it contains all the symbol definitions.

I think we need to seek the symbol conflict in your sketch or the libraries. What I can see of Arduino.h and pins_arduino.h there is no problems there.

Below is a semi-port of one of the NEXA example sketches. Instead of using the Cosa OutputPin member functions to toggle a LED on receiving a NEXA remote command the Arduino/Wiring digitalWrite() function is used.
Code:
#include "Cosa/Pins.hh"
#include "Cosa/Event.hh"
#include "Cosa/Driver/NEXA.hh"
#include "Cosa/RTC.hh"
#include "Cosa/Watchdog.hh"

class LED : public NEXA::Receiver::Device {
private:
  uint8_t m_pin;
public:
  LED(uint8_t pin) : NEXA::Receiver::Device(0L), m_pin(pin)
  {
    pinMode(m_pin, OUTPUT);
  }
  virtual void on_event(uint8_t type, uint16_t value)
  {
    digitalWrite(m_pin, value);
  }
};

NEXA::Receiver receiver(Board::EXT0);
LED device(LED_BUILTIN);

void setup()
{
  RTC::begin();
  Watchdog::begin();
  NEXA::code_t cmd;
  receiver.recv(cmd);
  device.set_key(cmd);
  receiver.attach(&device);
  receiver.enable();
}

void loop()
{
  Event event;
  Event::queue.await(&event);
  event.dispatch();
}
This compiles nicely in Arduino 1.0.5. Short on how the sketch works;
1. Connect a RF433 receiver module to EXT0 (that is Arduino pin D2).
2. Upload the sketch to your Arduino.
3. Use a NEXA remote. The address of the first code sent will be used as the address for the Arduino NEXA receiver.
4. After that pushing ON and OFF will turn the built-in LED on and off.
A modification is to add the serial device and print the received command code. And then hardwire it in the sketch. The next step is obviously to add a learning mode where the received code/address is stored in EEPROM.

Cheers!
« Last Edit: August 12, 2013, 02:17:02 am by kowalski » Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@englund

Here is the first problem:
https://github.com/LowPowerLab/WirelessProgramming/blob/master/WirelessHEX/WirelessHEX.h#L16
Code:
#define LED 9 //LED on digital pin 9
That should be defined as a typed value if it should be there at all.

BW: I had a look at Moteino and that might be a nice board to support with Cosa and add a device driver for the RFM69. The board is basically a variant of Arduino Pro Mini (ATmega328P).

Cheers!
« Last Edit: August 12, 2013, 01:20:29 am by kowalski » Logged

Sweden
Offline Offline
Newbie
*
Karma: 0
Posts: 6
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@kowalski

Thanks again for the quick reply! I will give your Nexa semi-port example a go asap.

I decided to try using Cosa with a couple NRF24L01+ I had lying around and got them communicating fine using the ping-pong example and the client-server example. However, both examples stop receiving when I go out of range and don't resume communications when I get in range again. Is there an easy way to modify any of these examples to provide a range/coverage testing application that tells me when packets are lost and when they reach the destination?
Logged

Sweden
Offline Offline
Newbie
*
Karma: 0
Posts: 6
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

And btw, supporting Moteino and RFM69 in Cosa would be awesome! Wireless programming of nodes and good range are the things that got me hooked on the Moteino and RFM69.
Logged

Sweden
Offline Offline
Newbie
*
Karma: 0
Posts: 6
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry for spamming... I just managed to modify the ping-pong example to do what I wanted. Turns out the range is quite ok on these guys although some packets get lost. Is there a mechanism to auto re-transmit until successful or would I have to implement this myself by sending back an ACK packet (and re-transmit until I get that ACK)?
   
It would be great if you could support wireless programming over nRF24L01+, is that something you would consider integrating into Cosa?
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I decided to try using Cosa with a couple NRF24L01+ I had lying around and got them communicating fine using the ping-pong example and the client-server example. However, both examples stop receiving when I go out of range and don't resume communications when I get in range again. Is there an easy way to modify any of these examples to provide a range/coverage testing application that tells me when packets are lost and when they reach the destination?
@englund

Nice the hear that you are testing other parts of Cosa as well and not just the NEXA support.

The NRF24L01+ is a second rewrite towards a Socket interface style to allow future interplay between Wifi, BT, NRFXX, etc. The current version is in mid-air as I am rethink the inheritance strategy to get down the footprint for ATtiny. The previous version left at least 3K over. This version does not leave that much over - I am sorry to say.

Yepp it would be possible to modify the example sketches and pull some performance statistics out of the chip. The protocol also needs to become more robust. Right now there is a lack of a timeout in the hand-shake. I have (kind of) left that to the application layer right now. Actually I think the driver goes into a bad state when the max retransmission level is exceeded. There is a need to flush the chip FIFO and resend.

BW if you have a few RF433 modules you could try the Cosa support for that. This weekend I have been testing different configurations. I have an Arduino Pro Mini (spec 5V/16 MHz) with two 1-Wire DS18B20 temp.sensors and a RF433 TX module running off a 3.7V battery (example sketch CosaVWItempsensor).

Been testing the limits of these ultra cheap radio modules. The receiver is hooked to an Arduino Nano. This setup has been running for over 50 hours now with an average power consumption (on the Pro Mini) of 2 mA. That is without any modification of the board. Works nicely between different ends of the our house (at least three walls and about 10m). Below is a sample of the CosaVWItempmonitor output.
Code:
0xc052:147:sample:21.43:21.43:3.831
0xc052:148:sample:21.43:21.43:3.831
0xc052:149:sample:21.43:21.43:3.831
0xc052:150:sample:21.43:21.43:3.831
0xc052:152:sample:21.43:21.43:3.831

Cheers!
« Last Edit: August 12, 2013, 01:09:04 am by kowalski » Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry for spamming... I just managed to modify the ping-pong example to do what I wanted. Turns out the range is quite ok on these guys although some packets get lost. Is there a mechanism to auto re-transmit until successful or would I have to implement this myself by sending back an ACK packet (and re-transmit until I get that ACK)?
@englund

No problem. Nice to hear that you got it working. The current setting of the NRF24L01+ chip is auto-ack and max retransmission. But it is still possible that this is not enough and then the application layer needs to step in and issue a resend or consider the receiver "dead". There is a lot of noise on 2.4 GHz so there are bursts of noise that may exceed the retransmission limit.

A better protocol is needed. Right now this is a very raw communication channel. There is also some performance to be gained by using NRF24L01+'s ability to send a payload with the auto-ack message. This would work for sensor nodes that periodically push data. Messages "down-stream" could then be sent with the ack of the next data "up-stream".

It would be great if you could support wireless programming over nRF24L01+, is that something you would consider integrating into Cosa?
Yes, thats on the looong to-do-list. Any serious IoT/M2M framework will need to allow remote update of software. Before doing this I need to add more infra-structure for security. I have just started to add encryption algorithms (Vigenere and RC4). My intent is to modify one of the bootloaders so that it can use an encrypted IOStream or Socket as source. It would be difficult to get all this to fit in an ATtiny84. 8K program memory is not much.

Also I need to get a Cosa version of a W5100 driver in place. And obviously support for ATmega32U4/USB. It all adds up and it is soon back to my day job :-)

Hum, that was kind of a spoiler on things to come.

Cheers and have fun().

BW Feel free to use the Issues handling on github for suggestions, bug reports, modifications, etc.
https://github.com/mikaelpatel/Cosa/issues?page=1&state=closed
« Last Edit: August 12, 2013, 02:09:41 am by kowalski » Logged

Sweden
Offline Offline
Newbie
*
Karma: 0
Posts: 6
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@kowalski

Great answers as always smiley-grin
Seems there is some work left with the nRF24L01+ networking then but nice to hear that it seems to be in the near future of your pipeline.
Another thing that would be awesome is to have dynamic mesh network support for nRF24L01+. That would make the RFM69W harder to motivate since I'm currently purchasing them for $7 and a nRF24 module can be had for $1.2 on ebay and with a mesh you can extend the range of nRF24 by just adding a few nodes where needed.

Regarding RF433 I have had the feeling that nRF24 is more reliable and has slightly better range (without testing myself). And since they cost the same ($1.2) on ebay I just never ordered any RF433. Also the nRF24 doesn't need two whip antennas..

I'm all for cheap hardware but when you can get a Arduino Pro Mini for $3.75 on ebay it almost seems like a bit of a waste of time to try and make all of Cosa work on a ATtiny..

Also I feel that you almost always want do to some processing of data in a local PC so ethernet/wifi nodes seem a little unnecessary (since you might aswell just plug in a nRF24 node via USB to that PC server), but maybe that's just me smiley

I hope wireless programming, reliable communication and mesh networking become a reality for nRF24 soon! Keep up the good work!


Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Great answers as always smiley-grin

Seems there is some work left with the nRF24L01+ networking then but nice to hear that it seems to be in the near future of your pipeline.
Another thing that would be awesome is to have dynamic mesh network support for nRF24L01+.
@englund

Thanks but is was mostly CMA as the NRF24L01+ support is very basic right now. About the same level as other libraries out there. What is maybe new is the addressing in a UDP-style with 32b address and 16b port and the "socket" mapping to the chip pipes.

The dynamic mesh support is somewhat more work ;-). Would need to understand more of the use cases before considering it as I guess it should be "dynamic" with a minimum of configuration. That would mean dynamic routing tables. And package queuing which sounds like memory. With only 2 K byte on a ATmega328 this could be a problem depending on the amount of traffic you would like to route. Restricting routing to a ATmega2560 with 8K byte might be the road to go.

Regarding RF433 I have had the feeling that nRF24 is more reliable and has slightly better range (without testing myself). And since they cost the same ($1.2) on ebay I just never ordered any RF433. Also the nRF24 doesn't need two whip antennas..

I'm all for cheap hardware but when you can get a Arduino Pro Mini for $3.75 on ebay it almost seems like a bit of a waste of time to try and make all of Cosa work on a ATtiny..
Thought you have a few RF433's to test the NEXA stuff? Anyway you are completely right on the price/cost of hardware. The Arduino Pro Mini's are perfect for a wide range of small scale applications. One would need to procedure a fair number of custom boards with ATtiny before motivating that. But then it would be nice to have to software platform to be able to do that when needed.

Back to the RF433. The fun here is the "low level". It is basically a transmitter and the whole protocol is done in software. That is an interesting challenge and it gives the possibility to play around with a number of abstraction layers at the same time.

But you are totally right when it comes to cost, etc. The NRF24L01+ module is very difficult to compete with.

Cheers!
« Last Edit: August 14, 2013, 07:01:01 am by kowalski » Logged

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

I am exploring the CosaVWIPClient & Server examples.

Currently, the example just sends some messages from the client and they are received and acknowledged by the server. What I wish to do is to be able to send the messages back to the client from the server on receiving some message from client. How to do it using trx ?

Any help on this topic please, I think may be I haven't quite understood how this system works...

Thanks,
Saumik
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@saumik

A reply from sunny Sirmone on the Garda Lake.

You can achieve what you are asking for by combinding the client and server example. More efficient is to introduce separate queues for the transmitter and receiver. Right now the support is tuned towards sensor networks which is a special case.

I will see if I can put together an example more in line with what you are looking for when I am back in Sweden next week.

Cheers!
Logged

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

@kowalski

Thanks for the reply and the help! Must admit that you are really doing a great job with Cosa!

Actually what I am trying to do is to make a wireless quiz buzzer system. I need to identify who has hit the buzzer first. The problem with using just the simple client-server example is that when two or more buzzers (clients) send their messages together, I either get a bad checksum or bad address or sometimes the ACK from the server gets lost. There is no means to do a CSMA/CD or something similar since these are normal RF modules (433 MHz ones).

So, I am planning to move onto a polling based method where the server polls each client for a 'hit' and the clients one by one send the timestamp of the hit. Also, a periodic time sync message would be sent by the server to all clients. I am doing all this to simply avoid transmission at the same time by two or more entities.

Is there any other easy way out or a faster and more accurate method than this one ? Will the nRFL01+ modules help ? I don't want to use XBee for such a simple and low budget project. What should I do to achieve this stuff ?

Thanks,
Saumik
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@saumik

That was an interesting project. It would be difficult to avoid possible collisions with RF433 and VWI if the buzzer would be allowed to send at any time. The VWI library does not support that.

A better solution would be to do as you suggest; 1) broadcast an "ARM" message to the buzzers, and then 2) poll them until timeout or one answers. You would also need a simple method of assigning addresses and attaching them. This could be done as a startup phase before the "game".

The buzzers would also need to report back the time measured until the button was pressed.

The NRF24L01+ is easier to use as it provides basic retransmission. You would need that even for the RF433 version as the poll message needs to be answered with a time measurement or not pressed (ack). My guess ;-)

Anyway, good luck with this project!

Cheers.
Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have started to use the github issue handling for new items on the development list. Please comment these to help with priority. Add suggestions or improvements.

https://github.com/mikaelpatel/Cosa/issues?state=open

Cheers!
« Last Edit: September 17, 2013, 09:25:13 am by kowalski » Logged

Sweden
Offline Offline
Sr. Member
****
Karma: 6
Posts: 372
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

For those of you that are following the Cosa project it might seem like there is a lack of progress after the summer holiday. Before pushing the next update I thought I would describe one of the ongoing refactoring and updates.

INTEGRATING MULTIPLE SPI LIBRARIES

The initial Cosa SPI class extended the Arduino SPI library with SPI/USI bus controller, slave device support, interrupt handling and a rich set of functions for typical SPI device interaction. Unfortunately it did not address one of the more important SPI issues.

On this forum there are a number of requests for support with integrating several SPI devices/libraries. The problem is often that the devices have different SPI bus usage, e.g. different speed, bit order, mode, etc, resulting in conflicts and confusion. Each library will work perfectly on its own but not together. Most of these support requests end with a recommendation to use SoftSPI and avoid the problem by using more pins. There are also very few SPI device libraries that use interrupts and do not work very well in low power applications as they require polling.

What are the requirements on the SPI library? Obviously it should be able to handle multiple devices with different settings. It should also support chip select and interrupt signals. Be available for both ATmega and ATtiny, i.e., SPI and USI hardware modules and allow replacement with a bit-banging version when needed through simple configuration.

As the TWI/Wire the functions begin() and end() should be used to define an SPI interaction block. The current usage in the Arduino SPI library is more or less a setup. Most SPI device libraries assume that there is only one device on the bus.

Addressing the interrupt issue is especially interesting as the interrupt handle will want to perform SPI transfers (read/write) to at least check the interrupt status register in the serviced device. Without special care this gives concurrency problems as an interrupt could be issued during an ongoing SPI transaction. This becomes even more challenging if the interrupt is issued from another SPI device on the same bus. Simply disabling interrupts is not a very good idea as this may affect other concurrent activities such as incoming data in other hardware modules (TWI, UART, etc).

The design must support architectures with multiple SPI bus controllers.

The ongoing Cosa SPI redesign tries to address the above issues and attempts to meet the requirements.
The design so far has resulted in the evolution of the initial SPI::Driver root class to hold the context of the SPI hardware (SPI control register) and chip select pin (OutputPin) so that spi.begin()---spi.end() will perform

  • loading of the SPI hardware state,
  • toggling the chip select pin,
  • disabling interrupt handlers to allow mutual exclusive access.
  • handle the clock pin polarity for ATtiny/USI implementation to achieve all four SPI modes

The ripple effect is a major update of the Cosa's SPI device driver. Which then results in a large batch of regression testing before pushing the update.

Cheers!
Logged

Pages: 1 ... 11 12 [13] 14 15 ... 22   Go Up
Jump to: