subject:"Re\: \[Emc\-developers\] Raspberry Pi running EMC \?\?\?"

I've done some bit-bang timing measurements for the Raspberry GPIO pins

see 
http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062

I'm not saying the Pi has many cycles left at 220nS transition spacing, but the 
'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an order 
of magnitude faster than I ever got with a PC parport driven from a user 
process; interrupt latency is another issue but GPIO in this style doesnt use it

- Michael


Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/20/2012 9:11 AM, Kent A. Reed wrote:
 On a more serious note, as has been discussed on the two emc mail
 lists, the road to ARM is littered with ideas but so far we have
 little result.
 
 The nicely done miniEMC2 project by Sergey Kaydalov is the most
 complete effort I know of. It employed the higher-latency Xenomi
 code rather than RTAI. Inquiring minds want to know more about the
 possibility of porting this code or something like it to boards
 like the RPi or BB and about the resulting performance attainable.
 I wish I could have tackled this already but I've got too many
 family issues at the moment.
 
 I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
 my Pi when it comes in, but I'm not sure what sort of latencies to expect.
 
 On conventional PC hardware, I've gotten decent latency jitter with
 modern systems, but not yet down to the RTAI levels.  On older
 hardware latency with PREEMPT_RT is much worse, particularly on
 single-core systems (although I don't yet know if this is due to not
 having two cores to schedule between or because all my single-core
 systems are pretty ancient).
 
 I'm also hoping on the Arm it might be possible to use the fast IRQ
 and read/write the I/O pins in an ISR which may allow the servo thread
 to run with much higher jitter.
 
 Then there's the problem of gluing these boards to our CNC hardware
 about which I yield to Jon.
 
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would probably
 make things much easier.  I'll evaluate that option once I see where I
 get with software stepgen.
 
 - -- 
 Charles Steinkuehler
 char...@steinkuehler.net
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
 zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
 =Dmby
 -END PGP SIGNATURE-
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-09-08 Thread Kenneth Lerman

Michael,

I took a quick look at the code and am wondering why there is a call to
delay within the loop. The delay function is called with a value of n
(default value is ten) which causes a loop incrementing a counter n
times. What effect does the delay constant have on the timing?

It's also worth noting that depending on the compiler and the
optimization level chosen, the delay function might be optimized out so
as to have no affect. To avoid such unwanted optimization, the variable
being counted could be declared global and volatile.

[I recognize that at least part of this code was written by others.]

I've often commented that there is no value in arguing how many angels
can dance on the head of a pin -- you need to get out there and count
them. Thank you for doing that.

Regards,

Ken

On 9/8/2012 6:43 AM, Michael Haberler wrote:
I've done some bit-bang timing measurements for the Raspberry GPIO pins

see
http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062

I'm not saying the Pi has many cycles left at 220nS transition spacing, but
the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an
order of magnitude faster than I ever got with a PC parport driven from a
user process; interrupt latency is another issue but GPIO in this style
doesnt use it

- Michael

Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 9:11 AM, Kent A. Reed wrote:
On a more serious note, as has been discussed on the two emc mail
lists, the road to ARM is littered with ideas but so far we have
little result.

The nicely done miniEMC2 project by Sergey Kaydalov is the most
complete effort I know of. It employed the higher-latency Xenomi
code rather than RTAI. Inquiring minds want to know more about the
possibility of porting this code or something like it to boards
like the RPi or BB and about the resulting performance attainable.
I wish I could have tackled this already but I've got too many
family issues at the moment.
I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
my Pi when it comes in, but I'm not sure what sort of latencies to expect.

On conventional PC hardware, I've gotten decent latency jitter with
modern systems, but not yet down to the RTAI levels. On older
hardware latency with PREEMPT_RT is much worse, particularly on
single-core systems (although I don't yet know if this is due to not
having two cores to schedule between or because all my single-core
systems are pretty ancient).

I'm also hoping on the Arm it might be possible to use the fast IRQ
and read/write the I/O pins in an ISR which may allow the servo thread
to run with much higher jitter.

Then there's the problem of gluing these boards to our CNC hardware
about which I yield to Jon.
My current plan is to bit-bang GPIO pins based on code from the
parallel port driver, but adding a bit of electronics would probably
make things much easier. I'll evaluate that option once I see where I
get with software stepgen.

- --
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
=Dmby
-END PGP SIGNATURE-

Re: [Emc-developers] Raspberry Pi running EMC ???


Am 08.09.2012 um 16:48 schrieb Kenneth Lerman:

 Michael,
 
 I took a quick look at the code and am wondering why there is a call to 
 delay within the loop. The delay function is called with a value of n 
 (default value is ten) which causes a loop incrementing a counter n 
 times.  What effect does the delay constant have on the timing?

