Subject:
|
Re: Bluetooth Comm Problem
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Tue, 13 Feb 2007 13:13:11 GMT
|
Viewed:
|
13675 times
|
| |
|
|
In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote:
> The only thing I can think of is whether, on the NXT, you are calling
> "ReadMessage" more than once. You should have a loop that runs for at
> least 50 (or better yet 150) milliseconds. Here's why.
I was a little confused about how I was supposed to determine when the message
had been received. I wasn't sure whether the ReceiveMessage should be called
multiple times or not. Here is my code:
// Connection = 1, Queue = 0
RemoteMessageWrite(1, 0, nbl_str, result) // calls NXTCommBTWrite
nbl_WaitMsgWrite:
BluetoothStatus(1, result) // calls NXTCommBTCheckStatus
brcmp EQ, nbl_WaitMsgWrite, result, STAT_COMM_PENDING // Gone out yet?
wait 60 // Probably not needed, but getting paranoid
nbl_WaitMsgRead:
// Queue = 0, Clear message in remote box (tried not clearing too)
ReceiveMessage(0, 1, nbl_str, result) // Calls NXTMessageRead
brcmp EQ, nbl_WaitMsgRead, result, STAT_COMM_PENDING // Gone out yet?
TextOut(0,LCD_LINE4,0, 'result=')
NumOut(50,LCD_LINE4,0,result) // Prints result=64
>
> When you perform a read remote message request, the return code of 64
> indicates that there were no immediately available queued remote
> messages on the NXT. It also checks to see if a BT message is in
> progress; if not, then it polls the slave devices in a round robin
> fashion asking them to reply with a remote message for the indicated
> queue. It takes tens of milliseconds for the poll request and its reply
> to return.
>
> Until the reply is received at the master, the "ReadMessage" request
> will return queue empty error code of 64.
>
> This implementation is kind of awkward. It relies on the user's
> application program to be periodically and frequently performing the
> remote "ReadMessage" requests. It is these calls to the "ReadMessage"
> request that are triggering the BT messages from the master to slave to
> retrieve remote messages.
As you can see, I am calling NXTMessageRead multiple times until I get a
non-STAT_COMM_PENDING (32/0x20) result. At one time, I had assumed that maybe
NXTMessageRead would not return until it polled, but when I saw the 32 come back
after calling it once, I decided to call it until I got something else back.
This is when I got the 64/0x40/empty queue.
Anything look wrong?
David
|
|
Message has 1 Reply:
 | | RE: Bluetooth Comm Problem
|
| The NXT-G firmware implementation for mailbox messaging is extremely funky. I don't think your code is working properly for this implementation. You need to be continuously calling "ReadMessage" and only check for "a message was found" error code. (...) (18 years ago, 14-Feb-07, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | RE: Bluetooth Comm Problem
|
| (...) A visual review looks like everything is appropriate. The only thing I can think of is whether, on the NXT, you are calling "ReadMessage" more than once. You should have a loop that runs for at least 50 (or better yet 150) milliseconds. (...) (18 years ago, 13-Feb-07, to lugnet.robotics.nxt)
|
8 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
