How to use RX/RXBUFFER ?

[choi0101]

I connect my device to my Hexapod through RS232 and they are properly connected.
I also send some signal to initiate my device which then send back ACK. This ACK signal is AA0E0D000000. However, RX only can read AA as it is 16 bits receiver.
So, how can i store the whole signal for further use?

Actually, i know that RXBUFFER can be used in this way. But i do not know how to use it...

HERE 16 6 * 4 + ALLOT CONSTANT BUFFER1
BUFFER1 16 6 * 4 + SCI1 RXBUFFER1

Then how can i use the BUFFER1 ?

[RMDumse]

However, RX only can read AA as it is 16 bits receiver.

Actually 8 bits, since that is one serial character. RX returns one character.

If you want more than a character, you have to use RX multiple times, or, deal with the input buffer and parse characters.

For instance, if you do < addr > < count > EXPECT, you will collect up to < count > characters at < addr >

You might want to look at the string extensions as well from the downloads, but that might be more than you need.

The key here is, you need to program your response according the the series of characters you get.

Actually, i know that RXBUFFER can be used in this way. But i do not know how to use it...

HERE 16 6 * 4 + ALLOT CONSTANT BUFFER1
BUFFER1 16 6 * 4 + SCI1 RXBUFFER1

It is probably wrong to think of the buffering as a way to create 6 bins with 16 characters in it each. Instead what BUFFERing is for is to collect characters with interrupts while your program is otherwise "away", and these collected characters are stored in a FIFO of a selected length. So if you think a whole string might come in while you were away, and the string is 16 characters, you might want to use a 32 character buffer to have double the length available, plus 4 to hold the pointers the buffering uses.

The key thing to remember is this is a circular buffer, a ring, a collection place, but not something that lays things down at hard addresses in memory for you to fetch. (If you want that you can program that.) But the buffer is just a temporary holding circular ring to gather characters as they come in so your sending unit can send as fast as it can, and as long as you get back to process them before the ring wraps over itself, you'll still get those characters in tact and in the correct order as you pull them out, even though you are using the same RX type words you would even without interrupts.

Then how can i use the BUFFER1 ?

So you have the creation right:

HERE 16 6 * 4 + ALLOT CONSTANT BUFFER1

But then you need to tell the system to use the buffer

BUFFER1 16 6 * 4 + SCI1 RXBUFFER

The key word there is RXBUFFER. It turns on interrupts and sends future character to the buffer you identify.

Now you may want to capture a string and put it in a buffer to process. That's fine. You can use EXPECT for that. Oh. EXPECT uses SCI0. You are using SCI1. Okay. Write your own EXPECT.


HERE 16 ALLOT CONSTANT MYBUFF

: EXPECTSCI1
0
BEGIN
RX
OVER MYBUFF + !
1+
DUP 16 < NOT
UNTIL
DROP
;

Don't call this until you're sure there are 16 characters ready to be placed in MYBUFF. RX? will tell you want is waiting in BUFFER1.

[choi0101]

Thank you for your fast reply !!

AA0E0D000000
This signal is in HEX
so 8 bits should be AA

I try to send the SYNC AA0D00000000 to my device and it will be :

AA SCI1 TX
0D SCI1 TX
00 SCI1 TX
00 SCI1 TX
00 SCI1 TX
00 SCI1 TX

And it works.

But what is the meaning of this code ?
Does EXPECT means that :
The coming data is stored in address accordingly since each address is 16 bits ( 8bits for something and 8 bits for two HEX such as AA )?
< address > <AA>
< address +1 > <0D>
< address +2 > <00>
< address +3 > <00>
< address +4 > <00>
< address +5 > <00>


Code:

HERE 16 ALLOT CONSTANT MYBUFF

: EXPECTSCI1
0
BEGIN
RX
OVER MYBUFF + !
1+
DUP 16 < NOT
UNTIL
DROP
;

And how can i use this function with RXBUFFER?