I know it's a hack (this aint our hal_gpio merge candidate just yet ;) - the 
reason: 

clock_nanosleep() is pretty useless at least on my current kernel (stock; Linux 
raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux) 
- it gave a minimum delay of some 25usec 

I've tried adapting the swave.c example from the RT linux wiki - same thing: 
http://git.mah.priv.at/gitweb/raspberry-test.git/shortlog/refs/heads/rt-gpio

see e.g. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29t=9882

one would have to dig, eg in 
https://github.com/raspberrypi/linux/blob/rpi-patches/arch/arm/mach-bcm2708/bcm2708.c
 to find out if corners were taken which are fixable or the architecture wont 
support acceptable precision timing 

if anything this seems to be the issue with the Rpi as an LinuxCNC realtime 
outboard, not io path latency

still great for the sprinkler application though


 
 It's also worth noting that depending on the compiler and the 
 optimization level chosen, the delay function might be optimized out so 
 as to have no affect. To avoid such unwanted optimization, the variable 
 being counted could be declared global and volatile.
 
 [I recognize that at least part of this code was written by others.]
 
 I've often commented that there is no value in arguing how many angels 
 can dance on the head of a pin -- you need to get out there and count 
 them. Thank you for doing that.

yeah, my armchair expert detector started wailing, and I cant credibly bitch 
about 'musings and conjecture' without actually doing it myself, so I had to 
cook this up: http://static.mah.priv.at/public/rpi-lport.jpg ;)

is your German good enough for Wer misst, misst Mist!? I appreciate the look 
over the shoulder.

- Michael

 
 Regards,
 
 Ken
 
 
 On 9/8/2012 6:43 AM, Michael Haberler wrote:
 I've done some bit-bang timing measurements for the Raspberry GPIO pins
 
 see 
 http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062
 
 I'm not saying the Pi has many cycles left at 220nS transition spacing, but 
 the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an 
 order of magnitude faster than I ever got with a PC parport driven from a 
 user process; interrupt latency is another issue but GPIO in this style 
 doesnt use it
 
 - Michael
 
 
 Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/20/2012 9:11 AM, Kent A. Reed wrote:
 On a more serious note, as has been discussed on the two emc mail
 lists, the road to ARM is littered with ideas but so far we have
 little result.
 
 The nicely done miniEMC2 project by Sergey Kaydalov is the most
 complete effort I know of. It employed the higher-latency Xenomi
 code rather than RTAI. Inquiring minds want to know more about the
 possibility of porting this code or something like it to boards
 like the RPi or BB and about the resulting performance attainable.
 I wish I could have tackled this already but I've got too many
 family issues at the moment.
 I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
 my Pi when it comes in, but I'm not sure what sort of latencies to expect.
 
 On conventional PC hardware, I've gotten decent latency jitter with
 modern systems, but not yet down to the RTAI levels.  On older
 hardware latency with PREEMPT_RT is much worse, particularly on
 single-core systems (although I don't yet know if this is due to not
 having two cores to schedule between or because all my single-core
 systems are pretty ancient).
 
 I'm also hoping on the Arm it might be possible to use the fast IRQ
 and read/write the I/O pins in an ISR which may allow the servo thread
 to run with much higher jitter.
 
 Then there's the problem of gluing these boards to our CNC hardware
 about which I yield to Jon.
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would probably
 make things much easier.  I'll evaluate that option once I see where I
 get with software stepgen.
 
 - -- 
 Charles Steinkuehler
 char...@steinkuehler.net
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
 zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
 =Dmby
 -END PGP SIGNATURE-
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT

Re: [Emc-developers] Raspberry Pi running EMC ???

I forgot to mention:

with a delay counter  10 there's no signal output at all; obviously the CPU 
overwhelms the IO path in that case

-m

