Porting XBee Lib

Hi there, so I’m trying to port the XBee Library from Arduino to Spark - this might seem like a somewhat odd thing to do when you got WiFi, but I’m basically using the XBees’ RSSI to detect proximity to collocated devices. So I got the WEB IDE to compile quite a few parts but am stuck on the avr/interrupt.h , as far as I can figure that would be because the Spark is ARM based? Not that I have the faintest clue what that means. Any suggestions as to how I can workaround this? Can I replace the interrupt with a compatible one?
the XBee lib can be found here:

Thanks for any help!

1 Like

@raune, the XBee module communicates via a serial port which the Spark has three of. Oddly, I downloaded the code from the link you provided and could not find the avr/interrupt.h line anywhere! Porting should be straight forward though I don’t have an xbee to test. I will post the ported code on my github when it’s done :smile:

1 Like

@raune, I posted the ported library on my repo here. Let me know how it goes :smile:

2 Likes

hi pekay - thanks I relly appreciate this alot! unfortunately your link seems broken :frowning: .

regarding the lib: when i put in XBee, it asks me for WProgramm, which I then put in (only .h, though there was no corresponding cpp) WProgramm then asks me for the avr/interrupt, which I added(again only the .h file) , which Spark then refuses to acknowledge (see screenshot) … might be I’m approaching this completely wrong though ??

@raune, odd that the link was broken! The files are HERE. :slight_smile:

1 Like

Hi peekay, shame not compiling, here’s the error message:

In file included from ../inc/spark_wiring.h:30:0,
from ../inc/application.h:29,
from XBee.h:26,
from XBee.cpp:20:
../../core-common-lib/SPARK_Firmware_Driver/inc/config.h:12:2: warning: #warning "Defaulting to Release Build" [-Wcpp]
#warning "Defaulting to Release Build"
^
In file included from ../inc/spark_wiring.h:37:0,
from ../inc/application.h:29,
from XBee.h:26,
from XBee.cpp:20:
../inc/spark_wiring_ipaddress.h: In member function 'IPAddress::operator uint32_t()':
../inc/spark_wiring_ipaddress.h:53:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
operator uint32_t() { return *((uint32_t*)_address); };
^
../inc/spark_wiring_ipaddress.h: In member function 'bool IPAddress::operator==(const IPAddress&)':
../inc/spark_wiring_ipaddress.h:54:72: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
bool operator==(const IPAddress& addr) { return (*((uint32_t*)_address)) == (*((uint32_t*)addr._address)); };
^
../inc/spark_wiring_ipaddress.h:54:105: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
bool operator==(const IPAddress& addr) { return (*((uint32_t*)_address)) == (*((uint32_t*)addr._address)); };
^
In file included from ../inc/spark_wiring.h:30:0,
from ../inc/application.h:29,
from rssi_prox.cpp:2:
../../core-common-lib/SPARK_Firmware_Driver/inc/config.h:12:2: warning: #warning "Defaulting to Release Build" [-Wcpp]
#warning "Defaulting to Release Build"
^
rssi_prox.cpp:8:10: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
void sendDataToNeighbors();
^
rssi_prox.cpp:8:841: warning: extra tokens at end of #include directive [enabled by default]
void sendDataToNeighbors();
^
rssi_prox.cpp:8:850: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
void sendDataToNeighbors();
^
rssi_prox.cpp:8:28063: fatal error: Copyright (c) 2009 Andrew Rapp. All rights reserved. * * This file is part of XBee-Arduino. * * XBee-Arduino is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * XBee-Arduino is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with XBee-Arduino. If not, see <http://www.gnu.org/licenses/>. */ #ifndef XBee_h #define XBee_h #if defined(ARDUINO) && ARDUINO >= 100 #include : No such file or directory
void sendDataToNeighbors();
^
compilation terminated.
make: *** [rssi_prox.o] Error 1

Error: Could not compile. Please review your code.

@raune, I compiled it using the spark CLI. It seems the errors are in rssi_prox.cpp which I don’t have. It needs to be ported as well. Can you tell me where to find this file?

:slight_smile: you are amazing thank you so much for helping, this is the arduino code https://www.dropbox.com/sh/6cspyky5j60h092/AACgToGNoMazIjPbWo7PYRPEa

1 Like

oh and the rssi_prox. is an ino file not cpp… by the way i did not write that code the guys from little bird did…

1 Like

@raune, I ported the rssi_prox and supporting programs and put them in the rssi_prox folder under examples. The repo is here :slight_smile:

3 Likes

@peekay123, @raune, many thanks for the port, Great work!

1 Like

@peekay123 compiling fine but there is no communication between the XBees and the led flashes 3 times red then breathing red/white…

@raune, do you have the XBee connected to the Serial1 Tx/Rx pins? How are you powering the XBee?

2 Likes

XBee is on a sparkfun explorer breakout board with DIN connected to TX on the Spark, DOUT to RX (not sure what you mean by series 1?) . Power to the XBee from VIN, the Spark is on a 5V external power supply.
There was a whole lot of files in the repo, I only took the rssi - prox.ino, Filteringscheme.cpp, Filteringscheme.h, XBee.cpp and XBee.h. Am I missing something?

@raune, the RX and TX pins on the Spark are for the Serial1 interface, whereas the Serial interface is on the USB. The flashing 3 times red then red/white is odd. I will investigate.

If you are using the XBee Explorer Regulated, there are on-board level shifters for DIN and DOUT which may interfere. The board is designed to be used with 5v logic even though the XBee is a 3.3v part. I also noticed that the DTR pin may be used.

I don’t have an XBee so I can’t confirm that the code is correct. I will however look into the DTR pin requirement.

@raune, I missed some stuff when porting the RSSI code. Can you point me to the little bird code you got yours from? The unported code in rssi_prox.cpp use an output pin called “fakeGND” and it is unclear what that does. I will fix the code in my repo and set the LED pin to the onboard blue LED and the fakeGND pin to D6 which you could change later. Let me know if that helps.

UPDATE: The updated code is available in the repo.

1 Like

@peekay123, there’s a 3.3V output on the XBee Explorer I’m intending to use once the project gets going as I need the VIN for a Vibeboard, I just went with the VIN for now as it was easier on the breadboard - power seems to be fine though, there’s a control LED on the board for that.
The “fakeGnd” is for the LED’s in the original project - i guess just to make the stitching easier as the onboard GND is on the opposite side of the board to the pins they used. I had the code working on Arduino Megas without actually using it at all…
I’m home now but will give the new code a go first thing in the morning and hook up with the 3.3V as well, just in case :smile:
you can find the original code and project here: http://www.instructables.com/id/Proximity-Sensing-Pocket-Squares/

NewSoftSerial.h needs to be changed to SoftwareSerial.h, i’m quite at a loss though for what that does?

@raune, NewSoftSerial and SoftwareSerial are software-only serial port libraries for Arduino. They are used since an UNO, for example, only has one serial port. The Spark does not have this problem.

1 Like

ok I see - so I should be able to clear that out of the code then?

@peekay123, no luck with new code, neither with running the Explorers of the 3.3V output, also tried hooking up the XBees directly without the Explorers, however did some testing around and found that when I put the XBees in AT - mode I could communicate over the serial1, just sending a simple char (Explorers behaving oddly on the controllights: DIN, DOUT, RSSI but still sending) . However when in API mode (as they are for the rssi_prox) there is no communication taking place over the serial1 at all. Now the API mode should be taking care of by the XBee LIb so I am guessing the problem must be in there or can the Spark some how not handle API Mode ?