Event Handler for Serial Comm...
sonny
Posts: 208
Greetings...
Working on a serial driver for the Harman Kardon AVR630. This device streams data continuously at 38400 and I don't seem to be able to capture it all on an NI3000. I get partial packets. I can capture the full packets on a PC.
My question is what is the model for which the 3000 OS calls the event handler? These packets are fixed length but don't have terminating characters on them. Is the handler called on the buffer being full in this case, byte by byte, etc.?
Thanks for any help.
Working on a serial driver for the Harman Kardon AVR630. This device streams data continuously at 38400 and I don't seem to be able to capture it all on an NI3000. I get partial packets. I can capture the full packets on a PC.
My question is what is the model for which the 3000 OS calls the event handler? These packets are fixed length but don't have terminating characters on them. Is the handler called on the buffer being full in this case, byte by byte, etc.?
Thanks for any help.
0
Comments
I almost always buffer serial data myself. When there is a known teminating character, it's pretty easy - just use CREATE_BUFFER and use your STRING event to trigger a parse. Then you can just use REMOVE_STRING on your buffer with the terminating character as a parameter, and you have your packet, even if it came in incomplete chunks.
In cases like you have, it's a bit trickier, but it comes down to much the same thing. Buffer your incoming data, but do a character-by-character operation on it to interpret your data. I assume there is a start bit - you have to check for that to begin your parse, and clear any partial data that might be in the buffer before it arrived. then you can count the characters coming in after to build your complete packet. In both cases, you need to make sure you remove the data from your buffer so it doesn't overflow, and also make sure it is big enough to hold whatever comes in while data is being processed. If it is truly streaming continuously, you might need to enable handshaking so you can pause it to catch up. I've found with this kind of data flow that using the STRING event is simply not adequate, and even checking your buffer in mainline can be too slow. So what I do is simply test for string length in the buffer in mainline and call my parse function...then have the parse function call itself at the end if there is more data in the buffer. You will want to flag the parse function with a variable you can see in mainline, so that the mainline call doesn't happen if the parse function is iterating already. Then your test at the end of the parse function can reset this variable if there is no more data in the buffer, but recurse if there is, and the mainline call only happens when there is data but the parse function is already inactive.
I can use a serial capture program on a pc and see that all of the data is being transmitted.
Needless to say, the Harman documentation is crap and they don't provide support. It is beyond comprehension why these companies take the time and money to put serial ports on their products, then provide pathetic documentation and support. Also, why a programmer would spit out the same data continuously is hokey as well.
need to do an avr7300 in a system soon, just saw the lovely RS232 document emailed from HK.
I see this thread is older, I did a search to find it, was there any success with the HK protocol?
I had none...I (gag) had to go with IR. Doing a project with the Denon AVR-3805 right now and it's serial protocol works like a champ. If the client doesn't already own the HK I would try to get them to switch to something better controlled.
BTW...Harman's support department will tell you to not bother calling them, they refuse to answer any questions.
Thanks for the heads up on HK tech support. I will call anyway.