Martin Peach wrote:
Martin Peach wrote:
To control a servo, using 1200 baud, the numbers 0, 128, 192 and 224, 240 should position the servo roughly at 1/5 range steps. 240, 248, 252, 254 and 255 may be too short.
That should be 4800 baud for 9 bits of 1/4800 seconds giving 1.875ms for the widest pulse. 4500 baud would give a 2ms pulse. Currently [comport] doesn't accept arbitrary baud rates even though they should be possible on modern hardware. I'll try it and see... (Adding messages to control the RTS and DTR lines worked OK in linux, but screws up data transmission, data is sent at unpredictable times. Probably needs to be flushed. I still need to implement the Windows version of this. )
Today I put a new version of [comport] and comport-help.pd in cvs at http://pure-data.cvs.sourceforge.net/pure-data/externals/iem/comport/comport... Now you can set dtr and rts lines to control things, also read the dsr and cts lines. This doesn't interfere with serial data transmission unless cts/rts or dsr/dtr flow control is enabled as well. Here it works in winXP and linux at least. As far as servos go, jitter is worse using the control lines: while the start of a pulse can be fairly accurately timed (using metro) to ~0.3ms, the end occurs at x ms or x+5ms regardless of the audio latency. It should work for switching on a coffee maker or a light though, just connect dtr or rts to a solid state relay. I suppose a [comport~] object could use a signal inlet for some kind of trigger to send a message that was set up on another inlet...any suggestions?
Martin