Pages: 1 ... 19 20 [21] 22 23 ... 29   Go Down
Author Topic: Cosa: An Object-Oriented Platform for Arduino programming  (Read 75020 times)
0 Members and 2 Guests are viewing this topic.
Sweden
Offline Offline
Sr. Member
****
Karma: 11
Posts: 437
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

A short update on the latest development. Two new MQTT client example sketches are available together with the the very first increments of the multi-tasking support.

The two MQTT example sketches show how easy it is to measure and push sensor data to an MQTT server. With available apps and web-clients no extra efford is needed to start monitoring.

1. CosaMQTTtemperature
Reads 1-wire temperature sensor (DS18B20) and publishes to MQTT server.
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/IoT/MQTT/CosaMQTTtemperature/CosaMQTTtemperature.ino

2. CosaMQTThumidity
Reads DHT11 humidity and temperature and publishes on two topics.
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/IoT/MQTT/CosaMQTThumidity/CosaMQTThumidity.ino

3. Cosa/Nucleo/Thread+Semaphore+Mutex
The first increments towards threads and other RTOS functionality contains a minimalistic implementation of threads (coroutines), semaphores and mutex. No assembly code, only C/C++ and a very small foot-print. The context switch (resume) is only four lines of code and together with the main thread run() member function supports low power idle mode.
Code:
void Thread::resume(Thread* t)
{
  if (setjmp(m_context)) return;
  s_running = t;
  if (t->m_state) s_go_idle = false;
  longjmp(t->m_context, 1);
}
// Main thread with low power mode support
void Thread::run()
{
  while (1) {
    s_go_idle = true;
    yield();
    if (s_go_idle) Power::sleep(s_mode);
  }
}
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Nucleo/Thread.hh
Source: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Nucleo/Thread.cpp
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoThread/CosaNucleoThread.ino
And semaphores;
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Nucleo/Semaphore.hh
Source: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Nucleo/Semaphore.cpp
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoSemaphore/CosaNucleoSemaphore.ino
And mutex (some syntactic sugar for mutual exclusive blocks of code using semaphores)
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Nucleo/Mutex.hh
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoMutex/CosaNucleoMutex.ino
There is also a start of a benchmark suite. The initial context switch benchmark shows 12 us and semaphore signal-wait at 42 us.
https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoBenchmarks/CosaNucleoBenchmarks.ino
This is without any optimizations. All written in standard C/C++. There are additional example sketches, https://github.com/mikaelpatel/Cosa/tree/master/examples/Nucleo, such as the classical blink sketch with two threads; one for the LED blink and the other controlling the blink period. They may be built and run on standard Arduino, Mega, Mighty and Tiny. The blink thread sketch will run three threads (main, LED and LED controller) on as little as ATtiny85's SRAM size (512 byte) and less than 2K byte program memory. https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoBlink/CosaNucleoBlink.ino
The main thread will power down while waiting for the Watchdog interrupt giving less than 5 uA when LED is off and typically 1-3 mA when LED is on.

Cheers!
« Last Edit: March 02, 2014, 05:12:29 pm by kowalski » Logged

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

I already like  where Nucleo is going. Looks very promising for the more complex tasks where a simple Arduino performs several parallel tasks!

I also checked the examples for MQTT. I see that you are using the LAN interface. Is it possible for remote nodes to send MQTT rmessages over an RF connection (nRF24, RFM69), to a central node that puts the message on the LAN?
It is unclear to me that the RFconnection can send large messages.

And of course the way back from the central node to any of the remote nodes requires some kind of administration I guess.
Logged

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

I already like  where Nucleo is going. Looks very promising for the more complex tasks where a simple Arduino performs several parallel tasks!
@MarsWarrior
The above post was the initial increments of Nucleo, the multi-tasking support in Cosa.  It will be integrated with the Cosa watchdog, timers and drivers in coming updates. There will also be more support for message passing, thread synchronization and priority. Also I need to work though the ISR integration so that it at least becomes possible to signal a thread from an ISR. Nucleo is right now a very simple straight forward implementation and very much in the prototyping phase.

I also checked the examples for MQTT. I see that you are using the LAN interface. Is it possible for remote nodes to send MQTT rmessages over an RF connection (nRF24, RFM69), to a central node that puts the message on the LAN?
It is unclear to me that the RFconnection can send large messages.
Yes, the Cosa MQTT client implementation uses Sockets and the Cosa W5100 device driver. There is no support for MQTT over the Wireless interfaces (MQTT-SN?). Right now the Wireless device drivers do not handle large payloads or streams. The interface is not connection oriented as TCP/IP. It is possible to bridge the Wireless interface to MQTT. Basically a central node that receives wireless messages with sensor data and then translates and transmitts them to a MQTT server.

The Wireless interface will later on support message acknowledgement and retransmission (as the NRF24L01+ has builtin). And after that extended to allow routing nodes. Then on top of that it is better suited to implement MQTT-SN.

Anyway this is all about the architecture and infra-structure for small sensor networks. And what I want to point out is that the local sensor network may use very cheap RF technology and transmit to a bridge instead of forcing a heavy weight TCP/IP socket level protocol onto the sensor nodes.