Am 08.09.2012 um 17:41 schrieb Michael Haberler:

 
 Am 08.09.2012 um 16:48 schrieb Kenneth Lerman:
 
 Michael,
 
 I took a quick look at the code and am wondering why there is a call to 
 delay within the loop. The delay function is called with a value of n 
 (default value is ten) which causes a loop incrementing a counter n 
 times.  What effect does the delay constant have on the timing?
 
 I know it's a hack (this aint our hal_gpio merge candidate just yet ;) - the 
 reason: 
 
 clock_nanosleep() is pretty useless at least on my current kernel (stock; 
 Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l 
 GNU/Linux) - it gave a minimum delay of some 25usec 
 
 I've tried adapting the swave.c example from the RT linux wiki - same thing: 
 http://git.mah.priv.at/gitweb/raspberry-test.git/shortlog/refs/heads/rt-gpio
 
 see e.g. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29t=9882
 
 one would have to dig, eg in 
 https://github.com/raspberrypi/linux/blob/rpi-patches/arch/arm/mach-bcm2708/bcm2708.c
  to find out if corners were taken which are fixable or the architecture wont 
 support acceptable precision timing 
 
 if anything this seems to be the issue with the Rpi as an LinuxCNC realtime 
 outboard, not io path latency
 
 still great for the sprinkler application though
 
 
 
 It's also worth noting that depending on the compiler and the 
 optimization level chosen, the delay function might be optimized out so 
 as to have no affect. To avoid such unwanted optimization, the variable 
 being counted could be declared global and volatile.
 
 [I recognize that at least part of this code was written by others.]
 
 I've often commented that there is no value in arguing how many angels 
 can dance on the head of a pin -- you need to get out there and count 
 them. Thank you for doing that.
 
 yeah, my armchair expert detector started wailing, and I cant credibly bitch 
 about 'musings and conjecture' without actually doing it myself, so I had to 
 cook this up: http://static.mah.priv.at/public/rpi-lport.jpg ;)
 
 is your German good enough for Wer misst, misst Mist!? I appreciate the 
 look over the shoulder.
 
 - Michael
 
 
 Regards,
 
 Ken
 
 
 On 9/8/2012 6:43 AM, Michael Haberler wrote:
 I've done some bit-bang timing measurements for the Raspberry GPIO pins
 
 see 
 http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062
 
 I'm not saying the Pi has many cycles left at 220nS transition spacing, but 
 the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly 
 an order of magnitude faster than I ever got with a PC parport driven from 
 a user process; interrupt latency is another issue but GPIO in this style 
 doesnt use it
 
 - Michael
 
 
 Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/20/2012 9:11 AM, Kent A. Reed wrote:
 On a more serious note, as has been discussed on the two emc mail
 lists, the road to ARM is littered with ideas but so far we have
 little result.
 
 The nicely done miniEMC2 project by Sergey Kaydalov is the most
 complete effort I know of. It employed the higher-latency Xenomi
 code rather than RTAI. Inquiring minds want to know more about the
 possibility of porting this code or something like it to boards
 like the RPi or BB and about the resulting performance attainable.
 I wish I could have tackled this already but I've got too many
 family issues at the moment.
 I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
 my Pi when it comes in, but I'm not sure what sort of latencies to expect.
 
 On conventional PC hardware, I've gotten decent latency jitter with
 modern systems, but not yet down to the RTAI levels.  On older
 hardware latency with PREEMPT_RT is much worse, particularly on
 single-core systems (although I don't yet know if this is due to not
 having two cores to schedule between or because all my single-core
 systems are pretty ancient).
 
 I'm also hoping on the Arm it might be possible to use the fast IRQ
 and read/write the I/O pins in an ISR which may allow the servo thread
 to run with much higher jitter.
 
 Then there's the problem of gluing these boards to our CNC hardware
 about which I yield to Jon.
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would probably
 make things much easier.  I'll evaluate that option once I see where I
 get with software stepgen.
 
 - -- 
 Charles Steinkuehler
 char...@steinkuehler.net
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
 zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
 =Dmby
 -END PGP

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-09-08 Thread Kenneth Lerman

google translate helped me with the translation in your previous email. :-)
My High School German studies ended over fifty years ago -- and I wasn't
very good at it then.

I'd be interested in seeing what the data sheet says about the need for
that delay.

Ken

On 9/8/2012 11:46 AM, Michael Haberler wrote:
I forgot to mention:

with a delay counter 10 there's no signal output at all; obviously the CPU
overwhelms the IO path in that case

-m

Am 08.09.2012 um 17:41 schrieb Michael Haberler:

Am 08.09.2012 um 16:48 schrieb Kenneth Lerman:

Michael,

clock_nanosleep() is pretty useless at least on my current kernel (stock;
Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l
GNU/Linux) - it gave a minimum delay of some 25usec

I've tried adapting the swave.c example from the RT linux wiki - same thing:
http://git.mah.priv.at/gitweb/raspberry-test.git/shortlog/refs/heads/rt-gpio

see e.g. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29t=9882

one would have to dig, eg in
https://github.com/raspberrypi/linux/blob/rpi-patches/arch/arm/mach-bcm2708/bcm2708.c
to find out if corners were taken which are fixable or the architecture
wont support acceptable precision timing

if anything this seems to be the issue with the Rpi as an LinuxCNC realtime
outboard, not io path latency

still great for the sprinkler application though

