Re: Homebrew STG card - PAR-PORT

["Arne Chr. Jorgensen" <instel-at-online.no>]

On Sun, 05 Mar 2000, you wrote:
>"Arne Chr. Jorgensen" wrote:
>
>> But here you work back towards some of the initital stages of EMC, - I think.
>> You need dedicated controllers again.   To me it seems like this is an endless
>> battle -  use a normal PC or add dedicated controllers.
>>
>> Jon Elson suggested to wire up an expansion to the par-port,  and for a
>> "homebrew"  system - this may be the easiest way to go.  You don't need any
>> FPGA chip either,  just some simple buffers and logic.
>
>On the hardware side, this would be easy - I've already done most of the
>work, as I'm using this in about 5 different systems.

I am not sure if I understood everything you wrote, Jon.  I did like the idea
in a way,  but.... then I wrote about this KISS thing.  I never expected that
Paul would get all these orders in,  and I did find it a bit funny.  I thought
we would have some more debate on this.  Maybe that was the thing that worried
people :)  But I think this is very nice,  a lot of people focus on something
common and simple.  The main thing is to get support in order to get anything
going.  But back to these other issues:


Most of what has been said,  is a passive expansions.  The Realtime system,  is
just a small piece, not a full blown OS. The interpreter etc, resides in the
normal Linux space.  Any rt-module will just have a limited time window.  If
you use USB/Firewire or expand the par-port,  then the main cpu would just poll
the io.  You would have a hard time with interrupts etc.   Let say you wanted
many ADC, or let say a  key matrix.  It would be stupid to let the main cpu do
all the work,  more than half of the time this add on electronics would stay
passive.  So for many parts,  you would rather like to have some dedicated
controller to process things in the time window that the RTLinux would not use
the this bus.  You would also like registers that behave a little intelligent,
like queing interrupts etc.  You would like to have something that would flag
that an ADC has valid info ( it had enough time for conversion )  etc.  It
could be a simple controller,  but I think that you soon would want something
like this.  For USB etc, you need one anyway.  

I have made a few bus systems, and I can't say they was very successful. 
Sure it worked,  but it was a lot of work.  A lot of the cards I made, didn't
really get used much,  to write software would also be a lot of work.  I was
alone, - so I got a bit tired - but I had full control.  If you should have
many people working on this,  then you had to make a very good and documented
system.  Paul will have some of this problem,  if he starts adding on a lot of
stuff people would want.  Say more ADC, DACs,  IO pins,  interrupts.   That is
way I would just keep things at simple as possible.  These other add ons can
come later.  To plan the foundation for a new IO system,  - is not simple,  at
least when you want it to be used with a system that already works in certain
ways.  

Here is another comment:  I don't understand why people would like to have 8255
or 8254 chips to run steppers.  You could just add another printer card.  Or
just use some ordinary buffers.  These chips is not that nice ( IMO )  as
people often think. A 6821 or similar on the other hand,  can set any pin as
either an input or output,  then I would say there is a lot more value in it. 
Well, this was a side track :)
But you could use board with 8255 chips as a bridge to en extended io system.
That would make more sense.  

Well, I often say too much - and it is not always I make much sense :)

About DMA:
---------
I said something about this before.  Once I expanded a Z80 system with  it,
giving me a full 64Kb address space, and you could interlink say another
computer to run in paralell  ( could be a XT or AT),  and use all the ISA
slots you want. The IBM type,  Eproms for basic, and you could compile and burn
a few eproms with a RT system,  take out floppy, hardisks - the lot.  Just use
the board as an IO system.  You get these board for "free" today.  You could
also hack the keyboard an use that sybsystem.  It is also easy to hack some old
printer adapters, so you could fill it up for as many axis you like, or fill it
up with Paul's KISS cards.  

There is so many options, - the problem is to nail it down.

//ARNE

    




  

  



>On the Linux software side, it gets really tricky, as it takes 3 or 4 commands
>to the external I/O to select and communicate with a single register out on
>the ribbon cable.  The problem comes in if more than one program is talking
>to things on the adapter.  You either have to have a single (real-time) program
>serializing the stream of I/O going both ways, or you need a reserve/release
>mechanism to prevent one program from stepping on another's toes.
>
>But, this sort of setup is REALLY appealing, as you could have servo amps
>or stepper drivers that just plug in to the bus, and also have auxilliary control;
>pendants with touch screens, lighted push-buttons, jog dials and joysticks,
>remote position displays, you name it!
>
>The USB might solve some of the serial access concerns, as it has to
>serialize access to a serial bus and protocol, anyway.
>
>> The problem is to plan for some sort of an overall architecture.  This creates
>> so much trouble - that I guess the best thing would be to just keep things
>> stupid simple.  Any homebrew card that would have what STG boards have, will
>> not be cheap and simple,  no matter what you do.  (IMO, cheaper Yes, simple No)
>
>Well, if we agree to forcing the RT process to handle serializing access to
>the adapter (or adding another RT process to manage the adapter) then
>we get pretty much everything we need (and want)!
>
>The biggest advantage is that by essentially breaking up the servo card,
>and distributing it along a ribbon cable, you can mix and match things,
>and add extra devices as needed.  For instance, someone, somewhere
>will say that, no matter how much digital I/O we provide, they need more.
>So, just plug in another digital I/O card, and set it to an extra module address,
>and you've doubled the number of digital I/O bits.  Somebody needs 11
>axes? (!!)  Sure, just plug in however many axis cards are needed.
>(And, there's another question, should we have digital I/O for steppers,
>and analog output for servos, or should the stepper driver and servo
>amp cards just plug into the bus, one axis per card?  There is a noise
>question, here.)
>
>Jon