On Sunday 04 January 2009, Stephen Wille Padnos wrote:
>Gene Heskett wrote:
>>[snip]
>>
>>>On the other hand you can do a lot with a embedded 32 bit processor in a
>>>FPGA (the ZPU for example uses about 20% of a 400K SP3, runs at ~ 100 MHz,
>>>is BSD licensed and has a GCC toolchain)
>>
>>Which again, sounds like a plus till you said 100mhz.  That might do for
>> servo driven machines but I'd guess it won't run steppers at usable speeds
>> will it?
>
>Apparently you missed the point that this is a processor embedded in an
>FPGA, so presumably you'd have the hardware needed for fast step
>generation, PWM, encoder counting, etc.
>
>- Steve
>
You are no doubt correct.  If the processor can keep up with the math, which 
might imply an fpu in there too, there should be enough pins to drive the 
hdwe.

>>[snip]
>>
>>If I was awake, its too late now for me, I might carve up a message to
>> lkml, and see if anyone has an idea of how much trouble it might be to
>> pretend a 4 core phenom is a 3 core chip, and hand the 4th core to rtai,
>> operating not in a sandbox cuz that would deny hdwe access, but I'd think
>> something along those lines could be put together, and probably without
>> major surgery to the core smp code linux now has.
>
>Linux and RTAI support isolated CPUsets.  You can tell Linux to not
>schedule process on certain cores, and then tell RTAI to bind processes
>to those cores.  EMC2 already does this by default when compiled on SMP
>machines, though you do need to supply the correct boot parameters to
>the kernel.

Its not been discussed on lkml (in a thread that got my attention), so I 
wasn't aware of how well developed that already was.  Thanks.

>In practice, I haven't seen a great improvement from simply going to a
>multi-core CPU.  I haven't tested every machine out there though, so who
>knows.

Which would imply a bus bandwidth bottleneck maybe?  I don't have a very good 
mental estimate of how many actual gates are between the cpu and a pin of the 
parport.  With the parport having fallen from favor, I can easily see that 
path getting slower and slower while others become more optimized to speed up 
the popular stuff.  That is just how things are.

Someone, maybe you, once made the comment that an accessory card for the 
parport was actually faster than the onboard.  Have any tests been made to 
somewhat define what the possible speedups might be? 10% isn't much, 400% 
would solve real problems I'd think.

I have a Rosewill dual port card I am going to put into my shop box to drive 
the lathe with when and if I get the lathe controllable, and I have the 3 
axis xylotex card I took from the mill when I made the rotary table drive for 
it & put a 4 axis xylotex on it.

But my lathe is so small I'd druther put that time & effort into a bigger one, 
something with 3 feet of bed and 1.75" or more of spindle bore.

>- Steve
>
>
>----------------------------------------------------------------------------
>-- _______________________________________________
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
What an author likes to write most is his signature on the back of a cheque.
                -- Brendan Francis

------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to