Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Help with serial port

 [1/12] from: parki:whatevernot at: 30-Aug-2003 10:27


I am trying to control my X.10 devices on my Mac OS X box from Rebol (which would be cool to the max :-). I am also a relative Rebol newbie, but loving the experience - very fun. Anyways, I know the /dev/tty port that I am interested in (I have determined that this works fine with a Mac OS X app called HomeRun). This is USA19QI14P1.1. Note that I am using a USB->serial port adaptor, but I know this all works (as I can turn lights on and off with HomeRun). Now, when I look in /dev, there are actually two references to USA19QI14P1.1: /dev/tty.USA19QI14P1.1 /dev/cu.USA19QI14P1.1 My understanding is thatthe /dev/tty.* port is the one to use (and that the /dev/cu.* ports are outdated). So, I try:
>> system/ports/serial: [tty.USA19QI14P1.1]
== [tty.USA19QI14P1.1]
>> p: open serial://port1/4800/8/none/1
This hangs - it never returns from the open command. So, I try:
>> system/ports/serial: [cu.USA19QI14P1.1]
== [cu.USA19QI14P1.1]
>> p: open serial://port1/4800/8/none/1
This works - I get a return value for p. I know that I need to set the X.10 protocol to no handshaking, so: p/rts-cts: false Now, the protocol for X.10 is pretty simple - I want to send down two bytes 0x06 and 0x61, and the device should respond with a checksum. I am a little unsure how to send down exactly two bytes (with no line feed or other bytes). So I try (where 0x06 = #"^F" and 0x61 = #"a"): insert p [ #"^F" #"a" ] When I send these, I can see a flicker on the USD->serial adaptor LED, so something is definitely happening. Once these bytes are sent, I expect to get a checksum byte back from the device, so I try: d: copy p But this hangs. I am completely stumped - everything seems to be kinda working, but I cannot get any data back from the X.10 device. Any help would be appreciated. parki...

 [2/12] from: brett::codeconscious::com at: 31-Aug-2003 0:40


Have you tried some of the refinements of the Open function? Eg. open/direct Brett,

 [3/12] from: parki:whatevernot at: 30-Aug-2003 14:17


Nope - truth is never occurred to me (!). New to Rebol and all. Thanks for the suggestion - I'll try a bunch of combinations. Looks like /binary, /direct and /no-wait might all apply here. Cheers, parki... --- x8 snip On Saturday, August 30, 2003, at 10:40 AM, Brett Handley wrote:

 [4/12] from: parki:whatevernot at: 30-Aug-2003 14:53


With some playing around, I have been able to get some data sent to the serial port, and a response from the X.10 controller. I am stumped now on being able to send a single 0 byte (?). Basically, I need to send down 0x06 0x61 to the X.10 controller, and it responds with a checksum (0x67) in response. I then send down one 0x00 byte instructing it to actually execute the command (turn on all lights), to which it responds with 0x55. The script (so far): ; I know that USA19QI14P1.1 controls the X.10 device system/ports/serial: [ cu.USA19QI13P1.1 cu.USA19QI14P1.1 ] ; Open the connection to the serial port serial-port: open/binary/direct/no-wait serial://port2/4800/8/none/1 serial-port/rts-cts: false update serial-port insert serial-port #{0661} At this point, I can read the response from the X.10 controller:
>> probe copy serial-port
#{67} Which is what we expect. So communications with the X.10 device certainly work. The next step is to send down one byte (0x00) and receive the response (0x55).
>> insert serial-port #{00} >> probe copy serial-port
#{} == #{} Not the 0x55 as expected. I am wonderfully stumped. The only conjecture that I have right now is that Rebol sends everything down the serial as two-byte words, and that "insert serial-port #{00}" really sends down 0x0000 (16 bits) which somehow upsets the X.10 device. Any idas? Progress certainly being made... Thanks, parki... On Saturday, August 30, 2003, at 10:40 AM, Brett Handley wrote:

 [5/12] from: tomc:darkwing:uoregon at: 30-Aug-2003 13:35


have you tried sending #"^@" ? On Sat, 30 Aug 2003, Brian Parkinson wrote:

 [6/12] from: parki:whatevernot at: 30-Aug-2003 16:51


On Saturday, August 30, 2003, at 04:35 PM, Tom Conlin wrote:
> have you tried sending #"^@" ?
Just tried this - doesn't work. parki...

 [7/12] from: brett:codeconscious at: 31-Aug-2003 11:52


Perhaps you need to check whether or not you really need the /no-wait on the open. I'm not entirely sure, but if you are using /no-wait then might need to use Wait on the port, in order to wait for the device to give you a response. Or perhaps the serial port settings are not quite right? Brett.

 [8/12] from: g:santilli:tiscalinet:it at: 31-Aug-2003 10:58


Hi Brian, On Saturday, August 30, 2003, 8:53:39 PM, you wrote: BP> >> insert serial-port #{00} BP> >> probe copy serial-port BP> #{} BP> == #{} This is just a guess, but if your device is taking some time to answer, you might not get the result soon enough. Try with: insert serial-port #{00} wait serial-port copy serial-port BP> The only conjecture BP> that I have right now is that Rebol sends everything down the serial as BP> two-byte words, and that "insert serial-port #{00}" really sends down BP> 0x0000 (16 bits) which somehow upsets the X.10 device. I don't think so, unless there's a bug in REBOL on MacOS X. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [9/12] from: parki:whatevernot at: 31-Aug-2003 6:37


> Hi Brian, > On Saturday, August 30, 2003, 8:53:39 PM, you wrote:
<<quoted lines omitted: 7>>
> wait serial-port > copy serial-port
Tried this - doesn't work (hangs on the wait statement). The device is pretty speedy on reply.
> BP> The only conjecture > BP> that I have right now is that Rebol sends everything down the
<<quoted lines omitted: 3>>
> BP> 0x0000 (16 bits) which somehow upsets the X.10 device. > I don't think so, unless there's a bug in REBOL on MacOS X.
Seems unlikely, but grasping at straws. parki...

 [10/12] from: parki:whatevernot at: 31-Aug-2003 18:47


Serial problem solved. Turns out that if I use 'open/binary/direct serial://port2/4800/8/none/1' and send down a command string, I don't see a reponse (the call hangs). So, I changed to 'open/binary/direct/no-wait serial://port2/4800/8/none/1' and while I got a reply back from the first (command) string, I was never able to get a reply from the execute string (the elusive 0x00). In a last ditch effort (which I perhaps should have thought of sooner) I put in a polling loop for the reply value, with a break when the "value not#{}" and lo and behold - it all works. I'll likely clean up the polling loop to sleep, but all is well. So, will be crufting up some Rebol utility scripts to control X.10 devices, which should be nice. Being new to Rebol, I have to gush - the code to control the X.10 device is clearly going to be wicked small, with no external libs needed (like Perl or Python). The more I use Rebol, the more I am impressed. Cheery days, parki...

 [11/12] from: maarten:vrijheid at: 1-Sep-2003 7:16


And reading this thread I understand even why: 'direct = use no buffering , 'no-wait = doesn't wait for data. When I write network code this works exactly the same (create a polling loop etc.) Nice to have consistency ;-) --Maarten

 [12/12] from: greggirwin:mindspring at: 1-Sep-2003 17:30


Hi Brian, BP> Being new to Rebol, I have to gush - the code to control the X.10 BP> device is clearly going to be wicked small, with no external libs BP> needed (like Perl or Python). The more I use Rebol, the more I am BP> impressed. And just think of the cool dialect you could put on top of it! :) -- Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted