headers
Michael Hansen | 8 Oct 2005 03:55
Picon

off-topic: Poking the parallel port

Sorry for the off-topic post, but there appears to be no list for user discussion yet...

Mr. Fjeld's presentation slides from June of last year indicate that "Poking the parallel
port should be easy!"  Would anyone be willing to share some code which illustrates
a trivial case? I haven't used anything which is less abstract than Scheme since the
early 1990's and I know little about the entrails of x86 hardware.  I am growing
comfortable with the differences between Scheme and Lisp, but I don't even know
where to start on this problem.

Specifically, I want to be able to toggle and latch the state of four outputs on an x86
parallel port under Movitz.  I have been told it is going to be more complicated than
just fiddling with the memory map as might be done with BASIC on a DOS box, since
Movitz (Muerte?) runs in protected-mode.


Why? What am I doing?

I'm taking an old PC motherboard, 64 MB RAM, a floppy drive, a convoluted mess of
DC-DC converters, a big 12V battery, a pair of DC gear-head motors, a pair of H-bridge
motor controllers, a homebrew parallel port break-out box with buffers and optocouplers,
attaching it all to some pieces of sheet metal, and trying to teach myself something
about mobile robot navigation.

I would eventually like to learn about peeking at some parallel port inputs so I can add
motor-shaft encoders and collision sensors.  It would also be nice to point the REPL
at a serial port so I can interact with the machine using an RF modem or a dragged cable,
but for now, I would be very grateful to simply know how I can control the motors.

Thanks,
-Mike Hansen

<div><p>Sorry for the off-topic post, but there appears to be no list for user discussion yet...<br><br clear="all">Mr. Fjeld's presentation slides from June of last year indicate that "Poking the parallel<br>
port should be easy!"&nbsp; Would anyone be willing to share some code which illustrates<br>
a trivial case? I haven't used anything which is less abstract than Scheme since the<br>
early 1990's and I know little about the entrails of x86 hardware.&nbsp; I am growing<br>
comfortable with the differences between Scheme and Lisp, but I don't even know<br>
where to start on this problem.<br><br>
Specifically, I want to be able to toggle and latch the state of four outputs on an x86<br>
parallel port under Movitz.&nbsp; I have been told it is going to be more complicated than<br>
just fiddling with the memory map as might be done with BASIC on a DOS box, since<br>
Movitz (Muerte?) runs in protected-mode.<br><br><br>
Why? What am I doing?<br><br>
I'm taking an old PC motherboard, 64 MB RAM, a floppy drive, a convoluted mess of<br>
DC-DC converters, a big 12V battery, a pair of DC gear-head motors, a pair of H-bridge<br>
motor controllers, a homebrew parallel port break-out box with buffers and optocouplers,<br>
attaching it all to some pieces of sheet metal, and trying to teach myself something<br>
about mobile robot navigation.<br><br>
I would eventually like to learn about peeking at some parallel port inputs so I can add<br>
motor-shaft encoders and collision sensors.&nbsp; It would also be nice to point the REPL<br>
at a serial port so I can interact with the machine using an RF modem or a dragged cable,<br>
but for now, I would be very grateful to simply know how I can control the motors.<br><br>
Thanks,<br>
-Mike Hansen<br></p></div>
Permalink | Reply | 1 comment |
headers
Frode Vatvedt Fjeld | 9 Oct 2005 00:31
Picon
Picon
Favicon

Re: off-topic: Poking the parallel port

Michael Hansen <mmhansen <at> gmail.com> writes:

> Specifically, I want to be able to toggle and latch the state of
> four outputs on an x86 parallel port under Movitz. I have been told
> it is going to be more complicated than just fiddling with the
> memory map as might be done with BASIC on a DOS box, since Movitz
> (Muerte?) runs in protected-mode.

I don't think anything is complicated by Movitz running in protected
mode. (Perhaps whomever you talked to were thinking about the
kernel/user-space protection in typical kernels?) You can easily
fiddle with the parallell port under Movitz by saying things like

  (setf (io-port <io-base> :unsigned-byte8) <bits>)

interactively or in a compiled function or whatnot. I don't remember
off-hand the exact details of how one interfaces the PC parallell
port, but I seem to remember that there are about eight pins that can
be controlled in the obvious way by writing to a certain (byte)
I/O-port. The exact details should be easily available on the web or
from one of the books on PC hardware programming.

Don't hesitate to ask more specific questions here if you run into
problems.

--

