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 > > 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).
Hi Bertho; I haven't heard any more, so I am wondering if you've found any more "magic beans"? I managed to get the box with the rebuilt controller mounted on the outside of the motor drivers box door today, but nothing is wired up yet. This is with the pi with the teeny capacitor (about 14 pf) loading the clocking line, which seems to be about bulletproof in that so far it has worked every time. This is with the new hm2_rpspi.c you had me build. So tomorrow, I'll start wiring this one back into the system. It will take some time though as I either have to splice & extend the cables, or start from scratch with longer cabling. I'll have to take inventory as finding really suitable cabling is a bit of a chore out here in the puckerbrush of West Virginia. This box is ground isolated as I mounted it on insulation strips, except for its power cord, so the first thing will be to extend the single point ground to include this box, and cut the static ground in the power cord off the back of the socket. Details, details. Boring. 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
