Go Down

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

kowalski

@MarsWarrior

Sounds like a nice project. Most of the components are available though there is still some glue missing.

Should I use Rete or Ciao for sending data from the wireless nodes to the central node?

Right now these two components do not contribute that much. Rete is more of a framework for wireless nodes inspired by Panstamp (http://www.panstamp.com/), while Ciao is a compact, self-descriptive, data serialization method. If both the wireless nodes and central node are AVR based the simplest approach is to send binary data (e.g. struct) and do the MIB modeling on the central node. More complex and generalized solutions could use the Protocol Buffer or Ciao support together with encryption for transmission. And UML modeling to code generate the MIB map (e.g. Cosa Registry). It all depends on the scale of the project and the product standardization one wants to achieve.


could I use the Registry to translate the remote sensors to MQTT objects?

Yes, this is actually one of the use-cases for the Cosa Registry. For MQTT it would be more natural to use string names instead of index sequences (ala SNMP). This is one of those items on the to-do-list.

Cheers!

kowalski


I'm trying to figure out how to use LCD::SPI3W (or LCD::Serial3W) without connecting SCE to the Arduino. The reason is that I need the pins for other IO.
Can this be done in any simple way?

@HeManHedman

Yes, simply copy the IO adapter to your sketch and remove the SCE handling. This assumes that the LCD device does not require the SCE signal to latch data, etc, and it can be tied low.

Cheers!

MarsWarrior

Thanks, kowalski, for claryfying Rete and Ciao frameworks.

I haven't decided yet on the best approach. The MQTT-SN protocol is also still a good solution for the wireless nodes, as it makes the gateway very easy: such a forwarding gateway is fully described - protocol and message encapsulation/decapsulation - in the MQTT-SN specification document.

Sensor nodes and gateway would both be based on AVR and Cosa.
I could use simple structs to compose messages and send them using one of the radio components available in Cosa.
For periodic sensor scans on the nodes, the Activity object seems very well suited.
Most sensors are already implemented in Cosa, so I get al lot for 'free' this way.

On the PC side, RSMB will be used as it contains both MQTT as MQTT-SN brokers.

kowalski

#363
Jun 10, 2014, 09:51 am Last Edit: Jun 10, 2014, 10:35 am by kowalski Reason: 1

I haven't decided yet on the best approach. The MQTT-SN protocol is also still a good solution for the wireless nodes, as it makes the gateway very easy: such a forwarding gateway is fully described - protocol and message encapsulation/decapsulation - in the MQTT-SN specification document.

Sensor nodes and gateway would both be based on AVR and Cosa.
I could use simple structs to compose messages and send them using one of the radio components available in Cosa.
For periodic sensor scans on the nodes, the Activity object seems very well suited.
Most sensors are already implemented in Cosa, so I get al lot for 'free' this way.

@MarsWarrior

I think the overall architecture sounds just right. I would only tweak it a bit; 1) to allow low power wireless sensor nodes it is more efficient to push data instead of pull (scan), 2) there is a need for a plug-in wireless protocol so that it is really easy to administrate, 3) there is also a need for a management protocol for remote sensor configuration (and software update). These are some of the really interesting challenges in wireless sensor networks protocol design and implementation.

Implementing MQTT-SN on top of the Cosa Wireless interface seems like an interesting project and something I might consider.
Right now I am adding support for Low Power Lab Moteino with RFM69/H and playing around with ST7920 LCD.

Cheers!

MarsWarrior

#364
Jun 10, 2014, 10:55 am Last Edit: Jun 10, 2014, 11:57 am by MarsWarrior Reason: 1

I think the overall architecture sounds just right. I would only tweak it a bit; 1) to allow low power wireless sensor nodes it is more efficient to push data instead of pull (scan), 2) there is a need for a plug-in wireless protocol so that it is really easy to administrate, 3) there is also a need for a management protocol for remote sensor configuration (and software update). These are some of the really interesting challenges in wireless sensor networks protocol design and implementation.


Thanks kowalski for the heads up!
Now I have to find the time to actually make it :smiley-red: I might get some time after the summer for this as I'm currently busy with other things... But after years of experimenting with several solutions, I guess I know found the best solution.

