Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/27/2017 09:43 PM, Gene Heskett wrote:
>> I do not have the hm2 hardware, but that should not prevent me from
>> seeing the problem on the SPI bus.
> 
> I think you'll have to have the hm2 hardware, although I'll be glad to be 
> the lab rat if you want to PM me the newly built modules.

Well, it just needs to load the RT module (hm2_rpspi) and then it may
bail out anyway it likes. Once the module loads it will initiate a probe
on the SPI bus, which I can measure.


> What should I do next?
 Try and try again?
 ;-)
>>> Thats not the smiley I'd use.
>> Well, I'm still smiling, hope you are too.
> I am at the thought that you might build us a working driver. ;-)

We're not there yet.

I now have a working Pi3 (4.9.30-rt20-v7+) and a linuxcnc (LINUXCNC -
2.8.0~pre1) from github running on the pi. Now I need to reproduce the
problem before I can hack it.

What I am missing are the target CNC machine configuration files. Gene,
could you send me a tarball with the specific machine setup you have
been testing?


-- 
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Saturday 27 May 2017 15:14:55 Charles Steinkuehler wrote:

> On 5/27/2017 12:21 PM, Gene Heskett wrote:
> > On Saturday 27 May 2017 11:26:18 Peter C. Wallace wrote:
> >> 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).
> >
> > SI? Acronym for what?
>
> Signal integrity.
>
> Source, cable, and load impedance all need to match pretty well, but
> you knew that already.  :)
>
> If you're running any distance, I'd recommend a buffer on the SPI
> lines.  The SoC parts are designed to drive short PCB traces and
> typically only have a few mA of drive, not really enough to properly
> drive a cable and it's capacitance.  For series termination to work
> well, the driver needs enough current output to drive the full signal
> across the series termination resistor.  Otherwise, you wind up
> needing two full cable round-trip times to get a reliable signal at
> the far end, and you leave the load sitting halfway through the
> transition for a cable round-trip time.
>
> I'd wager if you just stick a reasonably fast driver (AHCT, LVC, or
> just about any 3.3V logic family) on the clock like at the RPi end to
> drive the cable (with a suitable[1] series resistor, probably 25-33
> ohm), your problems will go away.
>
> [1] The driver output impedance plus the series termination resistor
> should equal the characteristic impedance of the cable.  Most cables
> (ribbon with alternating ground, twisted pair Ethernet) are going to
> be around 100-120 ohms.  The driver needs to be able to drive a full
> step (3.3V or 5V, depending on your logic family) into the effective
> impedance of the cable impedance plus the driver & series terminator
> (so 200-240 ohms).  The I/O drivers on most SoC parts just aren't big
> enough to be able to do that effectively, so it takes two round-trip
> flight times to bring the load end to the final voltage, which also
> typically leaves the load end sitting in the transition region for one
> round-trip flight time.  A recipe for problems when you're talking
> about a clock line.

This all sounds like a redesign of the adapter board, with good rail 
bypassing at those frequencies. If thats the case, can I request that 
the 26 pin socket be put on the same side of the board as the 40 pinner? 
That would make it hang over the edge of the pi, and that would allow a 
3/4" cable to be made.  At what point in shortening the cable can the 
terms be thrown away? My mental calcs tell me the cable ringing at 1.25" 
would be at quite a few gigahertz, and any ringing would be faster than 
the semi's on either end of it can either generate or respond to, so the 
losses in the term resistors can be eliminated by shorting them out. In 
the interests of shortening this cable, the pi for this second build has 
been turned upside down with the 40 pin gpio placed immediately inline 
with the 7i90 26 pin socket with perhaps 3/4" inch between them.
I could post a pix if anybody is interested.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Saturday 27 May 2017 13:53:51 Bertho Stultiens wrote:

> On 05/27/2017 02:41 PM, Gene Heskett wrote:
> [snip]
>
> > If I can rebuild just this module on the pi itself, that is TBD.
>
> Gene, can you specify which base-distro you run on the Pi and which
> kernel? I'd like to reproduce your problem here on the bench and see
> if I can hack a fix.
>
pi@pionsheldon:~ $ uname -a
Linux pionsheldon 4.4.9-rt17-v7+ #1 SMP PREEMPT RT Wed May 11 22:46:14 
CEST 2016 armv7l GNU/Linux

pi@pionsheldon:~ $ cat /etc/issue
Raspbian GNU/Linux 8 \n \l

> Also, what options do you have on the linuxcnc configure. Just to make
> similar systems.

the configure-$version number in /boot does not match the running kernel 
as this was an emlid based install, and the rt kernel has overwritten 
their 4.4.6 version kernel and kernel7 files. So although I had to 
install more utils, both pi's are pretty close to matching the above, 
with uname -a and /etc/issue being a 100% match.

> I do not have the hm2 hardware, but that should not prevent me from
> seeing the problem on the SPI bus.

I think you'll have to have the hm2 hardware, although I'll be glad to be 
the lab rat if you want to PM me the newly built modules.

I've been out shopping & pill collecting, and I've got to reload the 
dishwasher in order to find the sink, so I'll be busy for the next half 
hour at least.
>
> >>> What should I do next?
> >>
> >> Try and try again?
> >> ;-)
> >
> > Thats not the smiley I'd use.
>
> Well, I'm still smiling, hope you are too.

I am at the thought that you might build us a working driver. ;-)

Thanks Bertho Stultiens.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Charles Steinkuehler]

On 5/27/2017 12:21 PM, Gene Heskett wrote:
> On Saturday 27 May 2017 11:26:18 Peter C. Wallace wrote:
> 
>> 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).
> 
> SI? Acronym for what?

Signal integrity.

Source, cable, and load impedance all need to match pretty well, but
you knew that already.  :)

If you're running any distance, I'd recommend a buffer on the SPI
lines.  The SoC parts are designed to drive short PCB traces and
typically only have a few mA of drive, not really enough to properly
drive a cable and it's capacitance.  For series termination to work
well, the driver needs enough current output to drive the full signal
across the series termination resistor.  Otherwise, you wind up
needing two full cable round-trip times to get a reliable signal at
the far end, and you leave the load sitting halfway through the
transition for a cable round-trip time.

I'd wager if you just stick a reasonably fast driver (AHCT, LVC, or
just about any 3.3V logic family) on the clock like at the RPi end to
drive the cable (with a suitable[1] series resistor, probably 25-33
ohm), your problems will go away.

[1] The driver output impedance plus the series termination resistor
should equal the characteristic impedance of the cable.  Most cables
(ribbon with alternating ground, twisted pair Ethernet) are going to
be around 100-120 ohms.  The driver needs to be able to drive a full
step (3.3V or 5V, depending on your logic family) into the effective
impedance of the cable impedance plus the driver & series terminator
(so 200-240 ohms).  The I/O drivers on most SoC parts just aren't big
enough to be able to do that effectively, so it takes two round-trip
flight times to bring the load end to the final voltage, which also
typically leaves the load end sitting in the transition region for one
round-trip flight time.  A recipe for problems when you're talking
about a clock line.

