Show Posts
Pages: 1 ... 15 16 [17] 18 19 ... 31
241  Using Arduino / Interfacing w/ Software on the Computer / Re: Connecting two arduinos to the arduino software ? on: September 04, 2013, 03:39:38 am

(I am new to this forum)

I have two arduino's connected to my mac with two usb cables.
I want one sketch to connect to the first arduino, and another to connect to the second one. And I would like to open a serial monitor for each arduino (simultaneously). Is this possible ?

Whenever I select a usb interface, it connects both sketch to this interface (instead of only one)
Whenever I open a serial monitor, it automatically closes the existing serial monitor. It seems impossible to open two serial monitors.

Is the arduino software meant to be used with only one arduino at a time ?

Thank you for any help.

Hi Paul! Welcome!

I do this all the time ;-). It isn't possible from when running a single Arduino IDE but it is not a problem to start several Arduino IDE's and connect them to different COM ports. I work mostly on Linux and need to test network protocols etc. Then this comes in handy.

242  Using Arduino / Programming Questions / Re: LCD + SD on SPI on: September 04, 2013, 03:04:28 am
i've looked in sd2card.h/cpp, but don't understand how they initialize the bus. maybe SPI-Speed, bitorder or datamode is incompatible to the display


Yes, that is the problem (as I see it). Below is a snippet of the SD init code:
uint8_t Sd2Card::init(uint8_t sckRateID, uint8_t chipSelectPin) {
  errorCode_ = inBlock_ = partialBlockRead_ = type_ = 0;
  chipSelectPin_ = chipSelectPin;
  // 16-bit init start time allows over a minute
  uint16_t t0 = (uint16_t)millis();
  uint32_t arg;

  // set pin modes
  pinMode(chipSelectPin_, OUTPUT);

  // SS must be in output mode even it is not chip select
  pinMode(SS_PIN, OUTPUT);
  digitalWrite(SS_PIN, HIGH); // disable any SPI device using hardware SS pin
  // Enable SPI, Master, clock rate f_osc/128
  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR1) | (1 << SPR0);
  // clear double speed
  SPSR &= ~(1 << SPI2X);
#endif  // SOFTWARE_SPI
As you can see it uses the SPI hardware very different than your display. The "easy" way around this is to do as Nick said and use software SPI for one of them.

This shows one of the problems with the Arduino SPI implementation and how this ripples into libraries and basically makes it a single SPI device software interface. The current implementation is also very difficult to use with interrupts and threads (i.e. concurrent programming).

243  Using Arduino / Programming Questions / Re: Can analogRead return a faulty value ? on: September 04, 2013, 02:45:58 am
This is what the ATmega328P manual says about this:

23.5.2 ADC Voltage Reference

The reference voltage for the ADC (VREF) indicates the conversion range for the ADC. Single
ended channels that exceed VREF will result in codes close to 0x3FF. VREF can be selected as
either AVCC, internal 1.1V reference, or external AREF pin.
AVCC is connected to the ADC through a passive switch. The internal 1.1V reference is gener-
ated from the internal bandgap reference (VBG) through an internal amplifier. In either case, the
external AREF pin is directly connected to the ADC, and the reference voltage can be made
more immune to noise by connecting a capacitor between the AREF pin and ground. VREF can
also be measured at the AREF pin with a high impedance voltmeter. Note that VREF is a high
impedance source, and only a capacitive load should be connected in a system.
If the user has a fixed voltage source connected to the AREF pin, the user may not use the other
reference voltage options in the application, as they will be shorted to the external voltage. If no
external voltage is applied to the AREF pin, the user may switch between AVCC and 1.1V as ref-
erence selection. The first ADC conversion result after switching reference voltage source may
be inaccurate, and the user is advised to discard this result.

This is what the analogRead() function does:

uint8_t analog_reference = DEFAULT;

void analogReference(uint8_t mode)
// can't actually set the register here because the default setting
// will connect AVCC and the AREF pin, which would cause a short if
// there's something connected to AREF.
analog_reference = mode;

int analogRead(uint8_t pin)
uint8_t low, high;

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#elif defined(analogPinToChannel) && (defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__))
pin = analogPinToChannel(pin);
if (pin >= 14) pin -= 14; // allow for channel or pin numbers

#if defined(__AVR_ATmega32U4__)
pin = analogPinToChannel(pin);
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
// the MUX5 bit of ADCSRB selects whether we're reading from channels
// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits).  this also sets ADLAR (left-adjust result)
// to 0 (the default).
#if defined(ADMUX)
ADMUX = (analog_reference << 6) | (pin & 0x07);