Regarding your  tweaks:
1)  I will use MQTT-SN publish (fire and forget) methods for sending data, so these nodes can wake up, do their thing, send the data and go back to sleep again.
2)  I do not understand what you are saying with this tweak
3) OTA Software updates would be very nice, but not something I will do I think. Lowpowerlab has this already in place though, and afaik JeeLabs is also working on that issue, including auto discovery and enrollment of new nodes.
Sensor configuration is something else. As sensors are hard wired I don't see a direct usage for this, but maybe you can explain what you mean by this!

The next thing btw would be installing OpenHAB with the MQTT binding for handling and display of all sensor data, using rules to do things etc. this is one of the main reasons for wanting to use MQTT-SN: I can re-use a lot of existing interfaces, software, PC and iPhone/iPad monotoring programs etc.

Quote

Implementing MQTT-SN on top of the Cosa Wireless interface seems like an interesting project and something I might consider.

Cheers!

That would be very, very, very nice of course!

That would make my sensor network almost Plug and Play  XD
And since Cosa does support lots of sensors and platforms it becomes feasible to replace all nodes with Cosa / MQTT-SN in the future!

kowalski

#365
Jun 12, 2014, 08:42 pm Last Edit: Jun 12, 2014, 11:44 pm by kowalski Reason: 1
Some news on the latest Cosa updates:

1. Updated RFM69W/HW device driver
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Wireless/Driver/RFM69.hh

2. Support for LCD ST7920
First iteration of support for Graphical and Character based LCD ST7920. Character based (16x4) only in this release.
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/LCD/Driver/ST7920.hh

3. Support for LowPowerLab Moteino
Board definition: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Board/LowPowerLab/Moteino.hh
Arduino IDE: https://github.com/mikaelpatel/Cosa/blob/master/boards/lowpowerlab.txt
The Wireless example sketches work with Moteino and RFM69.

4. Unsigned integer counter wrap around handling
Improved support for timer (Watchdog/RTC::since) wrap around handling.
Example: https://github.com/mikaelpatel/Cosa/blob/master/examples/Compiler/CosaDiff/CosaDiff.ino
Interface: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Watchdog.hh#L133, https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/RTC.hh#L84
Usage pattern:
Code: [Select]

// Capture start time
static const uint32_t TIMEOUT = ....;
uint32_t start = RTC::millis();
...
// Check elapsed time
if (RTC::since(start) < TIMEOUT) {
 ...
}

Example usage: https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Wireless/Driver/RFM69.cpp#L228

5. New Wireless example sketches; Ping-Pong
Demonstrate simple retransmission of messages. CosaWirelessPing will send a sequence number to CosaWirelessPong which increments the received number before sending it back. The message is retransmitted if a reply is not received within a time-limit.
Code: [Select]

CosaWirelessPing: started

ping:nr=0,pong:nr=1
ping:nr=1,pong:nr=2
ping:nr=2,retry,pong:nr=3
ping:nr=3,pong:nr=4
ping:nr=4,retry,retry,retry,retry,retry,retry,pong:nr=5
ping:nr=5,pong:nr=6
ping:nr=6,pong:nr=7
...

https://github.com/mikaelpatel/Cosa/blob/master/examples/Wireless/CosaWirelessPing/CosaWirelessPing.ino
https://github.com/mikaelpatel/Cosa/blob/master/examples/Wireless/CosaWirelessPong/CosaWirelessPong.ino

Cheers!

jfpoilpret

Hi,

first off, thumbs up for all the quality work put into Cosa, this is really impressive!

I wonder if there are some guidelines for people who would want to contribute to the project (e.g. preferred tools and settings for these tools), and possibly some tips about it. Also, I am not completely clear about the way new source files should be organized.

I am currently developing a few classes to manage MAX7219/7221 IC (LED display drivers with a serial interface, like SPI).

