Discussion:
[Emc-developers] More RPI possibilities
Bertho Stultiens
2017-06-20 11:50:29 UTC
Permalink
Hi,

It occurred to me, while going through all the docs, that the RPI can do
more than just SPI. There are actually enough GPIO pins to do bit-banged
EPP as well. Even better, it turns out that you can have two EPP ports,
two SPI ports, or one of each running simultaneously. This works without
EPP and SPI biting each other if the pin-assignments are non-overlapping
(EPP0+EPP1, SPI0+EPP1, SPI1+EPP0 or SPI0+SPI1 can operate in parallel
and no mutex is needed).

The performance of EPP is similar to SPI (about 5 MByte/s). SPI has the
advantage of fewer pins to do the connection. EPP has the advantage of a
lower operating frequency. Although, SPI suffers from the round-trip
delay and can write at ~5MB/s, but only read at 3..4MB/s. EPP actually
has the potential to be faster if the firmware eases up on the imposed
200ns cycle-time.

As an academic exercise, I went ahead and wrote a test-driver and
emulated an EPP slave on some other hardware I had (pretending to be
7i43 and 7i90). Not a whole card emulation, but just enough to get the
communication checked. It all seems to work quite well.

So, anybody interested in a test drive?
--
Greetings Bertho

(disclaimers are disclaimed)
andy pugh
2017-06-20 12:19:30 UTC
Permalink
Post by Bertho Stultiens
So, anybody interested in a test drive?
I think this is an interesting idea, and something I considered myself a
while ago.
I even made a bunch of PCBs to do the voltage level shifting:

https://goo.gl/photos/vFdUEhSiq6Ei448D8

I wonder if there is a way to slot the virtual EPP port into a port
address, so that the existing drivers (such as Pico PPMC) can use them
without modification?
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Bertho Stultiens
2017-06-20 13:01:11 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
So, anybody interested in a test drive?
I think this is an interesting idea, and something I considered myself a
while ago.
https://goo.gl/photos/vFdUEhSiq6Ei448D8
Do you need the level-shifters? For the 7i90, the SPI lines seem to be
3.3V (attached directly to the FPGA) or the added propagation delay
would kill the SPI transfer speed. So I think that all lines are
actually 3.3V (but 5V tolerant).

The CPLD on the 7i43 is used for 5V tolerance (stated in the manual
under "EPP CONFIGURATION"). If the CPLD is not powered from 5V, then you
would not need level-shifting as the i/o is at 3.3V.

However, if you want long cables, then you do need to add buffers.


I did the exercise of designing a PCB. It was designed to support both
SPI and EPP using short flat-cables. See:
Loading Image...
http://media.vagrearg.org/rpi3-lcnc/pi-epp.pdf

(canceled the previous reply, message size exceeded on attachments; now
replaced with links)
Post by andy pugh
I wonder if there is a way to slot the virtual EPP port into a port
address, so that the existing drivers (such as Pico PPMC) can use them
without modification?
It should be possible to write a kernel lp driver supporting EPP mode
using bit-banging on the GPIOs.
--
Greetings Bertho

(disclaimers are disclaimed)
andy pugh
2017-06-20 13:37:44 UTC
Permalink
Post by Bertho Stultiens
Do you need the level-shifters?
I don't know. I was intending to interface to generic p-port breakouts and
I think I had the impression that RPi inputs are not 5V-tolerant.

The GTL chip I used seems to us magic to perform bidirectional level
shifting.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Bertho Stultiens
2017-06-20 14:12:51 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
Do you need the level-shifters?
I don't know. I was intending to interface to generic p-port breakouts and
I think I had the impression that RPi inputs are not 5V-tolerant.
No, the RPi is not 5V tolerant. So generic parallel port requires level
translation.
Post by andy pugh
The GTL chip I used seems to us magic to perform bidirectional level
shifting.
It is the Right Kind(TM) of magic employed (and if you look too closely,
then Heisenberg will prevent you from discovering the real magic).

What chip are you using? I did not notice any pull-ups, so I guess it
must be an active translator chip you have.
--
Greetings Bertho

(disclaimers are disclaimed)
andy pugh
2017-06-20 14:41:44 UTC
Permalink
Post by Bertho Stultiens
What chip are you using? I did not notice any pull-ups, so I guess it
must be an active translator chip you have.
I am pretty sure it was a GTL2000

