Show Posts
Pages: 1 ... 6 7 [8] 9 10 ... 30
106  Using Arduino / Microcontrollers / Re: LCD 20x4 on ATTiny85 I2C problems on: March 07, 2014, 10:02:23 am
do you have a simple sample sketch?
When working with the 85 do you call pin 5 or Pin 0?
First of all I need to explain that Cosa is an object-oriented platform for Arduino with over 100+ classes. It is an Arduino core but supports all AVR processor based boards plus ATtiny and Mighty. It is also stand-alone and does not depend on any Arduino code more than the IDE build process.

The simplest example sketch is the LCD hello world that I use for footprint benchmarking.

The pin-out is described in the Board description file for ATtiny.
Pins in Cosa are symbols, e.g. Board::D0 instead of integers as in Arduino/Wiring.

You can basically develop on Mega, Uno, etc, and simply select ATtiny85 and compile-and-burn with more libraries than in any other Arduino package. SPI, TWI, 1-Wire etc are all support. LCD support is an abstract class that is implemented for HD44780, PCD8544, ST7565. The HD44780 driver also has an adapter layer for 4-bit parallel, Shift Register 3-wire (Pin or SPI), Shift Register 4-wire and a whole range of different I2C adapters. You can see how the configuration works in the CosaLCDsize sketch above.


107  Using Arduino / Microcontrollers / Re: LCD 20x4 on ATTiny85 I2C problems on: March 07, 2014, 08:24:24 am
Did you use external pullup resistors? The internal are too weak on the ATtiny. Some I2C LCD adapter modules do not have them at all and require external.

Please see

More info on