I am considering adding support for Exosite, Xively, ThingSpeak and XMPP. The two first are commerical protocols so I need to work out the details if promoting them and their server/cloud services. The challenge will be to abstract them (including MQTT and SNMP) to a single interface so that applications may move between them.

I recently got hold of a SIM900 GSM / GPRS Shield development board and plan to write a Socket driver for that. All the Cosa Ethernet (INET) classes such as MQTT can then be used with this transport layer.

Cheers!
« Last Edit: March 02, 2014, 03:24:30 pm by kowalski » Logged

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

I haves een MQTT-SN implementations for Arduino and RF devices (JeeNode with RFM12B, CC stuff etc), and some of them are pretty small - qos -1 with only a publish function - and some are rather large - taking 20kb space...

Some I had noted some time ago:
- https://github.com/X13home
- https://github.com/TomoakiYAMAGUCHI/MQTT-S

And your GSM hardware also sounds nice!
Logged

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

The latest update of Cosa includes a ThingSpeak client for channel update. Allows post of sensor data to the ThingSpeak server and then visualization. The example sketch demonstrates reading a DHT11 sensor and posting humidity and temperature reading. https://thingspeak.com/channels/10734. Below is a snippet from the example sketch.
Code:
void loop()
{
  ThingSpeak::Channel channel(&client, KEY);
  ThingSpeak::Entry update;
  sensor.sample();
  update.set_field(1, sensor.get_temperature(), 1);
  update.set_field(2, sensor.get_humidity(), 1);
  TRACE(channel.post(update)));
  SLEEP(20);
}
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/IoT/ThingSpeak/CosaThingSpeakClient/CosaThingSpeakClient.ino
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/IoT/ThingSpeak.hh

This interface is not complete and currently only supports channel update. It will be extended with support for the other ThingSpeak server features; e.g. TalkBack, ThingHTTP, TweetControl API, and chart download to Arduino TFT (Cosa Canvas).

Cheers!

« Last Edit: March 05, 2014, 06:26:26 pm by kowalski » Logged

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

The next increment of the ThingSpeak API support in Cosa is now available. This update contains an implementation of the ThingSpeak TalkBack API and allows execution of commands sent to the server command queue. See https://thingspeak.com/docs/talkback for more details.

The Cosa support allows easy extension of a command handler by basically sub-classing the ThingSpeak::TalkBack::Command class and implementing the virtual member function execute(). The application does not need to match command strings and dispatch command handlers. All that is provided by the Cosa ThingSpeak TalkBack classes.

Below is a snippet from the example sketch. This section shows how to define a command handler. In this case a generic command handler that traces the command string.
Code:
class Command : public ThingSpeak::TalkBack::Command {
public:
  Command(ThingSpeak::TalkBack* talkback, const char* string) :
    ThingSpeak::TalkBack::Command(talkback, string)
  {}
  virtual void execute();
};

void
Command::execute()
{
  trace << Watchdog::millis() << ':' << get_string() << endl;
}

const char LED_ON[] PROGMEM = "LED_ON";
const char LED_OFF[] PROGMEM = "LED_OFF";
const char REBOOT[] PROGMEM = "REBOOT";

// Talkback command
Command led_on(&talkback, LED_ON);
Command led_off(&talkback, LED_OFF);
Command reboot(&talkback, REBOOT);
The setup and loop functions are very simple. Basically intiating the ethernet driver, creating a ThingSpeak client and executing queued commands on the server.
Code:
ThingSpeak::Client client;
ThingSpeak::TalkBack talkback(&client, KEY, ID);
...
void setup()
{
  uart.begin(9600);
  trace.begin(&uart, PSTR("CosaThingSpeakTalkBack: started"));
  Watchdog::begin();
  TRACE(ethernet.begin_P(HOSTNAME));
  TRACE(client.begin(ethernet.socket(Socket::TCP)));
}

void loop()
{
  // Take a nap if there was nothing to execute
  if (talkback.execute_next_command() != 0) SLEEP(30);
}
Example sketch: https://github.com/mikaelpatel/Cosa/blob/master/examples/IoT/ThingSpeak/CosaThingSpeakTalkBack/CosaThingSpeakTalkBack.ino
The TalkBack command queue can be connected to a ThingSpeak channel which is used as a log of the executed commands.
https://thingspeak.com/channels/10781

Cheers!
« Last Edit: March 07, 2014, 06:11:40 am by kowalski » Logged

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

I have seen MQTT-SN implementations for Arduino and RF devices (JeeNode with RFM12B, CC stuff etc), and some of them are pretty small - qos -1 with only a publish function - and some are rather large - taking 20kb space...
@MarsWarrior
Are there any MQTT-SN nodes that you want to communicate with (bridge sensor data through)? If the bridge is also Arduino based it might as well handle protocol translation. This makes the Wireless interface much simpler.  

I hit some issues with the GSM shield and refocused to instead writing a driver for a Wifi module. The idea is to implement the AT based protocol as the Cosa Socket interface.