[I recognize that at least part of this code was written by others.]

I've often commented that there is no value in arguing how many angels
can dance on the head of a pin -- you need to get out there and count
them. Thank you for doing that.
yeah, my armchair expert detector started wailing, and I cant credibly bitch
about 'musings and conjecture' without actually doing it myself, so I had to
cook this up: http://static.mah.priv.at/public/rpi-lport.jpg ;)

is your German good enough for Wer misst, misst Mist!? I appreciate the
look over the shoulder.

- Michael

Regards,

Ken

On 9/8/2012 6:43 AM, Michael Haberler wrote:
I've done some bit-bang timing measurements for the Raspberry GPIO pins

see
http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062

I'm not saying the Pi has many cycles left at 220nS transition spacing,
but the 'slow ARM IO myth' seems to be just that, memory mapped IO is
roughly an order of magnitude faster than I ever got with a PC parport
driven from a user process; interrupt latency is another issue but GPIO in
this style doesnt use it

- Michael

Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 9:11 AM, Kent A. Reed wrote:
On a more serious note, as has been discussed on the two emc mail
lists, the road to ARM is littered with ideas but so far we have
little result.

I'm also hoping on the Arm it might be possible to use the fast IRQ
and read/write the I/O pins in an ISR which may allow the servo thread
to run with much higher jitter.

- --
Charles Steinkuehler
char...@steinkuehler.net

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-09-08 Thread Lars Segerlund

A quick question, youre running preempt-rt on a raspberry pi, I might
be wrong on this, but I think there is a patch for the linux kernel
lowering the latency for context switching by running in a single
virtual adress space ( ie. the arm doesn't have to copy the
caches when it context switches ). If the patch is appliable to your
cpu it would lower latency MUCH.

If not I am barking up a tree .. :-D

I don't remember much but it was similar to this, worth checking out

http://www.denx.de/en/pub/News/Xum2009AbstractsAndPresentations/The_ARM_Fast_Context_Switch_Extension_for_Linux.pdf

Were talking ARM 5 here

/ regards, Lars Segerlund.

2012/9/8 Michael Haberler mai...@mah.priv.at:
I've done some bit-bang timing measurements for the Raspberry GPIO pins

see
http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062

- Michael

Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 9:11 AM, Kent A. Reed wrote:
On a more serious note, as has been discussed on the two emc mail
lists, the road to ARM is littered with ideas but so far we have
little result.

I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
my Pi when it comes in, but I'm not sure what sort of latencies to expect.

I'm also hoping on the Arm it might be possible to use the fast IRQ
and read/write the I/O pins in an ISR which may allow the servo thread
to run with much higher jitter.

Then there's the problem of gluing these boards to our CNC hardware
about which I yield to Jon.

My current plan is to bit-bang GPIO pins based on code from the
parallel port driver, but adding a bit of electronics would probably
make things much easier. I'll evaluate that option once I see where I
get with software stepgen.

- --
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
=Dmby
-END PGP SIGNATURE-

Re: [Emc-developers] Raspberry Pi running EMC ???


Am 08.09.2012 um 21:08 schrieb Lars Segerlund:

 A quick question, youre running preempt-rt on a raspberry pi, I might
 be wrong on this, but I think there is a patch for the linux kernel
 lowering the latency for context switching by running in a single
 virtual adress space  ( ie. the arm doesn't have to copy the
 caches when it context switches ). If the patch is appliable to your
 cpu it would lower latency MUCH.
 
 If not I am barking up a tree .. :-D 
 
 I don't remember much but it was similar to this, worth checking out 
  
 http://www.denx.de/en/pub/News/Xum2009AbstractsAndPresentations/The_ARM_Fast_Context_Switch_Extension_for_Linux.pdf
 
 Were talking ARM 5 here 
 
 / regards, Lars Segerlund.

the problem is precision timer support in the kernel/by hardware I think, so I 
guess that's optimizing the wrong end

also, this was a stock kernel and I dont know if the configure options are 
great or useless

maybe somebody aware of rt-preempt configuration can look over this: 
http://git.mah.priv.at/gitweb/raspberry-test.git/blob/7791f6c3f5c37242334511fda7187a2d0bddda54:/proc_config_gz.txt

