GetHSInputBuffer question

[mightor]

This is from the NXC documentation:

Code: Select all

void GetHSInputBuffer  ( const byte  offset,  
  byte  cnt,  
  byte &  data[]   
 ) 

What happens when cnt is larger than what is currently available in the buffer? Does it return immediately or wait until that count has been satisfied? I am aware of the fact that I can check with HSInputBufferInPtr() how much is there for me, but I want the "cnt" parameter to be the max number of bytes I care about.

Regards,
Xander

[mattallen37]

Well, you probably don't want to get an array that is only half there (if you attempt to read the data before the buffer is "full"), right? I would suggest waiting with something like this:

Code: Select all

until(HSInputBufferInPtr()>=max_number_of_bytes_I_care_about);
cnt=HSInputBufferInPtr();                      //this or the next line
cnt=max_number_of_bytes_I_care_about;          //this or the previous line
GetHSInputBuffer(Offset, cnt, Data);

I know that is probably not the answer you want, but that is how I would do what I think you want.

[mightor]

No, I wanted to know if it returns straight away or whether the call is a blocking one. I can't assume that enough bytes will be received. I'd rather a half full buffer than a call that doesn't return

- Xander

[mattallen37]

Based on some tests I just ran, the cnt MUST be exactly the same as HSInputBufferInPtr() (number of user bytes plus two one, I think). I sent 1 byte variable, followed by 5 6 int variables, so 11 12 bytes (made into an array, flattened into a string, sent, received, unflattened into an array), and the number 13 was the ONLY number that worked for cnt. 12 didn't get ANY of the data, and neither did 14... However, I am using a addressing system, so I can't be 100% sure about that. I'll test without the addressing.

[mattallen37]

Okay, I tested again, without addressing, and it's the same deal. cnt must be exactly the right number (number of user bytes, plus one).

[afanofosc]

I haven't tested this recently but reading from the hi-speed input buffer is just a call to IOMapRead and all it does with the cnt value is use it to count how many bytes to copy from the IOMap structure into the buffer you provide it. The buffer is 128 bytes long and regardless of how may bytes have been put there by the Comm module (copied from the VarsComm structure's hi-speed input buffer) an IOMapRead will read N bytes from an Offset into the specified IOMap structure. None of the API functions that read or write data via the IOMapRead and IOMapWrite system calls do any blocking whatsoever. Reading from the input buffer memory is completely independent of whatever values happen to be stored in the input and output pointer fields for the hi-speed input buffer.

John Hansen

[mattallen37]

Wow, great explanation, thanks a lot. I must just have a bug in my code then.

When I send a 6 piece(?, what is the term for a single "piece" of an array?) int array, flattened to a string, why does it need to read it as 13 bytes to get it properly? I know it is 12 (6ints x 16bits), but why the 13th byte? Is it related to the string? RS485 communication? Reading from the IOMap?

BTW, how many bytes can be read/written at a time? You said the buffer is 128 bytes long, but can you read/write all 128 bytes all at once? Or is there a limit (like 16 for I2C)?

[mightor]

Excellent, thanks John and thank you Matt for doing those tests!

- Xander

[mattallen37]

You're welcome. It ended up helping me as well. Now my RS485 code works a whole lot better (a lot faster, and more stable).

Was this inquiry made so you could write better NXC drivers for the NXTbees? How well do the NXTbees work? Can you use them as virtual RS485 cables? for example, if you have a program that uses two NXT's as a master and slave RS485 setup, can you plug in the NXTbees in place of the connecting wire, without modifying the code (other than maybe time related issues)?

[mightor]

Was this inquiry made so you could write better NXC drivers for the NXTbees?

Initially just to port my configuration utility from ROBOTC to NXC. After that I will probably work on porting my driver.

How well do the NXTbees work? Can you use them as virtual RS485 cables?

Yeah, pretty much. The only gotchas are throughput, it's not 900Kbit/s like on a back-to-back connections with cables and secondly, the baud rate of the NXT must match that of the NXTBee. That is what my configuration utility does. It scans for the NXTBee and then configures it with a user selectable baud rate.

There is a higher chance of in-transit data corruption due to the fact that the NXTBee shares its frequency range with many other devices. My test program [LINK] uses a CRC to make sure the data is as expected.

- Xander