On 05/27/2017 05:46 AM, Gene Heskett wrote: [snip] > This is the exact same response from the 7i90 at the initial 50 MHz > clocking: > > pi@pionsheldon:~ $ linuxcnc -l > LINUXCNC - 2.8.0-pre1-2771-gdc2ff49 > Machine configuration directory > is '/home/pi/linuxcnc/configs/sheldon-lathe' > Machine configuration file is '7i90-axis.ini' > Starting LinuxCNC... > Found file(REL): ./hm2-7i90-stepper.hal > Note: Using POSIX realtime > hm2: loading Mesa HostMot2 driver version 0.15 > Unknown board: HOST???? <------ same exact but wrong response [snip]
This is printed at line 314 in src/hal/drivers/mesa-hostmot2/hm2_rpspi.c in the probe_board() function. [snip] > With the demise of the armhf build machine, where do I find the srcs for > this driver? Isn't this at: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c > It makes sense to me to fix the driver rather than trying > to hack up a capacitor...[snip] Yes, indeed, fixing the driver would be the correct way. I just had a look at the code (from above link) and it does not make much sense that the first access to the card is at 50 MHz and subsequently 32 MHz. The SPI interface is configured once in setup_gpio() and then the hardware config is used as is from then on. Therefore, once the hardware registers are set, it should work the same way every time. The behavior reminds me of one possible problem, caching. If that is the problem, then loading the module a second time should not give you the 50 MHz initial board-probe, but the 32 MHz as set before. If loading the module twice give you the same result, then it may be possible that the hardware will only change setup once activated (maybe through CS cycling). Therefore, the board-probe may be (partly) at high speed, then the hardware discovers it has a new setup and subsequently uses the correct hardware register setup. You can verify the hypothesis by looking at the scope. There are actually two commands sent: read cookie and read board ident (you should see two assertions of CS in that process). If the first 16 bytes are read at 50 MHz and the next 8 bytes at 32 MHz, then the hardware is switching speed after the first transfer. If so, then there may be a simple work-around for the problem. Alter the code to do a dummy read in probe_board() (calling check_cookie()/read_ident(), see lines 292 and 296) and discarding the result in the first go. Then the second iteration is used as the actual probe, where the hardware should be running at the correct speed. The thing is, one peculiarity speaks against the hypothesis. You do not see an error message "Invalid Cookie", which is emitted when reading the cookie fails. This is the first transfer, which, under my hypothesis, should fail at the 50 MHz speed. Anyhow, it might be worth a try. > I also have some sort of a lightdm or related problem. Both pi's have the > latest firmware update in them now, and both now boot to a medium grey > blank screen, BUT I do have a movable mouse pointer, and a right click > on the mouse brings up a menu, from which I can call up a terminal > session, and gfx stuff, run from the cli, works just as if I had a full > blown x-server, so thats head scratcher #2 ATM. Ah, the beautiful headaches X can give you (sorry about the sarcasm). It seems here that your X session is not started properly. > What should I do next? Try and try again? ;-) -- Greetings Bertho (disclaimers are disclaimed) ------------------------------------------------------------------------------ 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
