Sending strings/char arrays to arduino

[Tim E.]

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.

Cheers,
Tim

[Paul Strohmeier]

Can i see your arduino code?

sent from android

[Tim E.]

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;



void setup(){
meetAndroid.registerFunction(getMessageLength, 'y');
meetAndroid.registerFunction(getaMessage, 'z');
}

void loop(){
meetAndroid.receive();
}


void getMessageLength(byte flag, byte numOfValues) {
messageLength = meetAndroid.getInt();
passNum = 1;
}


void getaMessage(byte flag, byte numOfValues) {

char tempCharArr[63];

if (messageLength <= 62) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < messageLength; i++) {
aMessage[i] = tempCharArr[i];
}
haveCompleteMsg = true;
}

else if (messageLength <= 124 && passNum == 1) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < 62; i++) {
aMessage[i] = tempCharArr[i];
}
}
else if (messageLength <= 124 && passNum == 2) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < messageLength - 61; i++) {
aMessage[i+62] = tempCharArr[i];
}
haveCompleteMsg = true;
}

else if (passNum == 1) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < 62; i++) {
aMessage[i] = tempCharArr[i];
}
}
else if (passNum == 2) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < 62; i++) {
aMessage[i+62] = tempCharArr[i];
}
}
else if (passNum == 3) {
meetAndroid.getString(tempCharArr);
for (int i = 0; i < messageLength - 123; i++) {
aMessage[i+124] = tempCharArr[i];
}
haveCompleteMsg = true;
}

for (int i = 0; i <= 62; i++) {
tempCharArr[i] = '\0';
}

passNum = passNum + 1;

if (haveCompleteMsg) {
sendMsgToLcd(aMessage);
haveCompleteMsg = false;
}
}


And here's the chunk from my Android app:

private void myMsgsToArduino(ArrayList<myMsgs> myMsgsToDisplay) {

int numMsgs = myMsgsToDisplay.size();
String aMessage;
int messageLength;

for (int i = 0; i < numMsgs; i++) {

aMessage = myMsgsToDisplay.get(i).message;
messageLength = aMessage.length();

Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'y',
messageLength);

if (messageLength <= 62) {
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z', aMessage);
}
else if (messageLength <= 123) {
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z',
aMessage.substring(0, 61));
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z',
aMessage.substring(62, messageLength - 1));
}
else {
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z',
aMessage.substring(0, 61));
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z',
aMessage.substring(62, 123));
Amarino.sendDataToArduino(this, DEVICE_ADDRESS, 'z',
aMessage.substring(124, messageLength));

}
}
}




On Aug 30, 4:52 pm, Paul Strohmeier <paul.strohme...@gmail.com> wrote:
> Can i see your arduino code?
>
> sent from android

[Brian Farrugia]

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.

According to this Blog Post the Arduino ATMega168 can handle strings with 613 characters, over serial. 

I think you can remove all string.length lines and for loops that send the string as a char in andriod

Hope it helps.

[Tim E.]

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

Cheers,
Tim

p.s. Here is my stripped down arduino code:

#include <MeetAndroid.h>
#include <LiquidCrystal.h>

#define LCD_LINES 2
#define LCD_COLUMNS 40

LiquidCrystal lcd(10, 11, 2, 3, 4, 5, 6, 7, 8, 9);

MeetAndroid meetAndroid;

char aMessage[160];
byte length;
byte charCounter;
byte positionMarker;
char space = ' ';

void setup() {
lcd.begin(LCD_COLUMNS,LCD_LINES);
Serial.begin(57600);

meetAndroid.registerFunction(getaMessage, 'z');
}

void loop() {
meetAndroid.receive();
}

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.
>
> According to this Blog

> Post<http://www.faludi.com/2007/04/13/arduino-string-memory/> the

> Arduino ATMega168 can handle strings with 613 characters, over serial.
>
> I think you can remove all string.length lines and for loops that send the
> string as a char in andriod
>
> Hope it helps.
>

[Tim E.]

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

#if (RAMEND < 1000)
#define RX_BUFFER_SIZE 32
#else
#define RX_BUFFER_SIZE 128
#endif

to

#if (RAMEND < 1000)
#define RX_BUFFER_SIZE 32
#else
#define RX_BUFFER_SIZE 1024
#endif

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

> > >    ...
>
> read more »

[Spectrem]

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.