http://www.nxp.com/documents/data_sheet/GTL2000.pdf
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Bertho Stultiens
2017-06-20 16:27:21 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
What chip are you using? I did not notice any pull-ups, so I guess it
must be an active translator chip you have.
I am pretty sure it was a GTL2000
http://www.nxp.com/documents/data_sheet/GTL2000.pdf
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?

The application note
(http://cache.nxp.com/documents/application_note/AN10145.pdf) states
that the high-side must have pull-ups or they will never reach the
high-side voltage.

The second problem is that you load the RPi with the capacitance of the
cable since the level shifter does not buffer for you. That will
severely impact the rise time (and therefore propagation delay). The RPi
GPIOs are not designed to take any significant load (max 3mA nominally).
There will also be a significant timing skew in directions, depending
the type of drivers used on the other side.
--
Greetings Bertho

(disclaimers are disclaimed)
andy pugh
2017-06-20 16:47:28 UTC
Permalink
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?
Hard to tell, this was a few years ago and using a kernel of unknown
quality.
As in, it didn't work well when I tried it with a software stepgen at
Wichita, but there were many other possible explanations for the issues.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
EBo
2017-06-20 17:03:01 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?
Hard to tell, this was a few years ago and using a kernel of unknown
quality.
As in, it didn't work well when I tried it with a software stepgen at
Wichita, but there were many other possible explanations for the issues.
Anyone tried it with the new RPi-3's?
Bertho Stultiens
2017-06-20 17:22:03 UTC
Permalink
Post by EBo
Post by andy pugh
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?
Hard to tell, this was a few years ago and using a kernel of unknown
quality.
As in, it didn't work well when I tried it with a software stepgen at
Wichita, but there were many other possible explanations for the issues.
Anyone tried it with the new RPi-3's?
Well, SPI is now working and it seems to be satisfactory. I created an
experimental EPP driver for the 7i90/7i43 (which is why I started this
thread) but it needs to be tested and I am looking for volunteers.
--
Greetings Bertho

(disclaimers are disclaimed)
EBo
2017-06-20 17:38:55 UTC
Permalink
Post by Bertho Stultiens
Post by EBo
Post by andy pugh
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?
Hard to tell, this was a few years ago and using a kernel of
unknown
quality.
As in, it didn't work well when I tried it with a software stepgen at
Wichita, but there were many other possible explanations for the issues.
Anyone tried it with the new RPi-3's?
Well, SPI is now working and it seems to be satisfactory. I created an
experimental EPP driver for the 7i90/7i43 (which is why I started this
thread) but it needs to be tested and I am looking for volunteers.
What all would be evolved with testing? We found a use at work to use
an RPi-3 for a proof of concept, so I will be jumping back into RPi's
for the next while. It would be nice to make sure that the hard
real-time and other systems are running correctly, as well as LCNC. I
also need to get back to some LCNC projects whenever I can break away
the time... Anyway, I or my intern might take a poke at the testing if
it does not envolve to much, or if we can find a way to make it work
related...

EBo --
Bertho Stultiens
2017-06-20 19:26:20 UTC
Permalink
Post by EBo
Post by Bertho Stultiens
Well, SPI is now working and it seems to be satisfactory. I created an
experimental EPP driver for the 7i90/7i43 (which is why I started this
thread) but it needs to be tested and I am looking for volunteers.
What all would be evolved with testing? We found a use at work to use
an RPi-3 for a proof of concept, so I will be jumping back into RPi's
for the next while. It would be nice to make sure that the hard
real-time and other systems are running correctly, as well as LCNC. I
also need to get back to some LCNC projects whenever I can break away
the time... Anyway, I or my intern might take a poke at the testing if
it does not envolve to much, or if we can find a way to make it work
related...
First thing you need is a quite a bit of patience. Creating bootable
images with all updates and extra packages RPi is a slow process on a
RPi. So you better have some other work too, or there cannot be enough
coffee.

You need to build a converter from the 40-pin I/O header to a 26-pin IDC
with flatcable (see http://media.vagrearg.org/rpi3-lcnc/pi-epp.pdf).

Now for the software.

The easy way gets you going, but there may be junk you do not need/want
or care about or whatever brainfart I mistakenly left in that image.

The hard way will make you in full control of the image you create. It
also ensures that you actually get an idea what you need to build and
run (I found that very helpful)


The "easy" way (couple of hours to start testing):
--------------------------------------------------
1 - Get my SD image.
It is a bit used, but it is fully functional.
This will take, no joke, about 3.14 hours <smile> to upload.
The image: picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
will be available from http://media.vagrearg.org/rpi3-lcnc/
(once it is uploaded)

sha256sum:
46f4ea007241274f879eb09142bf126ea3c32f5dbdd8488f0c9b1b4f43db79d1
picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
size:
1629293657

2 - dd image to 8+GB SD card
3 - Copy a set of ini/hal files to ~/linuxcnc/configs/...
and modify them to use the new hm2_rpepp driver
4 - test


The "hard" way (about a day before testing):
--------------------------------------------
1 - install base Raspbian image on 8+GB SD card

2 - update the image (atp-get update; apt-get dist-upgrade)

3 - install RT-PREEMPT kernel 4.4.4-rt9-v7+ from Machinekit
The procedure has been derived from
http://www.machinekit.io/docs/getting-started/install-rt-kernel-RPi2/
However, I did not want to upgrade the bootloader and that means doing
more work. Please note that is will run properly on the Pi3. If you
upgrade the bootloader then disregard the following and keep to the MK
described procedure.

Procedure without upgrading the bootloader:
$ sudo su -
# wget
http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# wget
http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# dpkg -i linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# cd /boot
# mkdir old
# mv bcm* overlays kernel7.img old/
# mv dtbs_rt/* .
# cp kernel_rt-4.4.4-rt9-v7+.img kernel7.img
# sync

Now you have to edit /boot/cmdline.txt to look something like this:
dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=PARTUUID=4fb6ef8f-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The first three parameters have been added. Your "root=..." and
"console=..." are probably different. I have a serial console attached
for debug purpose.

4 - add to /etc/rc.local
echo -n 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo -n performance >
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor


Finally, reboot.


5 - install git

6 - clone LinuxCNC from github. My fork has the hm2_rpepp module in a
branch called hm2_rpepp; see https://github.com/BsAtHome/linuxcnc

7 - brace yourself, about to install build-dependencies

8 - read docs/src/code/building-linuxcnc.txt how to find the build
dependencies. Basically:
$ sudo apt-get install dpkg-dev
$ cd ~linuxcnc-git/debian
$ ./configure uspace
$ cd ..
$ dpkg-checkbuilddeps

Now install all that has been listed and get some more coffee and
probably return the next morning.

9 - Build LinuxCNC. Beware: do _not_ compile with parallel jobs. The RPi
has not enough memory to compile multiple c++ files and starts swapping,
killing the performance and going to practically zero progress.
$ cd ~/linuxcnc-git/src
$ ./configure --with-realtime=uspace
$ make
$ sudo make setuid

10 - Copy a set of ini/hal files to ~/linuxcnc/configs/... and modify
them to use the new hm2_rpepp driver

11 - test
--
Greetings Bertho

(disclaimers are disclaimed)
EBo
2017-06-20 19:31:01 UTC
Permalink
Post by Bertho Stultiens
Post by EBo
Post by Bertho Stultiens
Well, SPI is now working and it seems to be satisfactory. I created an
experimental EPP driver for the 7i90/7i43 (which is why I started this
thread) but it needs to be tested and I am looking for volunteers.
What all would be evolved with testing? We found a use at work to use
an RPi-3 for a proof of concept, so I will be jumping back into RPi's
for the next while. It would be nice to make sure that the hard
real-time and other systems are running correctly, as well as LCNC.
I
also need to get back to some LCNC projects whenever I can break away
the time... Anyway, I or my intern might take a poke at the testing if
it does not envolve to much, or if we can find a way to make it work
related...
First thing you need is a quite a bit of patience. Creating bootable
images with all updates and extra packages RPi is a slow process on a
RPi. So you better have some other work too, or there cannot be enough
coffee.
You need to build a converter from the 40-pin I/O header to a 26-pin IDC
with flatcable (see http://media.vagrearg.org/rpi3-lcnc/pi-epp.pdf).
Now for the software.
The easy way gets you going, but there may be junk you do not
need/want
or care about or whatever brainfart I mistakenly left in that image.
The hard way will make you in full control of the image you create. It
also ensures that you actually get an idea what you need to build and
run (I found that very helpful)
--------------------------------------------------
1 - Get my SD image.
It is a bit used, but it is fully functional.
This will take, no joke, about 3.14 hours <smile> to upload.
The image: picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
will be available from http://media.vagrearg.org/rpi3-lcnc/
(once it is uploaded)
46f4ea007241274f879eb09142bf126ea3c32f5dbdd8488f0c9b1b4f43db79d1
picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
1629293657
2 - dd image to 8+GB SD card
3 - Copy a set of ini/hal files to ~/linuxcnc/configs/...
and modify them to use the new hm2_rpepp driver
4 - test
--------------------------------------------
1 - install base Raspbian image on 8+GB SD card
2 - update the image (atp-get update; apt-get dist-upgrade)
3 - install RT-PREEMPT kernel 4.4.4-rt9-v7+ from Machinekit
The procedure has been derived from
http://www.machinekit.io/docs/getting-started/install-rt-kernel-RPi2/
However, I did not want to upgrade the bootloader and that means doing
more work. Please note that is will run properly on the Pi3. If you
upgrade the bootloader then disregard the following and keep to the MK
described procedure.
$ sudo su -
# wget
http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# wget
http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# dpkg -i linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# cd /boot
# mkdir old
# mv bcm* overlays kernel7.img old/
# mv dtbs_rt/* .
# cp kernel_rt-4.4.4-rt9-v7+.img kernel7.img
# sync
dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=PARTUUID=4fb6ef8f-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
The first three parameters have been added. Your "root=..." and
"console=..." are probably different. I have a serial console
attached
for debug purpose.
4 - add to /etc/rc.local
echo -n 1200000 >
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo -n performance >
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Finally, reboot.
5 - install git
6 - clone LinuxCNC from github. My fork has the hm2_rpepp module in a
branch called hm2_rpepp; see https://github.com/BsAtHome/linuxcnc
7 - brace yourself, about to install build-dependencies
8 - read docs/src/code/building-linuxcnc.txt how to find the build
$ sudo apt-get install dpkg-dev
$ cd ~linuxcnc-git/debian
$ ./configure uspace
$ cd ..
$ dpkg-checkbuilddeps
Now install all that has been listed and get some more coffee and
probably return the next morning.
9 - Build LinuxCNC. Beware: do _not_ compile with parallel jobs. The RPi
has not enough memory to compile multiple c++ files and starts
swapping,
killing the performance and going to practically zero progress.
$ cd ~/linuxcnc-git/src
$ ./configure --with-realtime=uspace
$ make
$ sudo make setuid
10 - Copy a set of ini/hal files to ~/linuxcnc/configs/... and modify
them to use the new hm2_rpepp driver
11 - test
Thanks for the step-by-step instructions. In the past I had set up a
cross compiler a the 24-core server -- that cut the compile time a bit
;-) I will see if I can set that back up again. Other than that, I do
not mind punching the button and going to bed, reading a book, making
some stuff, so thanks for the warning ;-)

EBo --
Bertho Stultiens
2017-06-20 21:58:42 UTC
Permalink
Post by Bertho Stultiens
--------------------------------------------------
1 - Get my SD image.
It is a bit used, but it is fully functional.
This will take, no joke, about 3.14 hours <smile> to upload.
The image: picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
will be available from http://media.vagrearg.org/rpi3-lcnc/
(once it is uploaded)
46f4ea007241274f879eb09142bf126ea3c32f5dbdd8488f0c9b1b4f43db79d1
picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
1629293657
The image if now available at:
http://media.vagrearg.org/rpi3-lcnc/picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz

It only took sqrt(pi) time. The image was smaller than expected and luck
was with me too ;-)