-- 
Charles Steinkuehler
char...@steinkuehler.net

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/27/2017 02:41 PM, Gene Heskett wrote:
[snip]
> If I can rebuild just this module on the pi itself, that is TBD.

Gene, can you specify which base-distro you run on the Pi and which
kernel? I'd like to reproduce your problem here on the bench and see if
I can hack a fix.

Also, what options do you have on the linuxcnc configure. Just to make
similar systems.

I do not have the hm2 hardware, but that should not prevent me from
seeing the problem on the SPI bus.


>>> What should I do next?
>> Try and try again?
>> ;-)
> Thats not the smiley I'd use.

Well, I'm still smiling, hope you are too.


-- 
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Saturday 27 May 2017 11:26:18 Peter C. Wallace wrote:

> On Sat, 27 May 2017, Gene Heskett wrote:
> > Date: Sat, 27 May 2017 08:41:26 -0400
> > From: Gene Heskett 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] switching to a slower spi driver to see if
> > it works,
[...]
> 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).

SI? Acronym for what?

> 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've no clue how accurately shaped the 1 KHz test signal is, but expanded 
to see at 2ns per division, it actually looks pretty good.

However, the clock signal as I see it on this gigahertz sampler, is not 
too terrible removed from a sine-squared wave, so I'm not convinced I am 
looking at the truth.  At the pi, the swing is 3.35 volts, beyond the 
term r its under 2.9 volts for swing, like the 7i90 is pulling it up 
pretty strongly.
>
> 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)

This Chinese scope doesn't have a 50 ohm input. Std 1 meg. And probably 
about 50 pf. But its a thought, I'll see what I can cobble up right at 
the input bnc connector. And all the coax I can lay my hands on is 75 
(73 actually) ohm. Video stuff. In the meantime, I found some 6mm dia. 
30 pf max trimmers, 20 for about 7 dollars, s/b here around the 5th.  On 
fleabay of course.  That might get me going as they can be pasted on the 
back face of the 40 pin pattern.

Getting at the smd pad to parallel another resistor will be fun, the 
header sockets are sitting on them. And even with hot air, I'm not sure 
I could R the header sockets without damaging the board in addition to 
trashing the headers. At a 1.25" cable length, I'd think I ought to be 
able to just bridge the pads.  Theres not enough drive to damage 
anything.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Peter C. Wallace]

On Sat, 27 May 2017, Gene Heskett wrote:


Date: Sat, 27 May 2017 08:41:26 -0400
From: Gene Heskett 
Reply-To: "Enhanced Machine Controller (EMC)"

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:
   
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 

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

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:
   
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.

> 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 

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Thursday 18 May 2017 13:01:13 Gene Heskett wrote:

> On Thursday 18 May 2017 10:25:46 dave wrote:
> > No problem Gene, we just cross you with an octopus. :-)
> >
> > Dave
>
> Yeah but moving the breeding apparatus from where it is, to the end of
> the octpods 8th arm would be quite a trick. :)

To get this back on topic, I've been scrambling around for a couple days 
now, trying to get a working LCNC install on the last good pi-3b I have. 

I snarfed the debs from the other pi, and wire netted them to this one, 
and installed from the debs using "dpkg -i linuxcnc-*". No biscuit, 
whole screen full of missing dependencies it took a couple hours to 
round up and install.

And after quite a battle with dpkg, I am at exactly the same point with 
the new build, as I am with the older pi on the lathe right now, if I 
hang a 10x scope probe on the pi side of the clocking signal. But now I 
am using the pcb from OSHPark with quite close to the recommended 88 ohm 
terminating r's, 86.6 ohms IIRC, AND the interconnection cable from this 
adapter boards 26 pin header to the 26 pin input of the 7i90HD is not 
more than 1.25" long.

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
hm2_rpspi: rtapi_app_main: Operation not permitted (-1)
./hm2-7i90-stepper.hal:32: waitpid failed /usr/bin/rtapi_app hm2_rpspi
./hm2-7i90-stepper.hal:32: /usr/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...

There has to be a subtle timing error between the clock and the data 
latching in the rpspi.ko driver, or in the 7i90. Enough that the 10+ pf 
cap loading on the clocking signal at the pi's gpio pin used for 
clocking fixes it. Whatever one of the mpja 100 mhz scope probes 
represents as a load.  Certainly no more than 15 pf's and 10 megohms I 
would think, but have no means of measuring it, nor do I have any little 
one-half turn ceramic trimmers.

With the demise of the armhf build machine, where do I find the srcs for 
this driver?  It makes sense to me to fix the driver rather than trying 
to hack up a capacitor when where it would have to go is nearly buried 
under the header connectors installed after those resistors have been 
placed and hot air soldered.  Any mods to the adapter board would be 
best done by ordering 3 more of the blanks and 3 more of each header 
socket.  But it makes far more sense to me, to fix the driver so it 
works for everybody.

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.

What should I do next?

[...]

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Thursday 18 May 2017 10:25:46 dave wrote:

> No problem Gene, we just cross you with an octopus. :-)
>
> Dave
>
Yeah but moving the breeding apparatus from where it is, to the end of 
the octpods 8th arm would be quite a trick. :)

> On 05/17/2017 08:08 AM, Gene Heskett wrote:
> > On Wednesday 17 May 2017 10:38:23 Bertho Stultiens wrote:
> >> On 05/17/2017 12:50 PM, Gene Heskett wrote:
> >> [snip]
> >>
> >>> I can't hold the probe in contact, retrigger the scope to capture
> >>> the next snapshot, and hit the up-arrow then a return to initiate
> >>> the next signals existence as linuxcnc starts up. Birth defect I
> >>> guess, I'd need 6 arms, all steadier than the 2 I do have.  Or 3
> >>> of me in telepathic contact. :)
> >>
> >> Isn't this why you build CNC machines to help you?
> >
> > Something like that, but as you note below, machinery grows to
> > occupy all available space.  And I'm about there, darnit.
> >
> > He who dies with the most toy's is still dead though.
> >
> >> Hm, there is an error in here somewhere, need machine to build
> >> machine to debug machine to build machine... Recursion detected, no
> >> more stack space left, core dumped.
> >
> > And occasionally, a deep inspection of the core dump does come up
> > with a better answer.
> >
> >> Well, it was a thought anyway ;-)
> >
> > Cheers, Gene Heskett
>
> --
> 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


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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[dave]

No problem Gene, we just cross you with an octopus. :-)

Dave