- Michael

 


 
 
 2012/9/8 Michael Haberler mai...@mah.priv.at:
 I've done some bit-bang timing measurements for the Raspberry GPIO pins
 
 see 
 http://linuxcnc.org/index.php/english/component/kunena/?func=viewcatid=18id=20514limit=6start=48#24062
 
 I'm not saying the Pi has many cycles left at 220nS transition spacing, but 
 the 'slow ARM IO myth' seems to be just that, memory mapped IO is roughly an 
 order of magnitude faster than I ever got with a PC parport driven from a 
 user process; interrupt latency is another issue but GPIO in this style 
 doesnt use it
 
 - Michael
 
 
 Am 20.07.2012 um 16:30 schrieb Charles Steinkuehler:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 7/20/2012 9:11 AM, Kent A. Reed wrote:
 On a more serious note, as has been discussed on the two emc mail
 lists, the road to ARM is littered with ideas but so far we have
 little result.
 
 The nicely done miniEMC2 project by Sergey Kaydalov is the most
 complete effort I know of. It employed the higher-latency Xenomi
 code rather than RTAI. Inquiring minds want to know more about the
 possibility of porting this code or something like it to boards
 like the RPi or BB and about the resulting performance attainable.
 I wish I could have tackled this already but I've got too many
 family issues at the moment.
 
 I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
 my Pi when it comes in, but I'm not sure what sort of latencies to expect.
 
 On conventional PC hardware, I've gotten decent latency jitter with
 modern systems, but not yet down to the RTAI levels.  On older
 hardware latency with PREEMPT_RT is much worse, particularly on
 single-core systems (although I don't yet know if this is due to not
 having two cores to schedule between or because all my single-core
 systems are pretty ancient).
 
 I'm also hoping on the Arm it might be possible to use the fast IRQ
 and read/write the I/O pins in an ISR which may allow the servo thread
 to run with much higher jitter.
 
 Then there's the problem of gluing these boards to our CNC hardware
 about which I yield to Jon.
 
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would probably
 make things much easier.  I'll evaluate that option once I see where I
 get with software stepgen.
 
 - --
 Charles Steinkuehler
 char...@steinkuehler.net
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
 zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
 =Dmby
 -END PGP SIGNATURE-
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-21 Thread Karl Schmidt

On 07/20/2012 09:38 PM, andy pugh wrote:
 On 21 July 2012 02:47, Charles Steinkuehlerchar...@steinkuehler.net  wrote:
 My understanding is that one of the first things the servo thread does
 when it wakes up is poll for the current position from the appropriate
 lower-level (software step generator, mesa hardware, or whatnot).

 It is, but I think that the problem is that hardware frequency
 generators don't count their pulses.

All depends on the hardware used and how it is configured - there is no reason 
this bit of 
electronics can't support position-counter registers.

Depending on the uP chip - they can have lots of pulse generators - each 
counter has around a dozen 
config registers - they can be set up to count on the pulse outputs from one of 
the other counters 
that is set up to generate the pulses - or you can set it up to count pulses 
via interrupts.  (The 
ARM cortex (thumb ) processors have very fast Interrupts.)

Or using a cheap FPGA - the counter register is just more logic.

The problem of doing this on a PC, is that the code running is not 
deterministic in time - the same 
instruction can take different amounts of time depending on what is going on, 
not only on the system 
level, but even on the micro-code level.

Single chip uP systems are much more deterministic for doing real-time work - 
(even these can have 
differing instruction times - the time to read a flash location can sometimes 
take an extra cycle - 
but there are ways to work around this. )

In my mind, a single chip uP system, with just a small assembly program, could 
do the pulse 
generation busy work and make the position information available to the 
PC-system with time left 
over to play an audio stream.  The question is if there is going to be a 
latency issue of bringing 
that position information back into the PC without any problematic latency - ( 
the outer loop is 
running much slower - so I doubt there is an issue. )





Karl Schmidt  EMail k...@xtronics.com
Transtronics, Inc.  WEB 
http://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049  FAX (785) 841-0434

Any cat would tell you that you can only wash one paw at a time;
while we try to do everything at once. -kps



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-21 Thread Jon Elson

Karl Schmidt wrote:

 In my mind, a single chip uP system, with just a small assembly program, 
 could do the pulse 
 generation busy work and make the position information available to the 
 PC-system with time left 
 over to play an audio stream.  The question is if there is going to be a 
 latency issue of bringing 
 that position information back into the PC without any problematic latency - 
 ( the outer loop is 
 running much slower - so I doubt there is an issue. )
   
Yes, and an FPGA can do all that, with much better timing accuracy, and
for all axes in parallel.  All of this has already been done.  I was working
with the Beagle Board a couple years ago and built an adaptor to
connect one to my univeral stepper/PWM controllers, but was stopped by the
lack of an RT kernel.  I sent a Beagle Board to the ARM maintainer for
RTAI and hoped it would only take him a month or two to bring the
ARM version of RTAI up to date, but it hasn't happened.

I'm guessing the preempt kernel might be OK for hardware-assisted
motion systems, but probably not for software-generated stepping.