Let me know if you need any assistance.
--
Greetings Bertho

(disclaimers are disclaimed)
Gene Heskett
2017-07-14 05:56:57 UTC
Permalink
Greetings Bertho;

Giveing consideration to pre-ordering a pair of the rock64's from the
pine64 web site, $44.95 ea with 4 Gb of ram, the mali gpu-x2, Gigabit
ethernet, 2 usb2 and one usb3 port. Another $10 for usb3<->sata adaptor.
Ships the end of the month.

I get the impression the hole it squirts data thru is considerable larger
than the pi's with its usb2 hole for everything.

What do you think?

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Gene Heskett
2017-06-20 18:20:16 UTC
Permalink
Post by EBo
Post by andy pugh
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the real
world?
Hard to tell, this was a few years ago and using a kernel of unknown
quality.
As in, it didn't work well when I tried it with a software stepgen
at Wichita, but there were many other possible explanations for the
issues.
Anyone tried it with the new RPi-3's?
I am running it quite well on the the r-pi-3b's, newer single spi
interface on 3/4 ton of old Sheldon lathe. I say newer because the
hm2_rpspi.so driver I am running has grown some additional legs by
Bertho S. and was just accepted into master. It (the raspi-3b) is
kernel picky though, bad keyboard and mouse missfires with the newer
kernels like the 4.9.x. from Frank Durr.