On 05/17/2017 08:08 AM, Gene Heskett wrote:
> On Wednesday 17 May 2017 10:38:23 Bertho Stultiens wrote:
>
>> On 05/17/2017 12:50 PM, Gene Heskett wrote:
>> [snip]
>>
>>> I can't hold the probe in contact, retrigger the scope to capture
>>> the next snapshot, and hit the up-arrow then a return to initiate
>>> the next signals existence as linuxcnc starts up. Birth defect I
>>> guess, I'd need 6 arms, all steadier than the 2 I do have.  Or 3 of
>>> me in telepathic contact. :)
>> Isn't this why you build CNC machines to help you?
>>
> Something like that, but as you note below, machinery grows to occupy all
> available space.  And I'm about there, darnit.
>
> He who dies with the most toy's is still dead though.
>
>> Hm, there is an error in here somewhere, need machine to build machine
>> to debug machine to build machine... Recursion detected, no more stack
>> space left, core dumped.
> And occasionally, a deep inspection of the core dump does come up with a
> better answer.
>
>> Well, it was a thought anyway ;-)
>
> Cheers, Gene Heskett


--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Wednesday 17 May 2017 10:38:23 Bertho Stultiens wrote:

> On 05/17/2017 12:50 PM, Gene Heskett wrote:
> [snip]
>
> > I can't hold the probe in contact, retrigger the scope to capture
> > the next snapshot, and hit the up-arrow then a return to initiate
> > the next signals existence as linuxcnc starts up. Birth defect I
> > guess, I'd need 6 arms, all steadier than the 2 I do have.  Or 3 of
> > me in telepathic contact. :)
>
> Isn't this why you build CNC machines to help you?
>
Something like that, but as you note below, machinery grows to occupy all 
available space.  And I'm about there, darnit.

He who dies with the most toy's is still dead though.

> Hm, there is an error in here somewhere, need machine to build machine
> to debug machine to build machine... Recursion detected, no more stack
> space left, core dumped.

And occasionally, a deep inspection of the core dump does come up with a 
better answer.

> Well, it was a thought anyway ;-)


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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/17/2017 12:50 PM, Gene Heskett wrote:
[snip]
> I can't hold the probe in contact, retrigger the scope to capture the 
> next snapshot, and hit the up-arrow then a return to initiate the next 
> signals existence as linuxcnc starts up. Birth defect I guess, I'd need 
> 6 arms, all steadier than the 2 I do have.  Or 3 of me in telepathic 
> contact. :)

Isn't this why you build CNC machines to help you?

Hm, there is an error in here somewhere, need machine to build machine
to debug machine to build machine... Recursion detected, no more stack
space left, core dumped.

Well, it was a thought anyway ;-)

-- 
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Wednesday 17 May 2017 01:47:17 Bertho Stultiens wrote:

> On 05/17/2017 04:24 AM, Gene Heskett wrote:
> [snip]
>
> > The ideal situation in this instance would be to mirror the design
> > of the 7i90 so as to rotate the 26 pin header 180 degrees, which
> > would allow the cable to be only an inch long.  Or mount the pi
> > upside down, which would have the same effect.  Humm, why not, I
> > have some looong standoffs?  While I'm waiting on 7i42TA's, why not
> > try it?  More than one way to skin this scrawny cat.
>
> Reducing the cable's length to an inch would help. Then the
> transmission line characteristics would be much less a problem at
> 50MHz.
>
> >  Why is it I think best while writing
> > about a problem? Can't be the age of the wet ram.  Or is it... :(
>
> It is called reflection of your own thoughts ;-) It works very well
> while doing something completely different (like taking some time on
> the toilet).
>
> >> BTW, I think that not only the probe tip has influence, but also
> >> where your probe's ground-lead is placed (and not that fluffy long
> >> aligator-clip lead).
> >
> >  Chuckle, guilty yur honor, but its only a  4" lead. :) In this case
> > clipped onto a corner of a usb sockets frame.
>
> Well, using the default ground-lead on the probe at high frequency
> makes anything you see on the scope suspect. You do still have those
> springy clips that come with the probes, which clip onto the tip's
> ground-ring?

Someplace, but to use them I'd need three things.
1. A ground it could reach.
2. jigs to hold the probes in constant contact since there are no 
gripping hooks.
3. 6 arms & hands.

I can't hold the probe in contact, retrigger the scope to capture the 
next snapshot, and hit the up-arrow then a return to initiate the next 
signals existence as linuxcnc starts up. Birth defect I guess, I'd need 
6 arms, all steadier than the 2 I do have.  Or 3 of me in telepathic 
contact. :)

> With your confession, I'd be expecting ringing on the signals you
> measured. That makes me wonder if your probe is properly impedance
> matched to your scope... Maybe time to test and recalibrate the probes
> on the 1kHz scope reference?

BTDT, many times. For this sort of thing, the scopes need a 100khz test 
signal, and an isolated ground immediately adjacent, but this one has 
neither, dammit.

The scope itself is running on a ground isolation adapter, so I'm not 
getting the ground loop noises from that in my displays, nor is power 
applied to the motors as I have that tied to the motion enable gui 
button. So yes, I do understand that the scope pix I posted links to 
yesterday are showing the effects of that 4" long ground lead.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/17/2017 04:24 AM, Gene Heskett wrote:
[snip]
> The ideal situation in this instance would be to mirror the design of the 
> 7i90 so as to rotate the 26 pin header 180 degrees, which would allow 
> the cable to be only an inch long.  Or mount the pi upside down, which 
> would have the same effect.  Humm, why not, I have some looong 
> standoffs?  While I'm waiting on 7i42TA's, why not try it?  More than 
> one way to skin this scrawny cat.

Reducing the cable's length to an inch would help. Then the transmission
line characteristics would be much less a problem at 50MHz.


>  Why is it I think best while writing
> about a problem? Can't be the age of the wet ram.  Or is it... :(

It is called reflection of your own thoughts ;-) It works very well
while doing something completely different (like taking some time on the
toilet).


>> BTW, I think that not only the probe tip has influence, but also where
>> your probe's ground-lead is placed (and not that fluffy long
>> aligator-clip lead).
>  Chuckle, guilty yur honor, but its only a  4" lead. :) In this case 
> clipped onto a corner of a usb sockets frame.

Well, using the default ground-lead on the probe at high frequency makes
anything you see on the scope suspect. You do still have those springy
clips that come with the probes, which clip onto the tip's ground-ring?

With your confession, I'd be expecting ringing on the signals you
measured. That makes me wonder if your probe is properly impedance
matched to your scope... Maybe time to test and recalibrate the probes
on the 1kHz scope reference?


-- 
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Tuesday 16 May 2017 17:29:34 Bertho Stultiens wrote:

> On 05/16/2017 09:56 PM, Gene Heskett wrote:
> > Is this driver your work, Bertho?
>
> No, not at all. But, I have dealt with high frequency stuff before.
> The biggest problem is that some parts are in the realm of magic ;-)
>
Not really, but cost is as always, the deciding factor.

> The RPI hardware is not made for such high frequencies. Pushing that
> out of a china-model 100mil header is, generally, crazy and you have
> impedance mismatches everywhere in the path.

Yup.  Try to show some bean counter just how bad they are on a decent 
TDR, is the biggest waste of a good engineers time there is.
>
> > My point is adding that 7 pf+whatever the tip clipon is, 3 or so
> > more, to the pi src side of the termination resistor of 82 ohms, of
> > this clock signal, makes it work, everytime.
>
> There are probably several effects at work here. You are changing the
> impedance which probably changes the transmissionline properties as to
> feed back into other parts of the circuit (including into the Broadcom
> chip). That it works is amazing all by itself. I've had lots of
> problems with 20MHz on that header already.

Yeah it goes back to the first ide hard drives, whose cables weren't 
solid beyond a foot long, but they made them 16" long anyway.  Or the 
perfectly good design of a scsi controller that somewhere between the 
engineers drafting board and the production line, had a power schotky 
diode switched out for a si type that was only 10% of the cost of the 
schotky(sp) by a bean counter who had no clue why the designer specced 
such a high priced isolation diode, who also could never understand why 
the switchboard lite up like a Christmas tree from people trying to make 
it work a full hour at a time in a busy graphics production.  That 
bankrupted several back in the heyday of the Amiga.  I could go on, but 
we've been observing things long enough to understand that even if the 
engineer drew it right, thats no guarantee it will still be right when 
shipped.

The ideal situation in this instance would be to mirror the design of the 
7i90 so as to rotate the 26 pin header 180 degrees, which would allow 
the cable to be only an inch long.  Or mount the pi upside down, which 
would have the same effect.  Humm, why not, I have some looong 
standoffs?  While I'm waiting on 7i42TA's, why not try it?  More than 
one way to skin this scrawny cat.  Why is it I think best while writing 
about a problem? Can't be the age of the wet ram.  Or is it... :(
>
> BTW, I think that not only the probe tip has influence, but also where
> your probe's ground-lead is placed (and not that fluffy long
> aligator-clip lead).
>
 Chuckle, guilty yur honor, but its only a  4" lead. :) In this case 
clipped onto a corner of a usb sockets frame.
> > I think I will solder a tightly
> > twisted pair there for a loading cap, but that seems like such a
> > kludge that I'd really like to be able to test and adjust for
> > maximum data integrity. At some point I'll kill it again, but I
> > might be able to arrive at a "this size of cap is best" by using
> > half of what it takes to kill it again.
>
> That, of course, will work for this specific setup. However, changing
> the RPI or changing any cable may throw you off again.


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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Tuesday 16 May 2017 15:56:24 Gene Heskett wrote:

> On Tuesday 16 May 2017 15:03:00 Bertho Stultiens wrote:
> > On 05/16/2017 08:33 PM, Peter C. Wallace wrote:
> > > 50 MHz will work if everything is terminated correctly and if the
> > > RSPI timing is correct. (It may require using a SPI late data
> > > sample option if the RSPI hardware has that option)
> > >
> > > Correct series termination of RSPI outputs (130 Ohm total for
> > > 0.050" flat cable) depends on the output impedance of the RSPI
> > > outputs so there's no guarantee that the added 87 ohms is correct
> > > (this may also depend on RSPI output drive strength settings if
> > > such things exist on the RSPI)
> >
> > Well, in theory, that is true. I suspect that there is a
> > phase-reversal problem at these high frequencies. The probe of the
> > scope adds just enough capacity to delay the signal by a fraction.
> >
> > At 50MHz clock, you have a phase margin of <10ns. This time is
> > consumed by: - the wire-connection (~2ns per meter for copper),
> > - the round-trip in the slave tranceiver (the 7i90 SPI interface),
> > - the RPI buffers and SPI tranceiver.
> >
> > Lets assume that the wire, including PCB traces etc., takes 1ns
> > (roundtrip for 25 cm). The RPI buffers and shift register are
> > probably around 2ns and a bit more if it contains a glitch-filter.
> > The 7i90 interface has both input buffer, an output buffer and at
> > least one flip-flip propagation delay. My guess is that it would be
> > about 0.5ns + 0.5ns + 2ns.
> >
> > That brings the grand total to 6ns, which is at 60% of the phase
> > margin. This is an optimistic estimation where I specifically
> > disregarded setup- and hold-times, which make things much worse.
> > Assuming setup- and hold-margins on both ends (round-trip) of 0.5ns
> > means adding another 2ns, resulting in 8ns total time and 80% of the
> > phase margin. This is getting close to the failure point.
> >
> > Adding just a bit of capacity at the wrong place will make the
> > signal (seemingly) slower because the flanks are less steep (as seen
> > on the scope). This is enough to cause the system to fail.
> >
> > This also means that you cannot add external line-buffers on the
> > lines. These would simply add to much delay at these frequencies
> > (something like 6...10ns). Unfortunately, SPI is a synchronous and
> > timing-bound propocol and cannot tolerate phase reversal.
>
> Is this driver your work, Bertho?
>
> My point is adding that 7 pf+whatever the tip clipon is, 3 or so more,
> to the pi src side of the termination resistor of 82 ohms, of this
> clock signal, makes it work, everytime. I think I will solder a
> tightly twisted pair there for a loading cap, but that seems like such
> a kludge that I'd really like to be able to test and adjust for
> maximum data integrity. At some point I'll kill it again, but I might
> be able to arrive at a "this size of cap is best" by using half of
> what it takes to kill it again.
>
> Cheers, Gene Heskett

Just for S, I unplugged the probe from the clipon tip, leaving it 
hanging on the pi side of the 82 ohm resistor.  Killed it completely. 
Read    .

Is it beer thirty yet? No, too hot out for alcohol. Middle 80's here.  
And I've not found a trimmer cap yet. 3" of tightly twisted 30 gauge I 
guess.

If I can find a round tuit.
 
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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/16/2017 09:56 PM, Gene Heskett wrote:
> Is this driver your work, Bertho?

No, not at all. But, I have dealt with high frequency stuff before. The
biggest problem is that some parts are in the realm of magic ;-)

The RPI hardware is not made for such high frequencies. Pushing that out
of a china-model 100mil header is, generally, crazy and you have
impedance mismatches everywhere in the path.


> My point is adding that 7 pf+whatever the tip clipon is, 3 or so more, to 
> the pi src side of the termination resistor of 82 ohms, of this clock 
> signal, makes it work, everytime.

