On Thursday 01 June 2017 19:46:29 Bertho Stultiens wrote: > On 06/01/2017 02:13 AM, Gene Heskett wrote: > > Hi Bertho; I haven't heard any more, so I am wondering if you've > > found any more "magic beans"? > > Yes, I think I've tracked down (most of) the problem(s). There are > several factors that play a role. Not all are solved or maybe > solvable, but the timing is much more stable, and very fast most of > the time. > > > Problem 1: > The RPI3 has dynamic frequency scaling activated by default (ondemand > governor). This makes the Pi hop between 600MHz and 1.2GHz core > frequency. Very annoying and makes realtime rather unpredictable. > > Add a line to /etc/rc.local: > echo -n performance > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > This will disable the frequency hopping on boot and lock the cores to > 1.2GHz. > Done but not rebooted for effect. > > Problem 2: > The SPI peripheral input frequency appears to be hopping between > 400MHz and about 250MHz. This probably originates somewhere in the > Linux kernel as the kernel is in charge of clock-generation. > > Changing the cpu's frequency scaling governor to "performance" makes > the clock more stable, hanging out at 400MHz most of the time, but > I've seen lower frequencies once in a while. The spidev driver > actually reads the (peripheral) clock frequency before a transfer > starts and sets the divider for each transfer. However, I have, at > this moment, no clue how to read the clock setting in userspace. This > is a currently a minor issue and should not give rise to major > problems. > > > Problem 3: > The hm2_rpspi driver was miscalculating the clock-divider by > statically setting it to 8. This results in 50MHz SPI clock (400/8), > which is what we've been seeing. The 32MHz clock is the also explained > by the peripheral clock switching to ~250MHz. > > The code is now changed to do the calculation correct and is > configurable with a module parameter "spiclk_rate" to set the clock > (in kHz) and defaults to 33000kHz. > > It should be noted that the clock divider must be an even number, > resulting in frequencies of 200MHz, 100MHz, 66.6MHz, 50MHz, 40MHz, > 33.3MHz, 28.5MHz, 25MHz, etc.. down to 6.1kHz. > > > Problem 4: > The hm2_rpspi driver was missing memory barriers in the peripheral > write/read operations. This resulted in inconsistencies. The code now > uses memory barrier instructions to ensure consistency. > Sounds for sure like it ought to be more stable. > > I also unified the driver-code a bit and fixed some other problems I > could see. It should be functional. The SPI transfers are faster now > too. I've removed the inter-word delays by using the device's FIFO > properly. The chip-select latency is also minimal (factor 2..3 better > than spidev), but it can vary a bit if a (scheduling) interrupt delays > ending the transfer. The cookie-read is done in 5.7us versus 16.5us > using spidev. > > > Attached are the changed files. The .c and .h file are the modified > driver. These go in the source-tree at > "~/linuxcnc-git/src/hal/drivers/mesa-hostmot2/" (after copy do cd into > src and do make etc). The .hal and .ini files are the modified configs > for the sheldon lathe, adding the frequency configuration parameter, > and go in "~/linuxcnc/configs/sheldon-lathe/". > > Try the changes if you will. I'll take a look. But when I had assembled the board stack and was checking it out while sitting on the table saws table, I had to spend a day sorting the .hal file out, it looked like I had last edited it with gedit, and I am glad I had a printout dated the 10th so I could restore it. gedit is a major screwup looking for a place to happen. I blacklisted it over a year ago as it scrambles the contents of a file around pretty reliably, so I've been using geany ever since. Yeah, it has some warts, but nothing to compare to gedits open boils. Kate or Kwrite might be ok, but I could never fall in love with either.
ATM, I have hit a bad path thru the 7i90 to the direction output from the pwmgen.0 on gpio-21 to pin p1-43, thence thru the 7i42TA, its stuck on ground, meaning if I had power on the vfd, it would be running the motor backwards, so first thing tomorrow I have to remove at least 2 of the 7i42TA's to get under them, and after putting a bad card marker on it try another 7i90 as I must have built it with a bad card I had previously blown. I need to ask Peter if he repairs them, and if so how much $. Seems I am doing it in wholesale qty's, or I picked up the wrong card, I have 4 here, and I know for sure 3 are damaged. Power on the vfd & stepper drivers is next. But I'm hoping the 7i42TA's will solve the blown 7i90 problem. > I'm trying to build a new SD card with X > installed, but you should not stay awake for it to be finished (upload > alone of the compressed images takes already 3..4 hours). Ouch. Thank you Bertho. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
