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