There are probably several effects at work here. You are changing the
impedance which probably changes the transmissionline properties as to
feed back into other parts of the circuit (including into the Broadcom
chip). That it works is amazing all by itself. I've had lots of problems
with 20MHz on that header already.

BTW, I think that not only the probe tip has influence, but also where
your probe's ground-lead is placed (and not that fluffy long
aligator-clip lead).



> I think I will solder a tightly 
> twisted pair there for a loading cap, but that seems like such a kludge 
> that I'd really like to be able to test and adjust for maximum data 
> integrity. At some point I'll kill it again, but I might be able to 
> arrive at a "this size of cap is best" by using half of what it takes to 
> kill it again.

That, of course, will work for this specific setup. However, changing
the RPI or changing any cable may throw you off 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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[andy pugh]

On 16 May 2017 at 21:22, Gene Heskett  wrote:
> Where can I get the src for hm2_rpspi?
>
> And who is the author?


https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c



-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Tuesday 16 May 2017 15:03:00 Bertho Stultiens wrote:

> On 05/16/2017 08:33 PM, Peter C. Wallace wrote:
> > 50 MHz will work if everything is terminated correctly and if the
> > RSPI timing is correct. (It may require using a SPI late data sample
> > option if the RSPI hardware has that option)
> >
> > Correct series termination of RSPI outputs (130 Ohm total for 0.050"
> > flat cable) depends on the output impedance of the RSPI outputs so
> > there's no guarantee that the added 87 ohms is correct (this may
> > also depend on RSPI output drive strength settings if such things
> > exist on the RSPI)
>
> Well, in theory, that is true. I suspect that there is a
> phase-reversal problem at these high frequencies. The probe of the
> scope adds just enough capacity to delay the signal by a fraction.
>
> At 50MHz clock, you have a phase margin of <10ns. This time is
> consumed by: - the wire-connection (~2ns per meter for copper),
> - the round-trip in the slave tranceiver (the 7i90 SPI interface),
> - the RPI buffers and SPI tranceiver.
>
> Lets assume that the wire, including PCB traces etc., takes 1ns
> (roundtrip for 25 cm). The RPI buffers and shift register are probably
> around 2ns and a bit more if it contains a glitch-filter. The 7i90
> interface has both input buffer, an output buffer and at least one
> flip-flip propagation delay. My guess is that it would be about 0.5ns
> + 0.5ns + 2ns.
>
> That brings the grand total to 6ns, which is at 60% of the phase
> margin. This is an optimistic estimation where I specifically
> disregarded setup- and hold-times, which make things much worse.
> Assuming setup- and hold-margins on both ends (round-trip) of 0.5ns
> means adding another 2ns, resulting in 8ns total time and 80% of the
> phase margin. This is getting close to the failure point.
>
> Adding just a bit of capacity at the wrong place will make the signal
> (seemingly) slower because the flanks are less steep (as seen on the
> scope). This is enough to cause the system to fail.
>
> This also means that you cannot add external line-buffers on the
> lines. These would simply add to much delay at these frequencies
> (something like 6...10ns). Unfortunately, SPI is a synchronous and
> timing-bound propocol and cannot tolerate phase reversal.

Is this driver your work, Bertho?

My point is adding that 7 pf+whatever the tip clipon is, 3 or so more, to 
the pi src side of the termination resistor of 82 ohms, of this clock 
signal, makes it work, everytime. I think I will solder a tightly 
twisted pair there for a loading cap, but that seems like such a kludge 
that I'd really like to be able to test and adjust for maximum data 
integrity. At some point I'll kill it again, but I might be able to 
arrive at a "this size of cap is best" by using half of what it takes to 
kill it again.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Peter C. Wallace]

On Tue, 16 May 2017, Gene Heskett wrote:

> Date: Tue, 16 May 2017 15:40:41 -0400
> From: Gene Heskett 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] switching to a slower spi driver to see if it works,
> 
> On Tuesday 16 May 2017 14:33:29 Peter C. Wallace wrote:
>
>> On Tue, 16 May 2017, Gene Heskett wrote:
>>> Date: Tue, 16 May 2017 13:22:59 -0400
>>> From: Gene Heskett 
>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>> 
>>> To: emc-users@lists.sourceforge.net
>>> Subject: Re: [Emc-users] switching to a slower spi driver to see if
>>> it works,
>>>
>>> On Monday 15 May 2017 09:58:04 Gene Heskett wrote:
>>>
>>> I may have found it!!!
>>>
>>> Hooking up my scope, I discovered that the original query to get the
>>> board to ID itself, IS NOT MADE AT THE SAME CLOCK SPEED IT ACTUALLY
>>> OPERATES AT. THE INITIAL QUERY IS BEING MADE AT 50 MHz!
>>>
>>> I hung a scope probe on the clock, which due to its loading, changed
>>> the shape of the waveform and made it work.  Its now running at 32
>>> MHz, but I had captured the initial failure, and that was clocked at
>>> 50MHz.
>>>
>>> Now, I'll go remove my scope probe and see if it fails.
>>>
>>> Better yet, without the probe it fails, with the probe on the pi end
>>> of the 82 ohm terminating resistor I used in my home made adapter,
>>> it works 5 out of 5 times.  Move the probe to the other end of that
>>> resistor and the failure rate is 5 out of 5 times. I took some pix
>>> of the single trace capture of this startup card query.  Quite a bit
>>> of the voltage swing the pi is generating is being used up in the
>>> resistor, at least half a volt.
>>>
>>> Pix on my web page at
>>> >> ream-sclk.jpg> and
>>> >> stream-sclk.JPG>
>>>
>>> I note that if it succeeds, which it seems to do with my probe
>>> furnishing some initial loading, it then slows to 32MHz for the
>>> clock rate.
>>>
>>> And, when its hooked up with the OSHPark adapter and its 86.7 ohm
>>> resistors, there is not enough signal to tickle the 7i90 into
>>> responding at all.
>>>
>>> I'll go hook it up with one of those & try it again.
>>>
>>> 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 
>>>
>>> 
>>> -- 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
>>
>> 50 MHz will work if everything is terminated correctly and if the RSPI
>> timing is correct. (It may require using a SPI late data sample option
>> if the RSPI hardware has that option)
>>
>> Correct series termination of RSPI outputs (130 Ohm total for 0.050"
>> flat cable) depends on the output impedance of the RSPI outputs so
>> there's no guarantee that the added 87 ohms is correct (this may also
>> depend on RSPI output drive strength settings if such things exist on
>> the RSPI)
>>
>>
> All of which is UNK ATM, Peter, as I haven't bitten the bullet and
> downloaded the src for the whole thing.  One thing is surprising though,
> all the modules and such for master-sim carry a Dec 22, 2016 build date.
> I am tempted to change my apt/sources.list.d/linuxcnc file and point it
> at master-rt.  The newest hm2_rpspi I have won't even load, but its
> around 2500 bytes bigger, dated May 2, 2017.
>
> So I changed it, made no difference, apt says everything is uptodate?
> apt list shows:
> linuxcnc-doc-en/now 1:2.8.0~pre1.2771.gdc2ff49 all [installed,local]
> linuxcnc-uspace/now 1:2.8.0~pre1.2771.gdc2ff49 armhf [installed,local]
> linuxcnc-uspace-dev/now 1:2.8.0~pre1.2771.gdc2ff49 armhf
> [installed,local]
>
> ??
>
> Remove and re-install?  Or does somebody need the apply some brogan
> maintenance to the armhf leg of the buildbot?
>
> Silly Q, Peter, do I actually need a longer cable? I have NDI how long a
> cable was used when developing the OSHPark adapter and its choice of 88
> ohm resistors. Looking at the waveforms, I get the impression 68 ohms
> might be a better match.  I could throw a 10" cable together in 20
> minutes or less. I had figured the shorter the better so what I have is
> only 6 or 7". 4" didn't work, I tried that already with the Park adapter
> boards.