The latest development is support for the ThingSpeak TalkBack API. Both "Execute next command" and "Add command" have been implemented so it is really easy to handle both receive/dispatch TalkBack command and send commands to the server.


Cheers!
« Last Edit: March 08, 2014, 05:11:59 pm by kowalski » Logged

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

Some news on the latest development in Cosa.

1. ThingSpeak Channel and TalkBack example sketch
https://github.com/mikaelpatel/Cosa/tree/master/examples/IoT/ThingSpeak/CosaThingSpeakClient
An example sketch that allows the TalkBack commands LED_ON/OFF, SENSOR_ON/OFF, PING/PONG together with post of sensor data to a channel. The command SENSOR_ON will enable post of sensor data (DHT11) to a channel. The command LED_ON/OFF controls a led. Last the command PING demonstrates issuing commands back to the server (PONG).

2. Alarm class
Scheduling functions with seconds level resolution. The callback member function may be called once or periodic. Typical usage is "call function at given time", "call function every hour", etc.
https://github.com/mikaelpatel/Cosa/blob/master/examples/Time/CosaAlarm/CosaAlarm.ino
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Alarm.hh

3. Activity class
High level scheduling of functions with start time, duration and period on seconds and minutes level of resolution. The callback member function is periodically called throughout the activity duration. May be used to schedule activities such as "during 10:00 to 14:00 sample sensor every 5 seconds" or "every hour sample sensors every 10 seconds for two minutes", etc.
https://github.com/mikaelpatel/Cosa/blob/master/examples/Time/CosaActivity/CosaActivity.ino
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Activity.hh

4. Nucleo (multi-tasking) updates
a. Improved delay handing
The thread level delay function is now based on a delay queue.
b. Performance optimization
The context switch is 11 us, semaphore wait-signal pair is 41 us.
https://github.com/mikaelpatel/Cosa/blob/master/examples/Benchmarks/CosaBenchmarkNucleo/CosaBenchmarkNucleo.ino
c. Message Passing (Actors)
https://github.com/mikaelpatel/Cosa/blob/master/examples/Nucleo/CosaNucleoActor/CosaNucleoActor.ino
d. Blink example with threads
Three threads running on an ATtiny85 with 32 bytes stack and 33 byte context per thread. Demonstrates low power when using Cosa Nucleo. https://github.com/mikaelpatel/Cosa/blob/master/examples/Blink/CosaBlinkThread/CosaBlinkThread.ino

5. Sizeof Benchmark update
List of classes in Cosa and size of instances. Note: static data not included.
https://github.com/mikaelpatel/Cosa/tree/master/examples/Benchmarks/CosaBenchmarkSizeOf

6. Cosa example sketches
The example sketch folders have been restructured. There are over 130 test, benchmarking and example sketches in total.
https://github.com/mikaelpatel/Cosa/tree/master/examples
And most of them may be compiled for Tiny, Standard, USB, Mega, Mighty Arduino based boards.

Cheers!
« Last Edit: March 16, 2014, 06:45:21 pm by kowalski » Logged

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

Gets better all the time.

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

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

Gets better all the time.
@Graynomad
Thanks! Hope your Quub project is progressing well. Have been following some of the latest changes.

With the size of Cosa (50 KLOC/100+ classes) the Arduino build is starting to become a bottle-neck. More traditional build methods will become necessary. The initial build takes "time" and having pre-compiled libraries for different boards could remove this "delay". This could also allow delivering object code when source code is not "open".

Cosa is approaching the initial project goal; a rapid prototyping environment for Internet-of-Thing devices. With the support for HTTP, SNMP, MQTT and ThingSpeak there is essential support for getting sensor data to a server/cloud and commands back to the device over Internet.

I will be going back to the Wireless device drivers and improve security (encryption), robustness and reliability (acknowledgement/retransmission) and add support for additional wireless device (e.g Wifi, GSM). 

Cheers!
Logged

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

The Quub is progressing slowly, too many other (real) jobs to do as well, not the least of which is the building of a workshop so I have somewhere to play with the new PCBs when they arrive smiley

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

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

Some news on the latest update of Cosa.

1. Support for Microduino processor modules; Core, Core32u4 and Core+ (ATmega644, 64K PROM, 4K SRAM).

2. TWI bus frequency setting per device.

3. CDC speed improvement.

Cheers!
Logged

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

Quote
TWI bus frequency setting per device.
On the same wires? If so can that work?

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

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

Quote
TWI bus frequency setting per device.
On the same wires? If so can that work?
@Graynomad
No, not really as a device will a lower speed could misinterpret the signalling at higher speed and not "disconnect" correctly (i.e. START/ACK). The use case is simply moving the bus frequency setting from compile time to run time. This makes the frequency setting possible in the sketch instead of the TWI class.

Cheers!
Logged

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

Quote
moving the bus frequency setting from compile time to run time
OK. Understood smiley

______
Rob
Logged

Rob Gray aka the GRAYnomad www.robgray.com

Pages: 1 ... 19 20 [21] 22 23 ... 29   Go Up
Jump to: