ez_spi question

kwagner · 2026-04-03 15:35

I'm trying to use the ez_spi driver in a program and getting some confusing results. Trying to get to ground level in troubleshooting, I'm testing the following:
repeat i from 0 to 9 spi.shiftout(spi.LSBFIRST,i,8)

So the values I should get on my logic analyzer are 0,1,2,3,etc.
Instead, it appears the first bit is at the end, but everything else is in alignment.
So my values (bitwise) on the line look like:
00000000
00000001
10000000
10000001
01000000
01000001
11000000
11000001
etc

If I instead switch to MSBFIRST, it looks like I have a padded 0:
00000000
00000010
00000100
00000110
00001000
00001010
00001100
00001110
etc

The results are the same even if I put it to 32 bits (just more empty bits in between). I'm using flexprop for compilation so I'm not sure if there's a bug in that or I'm doing something wrong. I grabbed the ez_spi driver from the obex, but it also was last updated in 2020, so not sure if something changed between then and now as far as smart pins or hardware goes?

Any help would be appreciated.

Rayman · 2026-04-03 15:40

You might try messing with the SPI clock frequency... Things can go wrong if too fast..

Also, the SPI mode should match the analyzer..

I'm using JM_SPI.spin2 and it seems to work. Although defs for sdo and sdi seem backwards to me..

kwagner · 2026-04-03 15:47

My frequency is 1MHz, I tried lowering it to 100kHz with the same results.
Here's a pic of what it looks like on the analyzer for LSBFIRST (ignore the two noise bits from me breaking out the signals)

JonnyMac · 2026-04-03 21:30

I'm using JM_SPI.spin2 and it seems to work.

FTR... I don't use jm_spi.spin2 anymore -- it's a very old program and was trying to do everything for every situation, which usually results in everybody being unhappy.

Although defs for sdo and sdi seem backwards to me.

I've also dumped the politically-correct nomenclature in my code and gone back to MOSI and MISO which are nom-ambiguous.

My frequency is 1MHz,

How did you start the SPI object? In the future, I suggest you archive and upload troublesome code for others to run.

@kwagner There were a few things I didn't like about jm_ez_spi.spin2 so I saved it with a slightly different name, jm_ez-spi.spin2 (note dash replaces underscore) to prevent breaking other programs and I updated to my current liking. I did a quick demo with shiftout() and it works fine. And while I feel no responsibility to make my code work with FlexProp, I did run this demo through it and it works fine as far as I can tell. Below you see images from my LA using Spin Tools (interpreted) and FlexProp (compiled). Since the SPI clock is running a fixed rate via a smart pin the place to see the difference is in the time the CS pin spends low.

shiftout() demo in Spin Tools

shiftout() demo in FlexProp

I also tested the object using the P2 flash so that shiftout() and shiftin() could be tested. It works fine Spin Tools and FlexProp.

Flash demo in Spin Tools

Flash demo in FlexProp

JonnyMac · 2026-04-03 22:29

@kwagner said:
My frequency is 1MHz, I tried lowering it to 100kHz with the same results.
Here's a pic of what it looks like on the analyzer for LSBFIRST (ignore the two noise bits from me breaking out the signals)

Is there any chance you're running an inexpensive logic analyzer (I got one from Amazon for $13) and using PulseView? Based on your screen cap, I gave my cheap LA a try and it acted like what you're seeing. Clock and CS signals are fine, but MOSI is garbled. As the cheap LA will look like an old Saleae device in their software, I tried that, too, and got the same garbled results. I can't explain it. I even tried moving the MOSI pin away from the others and still had a problem. Unfortunately, PulseView doesn't work with my Logic-8 Pro so i couldn't check that.

You can see that it's fine with the 1MHz clock signal, but MOSI is broken. I think it has something to do with the way the device samples the bus. I have an idea that I will try after lunch.

JonnyMac · 2026-04-04 05:56

I'm using flexprop for compilation so I'm not sure if there's a bug in that

After experimenting this afternoon I am convinced that the problem is your logic analyzer. Given the way smart pins operate I thought I'd try an inline PASM approach; it seems to work, probably because the inline PASM code has more breathing room between the MOSI output and the rising edge SCLK signal -- this seems to make a difference with the low-cost LA using PulseView. In this capture I'm running SPI at 1MHz.

Please give this new object, jm_ip-spi.spin2, a try in your project. I hope this helps.

As before, I tested it with the flash interface. It works, too.

Rayman · 2026-04-04 11:15

That should fix it. The code @kwagner was using didn’t seem to set mosi before the rising edge of sck….

Seems in spi mode 0 the data is sampled on the rising edge of sck. The data @kwagner showed seems to look bad….

But maybe the logic analyzer was doing something weird. A very slow spi clock maybe shows something different?

ez_spi question

Comments