I doubt that longer is better, but a 68 or 50 Ohm clock series
termination resistor may be better. No idea what the RSPI output
impedances 

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Tuesday 16 May 2017 14:33:29 Peter C. Wallace wrote:

> On Tue, 16 May 2017, Gene Heskett wrote:
> > Date: Tue, 16 May 2017 13:22:59 -0400
> > From: Gene Heskett 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] switching to a slower spi driver to see if
> > it works,
> >
> > On Monday 15 May 2017 09:58:04 Gene Heskett wrote:
> >
> > I may have found it!!!
> >
> > Hooking up my scope, I discovered that the original query to get the
> > board to ID itself, IS NOT MADE AT THE SAME CLOCK SPEED IT ACTUALLY
> > OPERATES AT. THE INITIAL QUERY IS BEING MADE AT 50 MHz!
> >
> > I hung a scope probe on the clock, which due to its loading, changed
> > the shape of the waveform and made it work.  Its now running at 32
> > MHz, but I had captured the initial failure, and that was clocked at
> > 50MHz.
> >
> > Now, I'll go remove my scope probe and see if it fails.
> >
> > Better yet, without the probe it fails, with the probe on the pi end
> > of the 82 ohm terminating resistor I used in my home made adapter,
> > it works 5 out of 5 times.  Move the probe to the other end of that
> > resistor and the failure rate is 5 out of 5 times. I took some pix
> > of the single trace capture of this startup card query.  Quite a bit
> > of the voltage swing the pi is generating is being used up in the
> > resistor, at least half a volt.
> >
> > Pix on my web page at
> >  >ream-sclk.jpg> and
> >  >stream-sclk.JPG>
> >
> > I note that if it succeeds, which it seems to do with my probe
> > furnishing some initial loading, it then slows to 32MHz for the
> > clock rate.
> >
> > And, when its hooked up with the OSHPark adapter and its 86.7 ohm
> > resistors, there is not enough signal to tickle the 7i90 into
> > responding at all.
> >
> > I'll go hook it up with one of those & try it again.
> >
> > 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 
> >
> > 
> >-- 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
>
> 50 MHz will work if everything is terminated correctly and if the RSPI
> timing is correct. (It may require using a SPI late data sample option
> if the RSPI hardware has that option)
>
> Correct series termination of RSPI outputs (130 Ohm total for 0.050"
> flat cable) depends on the output impedance of the RSPI outputs so
> there's no guarantee that the added 87 ohms is correct (this may also
> depend on RSPI output drive strength settings if such things exist on
> the RSPI)
>
>
All of which is UNK ATM, Peter, as I haven't bitten the bullet and 
downloaded the src for the whole thing.  One thing is surprising though, 
all the modules and such for master-sim carry a Dec 22, 2016 build date. 
I am tempted to change my apt/sources.list.d/linuxcnc file and point it 
at master-rt.  The newest hm2_rpspi I have won't even load, but its 
around 2500 bytes bigger, dated May 2, 2017.

So I changed it, made no difference, apt says everything is uptodate?  
apt list shows:
linuxcnc-doc-en/now 1:2.8.0~pre1.2771.gdc2ff49 all [installed,local]
linuxcnc-uspace/now 1:2.8.0~pre1.2771.gdc2ff49 armhf [installed,local]
linuxcnc-uspace-dev/now 1:2.8.0~pre1.2771.gdc2ff49 armhf 
[installed,local]

??

Remove and re-install?  Or does somebody need the apply some brogan 
maintenance to the armhf leg of the buildbot?

Silly Q, Peter, do I actually need a longer cable? I have NDI how long a 
cable was used when developing the OSHPark adapter and its choice of 88 
ohm resistors. Looking at the waveforms, I get the impression 68 ohms 
might be a better match.  I could throw a 10" cable together in 20 
minutes or less. I had figured the shorter the better so what I have is 
only 6 or 7". 4" didn't work, I tried that already with the Park adapter 
boards.

Thanks for any further enlightenment you can share Peter

> 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
> 

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Peter C. Wallace]

On Tue, 16 May 2017, Bertho Stultiens wrote:

> Date: Tue, 16 May 2017 21:03:00 +0200
> From: Bertho Stultiens 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: "Enhanced Machine Controller (EMC)" 
> Subject: Re: [Emc-users] switching to a slower spi driver to see if it works,
> 
> On 05/16/2017 08:33 PM, Peter C. Wallace wrote:
>> 50 MHz will work if everything is terminated correctly and if the RSPI timing
>> is correct. (It may require using a SPI late data sample option if the RSPI
>> hardware has that option)
>>
>> Correct series termination of RSPI outputs (130 Ohm total for 0.050" flat
>> cable) depends on the output impedance of the RSPI outputs so there's no
>> guarantee that the added 87 ohms is correct (this may also depend on RSPI
>> output drive strength settings if such things exist on the RSPI)
>
> Well, in theory, that is true. I suspect that there is a phase-reversal
> problem at these high frequencies. The probe of the scope adds just
> enough capacity to delay the signal by a fraction.
>
> At 50MHz clock, you have a phase margin of <10ns. This time is consumed by:
> - the wire-connection (~2ns per meter for copper),
> - the round-trip in the slave tranceiver (the 7i90 SPI interface),
> - the RPI buffers and SPI tranceiver.
>
> Lets assume that the wire, including PCB traces etc., takes 1ns
> (roundtrip for 25 cm). The RPI buffers and shift register are probably
> around 2ns and a bit more if it contains a glitch-filter. The 7i90
> interface has both input buffer, an output buffer and at least one
> flip-flip propagation delay. My guess is that it would be about 0.5ns +
> 0.5ns + 2ns.
>
> That brings the grand total to 6ns, which is at 60% of the phase margin.
> This is an optimistic estimation where I specifically disregarded setup-
> and hold-times, which make things much worse. Assuming setup- and
> hold-margins on both ends (round-trip) of 0.5ns means adding another
> 2ns, resulting in 8ns total time and 80% of the phase margin. This is
> getting close to the failure point.
>
> Adding just a bit of capacity at the wrong place will make the signal
> (seemingly) slower because the flanks are less steep (as seen on the
> scope). This is enough to cause the system to fail.
>
> This also means that you cannot add external line-buffers on the lines.
> These would simply add to much delay at these frequencies (something
> like 6...10ns). Unfortunately, SPI is a synchronous and timing-bound
> propocol and cannot tolerate phase reversal.
>
>
> -- 
> 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
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