If somebody wants to try to build a driver for the ARM on-chip
peripherals that would be very interesting.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-21 Thread Jon Elson

Karl Schmidt wrote:
   The question is if there is going to be a latency issue of bringing 
 that position information back into the PC without any problematic latency - 
 ( the outer loop is 
 running much slower - so I doubt there is an issue. )
   
Shouldn't be much problem reading a register.  I have figured out how to
access the ARM GPIO registers and built some embedded systems.
But, the tech reference manual for the Beagle Board's CPU is 1700
pages!  Very hard to decipher.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-21 Thread Jon Elson

Jon Elson wrote:
 If somebody wants to try to build a driver for the ARM on-chip
 peripherals that would be very interesting.
   
Oh, one other problem with most of these systems is that only a VERY 
small portion
of the available package pins are brought out to expansion header pins 
on the board.
If the functions you want to use can only be multiplexed to package 
balls that are
not brought out, you can't use that I/O function.  That has been a big 
problem on
the Beagle Board, it has DOZENS of tantalizing I/O devices, but only about
20 package balls have been brought out to the expansion header.  The 
Beagle Bone
has more pins brought out, it appears the Pi has even less.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

On 20 July 2012 07:38, Darren Conway darren.con...@xtra.co.nz wrote:

 Would the Raspberry Pi be a candidate for running EMC?

Quite possibly, yes.
Some discussion here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=7t=1847
and here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2t=2376

When mine arrives it will definitely be something I at least play with.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Kent A. Reed

On 7/20/2012 4:57 AM, andy pugh wrote:
 On 20 July 2012 07:38, Darren Conway darren.con...@xtra.co.nz wrote:

 Would the Raspberry Pi be a candidate for running EMC?
 Quite possibly, yes.
 Some discussion here:
 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=7t=1847
 and here:
 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2t=2376

 When mine arrives it will definitely be something I at least play with.


Well, my US vendor tells me my RPi should be shipped finally! in late 
August, so you have at least a month to get LinuxCNC working on it:-)

On a more serious note, as has been discussed on the two emc mail lists, 
the road to ARM is littered with ideas but so far we have little result.

The nicely done miniEMC2 project by Sergey Kaydalov is the most complete 
effort I know of. It employed the higher-latency Xenomi code rather than 
RTAI. Inquiring minds want to know more about the possibility of porting 
this code or something like it to boards like the RPi or BB and about 
the resulting performance attainable. I wish I could have tackled this 
already but I've got too many family issues at the moment.

Then there's the problem of gluing these boards to our CNC hardware 
about which I yield to Jon.

Lay on MacDuff.

Regards,
Kent


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Charles Steinkuehler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 9:11 AM, Kent A. Reed wrote:
 On a more serious note, as has been discussed on the two emc mail
 lists, the road to ARM is littered with ideas but so far we have
 little result.
 
 The nicely done miniEMC2 project by Sergey Kaydalov is the most
 complete effort I know of. It employed the higher-latency Xenomi
 code rather than RTAI. Inquiring minds want to know more about the
 possibility of porting this code or something like it to boards
 like the RPi or BB and about the resulting performance attainable.
 I wish I could have tackled this already but I've got too many
 family issues at the moment.

I'm planning on trying to use the PREEMPT_RT version of LinuxCNC with
my Pi when it comes in, but I'm not sure what sort of latencies to expect.

On conventional PC hardware, I've gotten decent latency jitter with
modern systems, but not yet down to the RTAI levels.  On older
hardware latency with PREEMPT_RT is much worse, particularly on
single-core systems (although I don't yet know if this is due to not
having two cores to schedule between or because all my single-core
systems are pretty ancient).

I'm also hoping on the Arm it might be possible to use the fast IRQ
and read/write the I/O pins in an ISR which may allow the servo thread
to run with much higher jitter.

 Then there's the problem of gluing these boards to our CNC hardware
  about which I yield to Jon.

My current plan is to bit-bang GPIO pins based on code from the
parallel port driver, but adding a bit of electronics would probably
make things much easier.  I'll evaluate that option once I see where I
get with software stepgen.

- -- 
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJa6IACgkQLywbqEHdNFyNjwCfTVchMrwrcmA2RZ78hoYM0OEa
zn0AoOyTZa74B1MnFaDOL2HqUxG5LwOH
=Dmby
-END PGP SIGNATURE-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

Darren Conway wrote:
 Hi

 Would the Raspberry Pi be a candidate for running EMC?
   
There is no hardware floating point.  I think that would be a major killer.
Software emulation is slow, but the typical RT package probably does not
support the FP emulation for real time kernel modules.