[RMDumse]

AA0E0D000000
This signal is in HEX
so 8 bits should be AA

...

But what is the meaning of this code ?
Does EXPECT means that :
The coming data is stored in address accordingly since each address is 16 bits ( 8bits for something and 8 bits for two HEX such as AA )?

Okay, it seems the confusion is about addresses vs. hex digits vs. serial bytes.

The UART is an 8-bit device. It can only send and it can only receive 8-bits. So you get serial bytes (of 8 bits) from the UART. The 'Pod sends bytes, the camera sends bytes.

Now in those bytes, you can encode many things. There is room for two hex digits in a byte. A hex digit only requires 4-bits, so if you pack them, two hex digits can fit in 8-bits.

So you can send a byte, and think of it as containing two hex digits.

Addresses generally consist of larger groups of bits, in the 'Pod 16-bits make up an address. So if you want to send an address over the UART, you have to send two bytes to get a total of 16-bits. Or you can think of this you are sending four hex digits, 2 digits per byte. So in 2 bytes, you can send 4-hex digits, or 16-bit address if you prefer.

Now with buffers, you usually use one location per byte. Each location can store 16-bits, but for convenience, you only store 8-bits in a location. So in the example MYBUFF, when we did 1+, we moved from one of 16 locations, because we were expecting 16 characters. (Maybe that was too many? Maybe you are only looking for 6 characters?)

Here's the problem. When I see

AA0E0D000000

It could mean there are 12 characters there like this:

A A 0 E 0 D 0 0 0 0 0 0

and in an ASCII stream these would be the bytes (in hex).

41 41 30 45 30 44 30 30 30 30 30 30

-OR-

maybe

AA0E0D000000

is meant to be read in hex

AA 0E 0D 00 00 00

and in an ASCII stream these would be the bytes (in hex).

AA 0E 0D 00 00 00

There are very different methods of receiving these two streams on the receiving end, and not being familiar with the camera (is that still what we are working on?) I don't know which is which.

Now if there is an address in the stream, then we can combine bytes to make a 16-bit value. Lets say in the stream there is a HEX 1234 coming in two bytes. Like this:

12 34

We could reassemble them by RX >< RX OR and then we'd have 1234 as a 16-bit number/address on the stack.

Or if we had captured a stream into a buffer, and we knew that byte offset 2 and 3 were supposed to be a 16-bit number/address we could reach in the buffer and convert them like this:

MYBUFF 2 + @ >< MYBUFF 3 + @ OR

and there result would be left on the stack.

Sorry to be tedious, but I know there is a misunderstanding, but I don't know where, so being explicit in the description, and perhaps going too low or too simple is the best way to get to the bottom of the problem.



And how can i use this function with RXBUFFER?

It seems you find this hard. It isn't.

Some preconception stands in the way.

RXBUFFER is used to turn on interrupts, and assigns the place where the interrupt buffer goes. After you assign it, you for get it. You don't have to do anything else. It works in the background gathering up characters if you are not fast enough to get each character as it comes in.

Thats it.

You still use RX to get characters.

But if you don't use RXBUFFER, then the serial buffer is only one character deep, the one character is in the UART hardware. If you do use RXBUFFER, then the serial buffer is the size you make it, and it is somewhere in memory that you specify, and it is so many characters deep, depending on what number (less 4) you pass to RXBUFFER when you set it up.

[mohanarpit]

Hi

I went throught the entire conversation above. I had a query. I have attached a Compass Sensor purchased from "Ocean Server" to the Isopod. The Compass Sensor returns back 4 float values ( Heading, Pitch, Roll and Temperature) along with the prefixes as shown in an example output.

Eg. $C28.3P58.5R-54.6T28.3*37
(where c = compass, p= pitch, r=roll, t=temperature)

I don't have to poll these results. The sensor continously sends back results when connected to the serial port. I was wondering if it is possible to store these values in a buffer and access them later?