-- 
Frode Vatvedt Fjeld
Permalink | Reply | 0 comments |
headers
Shawn Betts | 24 Oct 2005 08:27
Picon
Favicon

yield stuff in threads.lisp

Hi Frode,

could you give an explanation of the yield stuff in the threads.lisp
file? Is that what needs to be called to "stop" a thread?

-Shawn
Permalink | Reply | 2 comments |
headers
Frode Vatvedt Fjeld | 24 Oct 2005 21:43
Picon
Picon
Favicon

Re: yield stuff in threads.lisp

Shawn Betts <sabetts <at> vcn.bc.ca> writes:

> could you give an explanation of the yield stuff in the threads.lisp
> file? Is that what needs to be called to "stop" a thread?

I suppose it's described more accurately as "starting" another
thread. I.e. the thread that calls yield is suspended, and the thread
that is passed as argument to yield is resumed.

You can even do this interactively, i.e. someting like

  (setf *t1*) (current-run-time-context))
  (setf *t2* (make-instance 'threading:thread))
  (threading:yield *t2*)

    [now you're in t2.. try e.g a backtrace]

  (threading:yield *t1*)

    [now you're back to the context of the first yield.. i.e. it'll be
     just as if the first call to yield just returned.]

Execpt, of course, right now there are some lingering bugs that
prevents this from working. I'll try to have it fixed this evening.

--

-- 
Frode Vatvedt Fjeld
Permalink | Reply | 1 comment |
headers
Frode Vatvedt Fjeld | 31 Oct 2005 11:01
Picon
Picon
Favicon

Re: yield stuff in threads.lisp

So, the SO is visiting the dentist, the little brat has been sleeping
for an hour or two, and I've allowed myself half a day off from
working on the new house, and jupiter and mars are properly aligned
with the moon, etc..  so I've been able to work an hour or so on
movitz' threading:

It turned out the problem wasn't really related to the threads as
such, rather it was the REPL and readling code that didn't respond so
well to the default environment that a fresh thread gets set up
with. Now I've debugged and robustified this code somewhat, and this
should make testing threading:yield etc. work ok.

Here's an illustrative screenshot from a bochs session, with
line-numbers added for references below:

                           
 1  INIT> :pa threading
 2  THREADING> (+ 35 7)
 3  #x2a
 4  THREADING> (yield (make-instance 'thread))
 5  [0d] INIT> *
 6  NIL
 7  [0d] INIT> :bt
 8   <1 (THREADING::STACK-BOOTSTRAPPER ...)
 9  [0d] INIT> (/ 17 2)
10  #x11/2
11  [0d] INIT> (setf *t2* (current-run-time-context))
12  #<THREAD   <at>  #xf0176>
13  [0d] INIT> (setf *t1* (%lispval-object 6))
14  #<RUN-TIME-CONTEXT :INIT  <at>  #x6>
15  [0d] INIT> (yield *t1*)
16  NIL
17  THREADING> *
18  NIL
19  THREADING> ***
20  #x2a
21  THREADING> (yield init::*t2*)
22  NIL
23  [0d] INIT> ***
24  #x11/2
25  [0d] INIT>

Line 4 is the most interesting one: It first makes a new thread, and
immediately switches control to it. Line 5 is from inside this new
thread, and you can see e.g. that it's getting a default *package*
bound to the INIT package. In line 7 a (short) stack backtrace is
printed for the new thread.  In line 11 the variable *t2* is set to
the new thread object (i.e. the object returned by make-instance in
line 4), which is available through the current-run-time-context
operator which returns the run-time-context that is currently
active. Note that a the threading:thread class is a specialization of
the muerte:run-time-context class. In line 13 the variable *t1* is set
to the initial boot-up "thread", which is not a threading:thread but
just a mere muerte:run-time-context instance. This object is always at
located at the very start of the address-space under the current
image-dumping scheme for LOS0. (6 is the low-tag for such objects.)

In line 15 control is switched back to the original "thread". Line 16
is actually the print-out of the return-value of the functon-call in
line 4. (Note that the yield at line 15 would accept an optional
second argument that would be this return-value.) Line 19 shows that
the *** variable of the initial thread is bound to the value from line
3, and that none of the goings-on in the other thread (lines 5-15)
affected such local bindings. In line 21 control is once more switch
back to the new thread, and we see that there are indeed two separate
environments.

Beware that GC is unlikely to behave robustly in the presence of
multiple thread objects yet (I'm not really sure, but I can't remember
working much on it, so..)

--

-- 
Frode Vatvedt Fjeld
Permalink | Reply | 0 comments |

Gmane