4.4.4-rt9-v7+ is working the best here ATM. With a Mesa 7i90 in the
bottom of the pile, and 3 7i42TA's on top for surge suppression and
noise filtering to protect the 3.3 volt 7i90, not to mention giving us a
decent place to terminate all the wires, I seem to be ready to rock &
roll. I am collecting tooling, and considering a 4 jaw chuck, and I've
already made some of its parts to cnc it, on it. I have the 3 jaw
within about 1.5 thou of true, lots better than it was when we horsed it
out of the cargo van here a year ago.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
EBo
2017-06-20 18:53:47 UTC
Permalink
Post by Gene Heskett
Post by andy pugh
Post by andy pugh
Post by Bertho Stultiens
It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in
the
Post by andy pugh
Post by Bertho Stultiens
real
world?
Hard to tell, this was a few years ago and using a kernel of
unknown
Post by andy pugh
quality.
As in, it didn't work well when I tried it with a software stepgen
at Wichita, but there were many other possible explanations for
the
Post by andy pugh
issues.
Anyone tried it with the new RPi-3's?
I am running it quite well on the the r-pi-3b's, newer single spi
interface on 3/4 ton of old Sheldon lathe. I say newer because the
hm2_rpspi.so driver I am running has grown some additional legs by
Bertho S. and was just accepted into master. It (the raspi-3b) is
kernel picky though, bad keyboard and mouse missfires with the newer
kernels like the 4.9.x. from Frank Durr.
4.4.4-rt9-v7+ is working the best here ATM. With a Mesa 7i90 in the
bottom of the pile, and 3 7i42TA's on top for surge suppression and
noise filtering to protect the 3.3 volt 7i90, not to mention giving us a
decent place to terminate all the wires, I seem to be ready to rock &
roll. I am collecting tooling, and considering a 4 jaw chuck, and I've
already made some of its parts to cnc it, on it. I have the 3 jaw
within about 1.5 thou of true, lots better than it was when we horsed it
out of the cargo van here a year ago.
Thanks Gene for the update. All good to know. I will have to review
the kernel updates, and look into the keyboard and mouse missfires. All
that said it would be nice to get back to this...

