> From a user perspective, you don't care and don't even know you need to > start or end a packet. But... sometimes you need to explicit. Use case could > be: > > for 10 loop > if condition == true then > slip_send_data(100) > slip_flush() > exit loop > end if > slip_send_data(5) > end loop
Ok, so you would like an "optional" end packet procedure. Instead of slip_flush(), I can still name it slip_end_packet(), but the user does not need to use it as long as they send a full packet. Sorry, I still don't like to flush :þ > RX array seems to be important as you need to "cache" received char. How > would do you another way ? Use a queue. Well, actually 2. One to store all packet data, and the other to store lengths of the packets that are in the first queue (you will need to cache more then one packet so you don't miss any). Data should be collected in this queue via a interrupt at each byte. I will make a serial hardware ISR, then a SLIP ISR. I am trying to match this lib with serial port functionality, but the serial port it's self has problems. What I have written so far is for basic usage. The serial port libs have blocking waits for data, this one currently does also. > About slip_serial_data_available, you could also enable to register a > callback: you would have to continuously poll for data then get each byte, then do the call back at the end of the packet. If it is non-blocking, the user may not pick up data quick enough and could miss data? Should I make a poll as well as an ISR? > Finally, you should (optionally) let users define their own data carrier Sure, I was wondering about this. > alias slip_serial_data_available is usb_cdc_rx_avail -- is that this > function ? If so, it should be renamed or aliased to match the others. > When using pseudo-var interface > (usb_serial_data'get, serial_hw_data'get, serial_sw_data'get, ...), funtions > already block until chars are received. I'll remove it. I didn't know, thanks. Here are some issues I have with serial ports that relate to this lib. 1. The blocking delays and monitoring data while receiving data. - I'll use an interrupt (serial_hw only), maybe usb? and a Queue for the data, as I said before. 2. Serial software will not do interrupts when receiving data. - I would have to use a timer interrupt to monitor for data and use a Queue for the data. I don't like the different usage, or having to use a timer. Other general serial port stuff I don't like. 3. Serial software contains many blocking delays for timing bits. Should another method be looked at? I'm sure it is too difficult. - Serial hardware should be used instead? I am going to try this SLIP thing on wireless, 9600 baud is quite blocking on serial sw. 4. I guess serial hardware must be blocking as well for sending data at 9600 baud. - data should go into a queue, then shifted out. but again, I guess this needs a timer to monitor the queue and PIC tx register state 5. PC's and other devices all use queues for serial data, PICs and our libs can only do 1 byte at a time. If I don't pick up data fast enough, will it get lost? Matt -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