All fine except that Gene said that slowing the clock (with added capacitance) 
made the interface work. If this were a clock --> read data timing issue, 
slowing the clock edges with added capacitance would make things worse.

So I think its more likely a signal integrity issue, though as you say 50 MHz 
is probably pushing it. I've run the 7I90 slave SPI interface for weeks at 50 
MHz with a FPGA master, but the FPGA master has the "late sample read data" 
option, not sure the RSPI has this or if its used




Peter Wallace
Mesa Electronics


--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Bertho Stultiens]

On 05/16/2017 08:33 PM, Peter C. Wallace wrote:
> 50 MHz will work if everything is terminated correctly and if the RSPI timing 
> is correct. (It may require using a SPI late data sample option if the RSPI 
> hardware has that option)
> 
> Correct series termination of RSPI outputs (130 Ohm total for 0.050" flat 
> cable) depends on the output impedance of the RSPI outputs so there's no 
> guarantee that the added 87 ohms is correct (this may also depend on RSPI 
> output drive strength settings if such things exist on the RSPI)

Well, in theory, that is true. I suspect that there is a phase-reversal
problem at these high frequencies. The probe of the scope adds just
enough capacity to delay the signal by a fraction.

At 50MHz clock, you have a phase margin of <10ns. This time is consumed by:
- the wire-connection (~2ns per meter for copper),
- the round-trip in the slave tranceiver (the 7i90 SPI interface),
- the RPI buffers and SPI tranceiver.

Lets assume that the wire, including PCB traces etc., takes 1ns
(roundtrip for 25 cm). The RPI buffers and shift register are probably
around 2ns and a bit more if it contains a glitch-filter. The 7i90
interface has both input buffer, an output buffer and at least one
flip-flip propagation delay. My guess is that it would be about 0.5ns +
0.5ns + 2ns.

That brings the grand total to 6ns, which is at 60% of the phase margin.
This is an optimistic estimation where I specifically disregarded setup-
and hold-times, which make things much worse. Assuming setup- and
hold-margins on both ends (round-trip) of 0.5ns means adding another
2ns, resulting in 8ns total time and 80% of the phase margin. This is
getting close to the failure point.

Adding just a bit of capacity at the wrong place will make the signal
(seemingly) slower because the flanks are less steep (as seen on the
scope). This is enough to cause the system to fail.

This also means that you cannot add external line-buffers on the lines.
These would simply add to much delay at these frequencies (something
like 6...10ns). Unfortunately, SPI is a synchronous and timing-bound
propocol and cannot tolerate phase reversal.


-- 
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Peter C. Wallace]

On Tue, 16 May 2017, Gene Heskett wrote:

> Date: Tue, 16 May 2017 13:22:59 -0400
> From: Gene Heskett 
> Reply-To: "Enhanced Machine Controller (EMC)"
> 
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] switching to a slower spi driver to see if it works,
> 
> On Monday 15 May 2017 09:58:04 Gene Heskett wrote:
>
> I may have found it!!!
>
> Hooking up my scope, I discovered that the original query to get the
> board to ID itself, IS NOT MADE AT THE SAME CLOCK SPEED IT ACTUALLY
> OPERATES AT. THE INITIAL QUERY IS BEING MADE AT 50 MHz!
>
> I hung a scope probe on the clock, which due to its loading, changed the
> shape of the waveform and made it work.  Its now running at 32 MHz, but
> I had captured the initial failure, and that was clocked at 50MHz.
>
> Now, I'll go remove my scope probe and see if it fails.
>
> Better yet, without the probe it fails, with the probe on the pi end of
> the 82 ohm terminating resistor I used in my home made adapter, it works
> 5 out of 5 times.  Move the probe to the other end of that resistor and
> the failure rate is 5 out of 5 times. I took some pix of the single
> trace capture of this startup card query.  Quite a bit of the voltage
> swing the pi is generating is being used up in the resistor, at least
> half a volt.
>
> Pix on my web page at
> 
> and
> 
>
> I note that if it succeeds, which it seems to do with my probe furnishing
> some initial loading, it then slows to 32MHz for the clock rate.
>
> And, when its hooked up with the OSHPark adapter and its 86.7 ohm
> resistors, there is not enough signal to tickle the 7i90 into responding
> at all.
>
> I'll go hook it up with one of those & try it again.
>
> 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 
>
> --
> 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
>

50 MHz will work if everything is terminated correctly and if the RSPI timing 
is correct. (It may require using a SPI late data sample option if the RSPI 
hardware has that option)

Correct series termination of RSPI outputs (130 Ohm total for 0.050" flat 
cable) depends on the output impedance of the RSPI outputs so there's no 
guarantee that the added 87 ohms is correct (this may also depend on RSPI 
output drive strength settings if such things exist on the RSPI)


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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Tuesday 16 May 2017 13:22:59 Gene Heskett wrote:

> On Monday 15 May 2017 09:58:04 Gene Heskett wrote:
>
> I may have found it!!!
>
> Hooking up my scope, I discovered that the original query to get the
> board to ID itself, IS NOT MADE AT THE SAME CLOCK SPEED IT ACTUALLY
> OPERATES AT. THE INITIAL QUERY IS BEING MADE AT 50 MHz!
>
> I hung a scope probe on the clock, which due to its loading, changed
> the shape of the waveform and made it work.  Its now running at 32
> MHz, but I had captured the initial failure, and that was clocked at
> 50MHz.
>
> Now, I'll go remove my scope probe and see if it fails.
>
> Better yet, without the probe it fails, with the probe on the pi end
> of the 82 ohm terminating resistor I used in my home made adapter, it
> works 5 out of 5 times.  Move the probe to the other end of that
> resistor and the failure rate is 5 out of 5 times. I took some pix of
> the single trace capture of this startup card query.  Quite a bit of
> the voltage swing the pi is generating is being used up in the
> resistor, at least half a volt.
>
> Pix on my web page at
> am-sclk.jpg> and
> ream-sclk.JPG>
>
> I note that if it succeeds, which it seems to do with my probe
> furnishing some initial loading, it then slows to 32MHz for the clock
> rate.
>
> And, when its hooked up with the OSHPark adapter and its 86.7 ohm
> resistors, there is not enough signal to tickle the 7i90 into
> responding at all.
>
It actually is responding, but the data is trash.

