Hi Matt,
2010/7/7 mattschinkel <[email protected]> > Hey Seb... So are you are suggesting this, so the flush_packet > procedure must run between each packet? > No, I suggest something like that (assuming packet length is max. 10 bytes) for 10 loop -- loop through all bytes in packet slip_send_data(5) -- send each byte via serial port end loop -- when reaching the end of this loop, 10 bytes were sent, -- so SLIP library (slip_send_data) knows it must append a EOF char (SLIP END char) >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 If a specific condition is met, packet is sent earlier and doesn't have 10 bytes, but only X bytes. > start_packet and end_packet packet seems a bit more readable and user > friendly. Some people may ask "what does FLUSH mean?" > Sure, but I may also ask "why do I need to start and end a packet if I already told packet should be 10 bytes long ?" :) > > I am not sure about the tx/rx array feature. Maybe I should just > remove both of those procedures? I'm sure a user would be able to do > it. > RX array seems to be important as you need to "cache" received char. How would do you another way ? If packets are flushed before prematurely, it may be useful to store current packet lenght. Or does count() will work ? Some more ideas/review: About slip_serial_data_available, you could also enable to register a callback: alias slip_when_packet_received is my_user_callback In the receive procedure, when you match a SLIP END char, you call slip_when_packet_received if defined. This would allow non-blocking calls and avoid this: while slip_serial_data_available loop end loop Finally, you should (optionally) let users define their own data carrier (slip_serial_data_available and slip_serial_data aliases), if they want to use something different than serial hardware or software. For instance, usb_serial: alias slip_serial_data is usb_serial_data alias slip_serial_data_available is usb_cdc_rx_avail -- is that this function ? When using pseudo-var interface (usb_serial_data'get, serial_hw_data'get, serial_sw_data'get, ...), funtions already block until chars are received. Do you really need to have slip_serial_data_available ? And actually, I wasn't able to find serial_sw_data_available in serial_software.jal, did I miss something ? About these "*_available" functions, I have exactly the same problem with Firmata implementation. I'm defining a firmata_carrier pointing to serial_sw, serial_hw, usb_serial, etc... but I somewhere need to try to read one char, and if not available, continue (non-blocking). Maybe we could add a "*_available()" to our carrier interface: - *_data'get() to read char (blocking) - *_data'put() to write char - *_data_available() to check if... well data is available :) This way, we can: if *_data_available(): char = *_data end if (and aliasing *_read() functions seems like a duplication of *_data'get() to me) Any thoughts about this ? 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.
