On Tuesday 30 May 2017 08:20:38 Bertho Stultiens wrote:
> On 05/30/2017 02:32 AM, Bertho Stultiens wrote:
> > After some digging I noticed that there might be a data-barrier
> > problem, where peripheral register access can become out-of-order.
> > The ARM has the __sync_synchronize() (via gcc) to insert DMB
> > (data-memory-barrier) instructions when you need to guarantee
> > ordering. Inserting DMB made things worse, such that sometimes the
> > setup is 32MHz and sometimes 50MHz. Well, actually, it exposes a
> > deeper problem.
>
> I suddenly realized that the SPI peripheral is configured and accessed
> in userspace. That will fail miserably if not extremely careful,
> especially on SMP.
>
> However, there already is a solution for this! The linux kernel has a
> SPI driver, which is quite good (used it before). It solves all the
> userspace problems and, to say the least, some very clever people have
> had a crack at this problem before.
>
> So, drop userspace access to the hardware and use the kernel
> interface.
>
> 1 - run raspi-config and enable the kernel SPI driver -> reboot
> 2 - you should now have /dev/spidev0.[01]
> 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/
> with the one attached
> 4 - recompile
> 5 - run
>
> Gene, with my (4GB) SD image do (you know the cmdline):
> - run raspi-config to enable the kernel SPI driver and reboot
> - save attached file on SD card as hm2_rpspi.c.new
> $ cp hm2_rpspi.c.new
> linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd
> linuxcnc-git/src
> $ make
> $ sudo make setuid
> $ ../scripts/linuxcnc -v
> ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
>
Well, I am still trying to figure out how to run linuxcnc w/o a gfx
screen.
I followed the above instructions when it wouldn't run the first time,
and now I get a somewhat different message, so lemme see if I can log in
from here and duplicate the results, at least to the interesting part.
pi@pionsheldon:~/linuxcnc-git/scripts
$ ./linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
Verbose mode on
RUN_IN_PLACE=yes
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/home/pi/linuxcnc-git/bin
LINUXCNC_TCL_DIR=/home/pi/linuxcnc-git/tcl
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/home/pi/linuxcnc-git/rtlib
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/home/pi/linuxcnc-git/src/objects
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.8.0~pre1
Machine configuration directory
is '/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
INIFILE=/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini
VERSION=1.0
PARAMETER_FILE=hm2-stepper.var
TASK=milltask
HALUI=
DISPLAY=axis
COORDINATES=X Z
KINEMATICS=trivkins coordinates=XZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_rpspi: spiclk=32000000 Hz
hm2_rpspi: Invalid cookie
hm2_rpspi: Read: 00000000 00000000 00000000 00000000
hm2_rpspi: rtapi_app_main: No such device (-19)
./hm2-7i90-stepper.hal:32: waitpid
failed /home/pi/linuxcnc-git/bin/rtapi_app hm2_rpspi
./hm2-7i90-stepper.hal:32: /home/pi/linuxcnc-git/bin/rtapi_app exited
without becoming ready
./hm2-7i90-stepper.hal:32: insmod for hm2_rpspi failed, returned -1
Shutting down and cleaning up LinuxCNC...
Killing task linuxcncsvr, PID=690
hm2_rpspi: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
hm2: unloading
<commandline>:0: unloadrt failed
Removing HAL_LIB, RTAPI, and Real Time OS modules
Note: Using POSIX realtime
Removing NML shared memory segments
LinuxCNC terminated with an error. You can find more information in the
log:
/home/pi/linuxcnc_debug.txt
and
/home/pi/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
pi@pionsheldon:~/linuxcnc-git/scripts $
Is that 14 pf cap to ground on the spi-clk0 now screwing it up?
On the first attempt, the error wording seemed to indicate it couldn't
find a display. I wish I'd have thought to capture it.
On the other card, I had 4 workspaces set up on the other card before I
had increased the framebuffer depth to 24, and I found they were still
there, just blank screens, and I could make my terminal session go away
by rolling the mouse wheel, and if I kept rolling the same direction it
wrapped and put me back on the 1st screen. Shade tree engineering at
its best. :) Doesn't work now of course.
Your turn, should you choose to accept it.
I'm going to put the other card back in and see if I have a good 7i90
under all those 7i42ta's. The one its running on now has some blown bus
buffers according to Peter. With 4 of them laying about, I may have
grabbed a bad one. So I'd better check before I bury it any deeper.
> I get the result as shown in the images. The advantage is that there
> are no inter-word delays anymore. The time for chip select to be
> active varies a bit (16.5 us in image 8 vs. 6.3 us data transfer in
> image 6). This variability is inherent to the driver how it handles
> chip select asynchronously. Still, it is an improvement, especially
> for large transfers.
>
> I did add a rtapi module parameter - spiclk - which should set the
> clock upon load. However, I've not been able to get that to work.
> Probably something trivial I did wrong. Ah well, at least it runs at a
> good speed now, also after reboots.
>
> My hm2_rpspi driver hack is fixed to /dev/spidev0.0 (CE0 pin). This
> should be a configurable parameter (features for the future).
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>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