At the glacial pace of RTAI development for the ARM processors, it
might take the rest of this century to get RTAI on the Pi.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???


 On 20 July 2012 07:38, Darren Conway darren.con...@xtra.co.nz wrote:

 
 Would the Raspberry Pi be a candidate for running EMC?
   
OOps, the Pi website now shows it DOES have hardware floating point, I'd
swear a few months ago it said there was NO hardware FP.  Well, that helps.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

Charles Steinkuehler wrote:
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would probably
 make things much easier.  I'll evaluate that option once I see where I
 get with software stepgen.
   
Well, it totally depends on the latency performance of whatever kernel 
you are
using.  RTAI when it is good is OK for software step generation, but just
barely, unless you are satisfied with very slow motion.  I've seen some
comments that seem to suggest 100 us latencies might be about as good as it
gets on ARM processors with the preempt-RT kernel.

I'm also hoping on the Arm it might be possible to use the fast IRQ
and read/write the I/O pins in an ISR which may allow the servo thread
to run with much higher jitter.

  

This is unlikely to help any, as that is basically what an RT task is, a 
thread that runs
several kernel modules in response to an interrupt.

Jon



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

On 20 July 2012 17:31, Jon Elson el...@pico-systems.com wrote:

 There is no hardware floating point.  I think that would be a major killer.
 Software emulation is slow, but the typical RT package probably does not
 support the FP emulation for real time kernel modules.

FPU support is optional in the RTAI config. But I don't know what you
get if you turn it off.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Alexey Starikovskiy

Debian is just released with hard FP for Raspberry Pi:
http://www.raspberrypi.org/archives/1605

On Fri, Jul 20, 2012 at 8:59 PM, andy pugh bodge...@gmail.com wrote:
 On 20 July 2012 17:31, Jon Elson el...@pico-systems.com wrote:

 There is no hardware floating point.  I think that would be a major killer.
 Software emulation is slow, but the typical RT package probably does not
 support the FP emulation for real time kernel modules.

 FPU support is optional in the RTAI config. But I don't know what you
 get if you turn it off.

 --
 atp
 If you can't fix it, you don't own it.
 http://www.ifixit.com/Manifesto

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Karl Schmidt

On 07/20/2012 11:47 AM, Jon Elson wrote:
 Charles Steinkuehler wrote:
 My current plan is to bit-bang GPIO pins based on code from the parallel 
 port driver, but
 adding a bit of electronics would probably make things much easier.


What would the bit of electronics look like? Most of the single chip uP have 
hardware pulse 
generators built in that could easily generate the stepper pulses without 
jitter. Those chips are 
under $1 these days...

Lattice now has a 1000 logic cell FPGA with built in configuration ROM and lots 
of other goodies for 
less than $2 .. (twice that in single quantities from digikey )  there is 
enough room to put a 
softcore CPU to talk to the controlling system etc..

If I have this pictured correctly - the controlling Linuxemc system would run 
the outer servo loop - 
and the hardware would generate the pulses for steppers?

Hardware cost is no longer an issue.


Karl Schmidt  EMail k...@xtronics.com
Transtronics, Inc.  WEB 
http://secure.transtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049  FAX (785) 841-0434

Any cat would tell you that you can only wash one paw at a time;
while we try to do everything at once. -kps



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Charles Steinkuehler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 5:37 PM, Karl Schmidt wrote:
 On 07/20/2012 11:47 AM, Jon Elson wrote:
 Charles Steinkuehler wrote:
 My current plan is to bit-bang GPIO pins based on code from the
 parallel port driver, but adding a bit of electronics would
 probably make things much easier.
 
 What would the bit of electronics look like? Most of the single
 chip uP have hardware pulse generators built in that could easily
 generate the stepper pulses without jitter. Those chips are under
 $1 these days...
 
 Lattice now has a 1000 logic cell FPGA with built in configuration
 ROM and lots of other goodies for less than $2 .. (twice that in
 single quantities from digikey )  there is enough room to put a 
 softcore CPU to talk to the controlling system etc..

Yeah, I've been helping Tim (a mutual friend) write some VHDL code for
the Lattice parts, which look pretty sweet.

I'd probably use some form of programmable FPGA/CPLD under $10 or so,
and right now the Lattice Ice parts are looking like the best bang for
the buck.  Having even a little bit of real hardware makes stepgen and
encoder monitoring a lot simpler than bit-banging in SW.  Plus most of
the micro-controllers don't have real (or very many) encoder inputs,
and can run out of timers fairly quick.