I have got inspiration from Cosa LCD and could already reach some success (for the moment, I published my work on https://github.com/jfpoilpret/arduino-projects/tree/master/CosaMax7219); it integrates well with Cosa IOStream.

kowalski


Hi, first off, thumbs up for all the quality work put into Cosa, this is really impressive!

@jfpoilpret
Thanks for your kind words. I hope you find the going development inspiring.

I wonder if there are some guidelines for people who would want to contribute to the project (e.g. preferred tools and settings for these tools), and possibly some tips about it. Also, I am not completely clear about the way new source files should be organized.

There are no required tools other than the Arduino IDE for building, upload and testing. I use GNU Emacs and basic Linux tools. Standard C/C++ Emacs mode setting (2 character indent). The only thing extra in my .emacs settings is:
Code: [Select]

(setq auto-mode-alist (cons '("\\.\\(pde\\|ino\\)$" . c++-mode) auto-mode-alist))

It is possible to contribute to Cosa as any other Arduino software; as libraries or simply source code. The Cosa repository is not open but you can still clone/fork and do pull requests. Normal git style.

I should add a list of contributed Cosa libraries with links to their repositories on the Cosa github README page. Will put that on the to-do-list.

I am currently developing a few classes to manage MAX7219/7221 IC (LED display drivers with a serial interface, like SPI).
I have got inspiration from Cosa LCD and could already reach some success (for the moment, I published my work on https://github.com/jfpoilpret/arduino-projects/tree/master/CosaMax7219); it integrates well with Cosa IOStream.

Fun! It is really interesting to see that you have been able to produce a driver with the limited documentation available. And reuse a fair amount of code.

That driver was actually something I have on the summer to-do-list. Waiting for an LCD board from ebay ;-). I was planning to add MAX7219/7221 simply as yet another implementation of the Cosa LCD interface. Looks like you have added an extra class level instead of using LCD::Driver as the base class. The LCD::IO adapters can be used directly. That would make it much simpler, less code, and follows the Cosa design style with an abstract interface and adapter pattern.

Your font handling was an interesting approach. I hadn't come so far to considering this issue.

Cheers!

jfpoilpret

Thanks for your answer.
Quote
There are no required tools other than the Arduino IDE for building, upload and testing. I use GNU Emacs and basic Linux tools. Standard C/C++ Emacs mode setting (2 character indent).

I don't use Arduino IDE / emacs, for development but Eclipse with Arduino plugin from @jantje; I'll have to prepare the setup accordingly.
Quote
Looks like you have added an extra class level instead of using LCD::Driver as the base class. The LCD::IO adapters can be used directly. That would make it much simpler, less code, and follows the Cosa design style with an abstract interface and adapter pattern.

The reason why I have used an extra class level for handling MAX7219 is due to the fact that you can chain several of these IC through the same wires (SPI or Serial3W), which means you can potentially use the same SPI for different LED circuits, you can even imagine having one circuit with 8 7-segment digits, one circuit with an 8x8 LED matrix, and 2 circuits for a total of 16 7-segment digits driven as its own IOStream. I felt that the current LCD::Driver/IO design could not work for this special situation.
Note that my current work does not yet allow combining 2 or more chained 7219/7220 in a single IOStream device, I still need to infer about the proper way to implement this.
Quote
Your font handling was an interesting approach. I hadn't come so far to considering this issue.

Regarding font handling, I chose the most compact way I could find (in terms of memory usage), since anyway, with 7 segments only, it is just impossible to represent every single ASCII character. So the rationale was to use the best possible representation for each alphabetic character, not caring about its case (you are already glad when you can represent a "t" on 7 segments, why try to represent a "T" that would not look like a "T"?) On top of that I added a few special characters that I found could be easily represented on 7 segments, that is all.
Quote
That driver was actually something I have on the summer to-do-list.

Good to know! I was not sure people could still be interested in old style 7-segment LED displays :-)

By the way, I am new to this forum, so please bear with me if I don't use the post editor perfectly yet, that will come after a while.

Cheers

MarsWarrior

At work we have a lot of experience with code quality metrics and the relation with software maintenance and software realibility. Maintenance costs are calculated using these code metrics: the better the code, the easier to maintain and the lower the costs.

As Cosa is imho quality wise a step-up compared to most of the libraries out there for Arduino, I wondered what the statistiscal metrics and quality of this package is  XD So I downloaded the current Cosa package and ran it through some analysis with the following overall very satisfying result I must say mr. Kowalski!

The most widespread and valuable method but also one of the least understood methods is McCabes' Cyclomatic Complexity.

Cyclomatic complexity is defined as measuring "the amount of decision logic in a source code function" where higher numbers are "bad" and lower numbers are "good". Simply put the more decisions that have to be made in code, the more complex it is. We use cyclomatic complexity to get a sense of how hard any given code may be to test, maintain, enhance, refactor or troubleshoot as well as an indication of how likely the code will be to produce errors.

The complexity of the source code is described by a number. That number defines the risk of the module and is defined by the the Software Engineering Institute, as follows:





Cyclomatic Complexity    Risk Evaluation
1-10A simple module without much risk
11-20A more complex module with moderate risk
21-50A complex module of high risk
51 and greaterAn untestable program of very high risk


We always strive for any number below 10 as it has proven to be the easiest to maintain and debug. The largest number I have had so far is 85. This software has proven over 1 year maintenance to be very, very, very hard to modify and almost impossible to test.

So how does Cosa 'perform' code metrics wise?

As you can see Cosa contains 163 files with a total of 20.564 lines. Of these lines, 21% is comment (about 4.380 lines), 20% are branch statements (about 4.215 lines) and 9.933 lines contain normal statements.

If I zoom in to the quality metrics, I get the following Kiviat Graph where green = ok and above or below that green band means that that quality metric has a value that should be investigated further:

The general impression is good: 5 of the 7 quality metrics are within the green band, 1 (Max Depth) is just outside this band, and one - Max (Cyclomatic) Complexity - is with a value of 39 far outside the required bandwith which should be investigated further.

The next list shows the modules that are outside the Max Complexity value of 10. It also shows the modules average complexity. What we see is that the number of modules with a higer than wanted complexity is not very high, but that the average complexity of some of these modules is also to high: in other words, it is not just one function that has a high complexity.



I took just 3 different modules to show the metrics for the MQTT, TWI and Menu modules to get an idea what is causing this high complexity and depth.
Menu:


The Menu module is by far the worst module ]:D All metrics are OUTSIDE the green band!
The worst offender is the Menu::Walker::on_key_down() method which scores the highest on both Complexity (39) and block depth (7). The method contains nested switch statements and a lot of decision logic causing these high complexity and depth numbers.

MQTT:


The MQTT module scores high on statememts per method and on both average and maximum complexity. The worst offender is the MQTT::Client::publish() method that scores the highest on both Complexity (24) and block depth (4). Again a large switch statement seems to be responsible for the high complexity and depth.

TWI:


The last module, TWI, scores good on all metrics except for the maximum complexity. The worst offender is the ISR() method that scores the highest on both Complexity (34) and block depth (4). Again a large switch statement seems to be responsible for the high complexity and depth.

These three examples show that (large) switch statements are responsible for most of the high complexity and depth.
I haven't analysed in depth if these modules could be refactored to increase quality metrics or that these metrics are just the way they are: there is no other choice to implement this functionality! I hope kowalski can shed a light on this issue :smiley-zipper:

Summerized: Cosa shows that there is high quality software in the Arduino world. The full object oriented approach and the constant refactoring that kowalski does are no doubt some of the reasons behind these good code metrics results.

I did like Cosa already, but now even more :smiley-mr-green:

kowalski

#370
Jun 18, 2014, 10:25 pm Last Edit: Jun 19, 2014, 08:12 am by kowalski Reason: 1
@MarsWarrior

Great analysis and fun to see that you are using the same tool as I do for Software Quality Analysis - SourceMonitor, http://www.campwoodsw.com/sourcemonitor.html. This is a great open-source tool.

I also use the data collected from Ohloh, https://www.ohloh.net/p/cosa. Here you can get a picture of the "commitment" behind Cosa also the estimation of the effort and development cost.  The Ohloh code browser is just great. http://code.ohloh.net/file?fid=mVgoe27AUP5UxXPqMApmnvc6trQ&cid=a76NbRQjUKM&s=&fp=499294&projSelected=true#L0

As you may see there is a difference in the KLOC count. No big deal but I guess that you have only looked at *.cpp files? If you include *.hh, *.h and *.c the total number of lines and files is somewhat larger  :D. Including all the example sketches Cosa is well over 100 KLOC (commented source code).

I use several programming techniques to reduce complexity; basically try to reduce to a "straight block" of code. I use SourceMonitor to keep a list of class/functions that should be refactored due to high complexity. Some complexity is motivated such as the switch/case blocks that give high complexity levels but are kept if the complexity per case is low. Some of them need to be refactored to an additional function level. And others refactored to classes to remove the switch all together.

Small scale embedded systems with low memory resources and moderate processor speed give a very thin line to balance complexity, performance, and memory footprint together with readability and maintainability. At the same time Cosa tries to achieve high variability and support a large number of AVR MCUs (ATtinyX5 up to ATmega2560) and boards both Arduino(TM) and clones (Anarduino, Microduino, Moteino, Pinoccio and Teensy). This is the real challenge!

With 10 years research and teaching at University followed by over 25 years in Industry I have had the opportunity to test and evaluate a number of programming paradigms, languages, and development tools and methods. This gives a slight advantage.

Thanks for your effort and putting focus on software quality.

Cheers!

kowalski

#371
Jun 19, 2014, 06:23 pm Last Edit: Jun 19, 2014, 06:28 pm by kowalski Reason: 1
Time for some news on the latest Cosa updates:

1. RFM69W/HW device driver improvements.
a. New member function for temperature reading.
b. New member function for RC oscillator calibration.
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Wireless/Driver/RFM69.hh#L182

2.  CC1101 device driver improvements.
a. SPI burst read and write for send/recv.
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Wireless/Driver/CC1101.cpp

3. Board support for Anarduino MiniWireless
Below device drivers for RTCC and Flash to support resources on MiniWireless boards.

One of the best price-performance-functionality Arduino clone board with Wireless, RTC and Flash support (in micro format). http://www.anarduino.com/miniwireless/

4. New MCP7940N Real-Time Clock/Calendar (RTCC) device driver.
http://ww1.microchip.com/downloads/en/DeviceDoc/20005010F.pdf
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/TWI/Driver/MCP7940N.hh
NB: This is ongoing work. Will be extended with alarm interrupt handler.

5. New S25FL127S 128 Mbit (16 Mbyte) SPI Flash device driver.
http://www.spansion.com/Support/Datasheets/S25FL127S_00.pdf
https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/SPI/Driver/S25FL127S.hh
NB: This is ongoing work. A file/object store system will be needed for the 16 Mbyte available. A possible refactoring to the SD interface to allow FAT16 file system on Flash device.

Cheers!

MarsWarrior


4. New MCP7940N Real-Time Clock/Calendar (RTCC) device

5. New S25FL127S 128 Mbit (16 Mbyte) SPI Flash device driver.


Great. I just finished a board with these chips. Are the MCP7941 and MCP7942 also supported?

kowalski

#373
Jun 19, 2014, 08:52 pm Last Edit: Jun 19, 2014, 09:03 pm by kowalski Reason: 1

Great. I just finished a board with these chips. Are the MCP7941 and MCP7942 also supported?

@MarsWarrior

Do you mean MCP7941X (X=0,1,2)? They have an EEPROM. Do you have a link to the Data Sheet?

I am working on support for the devices on the Anarduino MiniWireless board. Don't have any board with those but it looks like the Cosa EEPROM driver could be adapted.

Cheers!

MarsWarrior



Great. I just finished a board with these chips. Are the MCP7941 and MCP7942 also supported?

@MarsWarrior

Do you mean MCP7941X (X=0,1,2)? They have an EEPROM. Do you have a link to the Data Sheet?

I am working on support for the devices on the Anarduino MiniWireless board. Don't have any board with those but it looks like the Cosa EEPROM driver could be adapted.

Cheers!

Ah yes. My mistake. Always mix those chips... I do mean the MCP79411 with EUI-48 unique id!
See attached datasheet.

FYI:
S25FL dataflash Library:· https://github.com/BleepLabs/S25FLx
MCP7941x RTC Library:· https://github.com/ichilton/mcp7941x_arduino


Go Up