Get_buffer_char

Spannertech

I have a question about receiving and parsing strings of varying length, with no defined end character. I don't believe I can do much with a WHILE in the STRING event because I don't have a known finishing condition. I think I've also learnt that knowing the length or end character, the WHILE is the key to preventing the STRING event from firing more times than you want and capturing the whole string intact.

In theory I thought I could do something like:

DEFINE_START

CREATE_BUFFER dvDEVICE,buffer

DEFINE_EVENT

Data_event[dvDEVICE]
{
STRING:
{
GET_BUFFER_CHAR(buffer)
GET_BUFFER_CHAR(buffer)
GET_BUFFER_CHAR(buffer)
GET_BUFFER_CHAR(buffer)
GET_BUFFER_CHAR(buffer) //I don't care what these are just remove 'em
data_I_want[1] = GET_BUFFER_CHAR(buffer)
data_I_want[2] = GET_BUFFER_CHAR(buffer)
data_I_want[3] = GET_BUFFER_CHAR(buffer)
data_I_want[4] = GET_BUFFER_CHAR(buffer)
GET_BUFFER_CHAR(buffer) //more stuff I don't need
GET_BUFFER_CHAR(buffer)
more_data_I_want[1] = GET_BUFFER_CHAR(buffer)
more_data_I_want[2] = GET_BUFFER_CHAR(buffer)
etc

CLEAR_BUFFER buffer //do we like this here or not?
}
}

I think this is a bit too simplistic, and it's certainly seems to be spotty, and the event fires multiple times - usually twice. When I fire a string to it, it gets it right about 1 in 5 times (I'm doing a send_string 0 for each of the data elements).

Can anyone out there recommend a "good practice" for this kind of situation?

Many thanks

OP

Spire_Jeff

Spannertech wrote:

I have a question about receiving and parsing strings of varying length, with no defined end character. I don't believe I can do much with a WHILE in the STRING event because I don't have a known finishing condition. OP

I hesitate to recommend any procedure without knowing a little more info. Are you searching for a known response? Is there a beginning indication? Do you have any documentation on the device you could post?

Jeff

Spannertech

The first two bytes will always be the same for all lengths of strings as far as I can tell (I'm doing some reverse engineering here...). I need to extract individual bytes as they contain numerical data which I have to manipulate. I think it would be the wrong approach to just do fixed string matching. I can see this would work if I had a few known different strings to deal with, but these numbers will be all over the place and I couldn't possibly do a if(FIND_STRING) for every possibility.

OP

Chip Moody

Oliver, you might want to do a google search on "ipod protocol".

There are a couple of sites that have already reverse engineered the protocol fairly well. You'll find that after the two header bytes, the following one or three bytes indicate the length of the packet. I haven't seen any instances where the three-byte length comes up, so you can probably get away with just checking the first byte. If you have three bytes in your buffer, and the first two are the headers, you can now tell how many bytes to either wait for OR pop out of the buffer if they're already there...

Extra hint - if the first byte after the header is a 0, you can probably ignore the rest of that packet. Pop off the header and wait until the next time you see it come in. And whenever you >do< find a header in the buffer, if they're NOT the first two bytes, delete everything preceeding them!

Are you using Zemma's interface?

- Chip