With an OSHPark board adapter, I had to clip onto the back legs of the 26 
pin socket on the 7i90. The clock is there, looking pretty close to what 
I observed on the other end of the cable, but its still trash.

Houston, we do indeed have a problem, and it looks as if its a timeing 
problem between the clock, and the command data coming out of the pi, 
fixed by the 3 or 4 ns delay in the clock that hanging my scope probe on 
it is causing.

Where can I get the src for hm2_rpspi?

And who is the author?

There is also some spi related stuff in /boot/config.txt:
dtparam=spi=on
dtoverlay=spi0-2cs
dtoverlay=spi1-1cs,cs0_pin=16,cs0_spidev=disabled

but, if commented out, no video drive at all on a reboot.  Anybody 
actually know WTH it does?

> I'll go hook it up with one of those & try it again.

100% failure, but there is data flowing.  If I can find a low cap trimmer 
cap, and add it to the 40 pin side of the adapter, it might work in 
place of the probe.  But I've been out of those critters for decades. 
Picture me in the basement, frantically looking for such critters.

> Cheers, Gene Heskett


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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Monday 15 May 2017 09:58:04 Gene Heskett wrote:

I may have found it!!! 

Hooking up my scope, I discovered that the original query to get the 
board to ID itself, IS NOT MADE AT THE SAME CLOCK SPEED IT ACTUALLY 
OPERATES AT. THE INITIAL QUERY IS BEING MADE AT 50 MHz!

I hung a scope probe on the clock, which due to its loading, changed the 
shape of the waveform and made it work.  Its now running at 32 MHz, but 
I had captured the initial failure, and that was clocked at 50MHz.

Now, I'll go remove my scope probe and see if it fails.

Better yet, without the probe it fails, with the probe on the pi end of 
the 82 ohm terminating resistor I used in my home made adapter, it works 
5 out of 5 times.  Move the probe to the other end of that resistor and 
the failure rate is 5 out of 5 times. I took some pix of the single 
trace capture of this startup card query.  Quite a bit of the voltage 
swing the pi is generating is being used up in the resistor, at least 
half a volt.

Pix on my web page at 

and 


I note that if it succeeds, which it seems to do with my probe furnishing 
some initial loading, it then slows to 32MHz for the clock rate.

And, when its hooked up with the OSHPark adapter and its 86.7 ohm 
resistors, there is not enough signal to tickle the 7i90 into responding 
at all.

I'll go hook it up with one of those & try it again.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[Gene Heskett]

On Monday 15 May 2017 03:12:34 andy pugh wrote:

> On 15 May 2017 at 07:26, Gene Heskett  wrote:
> > Or is this driver simply not a compatible driver for use on a pi 3b?
>
> Have you read the manpage?
> http://linuxcnc.org/docs/2.7/html/man/man9/hm2_spi.9.html
>
> Do you have that spidev path?
>
Not visible in /dev now, but I had restored the driver string to rpspi, 
and now its reading 4 bytes of 0x00 for the name cookie.  The spi driver 
apparently left it in a state that may take a full power down to 
restore.

> The manpage says that it works with the Odroid U3, with a specially
> patched kernel.
> I suspect that with an RPi you would expect rpispi to work better.

It does work, when it works.  And it may start working at any time, and 
work for a week. The quit again for no reason. The adapter board we can 
buy from OSHPark, has never worked. Perhaps I've assembled it wrong, the 
40 pin header is on the bottom, pin 1 to pin 1, the resistors are 86.7 
ohms, and the 26 pin socket is on top of the board. With pin one in the 
pin 1 hole. The pin 1 arrangement means the cable, if using that 
adaptor, has to come off the top of the pi board, bend back down and 
dive under the pi to get to the 7i90 unless one of them is upside down. 
So the pi is on standups about 30mm tall, which allows the cable to plug 
into the 7i90. pin 1 to pin 1.

My home made cable comes across the top of the pi, then goes across the 
top of the 7i90, doing a 90 degree fold with the last inch, then hooks 
over the socket on the 7i90.  It works and then doesn't. Changing the 
7i90 makes no difference.

I did change the pi out Saturday when I found the same sd card plugged 
into a different pi would boot. I've since built up an install based on 
the 04/17/2017 raspian jessie iso, used apt to update it, then overwrote 
its kernel with a 4.4.9-rt17 kernel. It boots in half the time, and the 
keyboard is much better behaved.  But it still doesn't talk to a 7i90, 
giving the exact same error I've now posted 2 dozen times when my home 
made cable is used, or when the OSHPark adapter is in place it gets 
   0 back from the 7i90.

My cobbled up cable connects all the pi's grounded pins thru to the 7i90, 
and the 4 signal pins but nothing else. I've rung the OSHPark pcb, and 
it seems to match that same connection setup, but has never worked with 
an even shorter piece of the 26 pin cable. I've connectors, and a roll 
of ribbon cable, so today I'm going to make another 26 pin jumper about 
3" longer AND stick up some teeny loops of wire so I can get a scope 
probe onto the OSHPark pcb to see the signals on my gigahertz sampler 
scope.

And this is without any noise injecting connections to the machine, no 
outputs on the 7i90 are connected. If I can make them talk, it will 
still take me 3 or 4 days to trace out each wire and reconnect it.  And 
those 50 pin headers are such a pain in the ass I'm now waiting for 
Peter to get some 7i42TA's back in stock so I can order at least 2 of 
them so I've solid, screwed terminations to all the hookups, AND 
surge/static electricity protections on every I/O of the 7i90. What I 
have been building on perfboard works, but thats about 15 minutes a 
wire, and ugly as sin.

Putting a scope probe on my homemade cable has to be done after its 
working because even a 10x probe messes with the signal enough for it to 
make com mistakes and it will not init itself when its probed. And it 
would be very helpfull if the spi signals were better described. I 
haven't a clue which one is going which direction from the descriptions 
I've been able to find.

Would a set of 100x probes be a good buy?  MPJA did have them.  But not 
now.

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 

--
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

Re: [Emc-users] switching to a slower spi driver to see if it works,

[andy pugh]

On 15 May 2017 at 07:26, Gene Heskett  wrote:
> Or is this driver simply not a compatible driver for use on a pi 3b?


Have you read the manpage?
http://linuxcnc.org/docs/2.7/html/man/man9/hm2_spi.9.html

Do you have that spidev path?

The manpage says that it works with the Odroid U3, with a specially
patched kernel.
I suspect that with an RPi you would expect rpispi to work better.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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