Ruben, I am, in fact that underspecified crappy protocol is the cause of my=20 most common support call. (Finding the right endian setting for=20 multi-register values, etc) It's an incredible pain in the ... =20 It's also not avoidable in my niche. Luckily, most devices are more lenient than the spec is on timing. What's the saying? Accept widely, but perform narrowly? I can't=20 recall. Essentially, tolerate poorly behaving external systems but be=20 well behaved yourself. Again, if you've got a real reason for any given protocol... there's not=20 much you can do about it. If you're free to choose what to implement,=20 though, please rethink tight timing requirements if you don't actually=20 need them. Darron On 2/2/14, 4:29 PM, Ruben J=F6nsson wrote: >> If you're making a product, don't screw it all up with systems >> requirements from the 1990s. >> >> I will avoid any product if I can't run the user software or a >> development environment from a virtual machine. There's no excuse for >> that these days. >> >> >> Darron >> > So I guess you are not using Modbus over RS485 or RS232? Continuous > stream of data and 3.5 character silence to mark end of frame. > > /Ruben > > > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .