Hey guys, I have added a poll sample and an isr sample. Seb, I did it with your suggestions. max packet size is currently 256 (same as queue lib). Joep please add 4 more queues, I'll take a look at making a large queue lib.
I did not find the cts lib useful since I don't use the cts line (that is the point of slip, no cts!), but maybe you can explain what other benefits of the cts lib has (I may not understand). The poll sample I uploaded works ok as long as a 2nd packet does not come in before you finish reading the first. The ISR sample works perfect. Matt. On Jul 9, 4:26 am, Sebastien Lelong <[email protected]> wrote: > Hi Matt, > > 2010/7/9 mattschinkel <[email protected]> > > > > > 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 :þ > > OK. You're right, slip_end_packet() is more what it would do than flush. > Re-reading SLIP specs, your SLIP_MAX_PACKET_SIZE is actually MTU, Maximum > Transfer Unit. Maybe it should be rename SLIP_MTU to match network protocol > vocabulary/wordings. > > (also note there's no standard MTU, though 1006 seems to be the standard. > If, on the PC side, SLIP MTU can't be configured, packets will quite big :)) > > > > > > 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. > > OK, array or queue, but cache anyway. > > > > > > 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. > > I'm only considering the user point of view, not the coder's or library's. > In your sample, code is using slip_serial_data_available and check the end > of the packet. This should IMO clearly the responsibility of the library, > user shouldn't have to deal with this kind of details (this is what SLIP > does behind the scene). If you can register a callback, or if you could just > pool a "slip_packet_finished", your sample code would look like: > > -- callback > procedure mycallback() is > -- slip_packet is a global var in slip library storing received payload > var byte i > for count(slip_packet) using i loop > lcd = slip_packet[i] > end loop > end procedure > > -- slip library will call slip_when_packet_finished when a complete packet > -- is received (if slip_when_packet_finished is defined) > alias slip_when_packet_finished is mycallback > > forever loop > -- you just wait the library to call your own callback > -- do other things > end loop > > -- poll packet finished > foreverloop > if slip_packet_finished == true > mycallback() > end if > -- do other things > end loop > > HIH > Cheers, > Seb -- 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.
