#POPCHAR SERIAL CODE#
You need to understand that the code looking 'at' the received data, needs to be checking and processing this as soon as a string arrives, not delaying and relying on a buffer. I'd suspect your problem really is how your code is written. All delays are done using countdown timers, and the code is continuously looping checking the incoming buffers for each device. I'm currently using a PIC handling USB MSD, bluetooth, I2C, SPI, three serials, etc., and not one character has been lost at 57600bps, with buffers at just 64 bytes. The key is how fast your code is then at handling what is in this string. The string you show is under 20 characters long. Now honestly why do you think you need such size?. Also be aware that the standard code only handles 256bytes max. If using SISR, make sure you either use binary buffer sizes (2,4,8,16 etc.), or make the changes published here to the overflow handling. So use EX_SISR, and get rid of 'RECEIVE_BUFFER=xx', and 'DISABLE_INTS', or get rid of EX_SISR, and just use RECEIVE_BUFFER=xx. The other use, is if you are using direct writing to the UART, in some parts of your code, while also using interrupt driven I/O at other times.
#POPCHAR SERIAL SOFTWARE#
_Either_ let the compiler handle the receive buffer _or_ do it yourself with INT_RDA (there are advantages to the latter, especially if the buffer overflows).ĭISABLE_INTS, is designed primarily to stop bytes being corrupted when using the software serial. It will then call your own INT_RDA if present, but the byte will already have been read, so this will not work properly. This is then called when INT_RDA triggers.
If you use the 'RECEIVE_BUFFER=512' syntax, the compiler sets up it's own interrupt handler. While (packet_length-) checkbyte ^= *packet++ If (packet_length > (MSGSIZE-1) ) packet_length = MSGSIZE-1 Calculate checksum byte for the string 'packet' using the exclusive OR methodĬhar XorChecksum( char *packet, byte packet_length ) P->index = (p->index+1) & (MSGSIZE-1) // Assumes MSGSIZE is a power of 2.ĬalcSum = XorChecksum( m->ch, m->index - 1 ) For testing purposes you may want to leave it off until you're satifiedįor example, to send the string in your post, the message would look like this: It does provide better error detection than The checksum is optional, you don't have to use it. It's the only character of the message that is not strictly an ASCII character. Following the ETX character, is a checksum byte for the entire message. Each message is terminated with an End Character, ETX (0x03).Ĥ. Each message begins with a Start Character, STX (0x02).ģ. All message bytes are ASCII characters.Ģ. I didn't include IsValidChecksum() and AddToBuf() because I they are specific to the messageįormat I use. I can just comment out the IsValidCheckSum at the moment, but that still leaves AddToBuf. I have set up a test program with the code you put in your post, but AddToBuf and IsValidChecksum are missing, so I can't compile and try it. Sometimes it arrives as sent, but most times it is corrupted either with bad characters or bits missing off the end. I am trying to receive a line of comma delimited text, such as I have tried altering the buffer size but to no avail. What I have at the moment is the same as ex_sisr, if I remove the RECEIVE_BUFFER from the #use line. I will need to do some studying of your replies! Reason: See Jeremiah's warning at the end of this thread about the He is attempting to combine two separate methods of doing a receive buffer: I have used the CCS ex_sisr.c on the 46K22 at 100KB without any problems using BOTH HW UARTs. Please post your complete 'test program'. So at the very least the incoing data isn't being stored where I think it should be. Seems to suggest that the data will be stored in a buffer called 'RECEIVE_BUFFER' Real hard to figure out without seeing the complete program but. I think you are doing too much in your ISR. I don't see where RCV_BUFFER_3 is declared, so I can't say why the warning.
When the pl2303 locks up, only unplugging it and then plugging it back in again clears the problem and you can continue! I have read the help and it appears I need to do something to get rid of this warning, but I know not what! This definitely helps but I get a warning from the compiler (5.05d) : #use rs232(baud=9600,UART1,ERRORS,DISABLE_INTS,RECEIVE_BUFFER=512,stream=rpi) I have found that declaring a receive buffer is helping to stop random lockups when receiving data and so I have the line
#POPCHAR SERIAL SERIAL#
I am using the h/w uart uart1 on my 18LF4620 to receive data from a Raspberry Pi computer, at 9600Bd, using a pl2303 USB to serial converter. Please do not post bug reports on this forum. FAQ Forum Help Official CCS Support Search Register Profile Log in to check your private messages Log inĬCS does not monitor this forum on a regular basis.
0 kommentar(er)