// without a delay, we seem to read from the wrong channel

#if defined(ADCSRA) && defined(ADCL)
// start the conversion

// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read.  reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low  = ADCL;
high = ADCH;
// we dont have an ADC, return 0
low  = 0;
high = 0;

// combine the two bytes
return (high << 8) | low;
As you can see it uses the reference value and sets the ADMUX and does not discard if a reference change was done. Your work-around, i.e. read additional values, is just fine.

And to answer your question: Yes the ADC can return a faulty value due to time required to stabilize reference voltage and noise.

244  Using Arduino / Microcontrollers / Re: virtual wire and attiny85 on: September 04, 2013, 02:20:26 am
If you google the error message you will find a number of people have had the same problem. This error message means that you have exceeded the program size limit (4 Kbyte). There is a patch for the AVR GCC linker that allows you to use the full 8K byte program size.

You can find a link to the patch on the Cosa install page:

Here is the direct link to the patch:

Please note that the above helps with your initial error message (only ;-).

If you are interested there is a Cosa version of Virtual Wire that is fully OOP and allows several configurations. It works on all of the boards that Cosa supports. Ranging from Tiny to Mega and Mighty.

245  Using Arduino / Programming Questions / Re: PROGMEM - compilation fail on: September 03, 2013, 09:32:24 am
This should work as it is the correct syntax (attribute):

static const unsigned char MD2_S[256] PROGMEM = { ... };

Please post the compiler error message for the above.

246  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: September 02, 2013, 08:50:57 am

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!

247  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 27, 2013, 12:59:01 pm

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.

248  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 14, 2013, 06:57:42 am
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+.

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.

249  Using Arduino / Installation & Troubleshooting / Re: Pro Mini Confusion on: August 14, 2013, 06:07:50 am
I have bought a bunch of these cheap Arduino Pro Mini boards from ebay. All have the FTDI pins mirrored.

To program them turn the FTDI breakout or cable upside down. That's all.

Chip side down on this one:

BW: These cheap Pro Mini (5V/16Mhz) work fine with a 3.7V battery connected to the VCC and GND pin.


250  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 11, 2013, 06:12:58 pm
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)?

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.
251  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 11, 2013, 05:56:39 pm
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?

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.

252  Development / Other Software Development / Re: Nil RTOS update - Fast and Tiny! on: August 10, 2013, 05:21:19 pm

Had some time to have a look at this RTOS. I build RTOS/platforms/dev.environment for many-core/DSP (32-128 cores) in my day job and found this code nice and compact.

It might be time to introduce a context switching kernel layer in Cosa to tackle the next complexity level. This could also give even more structure to the device drivers. I have a lot of work to get the code thread safe but the end result would be worth that. There a too many device libraries that do not work very well together due to lack of semphores/synchronization on SPI, TWI, etc. And even basic functions such as ADC conversion in the background.

A "life-time ago" I implemented a co-routines/context switch with longjmp/setjmp. Comparing the NilRTOS context switch with the AVR code for longjmp/setjmp they are very simular. The next issue is the thread memory model and if dynamic threads should be allowed. Most design today is static thread pools (web-servers, protocol stacks, etc).

Appreciate that you push the usage of a RTOS for Arduino. It is needed for larger projects.

This is a totally different route than the event driven/object-oriented style I have introduced in Cosa. The main argument being memory requirements and initial complexity for users. But as the context can be as small as max stack depth plus processor state for a thread, given that ISRs are run on their own stack, I might need to reconsider this.

253  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 10, 2013, 04:36:54 pm

Here is the first problem:
#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).

254  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 10, 2013, 04:30:20 pm

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.
#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 {
  uint8_t m_pin;
  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);

void setup()
  NEXA::code_t cmd;

void loop()
  Event event;
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.

255  Development / Other Software Development / Re: Cosa: An Object-Oriented Platform for Arduino programming on: August 09, 2013, 06:39:37 pm
Not using Cosa here, but I just have to say this:
This freamework looks great! Well thought out and beautifully written & documented.

My hat is off to you!

Thanks for your interest in this project and encouraging words! Please feel free to "take Cosa for a spin" and try some of the available example sketches. I have tried to make it really easy to get started and experience this slightly different approach to programming the Arduino/AVR based boards.

It is possible to start off in the "traditional" sequential and procedural style of Arduino/Wiring and move towards a more object-oriented and event driven style with periodic functions, state-machines and proto-threads. It is a learning curve but the interesting aspect is the possible scaling of systems and the major reduction of the complexity of writing semi-concurrent low-power applications.

Pages: 1 ... 15 16 [17] 18 19 ... 31