EBo --
Andrew
2017-06-20 17:56:23 UTC
Permalink
Post by Bertho Stultiens
As an academic exercise, I went ahead and wrote a test-driver and
emulated an EPP slave on some other hardware I had (pretending to be
7i43 and 7i90). Not a whole card emulation, but just enough to get the
communication checked. It all seems to work quite well.
So, anybody interested in a test drive?
By coincidence I have an old 7i43 with a few daughter cards like 7i48 and
7i39.
So I might try testing later this summer.
Is EPP supposed to be more robust than SPI?
Is there an adapter board?

WBR
Andrew
Bertho Stultiens
2017-06-20 18:52:14 UTC
Permalink
Post by Andrew
Post by Bertho Stultiens
As an academic exercise, I went ahead and wrote a test-driver and
emulated an EPP slave on some other hardware I had (pretending to be
7i43 and 7i90). Not a whole card emulation, but just enough to get the
communication checked. It all seems to work quite well.
So, anybody interested in a test drive?
By coincidence I have an old 7i43 with a few daughter cards like 7i48 and
7i39.
So I might try testing later this summer.
Is EPP supposed to be more robust than SPI?
Is there an adapter board?
There is no adapter as of yet. You need to make a cable yourself or put
two connectors (40-pin female and 26-pin male) on a veroboard and wire
it manually (13 connections required, should be doable, see
http://media.vagrearg.org/rpi3-lcnc/pi-epp.pdf).

The EPP should be more timing-robust because it uses parallel transfers,
thus lower frequencies for similar data-transfer rates. However, that is
not the only reason to make an EPP driver. The 7i90 can do both SPI and
EPP, but the 7i43 only EPP afaict. The 7i43 board is interesting if you
do not need that many pins avalable.

I'm writing down a procedure for an RPi test-image in another reply.
--
Greetings Bertho

(disclaimers are disclaimed)
Bertho Stultiens
2017-07-14 10:59:18 UTC
Permalink
This should be of interest on the devlist as well (that darn reply all
button).


-------- Forwarded Message --------
Subject: Re: [Emc-developers] More better r-pi?
Date: Fri, 14 Jul 2017 12:19:51 +0200
Post by Gene Heskett
Giveing consideration to pre-ordering a pair of the rock64's from the
pine64 web site, $44.95 ea with 4 Gb of ram, the mali gpu-x2, Gigabit
ethernet, 2 usb2 and one usb3 port. Another $10 for usb3<->sata adaptor.
Ships the end of the month.
I get the impression the hole it squirts data thru is considerable larger
than the pi's with its usb2 hole for everything.
What do you think?
It is a faster quad core than the Pi (1.6GHz vs 1.2GHz), but it depends
on the support in the kernel how well it will perform in practice. The
board is brand new and you probably see some pains at birth.

The RockChip's SPI interface seems to be supported by a spidev driver,
but how well it performs I do not know. However, the linuxcnc spidev
driver does not support split read/write speeds, which will limit the
overall performance to the read speed. This may be fixable, but needs a
bit of thought.

The actual performance will depend on many things and needs to be tested
to tell a true story.

I am guessing that there are some other optimizations that can/need to
be performed, like anticipatory I/O scheduling, to press more
performance out of these chips. But that would require to analyze a
whole lot more than just the hardware I/O routines.


Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
--
Greetings Bertho

(disclaimers are disclaimed)
andy pugh
2017-07-14 11:26:39 UTC
Permalink
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Bertho Stultiens
2017-07-14 12:14:02 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
The throughput should be fine, but what about the latency?
--
Greetings Bertho

(disclaimers are disclaimed)
EBo
2017-07-14 12:22:08 UTC
Permalink
Post by Bertho Stultiens
Post by andy pugh
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
The throughput should be fine, but what about the latency?
Everything has latency. The real question is if the latency of that
device is sufficiently small for a particular application.

EBo --
Jon Elson
2017-07-14 16:35:17 UTC
Permalink
Post by Bertho Stultiens
Post by andy pugh
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
The throughput should be fine, but what about the latency?
I've measured this on a Pentium 4 at 2 GHz or so, and with
RTAI jitter is about +/- 5 us, with preempt-rt it is more
like +/- 10 us. preempt-rt has a possibility of scheduling
the servo thread via an external interrupt, but it would
take some changes to the rtapi, which is likely above my
skills. This would reduce effective jitter to sub-ns
levels, as all of our hardware can sample the encoder
position via a hardware timer that then triggers an
interrupt on the PC. Someday, I'd like to make that work.

Jon
Jon Elson
2017-07-14 16:22:17 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
Yes, our 3 products (an analog servo interface, a stepper
controller, and a PWM controller) all use the parallel port
as a communications channel. They use it in EPP mode, which
allows better than 1 MByte/second transfers. Not sure what
you really are asking for with "I/O scheduling". We
normally run at a 1 KHz servo thread, with no base thread,
and have two driver functions, one reads all the registers
that need to be read, then the PID etc. are calculated, then
the other writes out the results to set the axis velocity
and digital outputs. On a pedestrian Pentium 4 the whole
servo cycle takes place in about 150 us.

Jon
Bertho Stultiens
2017-07-14 16:47:25 UTC
Permalink
Post by andy pugh
Post by Bertho Stultiens
Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?
EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.
Yes, our 3 products (an analog servo interface, a stepper controller,
and a PWM controller) all use the parallel port as a communications
channel. They use it in EPP mode, which allows better than 1
MByte/second transfers. Not sure what you really are asking for with
"I/O scheduling".
I/O scheduling is a means of doing asynchronous I/O. A synchronous
control-loop idles (busy-waits) a lot at doing I/O.

If you anticipate the I/O delays (requires some time-tagging), then
calculations may overlap the I/O. This is especially attractive in the
modern CPUs which have multiple cores. That means that work can be done
in more abstract parallel fashion and effectively be faster.

For x86 it may not be very interesting, but for ARM it is interesting
and will improve timing stability.
--
Greetings Bertho

(disclaimers are disclaimed)
Continue reading on narkive:
Loading...