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

[REBOL] Re: Automation, Robotics?

From: dlhawley:home at: 13-Mar-2001 22:52

Previously, you (Sharriff Aina) wrote:
> Sounds like the direction that Im trying to get into, I would > appreciate it , naturally if youve got the time, if you could > explain the basic steps I would need to take in controlling > devices over the serial port on a 80x86 processor( hardware and > software)
REBOL makes serial port control pretty easy. You open a serial port and get a port which you can read, write and wait on. There are some funny design decisions, but I think that they make sense. Here's some code snippits: path: serial-path-to/options lcd 19200 path == serial://port2/19200/none/8/1 fp: open/mode path [ direct write read binary no-wait ] serial-path-to is: serial-path-to: func [ 'name ; port name ser1, com1, ... /options opts ; baud setting options in REBOL open fmt /loc number ] [ either number: find system/ports/serial name [ number: index? number ][ append system/ports/serial name number: length? system/ports/serial ] ; Append opts or default (redundant) either options [opts: join "/" opts] [ opts: "/9600/none/8/1" ] ; this was the hard statement for me to figure out join serial://port rejoin [ number opts ] ] REBOL (still exp versions) puts the port names in: system/ports/serial The defaults are [ ser0 ser1 ] which will be useless in most cases. In QNX, ports are in /dev and are typically names ser1, ser2 ... In the MS world they are com1 and so on. So the first thing that one needs to do is replace system/ports/serial with valid OS names without the /dev prefix. In my box, I make symbolic links to ser1 and ser2 to lcd and cbr - hence the lcd in the first code line above. Although striping the /dev prefix is somewhat handy it at first seemed limiting in QNX where a serial port on another node has a node number or name in front of /dev. ie: //4/dev/ser5 refers to serial port 5 on node 4 and can be opened accross the net just like /dev/ser1 on whatever the local node is. Fortunately, QNX allow one to symbolic link (prefix) a remote node into the local namespace. One could thus prefix //4/dev/ser5 -> /dev/ser4.5 and open ser4.5 using REBOL - so REBOL does not to be QNX net aware to benefit. The crazy thing that REBOL does is make you open the port with a path name serial://port[N] where N is the index? of the port name in system/ports/serial. Thus in serial-path-to above, I find the index? or append the passed name and use the length? to get port[N]. Of course, REBOL then has to change this back into an open( "/dev/serX", ..) so to me it would make sense to use the port name instead of index. To set baud, parity, stop bits one just appends resonable values to the port path so an open could look like: fp: serial://port3/2400/odd/7/2 and REBOL would figure out that you want 2400 baud, 7 data bits, even parity and 2 stop bits. I don't think that REBOL provides a mechanisim to change the option after an open. This does bring up a buglett in QNX4 and QNX RTP - the open parameters are not correctly set. To solve this, I call the stty command after the open so that the baud and so on are correct. At least the port has internal attributes of speed, parity, data-bits and stop-bits which make the stty command trivial to build. I currently execute stty in core by writing the command "stty baud=xxx ..." to a fifo (named pipe) which has a shell script on the other end. This scriptsimply executes whatever command is fed to it. OK, you have a port, now what? Well it behaves pretty much like a socket so you can read, write and wait on it. I have an event loop that looks like this: loop: func [ /loc ok pd ] [ ok: 1 while [ ok ][ pd: eval-rules ; do something on every pass wait [ pd lcd/fp ] ; wait for a timeout or lcd key press ok: not-equal? 'A pick lcd/fp 1 ; get pressed key. ] ] OK, I don't have the keypad doing anything cool yet. If your device returns lines of data, then you'd probably open the port with something like: cbr/fp: open/mode/with serial://port4/9600/none [ direct write read no-wait lines ] "^M" The cbr port device returns strings of data terminated with ^M in response to a command. I have a function which sends a command, waits for a response and returns whatever the device sent back minus some prefix. The read removes the ^M. It's all pretty slick and with any luck would work on a MS OS if I used com[N} type names. read-check: func [ cmd prefix /loc data] [ insert fp cmd ; write command to the serial port wait timeout ; wait for a response data: first fp ; get line of data return find/match data prefix ; return stuff after prefix ]
> >I'm working on a prototype home data acquisition/control device. It > currently runs on a 486 class SBC onder QNX but only because I don't > Previously, you ([Sharriff--Aina--med-iq--de]) wrote: > > > > Hi guys! > > > > Anyone with experience in robotics or microcontrollers in REBOL? > > > > -- > David L. Hawley D.L. Hawley and Associates 1.503.274.2242 > Software Engineer [David--L--Hawley--computer--org] > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.< > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes. >
-- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]