108  Development / Other Software Development / Re: "optimizing compiler" on: March 06, 2014, 06:02:23 pm
Great! Good luck with your project. Cheers!
109  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: March 06, 2014, 04:09:26 pm
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 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.
class Command : public ThingSpeak::TalkBack::Command {
  Command(ThingSpeak::TalkBack* talkback, const char* string) :
    ThingSpeak::TalkBack::Command(talkback, string)
  virtual void 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.
ThingSpeak::Client client;
ThingSpeak::TalkBack talkback(&client, KEY, ID);
void setup()
  trace.begin(&uart, PSTR("CosaThingSpeakTalkBack: started"));

void loop()
  // Take a nap if there was nothing to execute
  if (talkback.execute_next_command() != 0) SLEEP(30);
Example sketch:
The TalkBack command queue can be connected to a ThingSpeak channel which is used as a log of the executed commands.

110  Development / Other Software Development / Re: "optimizing compiler" on: March 05, 2014, 07:17:17 pm
So where did you put the function attribute and did you update the platform.txt file?

I checked your code and you are not using header files right. Please check how to partition code into header and source files. Below is the correct pattern for the "noinline" attribute.

int func(int arg) __attribute__((noinline))

As all code is included into the build through the "header" files this actually signals to the compiler that the functions are inline. This is how C++ works. Member functions in header files are automatically inline (when possible). The compiler uses a few heuristics to determine if there is actually en benifit from inline and how much the function is allowed to grow.

If your really want to do something about your source code start by cleaning up the "header" file mess. This will also clean up the footprint problem.

111  Using Arduino / Project Guidance / Re: generating interrupt for running a specific code on: March 05, 2014, 06:54:26 pm

Unfortunately this question is poorly specified. We (at least I) simply do not know the full spec/use case/etc. Using digitalRead() does not say that it is 5V. It could be as low as 0.6VCC (3V typical). Below is the original question.

i want to generate an interrupt on detecting 5 volts and run any specific code

The function digitalRead does not generate an interrupt. All this depend on how we interpret the question; logical high signal, analog voltage theshold, button, etc. And an interrupt is intended.

But I fully agree Analog Comparator is the more complex and thus less likely (Occam). The interpretation of the question is then "how do it detect a logical high signal and execute a specific part of code". And the answer is:

if (digitalRead(PIN)) {
   // the specific code block to execute when the PIN is logical high/on/active/etc


[Update] After reading other forum posts by kazmi I am convinced that @Robin2 your interpretation is spot on. The usecase seems to be a trigger to capture an image and send to a mobile phone. But this is with some hand-waving.
112  Development / Other Software Development / Re: "optimizing compiler" on: March 05, 2014, 04:36:38 pm
I think we have answered your original question. To make it easier for others to find information please post a new question instead of continueing on this post. Please make an attempt to search for the information and share instead of just asking questions. For instance google on gcc function attributes, read the manual, and ask for an interpretation and/or examples.

113  Using Arduino / Project Guidance / Re: generating interrupt for running a specific code on: March 05, 2014, 04:32:34 pm
Actually ATmega has the perfect mechanism for this. Below is a section from the manual:

25. AC – Analog Comparator
The Analog Comparator compares the input values on the positive pin AIN0 and negative pin
AIN1. When the voltage on the positive pin AIN0 is higher than the voltage on the negative pin
AIN1, the Analog Comparator output, ACO, is set. The comparator’s output can be set to trigger
the Timer/Counter1 Input Capture function. In addition, the comparator can trigger a separate
interrupt, exclusive to the Analog Comparator. The user can select Interrupt triggering on com-
parator output rise, fall or toggle.

You can find out more on page 271 in the ATmega2560 manual.


Does Arduino/Wiring support this? No but Cosa does. Check github or my posting on the forum.

114  Development / Other Software Development / Re: "optimizing compiler" on: March 05, 2014, 12:18:44 pm
The next thing to do is to sort the symbol files;

sort xxx.sym > xxx.sorted.sym

And then check where the commented function size is larger than uncommented. Then you check the listing to see the assembly code. And my guess is that you will find the answer --- compiler function inlining.

I did all this and found that the menu functions became much larger in the commented version. This implies the compiler took the decision to inline some functions.

00002bb6 000007e6 T MenuGeneral()         commented
00002266 000001e4 T MenuGeneral()          uncommented

Hum, you need to know something about the file format. It is simply address, size, attribute and symbol. Nothing strange. Try using google and reading manuals ;-)

And, yes, you can force the compiler to not inline (for instance AddWord) to reduce footprint but that is a different line of QA.

115  Development / Other Software Development / Re: "optimizing compiler" on: March 05, 2014, 03:28:08 am
Replacing "avr-size" with "as" is not correct. Try removing that all together. Skip the size information for now and generate the symbol and listing file first. Then you have something to work on.

To implement the "avr-size" information I think it's easiest just to look at what the IDE for 1.5.X does as it produces that information at the end of the build.

116  Development / Other Software Development / Re: "optimizing compiler" on: March 04, 2014, 06:21:35 pm
Ok. I do not use a mac so this is hand-waving.

First you have to find the Arduino installation and locate the AVR tools bin directory. Add that to your PATH or simply execute the script from there. On my machine it is /opt/arduino-1.5.6-r2/hardware/tools/avr/bin.

Second check where the Arduino build puts the compiled files and replace the /tmp/build*/ etc with that path. Hint: Enable compiler printout in the Arduino IDE and look for the path when compiling.

When you get this working I will be waiting for the next question ;-)

117  Development / Other Software Development / Re: "optimizing compiler" on: March 04, 2014, 04:04:55 pm
So is there some way to understand what is going on? Yes, there are tools to this. Not in the Arduino library but in the AVR toolbox. You can check what goes into the build and understand the difference and thus find the source to the problem. Below is a Linux shell script that I use to generate a list and symbol file (to reduce the Cosa footprint, do not what to end up with this type of problems ;-)
avr-size -C /tmp/build*.tmp/$1.cpp.elf > $1.lst
avr-objdump -d /tmp/build*.tmp/$1.cpp.elf >> $1.lst
avr-nm -CS /tmp/build*.tmp/$1.cpp.elf > $1.sym
The script generates size information and an assembly listing but also a symbol file.

"Know your numbers",

118  Development / Other Hardware Development / Re: Memory space on: March 04, 2014, 03:44:18 pm
Here is the information you are looking for or at least a pointer in the right direction;


PS: Don't forget to donate to Wikepedia. Support open information. DS.
119  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: March 03, 2014, 06:33:08 pm
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. Below is a snippet from the example sketch.
void loop()
  ThingSpeak::Channel channel(&client, KEY);
  ThingSpeak::Entry update;
  update.set_field(1, sensor.get_temperature(), 1);
  update.set_field(2, sensor.get_humidity(), 1);

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


120  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: March 02, 2014, 10:28:59 am
I already like  where Nucleo is going. Looks very promising for the more complex tasks where a simple Arduino performs several parallel tasks!
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.

Pages: 1 ... 6 7 [8] 9 10 ... 30