strlen()
instead of the deprecated StrLen()
. Same with SubStr()
.Try it with:
Code: Select all
arrinit tmp, 0, 1
strlen()
instead of the deprecated StrLen()
. Same with SubStr()
.Code: Select all
arrinit tmp, 0, 1
I tried your suggestion, but it still fails at some point during the last block. And the reason I know it has something to do with Mr. Hansen's code is because if I just write the data to a file, everything goes fine. There's something funny going on with that asm block...muntoo wrote:You should usestrlen()
instead of the deprecatedStrLen()
. Same withSubStr()
.
Try it with:Where does it freeze? The last block?Code: Select all
arrinit tmp, 0, 1
CLICK
between each line of code in the last block. (Excluding inside the asm
block.)
Code: Select all
#define CLICK while(!(ButtonPressed(BTNCENTER, 0))); \
while(ButtonPressed(BTNCENTER, 0));
Code: Select all
while(numBytesWritten < size) {
while(ReceiveMessage(0, true, packet) != LDR_SUCCESS);
CLICK
asm {
strcat tmp, message, packet
mov message, tmp
arrinit tmp, 0, 0
}
CLICK
numBytesWritten += StrLen(packet);
CLICK
}
CLICK
s till the program freezes?clicks % 3 == 1
, then try this program:
Code: Select all
while(numBytesWritten < size) {
while(ReceiveMessage(0, true, packet) != LDR_SUCCESS);
asm { strcat tmp, message, packet } CLICK
asm { mov message, tmp } CLICK
asm { arrinit tmp, 0, 0 } CLICK
numBytesWritten += StrLen(packet);
}
CLICK
s this time?clicks > 30
, you don't have to keep clicking a few thousand more times. You could then replace the definition with:
Code: Select all
unsigned long clicks = 0;
// CHANGE THESE!!
#define SKIP 30
#define WAIT 500
#define CLICK ++clicks; \
NumOut(0, 0, clicks, 0); \
if(clicks >= SKIP) { \
Wait(WAIT); \
}
Indeed, the problem turned out to be an uninitialized string. My code works fine now. Even with the asm block, though, it still crashes after receiving too much data, so I've just decided to write it to a file. The performance does not suffer too much. However, I have noticed that there is a drastic difference between the performance of the bluetooth on my 2009 MacBook Pro and my PowerMac G4. Does anybody know why this could be? When my MacBook Pro is connected to the NXT, it takes forever to send the data over bluetooth. (It took a minute and a half to send a 20.4 kB file.) The PowerMac sends the data over 4x as fast (21 seconds to send the same file). What could be the cause of such a large performance difference? Is it the bluetooth card in my MacBook that is slowing things down? Or perhaps a setting I can change or a patch I can install?afanofosc wrote:Make sure you are using the very latest BricxCC/NBC/NXC version. There was a bug with uninitialized strings that I have fixed recently and that may not be available in any publicly available version at this time. All your strings need to be null terminated or strcat will fail - possibly crashing your NXT. Try initializing your strings to "" before entering the loop and make sure that packet is absolutely guaranteed to be null terminated. It should be if it is a valid message.
John Hansen
Alas, I already have the latest Fantom drivers for Mac OS X installed. In response to your question, the program crashes after receiving 10.3 kB.afanofosc wrote:The very latest Fantom drivers for Mac OS X might help you, if you do not already have them installed. LEGO released an update that was intended to help improve support for the new bluetooth hardware used in newer Mac computers.
http://cache.lego.com/upload/contentTem ... 5DA785.zip
This is version 1.13, iirc.
When you say your program still crashed after receiving too much data, are you talking about close to 16kb or something much less than that?
John Hansen
Users browsing this forum: No registered users and 4 guests