There's still level translation, isolation, and protection to deal
with, but that can be scaled to the task (ie: I'd put a lot more money
into protecting I/O headed to mains-driven servos than a RepRap
powered from the same 12V supply as my CPU).

 If I have this pictured correctly - the controlling Linuxemc system
 would run the outer servo loop - and the hardware would generate
 the pulses for steppers?
 
 Hardware cost is no longer an issue.

...as long as I can get it to work.  If not, you'll have to wait until
the atom class chips get down to the Raspberry Pi pricing level.  :)

- -- 
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJ7i8ACgkQLywbqEHdNFxiSgCffU9l2ydzcRafQuEutFzQUl1J
ZZoAoOoeOQgNyqoh+rx3C7RLY0LBLNNy
=4tHo
-END PGP SIGNATURE-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

On 20 July 2012 23:37, Karl Schmidt k...@xtronics.com wrote:
 Lattice now has a 1000 logic cell FPGA with built in configuration ROM and 
 lots of other goodies for
 less than $2 .. (twice that in single quantities from digikey )  there is 
 enough room to put a
 softcore CPU to talk to the controlling system etc..

There is a well-established, open-source, LinuxCNC-supported library
of motion control components for FPGA/VHDL. It is mainly used in the
Mesa cards (because Mesa wrote it) but it has been used by other
people in their own hardware. I think Ariasrobo use a modified version
(in Mesa Hardware) and
https://picasaweb.google.com/lh/photo/Z-qp8MIIrve8EZT6eVVyaNMTjNZETYmyPJy0liipFm0?feat=directlink
Is a board someone is making with Hostmot2 firmware and their own hardware.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

andy pugh wrote:
 On 20 July 2012 17:31, Jon Elson el...@pico-systems.com wrote:

   
 There is no hardware floating point.  I think that would be a major killer.
 Software emulation is slow, but the typical RT package probably does not
 support the FP emulation for real time kernel modules.
 

 FPU support is optional in the RTAI config. But I don't know what you
 get if you turn it off.
   
The original Pi docs said the HARDWARE did not have floating point 
instructions.
This may have been wrong, or they have moved to a different ARM chip.
The low-end ARMs still do not have FP hardware, and do it by emulation.

The base thread of LinuxCNC does not support FP instructions, this speeds up
context switches and is why the latency is usually better on the base 
thread than
the servo thread.

But, I'm quite sure if you perform an FP instruction in the base thread, 
you will
get an exception.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

Karl Schmidt wrote:
 On 07/20/2012 11:47 AM, Jon Elson wrote:
   
 Charles Steinkuehler wrote:
 
 My current plan is to bit-bang GPIO pins based on code from the parallel 
 port driver, but
 adding a bit of electronics would probably make things much easier.
   

 What would the bit of electronics look like? Most of the single chip uP 
 have hardware pulse 
 generators built in that could easily generate the stepper pulses without 
 jitter.
No, the problem is you need to COUNT your pulses.  There is no way for 
the CPU to
know exactly when a pulse gets issued without counting them, due to 
slight variations
in timing.  Now, on the ARM chips with everything in one, and all 
clocked off the
same crystal, it MAY be possible to keep some kind of sync on the whole 
system,
but it might take some revision of the way LinuxCNC works.  If the rates 
are not
perfectly synched between the pulse generator and the software, small errors
could accumulate to cause large position errors.

Jon

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???

2012-07-20 Thread Charles Steinkuehler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/20/2012 8:28 PM, Jon Elson wrote:
 No, the problem is you need to COUNT your pulses.  There is no way 
 for the CPU to know exactly when a pulse gets issued without
 counting them, due to slight variations in timing.  Now, on the ARM
 chips with everything in one, and all clocked off the same crystal,
 it MAY be possible to keep some kind of sync on the whole system,
 but it might take some revision of the way LinuxCNC works.  If the
 rates are not perfectly synched between the pulse generator and the
 software, small errors could accumulate to cause large position
 errors.

My understanding is that one of the first things the servo thread does
when it wakes up is poll for the current position from the appropriate
lower-level (software step generator, mesa hardware, or whatnot).

So assuming the servo thread can actually read the number of counts
generated (by whatever means), there should be no position error
accumulation.  It shouldn't matter _how_ the pulses are generated, as
long as there is something (pulse count, encoder position) feeding
back to the servo thread so it knows what the position is *RIGHT NOW*
and can act accordingly.

Is this mistaken?

- -- 
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAKChkACgkQLywbqEHdNFx5SwCgz3KvZxsX7QO8FLQzfrowFVrF
m3MAniIGw1EctzYigz1HY8nOXErg3pWF
=lmyF
-END PGP SIGNATURE-

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Raspberry Pi running EMC ???