Re: [Emc-developers] EMC2 port to Beagle Board

[Jon E. <el...@pi...>]

Adam wrote:
> What does your physical interface look like? What are you hanging a parallel
> port off of?
>
> This may be entirely off-topic but what I'd love to see is a Mesa card with an
> Ethernet interface and RTnet support in HAL/EMC. 
>   
The Beagle has a 28-pin header with a scrambled bunch of GPIO pins.  It 
was a little tricky to find 8 contiguous bits plus the necessary control 
bits.  I was trying to make a driver emulate a PC parallel port with the 
minimum of bit packing, etc.  I made a board that stacks below the 
Beagle, and has a DB25 connector on it.  It can emulate a standard 
parallel port, bi-dir port, or EPP port, with only a couple lines of C 
code to shift the bits to the right fields.  I crashed the Linux OS a 
number of times before finding out what other GPIO pins in the same bank 
were used for other on-board functions.  I have to mask around the 
register bits to keep from interfering with those.

I make some boards for motion interfaces, a mix-and-match set for analog 
servo amps, and a single board that can be programmed either as a step 
pulse generator or a PWM pulse generator.  These all have digital I/O 
and encoder interfaces.  These are all controlled through an EPP 
parallel port, presenting a register interface to the PC.  So, the 
Universal PWM Controller has a DB25 on the board, the parallel port 
adapter plugs into that, and the Beagle stacks on top.

I looked at RTnet, and it looked like there was too much overhead to do 
what I wanted, which was to move the EMC servo interface to Ethernet.  
The computer has to send out a command to capture encoder position, 
receive encoder position, and then send out new velocity commands.  To 
do this all (3 packets) in a millisecond at the absolute maximum was 
already looking difficult, and running the servo loop faster than 1 KHz 
looked entirely impossible.


I have already verified that I can do an emulated EPP data cycle in 720 
ns (the Beagle's main chip has a multiplexed GPIO architecture, so each 
GPIO pin can only be updated every 240 ns, that's a real bummer).  But, 
720 ns is comparable to a PC EPP port cycle, so it isn't any worse, at 
least.  With trickier coding, I may be able to speed that up to 480 
ns/cycle.

I'm not at all sure I have answered your question.

Jon