Hello, all. I'm having difficulty sending long strings to the arduino
from android and I've pretty much exhausted myself trying to solve my
problem, so I thought I'd ask for help. Before I post any code,
though, I wanted to ask if some of my assumptions are correct.
The strings I want to send could be up to 200 chars long, but
somewhere in the Amarino documentation I thought I read the Arduino is
only going to be able to handle about 62 chars at a time (buffer?
memory?). Is this correct? Because, on the Android side, I am
currently doing an IF-THEN-ELSE based on the string length that breaks
up the string into 62 char chunks, which I then (attempt to)
reassemble them on the arduino side. Is there a simpler way to
accomplish this that I have yet to find?
Strings are getting through to my arduino from the android, and the
earliest chunks sent are even correct, but when it comes to getting
the additional chunks to reassemble the string, it eventually starts
mixing garbage in with the readable stuff and locks up (seemingly on
the arduino side). In trying to figure this out, it seems clear that
I'm not understanding the whole android vs. arduino thing regarding
the null character/end of string/ack flag stuff, if those are even the
same/similar things, and how to handle them properly.
Any insight would be greatly appreciated. And if Bonifaz reads this,
thanks for all you've done with Amarino.
> Hello, all. I'm having difficulty sending long strings to the arduino > from android and I've pretty much exhausted myself trying to solve my > problem, so I thought I'd ask for help. Before I post any code, > though, I wanted to ask if some of my assumptions are correct.
> The strings I want to send could be up to 200 chars long, but > somewhere in the Amarino documentation I thought I read the Arduino is > only going to be able to handle about 62 chars at a time (buffer? > memory?). Is this correct? Because, on the Android side, I am > currently doing an IF-THEN-ELSE based on the string length that breaks > up the string into 62 char chunks, which I then (attempt to) > reassemble them on the arduino side. Is there a simpler way to > accomplish this that I have yet to find?
> Strings are getting through to my arduino from the android, and the > earliest chunks sent are even correct, but when it comes to getting > the additional chunks to reassemble the string, it eventually starts > mixing garbage in with the readable stuff and locks up (seemingly on > the arduino side). In trying to figure this out, it seems clear that > I'm not understanding the whole android vs. arduino thing regarding > the null character/end of string/ack flag stuff, if those are even the > same/similar things, and how to handle them properly.
> Any insight would be greatly appreciated. And if Bonifaz reads this, > thanks for all you've done with Amarino.
Absolutely. Thanks for responding, Paul. I have no doubt there are
ways to do what I'm trying to do in a less cumbersome way, but for the
moment I'd be happy to just get it working properly.
Here's the chunk from my arduino code:
(Hopefully it's okay to cut and paste code)
#include <MeetAndroid.h>
MeetAndroid meetAndroid;
char aMessage[190];
int messageLength;
unsigned int passNum;
boolean haveCompleteMsg = false;
> sent from android
> On Aug 30, 2011 7:27 PM, "Tim E." <secon...@gmail.com> wrote:
> > Hello, all. I'm having difficulty sending long strings to the arduino
> > from android and I've pretty much exhausted myself trying to solve my
> > problem, so I thought I'd ask for help. Before I post any code,
> > though, I wanted to ask if some of my assumptions are correct.
> > The strings I want to send could be up to 200 chars long, but
> > somewhere in the Amarino documentation I thought I read the Arduino is
> > only going to be able to handle about 62 chars at a time (buffer?
> > memory?). Is this correct? Because, on the Android side, I am
> > currently doing an IF-THEN-ELSE based on the string length that breaks
> > up the string into 62 char chunks, which I then (attempt to)
> > reassemble them on the arduino side. Is there a simpler way to
> > accomplish this that I have yet to find?
> > Strings are getting through to my arduino from the android, and the
> > earliest chunks sent are even correct, but when it comes to getting
> > the additional chunks to reassemble the string, it eventually starts
> > mixing garbage in with the readable stuff and locks up (seemingly on
> > the arduino side). In trying to figure this out, it seems clear that
> > I'm not understanding the whole android vs. arduino thing regarding
> > the null character/end of string/ack flag stuff, if those are even the
> > same/similar things, and how to handle them properly.
> > Any insight would be greatly appreciated. And if Bonifaz reads this,
> > thanks for all you've done with Amarino.
Hi Tim, did you look at the Conver Events example available with the meet android library? There is a method, found below, ho to handle strings.
*void stringValue(byte flag, byte numOfValues)* *{* * // first we need to know how long the string was in order to prepare an array big enough to hold it.* * // you should know that: (length == 'length of string sent from Android' + 1)* * // due to the '\0' null char added in Arduino* * int length = meetAndroid.stringLength();* * * * // define an array with the appropriate size which will store the string* * char data[length];* * * * // tell MeetAndroid to put the string into your prepared array* * meetAndroid.getString(data);* * * * // go and do something with the string, here we simply send it back to Android* * meetAndroid.send(data);* * * * for (int i=0; i<length-1; i++)* * {* * meetAndroid.send(data[i]);* * }* *}*
make sure to cater for the "\0" charcter as mentioned in the comments above.
> Absolutely. Thanks for responding, Paul. I have no doubt there are > ways to do what I'm trying to do in a less cumbersome way, but for the > moment I'd be happy to just get it working properly.
> Here's the chunk from my arduino code: > (Hopefully it's okay to cut and paste code)
> #include <MeetAndroid.h>
> MeetAndroid meetAndroid;
> char aMessage[190]; > int messageLength; > unsigned int passNum; > boolean haveCompleteMsg = false;
> On Aug 30, 4:52 pm, Paul Strohmeier <paul.strohme...@gmail.com> wrote: > > Can i see your arduino code?
> > sent from android > > On Aug 30, 2011 7:27 PM, "Tim E." <secon...@gmail.com> wrote:
> > > Hello, all. I'm having difficulty sending long strings to the arduino > > > from android and I've pretty much exhausted myself trying to solve my > > > problem, so I thought I'd ask for help. Before I post any code, > > > though, I wanted to ask if some of my assumptions are correct.
> > > The strings I want to send could be up to 200 chars long, but > > > somewhere in the Amarino documentation I thought I read the Arduino is > > > only going to be able to handle about 62 chars at a time (buffer? > > > memory?). Is this correct? Because, on the Android side, I am > > > currently doing an IF-THEN-ELSE based on the string length that breaks > > > up the string into 62 char chunks, which I then (attempt to) > > > reassemble them on the arduino side. Is there a simpler way to > > > accomplish this that I have yet to find?
> > > Strings are getting through to my arduino from the android, and the > > > earliest chunks sent are even correct, but when it comes to getting > > > the additional chunks to reassemble the string, it eventually starts > > > mixing garbage in with the readable stuff and locks up (seemingly on > > > the arduino side). In trying to figure this out, it seems clear that > > > I'm not understanding the whole android vs. arduino thing regarding > > > the null character/end of string/ack flag stuff, if those are even the > > > same/similar things, and how to handle them properly.
> > > Any insight would be greatly appreciated. And if Bonifaz reads this, > > > thanks for all you've done with Amarino.
(Warning, thar be a long post ahead. Feel free to take a shortcut to
Issue #3, which discusses my primary problem.)
Hi, Brian. Thanks for the reply. Yes, I actually started from the
Convert Events sample (there may even be a line or two of the code
still remaining in mine.) To try and solve my issue (which has turned
out to be issues) I've stripped both programs to the bare minimum,
with the android only sending one continuous string at a time and the
arduino receiving it and printing it to the LCD, testing with
different string lengths. I've identified 3 issues in particular, two
of which I feel I can probably solve, the third being the one I don't
yet have an answer for.
The three issues are:
1) I have non-printable characters ending up in the messages when
printed to the LCD that cause the program to crash. Sometimes these
characters exist in the original messages, but, strangely, sometimes
they appear in place of orginal message chars, getting changed
somewhere in the process, though I'm not sure where. (eg. In one
message, an "@" may come through fine, yet in another message it ends
up replaced with a null. Huh?) I'm hoping the solution is better
parsing of the original text to avoid troublesome characters, although
the behavior isn't exactly consistent.
2) There is a 62 character buffer limit in feeding chars to the
arduino (at least there is for me), which I have verified. Anything
longer and it's cut off. I'm confident this is a buffer limitation,
although maybe specific to sending strings to the arduino via
bluetooth, rather than a limitation in the arduino's ability to store
long strings (as discussed in your link) since it seems to handle
multiple messages which, collectively, total more than 62 chars, as
long as each message individually is <= 62 chars. I'm assuming
(always a logical approach, I know) the solution for this is my
original process of breaking longer strings into chunks of 62 or less
chars, sending them to the arduino, and reassembling them there before
sending to the LCD.
3) I'm hitting a limit on the total number of chars combined from all
messages I'm able to send from Android to the arduino. In sending/
receiving multiple messages, the overall limit is somewhere between
144-149 chars. If the total chars of all messages sent is greater
than that, it crashes. Now, at first glance, this seems like it would
be the arduino memory limitation issue I discounted as a cause of
issue #2, but I'm not sure it's exactly that. The reason I say I'm
not sure is because I'm running a stripped down pde file on a
ATMega328 (Arduino Mini Pro) with 2K of SRAM. Shouldn't I be able to
store an array of 200 chars? What's strange to me is that even when I
bring in multiple, shorter messages, I still end up hitting that
limit, even though I'm reusing the same array for each incoming
message. It seems like, from a storage standpoint, something is
collecting/agregating that is not being reset/cleared/reused on each
send/receive/print-to-LCD cycle.
So, what am I not understanding? Could the LCD and it's data
registers be the issue/limitation? As far as it possibly being an
arduino SRAM limitation, shouldn't I be able to feed it endless
strings, if they're small enough, if I'm reusing the same variables/
arrays? I feel like I'm missing something obvious.
As before, any insight would be greatly appreciated.
void getaMessage(byte flag, byte numOfValues) {
length = meetAndroid.stringLength(); // get the string length
meetAndroid.getString(aMessage); // get the string
// writes the string to the LCD
lcd.clear();
positionMarker = 1;
// the following "if-else" and "for" statements are to scroll the text
left
// if the message is longer than the width of the LCD (40)
if (length < 42) {
for (charCounter = 0; charCounter < length - 2; charCounter++) {
lcd.setCursor(charCounter, 1);
lcd.write(aMessage[charCounter]);
delay(100);
}
}
else {
for (charCounter = 0; charCounter < LCD_COLUMNS; charCounter++) {
lcd.setCursor(charCounter, 1);
lcd.write(aMessage[charCounter]);
delay(100);
}
for (charCounter = LCD_COLUMNS; charCounter < length +
LCD_COLUMNS; charCounter++) {
for (int i = 0; i < LCD_COLUMNS; i++) {
lcd.setCursor(i, 1);
if (i + positionMarker >= length - 1) {
lcd.write(space);
}
else {
lcd.write(aMessage[i + positionMarker]);
}
}
++positionMarker;
delay(175);
}
}
// resetting the char array to nulls after each message, thinking it
might help
// but it doesn't appear to
for (byte i = 0; i < 160; i++) {
aMessage[i] = '\0';
}
lcd.clear();
}
On Aug 30, 11:26 pm, Brian Farrugia <bri...@gmail.com> wrote:
> Hi Tim,
> did you look at the Conver Events example available with the meet android
> library?
> There is a method, found below, ho to handle strings.
> *void stringValue(byte flag, byte numOfValues)*
> *{*
> * // first we need to know how long the string was in order to prepare an
> array big enough to hold it.*
> * // you should know that: (length == 'length of string sent from Android'
> + 1)*
> * // due to the '\0' null char added in Arduino*
> * int length = meetAndroid.stringLength();*
> * *
> * // define an array with the appropriate size which will store the string*
> * char data[length];*
> * *
> * // tell MeetAndroid to put the string into your prepared array*
> * meetAndroid.getString(data);*
> * *
> * // go and do something with the string, here we simply send it back to
> Android*
> * meetAndroid.send(data);*
> * *
> * for (int i=0; i<length-1; i++)*
> * {*
> * meetAndroid.send(data[i]);*
> * }*
> *}*
> make sure to cater for the "\0" charcter as mentioned in the comments above.
> I think you can remove all string.length lines and for loops that send the
> string as a char in andriod
> Hope it helps.
> On 31 August 2011 02:24, Tim E. <secon...@gmail.com> wrote:
> > Absolutely. Thanks for responding, Paul. I have no doubt there are
> > ways to do what I'm trying to do in a less cumbersome way, but for the
> > moment I'd be happy to just get it working properly.
> > Here's the chunk from my arduino code:
> > (Hopefully it's okay to cut and paste code)
> > #include <MeetAndroid.h>
> > MeetAndroid meetAndroid;
> > char aMessage[190];
> > int messageLength;
> > unsigned int passNum;
> > boolean haveCompleteMsg = false;
ISSUES SOLVED!!!! Turns out the issues were buffer related.
Different buffers, though.
DISCLAIMER: This is all still pretty new to me. These solutions
worked for my application on my arduino (Mini Pro) and I arrived at
them through experimentation led by things others had done before.
There is a distinct possibility they could cause problems for other
programs and other arduinos. Use at your own risk.
Here are the solutions I arrived at, listed in reverse order:
Issue #3 Solution: Edited the \arduino\hardware\arduino\cores\arduino
\HardwareSerial.cpp file, changing
Now I'm able to pump through a lot more messages before reaching a
limit. Even more messages would require a larger RX_BUFFER_SIZE, but
I'm guessing this is limited by the amount of SRAM on your arduino. I
also read somewhere that this number should be a power of 2 (64, 128,
etc.). If so, my next step up would be to 2048, which my Mini Pro
surely wouldn't handle. I have not tested to confirm that the power
of 2 requirement is a fact, however. I'm still searching for the
better solution, which is to be able to reset the rx buffer on the
fly, without having to reset the arduino, so that space in the buffer
is continually freed up whenever a message has already been written to
the LCD.
Issue #2 Solution: Edited the \arduino\libraries\MeetAndroid
\MeetAndroid.h file, changing
#define ByteBufferLenght 64
to
#define ByteBufferLenght 160
Now my individual messages go from Android to Arduino to LCD without
getting cut off. This solution works for the length of messages I'm
using. Longer messages may need a longer ByteBufferLength, although
the limit appears to be somewhere between 160 and 256 without having
to tweak other values (it least it appeared to be for my app and my
arduino), having tried 256 and it crashing my program. As I am using
a value of 160, the power of 2 thing doesn't seem to be an issue
here. Since 128 wasn't a long enough buffer for my messages, I
increased it by a multiple of 8, thinking byte-wise that would be a
good idea. Don't know if that's necessary, that's just what I did.
Issue #1 Solution: Seems to have resolved itself with the resolution
of Issues #2 & #3. So far so good, anyway.
Hope this helps others.
Cheers,
Tim
On Aug 31, 6:31 pm, "Tim E." <secon...@gmail.com> wrote:
> (Warning, thar be a long post ahead. Feel free to take a shortcut to
> Issue #3, which discusses my primary problem.)
> Hi, Brian. Thanks for the reply. Yes, I actually started from the
> Convert Events sample (there may even be a line or two of the code
> still remaining in mine.) To try and solve my issue (which has turned
> out to be issues) I've stripped both programs to the bare minimum,
> with the android only sending one continuous string at a time and the
> arduino receiving it and printing it to the LCD, testing with
> different string lengths. I've identified 3 issues in particular, two
> of which I feel I can probably solve, the third being the one I don't
> yet have an answer for.
> The three issues are:
> 1) I have non-printable characters ending up in the messages when
> printed to the LCD that cause the program to crash. Sometimes these
> characters exist in the original messages, but, strangely, sometimes
> they appear in place of orginal message chars, getting changed
> somewhere in the process, though I'm not sure where. (eg. In one
> message, an "@" may come through fine, yet in another message it ends
> up replaced with a null. Huh?) I'm hoping the solution is better
> parsing of the original text to avoid troublesome characters, although
> the behavior isn't exactly consistent.
> 2) There is a 62 character buffer limit in feeding chars to the
> arduino (at least there is for me), which I have verified. Anything
> longer and it's cut off. I'm confident this is a buffer limitation,
> although maybe specific to sending strings to the arduino via
> bluetooth, rather than a limitation in the arduino's ability to store
> long strings (as discussed in your link) since it seems to handle
> multiple messages which, collectively, total more than 62 chars, as
> long as each message individually is <= 62 chars. I'm assuming
> (always a logical approach, I know) the solution for this is my
> original process of breaking longer strings into chunks of 62 or less
> chars, sending them to the arduino, and reassembling them there before
> sending to the LCD.
> 3) I'm hitting a limit on the total number of chars combined from all
> messages I'm able to send from Android to the arduino. In sending/
> receiving multiple messages, the overall limit is somewhere between
> 144-149 chars. If the total chars of all messages sent is greater
> than that, it crashes. Now, at first glance, this seems like it would
> be the arduino memory limitation issue I discounted as a cause of
> issue #2, but I'm not sure it's exactly that. The reason I say I'm
> not sure is because I'm running a stripped down pde file on a
> ATMega328 (Arduino Mini Pro) with 2K of SRAM. Shouldn't I be able to
> store an array of 200 chars? What's strange to me is that even when I
> bring in multiple, shorter messages, I still end up hitting that
> limit, even though I'm reusing the same array for each incoming
> message. It seems like, from a storage standpoint, something is
> collecting/agregating that is not being reset/cleared/reused on each
> send/receive/print-to-LCD cycle.
> So, what am I not understanding? Could the LCD and it's data
> registers be the issue/limitation? As far as it possibly being an
> arduino SRAM limitation, shouldn't I be able to feed it endless
> strings, if they're small enough, if I'm reusing the same variables/
> arrays? I feel like I'm missing something obvious.
> As before, any insight would be greatly appreciated.
> void getaMessage(byte flag, byte numOfValues) {
> length = meetAndroid.stringLength(); // get the string length
> meetAndroid.getString(aMessage); // get the string
> // writes the string to the LCD
> lcd.clear();
> positionMarker = 1;
> // the following "if-else" and "for" statements are to scroll the text
> left
> // if the message is longer than the width of the LCD (40)
> if (length < 42) {
> for (charCounter = 0; charCounter < length - 2; charCounter++) {
> lcd.setCursor(charCounter, 1);
> lcd.write(aMessage[charCounter]);
> delay(100);
> }
> }
> else {
> for (charCounter = 0; charCounter < LCD_COLUMNS; charCounter++) {
> lcd.setCursor(charCounter, 1);
> lcd.write(aMessage[charCounter]);
> delay(100);
> }
> for (charCounter = LCD_COLUMNS; charCounter < length +
> LCD_COLUMNS; charCounter++) {
> for (int i = 0; i < LCD_COLUMNS; i++) {
> lcd.setCursor(i, 1);
> if (i + positionMarker >= length - 1) {
> lcd.write(space);
> }
> else {
> lcd.write(aMessage[i + positionMarker]);
> }
> }
> ++positionMarker;
> delay(175);
> }
> }
> // resetting the char array to nulls after each message, thinking it
> might help
> // but it doesn't appear to
> for (byte i = 0; i < 160; i++) {
> aMessage[i] = '\0';
> }
> lcd.clear();
> }
> On Aug 30, 11:26 pm, Brian Farrugia <bri...@gmail.com> wrote:
> > Hi Tim,
> > did you look at the Conver Events example available with the meet android
> > library?
> > There is a method, found below, ho to handle strings.
> > *void stringValue(byte flag, byte numOfValues)*
> > *{*
> > * // first we need to know how long the string was in order to prepare an
> > array big enough to hold it.*
> > * // you should know that: (length == 'length of string sent from Android'
> > + 1)*
> > * // due to the '\0' null char added in Arduino*
> > * int length = meetAndroid.stringLength();*
> > * *
> > * // define an array with the appropriate size which will store the string*
> > * char data[length];*
> > * *
> > * // tell MeetAndroid to put the string into your prepared array*
> > * meetAndroid.getString(data);*
> > * *
> > * // go and do something with the string, here we simply send it back to
> > Android*
> > * meetAndroid.send(data);*
> > * *
> > * for (int i=0; i<length-1; i++)*
> > * {*
> > * meetAndroid.send(data[i]);*
> > * }*
> > *}*
> > make sure to cater for the "\0" charcter as mentioned in the comments above.
Has anyone else had this similar issue? I have corrupt data when sending a 10 integer array. Thats only 20 bytes though and should not reach the original limits.
On Tuesday, August 30, 2011 6:27:15 PM UTC-5, Tim E. wrote:
> Hello, all. I'm having difficulty sending long strings to the arduino > from android and I've pretty much exhausted myself trying to solve my > problem, so I thought I'd ask for help. Before I post any code, > though, I wanted to ask if some of my assumptions are correct.
> The strings I want to send could be up to 200 chars long, but > somewhere in the Amarino documentation I thought I read the Arduino is > only going to be able to handle about 62 chars at a time (buffer? > memory?). Is this correct? Because, on the Android side, I am > currently doing an IF-THEN-ELSE based on the string length that breaks > up the string into 62 char chunks, which I then (attempt to) > reassemble them on the arduino side. Is there a simpler way to > accomplish this that I have yet to find?
> Strings are getting through to my arduino from the android, and the > earliest chunks sent are even correct, but when it comes to getting > the additional chunks to reassemble the string, it eventually starts > mixing garbage in with the readable stuff and locks up (seemingly on > the arduino side). In trying to figure this out, it seems clear that > I'm not understanding the whole android vs. arduino thing regarding > the null character/end of string/ack flag stuff, if those are even the > same/similar things, and how to handle them properly.
> Any insight would be greatly appreciated. And if Bonifaz reads this, > thanks for all you've done with Amarino.
