Hello,
I'm trying to port the SigGenerator to a Picomite. Changes are done and the programm runs, but only the AD9833 doesn't work, no output.
The AD9833 works correct in a testcase on an Arduino nano with bitbanging SPI.
So the only difference is in handling the clock signal of SPI. Picomite let the CLK go low in idle mode and comes up only short before sending data.
The AD9833 datasheet states the CLK has to be high when FSY (CS) goes low. This is not the case on Picomite.
I modified the testcase in the way the Picomite SPI communicates and the AD9833 has no output.

Does the SPI on Picomite works as designed?
Any workaround to get the AD9833 work?
Any help is appreciated!  Tks
Regards redtif

I wonder if you should be using Mode 2 or Mode 3? SCLK would idle high then. If CS falls first then that fulfills the requirement. Then you need to figure out whether data is captured on the falling or rising edge to figure out if it's Mode 2 or Mode 3.

The Pico SDK doesn't appear to set the clock up until the first use of the bus. The workaround is to do a dummy transaction with CS high before you first use it for real

e.g.

Ah... that's interesting to know.

Might this explain why some SD cards don't respond the first time after powerup but are fine thereafter?
Might it be worth using Peter's workaround in all programs using SPI?
If so it may be worth a note in the manual.

Could it eventually be built into OPTION SDCARD?
Edited 2022-06-16 08:37 by phil99

The SDcard SPI is bitbanged, it doesn't use the on-chip SPI modules so I suspect that it's probably being handled correctly for the SDcard standard as it is.

Thanks for the reply.
I have leant to allow for it anyway, using "On Error Skip : Files" before the main loop and ignoring the output.

I find it interesting as I've never had that problem at all. I've had two microSD cards that wouldn't work via an adapter in a ILI9341 display, but that was fixed by shorting out the series resistors on the data lines. I've never had cards that didn't initialise though. The other thing is, it depends on the supply voltage circuitry. Peter uses a 2R2 resistor and a capacitor to allow some surge when writing. I wonder if that's done on your board?

All the methods Peter and others have used to get best results have been tried. None have changed this odd behavior, They work fine in all Win and Linux PCs and on the second and subsequent accesses on a Pico, just not the first try.
Have yet to see if Peter's latest beta changes anything.
.
Edited 2022-06-16 23:15 by phil99

Are you having this problem with just one SDcard (or one make and type) on the Pico? Have you tried others? It's starting to make me wonder if it's a hardware timing issue on the card itself. Have you tried the same card on any other MMBasic platform?

It's just two SD cards. One, a Canon 128MB standard SD does it on all and a SanDisk 16GB uSD just on the Pico.
As I have learnt to live with it and no one else is seeing this it probably isn't worth the investment in time to go any further with it.

The Canon doesn't surprise me that much as it will be badge engineered - you don't know who made the memory in it - and it's possible that Canon don't either! The SanDisk does surprise me as they seem to have tight control over their memory sources (I'm not certain that even they actually have their own chip fab though).

If you have a scope it would be instructive to watch the supply voltage actually on the pins of the card socket (solder wires on, don't rely on holding probes, keep them as short as possible and also use the card's GND connection). Watch for a negative-going glitch caused by a high start-up current. You could try soldering 100uF across the card supply pins. Apart from that I can't really think of anything else, after all, they work after a failed initialisation.

@ matherp

Thanks, this worked with AD9833. I've still some more problem with the breakoutboard. There is no output after the opamp. Directly from the AD9833 it's ok.
I will investigate.

  matherp said  

The Pico SDK doesn't appear to set the clock up until the first use of the bus. The workaround is to do a dummy transaction with CS high before you first use it for real

e.g.

setpin cspin,dout
pin(cspin)=1
setpin 4,5,6,spi
spi open 1000000,3,8
spi write 1,0
'
' now the clock will be high
'

I found one more different behavior at the pin init.



This doesn't work. The pin for FSY is again low after the SETPIN!
After some testing I commented out the SETPIN. It's not needed in this case!


Thanks for your support!

If I got it working on the Picomite, I will post the adapted code here.

Rgds

Short update, had HW problems with both AD9833 modules. I fixed them by resoldering ICs.
Tomorrow I'll test them with picomite.

Rgds redtif

Last problem to fix was the SETLEVEL sub. No output, but in the test scenerio the Board works well.
Solved by changing the SPI Mode for the MCP41010 to 3, as the datasheets direct.
Originally in Geoff's code it is mode 2!

I will do a complete check now. After that a code cleanup and I post it

rgds

Finally I've got all function to work except the last sweep option is suppressed, because it rebooted (watchdog?). Reason unknown to me. Maybe a SPI clockspeed of 13 Hz is to slow?
Anyway here is the code if anyone find it useful.

SigGenerator_PM.zip

  matherp said  

The Pico SDK doesn't appear to set the clock up until the first use of the bus. The workaround is to do a dummy transaction with CS high before you first use it for real

e.g.

setpin cspin,dout
pin(cspin)=1
setpin 4,5,6,spi
spi open 1000000,3,8
spi write 1,0
'
' now the clock will be high
'

3 years later . .

Thank you for posting about this SPI issue. I was about ready to tear my hair out when I stumbled across it. Output from an AD9833 the moment I tried it.
Using PicoMite 6_0_3 so no fix yet, but your workaround is great

SMO

Maybe this issue and the workaround should be noted in the manual. It seems that would save lots of wasted hair ....  

I ordered a AD9833 board, just to play with...

Volhout

Have you seen this thread?