On Sat, 27 May 2017, Gene Heskett wrote:
Date: Sat, 27 May 2017 08:41:26 -0400
From: Gene Heskett <ghesk...@shentel.net>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] switching to a slower spi driver to see if it works,
On Saturday 27 May 2017 04:49:51 Bertho Stultiens wrote:
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.
I would tend to think that the theory was if it works at 50 MHz, then it
ought to be rock solid at 32 MHz. The switch to 32 MHz then assures it
works well within its limits.
Its been quite a while since I kicked any tires in C, but I've copied the
file, and see if I can see a way to lag the clock by a few nanoseconds
since it seems to work well with the 10x scope probe attached. The
scope doesn't have to be on, just attached.
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.
I have seen the bad cookie message too but its much rarer. Easy to get
though, just move the probe to the 7i90 side of the termination
resistor. That loading shows a reduced swing of the clock, just enough
I'd guess the 7i90 never sees a logic 0. In that event the cookie is
printed as:
00000000 00000000 00000000 00000000
It never gets below .95 volts, nor above 2.75 volts. These are the
probes that came with the scope.
I am tempted to replace them with the 200MHz rated probes from mpja.com.
Hmmm, I may already have them, on the Hitachi v1065.
You might try lowering the series termination resistor value since this looks
like a possible SI issue (and the clock signal will be very sensitive to SI
issues).
Also standard 10M capacitive divider probles are pretty useless for high speed
signal waverform checking, they have way too much capacitance and typically
poor step response.
I would suggest tacking a 4.99K resistor on the end of a bit of 50 Ohm COAX
to make a 100-1 passive divider probe with ~1 GHz band with and less than 1
PF input capacitance (assuming you have a 50 Ohm Scope input option)
Anyhow, it might be worth a try.
If I can rebuild just this module on the pi itself, that is TBD.
build-essential is on it. But it reminds me that:
[snip]
build-essential is already the newest version.
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
libraspberrypi-doc : Depends: libraspberrypi0 (= 1.20170427-1) but it is
not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
specify a solution).
pi@pionsheldon:~ $ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
libraspberrypi0 raspberrypi-bootloader
The following NEW packages will be installed:
libraspberrypi0 raspberrypi-bootloader
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
22 not fully installed or removed.
Need to get 0 B/4,147 kB of archives.
After this operation, 16.3 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Which I have not done because rpi-update has been run, which updates the
firmware, and the second package (raspberrypi-bootloader) above will
brick it by re-installing the older firmware. BTDT, had to start a new
sd card build from square one, which takes about 4 hours to a bootable
card, and another 6 or more to install enough utils that one can
actually do something. Then a couple days sorting dependencies while
trying to install the linuxcnc deb's I lifted from the other pi that
first showed me that error I've posted a dozen times now, and found it
worked reliably with the scope probe attached.
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.
My traceing and poking about seems to indicate a dbus problem, but
reinstalling everything dbus related has no effect. The limited color
pallate of the 16 bit framebuffer is a bit of a problem, so I ran, as
root, fbset --depth 24, and nothing restores it, with reboots still
showing the 16 bit depth, so its not sticky. fbset doesn't return an
error either. But since I can run linuxcnc without it, its not a total
show stopper.
What should I do next?
Try and try again?
;-)
Thats not the smiley I'd use.
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
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
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
