Page 1 of 1
NXC: max string length for SendResponseString
Posted: 27 Feb 2011, 14:33
by HaWe
I can't find it in the docs:
What is the max string length for out in SendResponseString(OUTBOX_1, out)?
Re: NXC: max string length for SendResponseString
Posted: 27 Feb 2011, 17:10
by mattallen37
I don't remember exactly, but I think the max is 64 bytes, but only like 59 (or about that) of user-bytes.
Re: NXC: max string length for SendResponseString
Posted: 27 Feb 2011, 17:29
by HaWe
thx, that's a good guess I think.
Does anyone know the number for a fact?
Re: NXC: max string length for SendResponseString
Posted: 28 Feb 2011, 09:57
by afanofosc
I'm not sure but I think that the firmware source may have code that look something like this:
Code: Select all
//Can't accept oversize messages because we treat them as strings (truncation would remove null termination)
if (Length > MAX_MESSAGE_SIZE)
return ERR_INVALID_SIZE;
My guess is that the actual queue/mailbox is a dynamically sized array but the above code in cCmdMessageWrite makes sure that you never try to write more than MAX_MESSAGE_SIZE bytes to any queue. Care to guess what value MAX_MESSAGE_SIZE has? My guess is that c_cmd.h probably has something like this in it:
Code: Select all
//MAX_MESSAGE_SIZE including null-terminator
//!!! Capped at 59 unless USB protocol assumptions are changed!
//
#define MAX_MESSAGE_SIZE 59
The only thing I know for a fact is that Matt was absolutely right wrt the maximum length of data that can be written to an NXT mailbox.
John Hansen
P.S. It's a bit confusing since some things do have the whole 64 bytes but only 59 are usable situation. Specifically, when you send a direct command it limits you to 64 bytes max with some of those bytes being protocol overhead leaving, in the case of the message write direct command, only 59 bytes available. Writing directly to a queue/mailbox within a running program does not involve any protocol overhead so you simply have the 59 bytes and that's it.
Re: NXC: max string length for SendResponseString
Posted: 28 Feb 2011, 10:02
by HaWe
I came upon this issue because I have a BT slave program that writes a BT response string.
When it happend to be very long (> 64-80 byte) the BT master hangs up most of the time and gets not slave data at all.
When I'm limiting it (currently my own try was 55), all was ok.
So if you think 59 would be safe, I'll try it (That's easier than to try all values between 55 and 80.
Thanks so far!
Re: NXC: max string length for SendResponseString
Posted: 28 Feb 2011, 10:41
by mattallen37
I do think 59 would be "safe". If for some reason it doesn't work, just reduce the number.
Re: NXC: max string length for SendResponseString
Posted: 02 Mar 2011, 00:33
by muntoo
See page 8 of 10 of the
"LEGO MINDSTORMS NXT Bluetooth Developer Kit.pdf". (Click on the smiley.
)
Message data is treated as a string; it must include null termination to be accepted. Accordingly, message size must include the null termination byte. Message size must be capped at 59 for all message packets to be legal on USB!
Re: NXC: max string length for SendResponseString
Posted: 02 Mar 2011, 08:32
by HaWe
thx a lot, good to know it now 100% for sure! Thx for your efforts!
Re: NXC: max string length for SendResponseString
Posted: 03 Mar 2011, 12:26
by ricardocrl
Hello guys,
I lost too many time looking for this answer some time ago and wrote about that here:
-
https://sourceforge.net/apps/phpbb/mind ... ?f=3&t=490
So, the actual limit becomes 58! I've used this limit and I can ensure it is OK.
I needed to exchange bigger messages between a NXT and a PC, so I wrote NXC functions and C++ methods to send and receive messages of "any" size, by spliting the messages in small portions and joining them on the receiver. I tested them up to 2500 chars and it was fine. I can share them later.
Re: NXC: max string length for SendResponseString
Posted: 03 Mar 2011, 14:14
by HaWe
Ricardo,
thx for your posting! Good to have asked and now good to know really for sure.
Your reply probably saved me days and weeks of unnecessary headaches during unnerving troubleshooting when in some cases my BT Network Program messaging might have been broken - and for all people who entered that trap after me.
Thx a lot again!
=)