Multimode SPI Implementation (SPIN2 + PASM)
greg_physics
Posts: 6
Hi All,
I've written some SPIN2+PASM code (see file links below) for handling SPI communication for a wide variety of devices. I found SPI mode 3 communication (required for the AD71240-8 adc chip of interest) to be difficult using smart pin implementations so I began development using SPIN2+PASM code primarily derived from Jon "JonnyMac" McPhalen's work. My code was written with the Propeller Tool Version 2.5.3.
A new object file 'gp_asm_spi.spin2' was used to communicate with both the P2 Edge's internal serial
flash chip (using SPI mode 0 or 3) and an external AD71240-8 adc chip (using SPI mode 3) simultaneously. Two object instances of 'gp_asm_spi' were used (spi & spi2) as different i/o pins were needed by the two SPI devices.
Code Use Examples:
SPI.start(pMISO, pMOSI, pSCK, pSPI_MODE, pSCK_KHZ) 'initialize SPI interface SPI.shiftout_msbf( value, 8) 'send 8-bit command, MSB first result := SPI.shiftin_msbf(8) 'receive 8-bit reply, MSB first SPI.shiftout(spi.MSBFIRST, value, 32) 'send 32-bit command, MSB first result := SPI.shiftin(spi.MSBFIRST, 32) 'receive 32-bit reply, MSB first
'gp_asm_spi.spin2' should support all 4 SPI modes.
Please test & provide feedback to confirm correct operation under all SPI modes.
Also please suggest code improvements. Thanks.
Comments
Hello Greg,
I've been working with a round 1.28 inch IPS screen (from Waveshare), driven by a GC9A01A controller via SPI. I've been converting their Arduino driver to spin2. Then for the communication via SPI, I started out with JonnyMac's 'jm_ez_spi.spin2', then went to Diez "deets" Roggisch 'deets_spi.spin2', and it seemed like the mode 3 was needed, but I could not get it to work at all, just a black screen. So I turned back to Arduino again and got it working on a ESP-12E NodeMCU (ESP8266), but no success on the P2 Eval RevB board I was running.. then I found this post, and man, was I happy
The driver converted from Arduino works now, with this 'gp_asm_spi.spin' for the SPI communication, I was trying to get some good video of the screen in action, but the camera looses focus all the time due to the screen's backlight beeing faded in and out using JonnyMac's 'jm_led.spi', then I guess I dropped something on the Eval board in the middle of this, It now makes a hissing noice, and the left part of the chip is getting hot as soon as I power it up.. The red diode (warning triangle) lights up etc.. Ordered a new one (Rev C) from Mouser, hope it arrives soon, don't know how fast the ship to Sweden, hopefully soon, this was fun stuff to play around with !
Thank you for publishing this code, It helped alot, awesome !
The only question I have is about max speed for clock frequence :
khz is clock frequence in kilohertz (1000 = 1MHz)
If I run the spin code with:
CLK_FREQ = 200_000_000 ' system freq as a constant
What might be the max speed this object/drive might handle, with regards of it using assembly and smart pin etc, if just shuffling out bytes directly from memory?
Some references if someone wants to use a round 1.28 inch screen with GC9A01A:
https://www.waveshare.com/1.28inch-lcd-module.htm
https://www.waveshare.com/wiki/File:LCD_Module_code.zip
I used this image converter to convert images to the R5G6B5 format:
https://lcd-image-converter.riuson.com/en/about/
Many thanks to JonnyMac and Parallax also.
Best Regards,
M.E.S.H
Hii, Is it possible to send/Receive 1MByte or 2 MByte of data using SPI protocol with in millisecond? if yes, can anyone help me.
The data rate needed to move 1 million bytes in 1 thousandth of a second is 1 billion bytes per second (8Gb/s) and this makes no allowance for overhead (commands and addressing)
Even using 8 lanes in parallel (OPI), this is beyond the capability of the interface you are asking about.
And with only 512 kByte of hubRAM there is limited space to fit such a fast burst too. The two are somewhat linked.
OK thanks @AJL @evanh ,
In my case it is not working properly. May be i am doing some mistake So please once go through my code. I am new in propeller 2 and i don't know spin2 development. So doing my development using C programing. I have taken also help from discussion (https://forums.parallax.com/discussion/174747/spi-communication-between-parallax-p2-and-raspberry-pi#latest).
#include "spi-c.h" #define CS 32 #define CLK 33 #define MOSI 34 #define MISO 35 unsigned char data[4096]; enum { _clkfreq = 200000000 }; int my_shift_in(void) { int count = 0; // bytes received while(_pinr(CS) == 1); // wait while CS high _pinl(MOSI); // enable smart pin SPI RX while(_pinr(CS) == 0) { // while CS is low if (_pinr(MOSI)) // if byte waiting data[count++] = _rev(_rdpin(MOSI)); // read, fix MSB, save to array } _pinf(MOSI); // disable/reset SPI RX return count; } void main() { DIRA = 0; int m = 0, x = 0, ret = 0; DIRA |= MOSI ; _pinclear(CS); m = P_SYNC_RX; m |= ((CLK-MOSI) & 0b111) << 24; x = 0b0_00000 | (8-1); _pinstart(MOSI, m, x, 0); while(1){ ret = 0; ret = my_shift_in(); if(ret>0) for(int i = 0; i<ret; i++){ printf("%d ",data[i]); } } }Ah, yes, there was a pending unanswered question for you in that topic. What is the desired SPI clock mode (CPOL/CPHA) of the RPi?
If you don't know then it probably also still need set at that end.
Hi @evanh ,
In Rpi side, we are using default spi clock mode 0. (CPOL = 0, CPHA = 0) but in P2 we don't know how to set SPI clock modes using smart pin.
Good. That's what the smartpin expects by default. Receiving should just work.
I should setup something here myself. I've not tried to connect a Prop2 as a slave device.
PS: Did you ever try my last posted source code?
PPS: I'm assuming the RPi has real hardware controller for SPI. As in it shifts data out on falling edge in mode 0 above. That's how a master normally functions. It's the slave that's expected to shift in on rising edge. Just there isn't any hard standard that says the master must do that.
Yes i've tried your shared source code with our setup. We are getting garbage data. I have printed the returning value of count you can see in below mentioned code. The count value varies every time.
For example,
I have sent a buffer of 256 Bytes from Rpi. sometimes getting count value = 256 but most of time getting different count value at a time. you can see in attached image.
And when i am increasing the buffer size to 512Bytes and more, then every time getting different count values.
#include <stdio.h> #include "spi-c.h" enum { // _xinfreq = 20_000_000, _xtlfreq = 20_000_000, _clkfreq = 350_000_000, DOWNLOAD_BAUD = 200_000, DEBUG_BAUD = DOWNLOAD_BAUD, }; unsigned char data[4096]; int my_shift_in(unsigned char *addr) { int data, count = 0; // bytes received __asm volatile { // no optimising and enforces Fcache use - Needed to free up the FIFO fltl #MOSI // disable/reset SPI RX .wait1 testp #CS wc if_nc jmp #.wait1 // wait while CS low wrfast #0, addr // setup the hubRAM FIFO hardware for sequencial writes dirh #MOSI // enable smart pin SPI RX .wait2 testp #CS wc if_c jmp #.wait2 // wait while CS high rep @.rend, #0 // loop forever testp #CS wz testp #MOSI wc if_nc_and_z jmp #.rend // break loop if CS high if_c rdpin data, #MOSI // collect the received byte if_c rev data if_c wfbyte data // write to FIFO (hubRAM) if_c add count, #1 .rend dirl #MOSI // disable/reset SPI RX } // returning from Fcache (cogexec) issues an implicit RDFAST (flushing the FIFO to hubRAM) //return count; printf("%d\n",count); } void main() { _waitms(200); printf( "\n clkfreq = %d clkmode = 0x%x\n", _clockfreq(), _clockmode() ); DIRA = 0; int m = 0, x = 0, ret = 0; DIRA |= MOSI; _pinclear(CS); m = P_SYNC_RX; m |= ((CLK-MOSI) & 0b111) << 24; x = 0b0_00000 | (8-1); _pinstart(MOSI, m, x, 0); while(1){ ret = 0; ret = my_shift_in(data); // if(ret>0) // for(int i = 0; i<ret; i++){ // printf("%d\n",data[i]); // } } }Dunno, I guess I have to set up a test ...
Thanks @evanh, This will be really helpful for me because I'm stuck right now.
I've written software for SPI master now but my second micro USB cable is at customer site, as is the soldering station and oscilloscope ...
EDIT: Testing on self, using two cogs, is working as expected. I've reused part of my recent PSRAM work to produce an ideal SPI mode0 output signal. Whereas a smartpin's Sync TX mode is known to phase lag by a few sysclocks.
I guess I should advise same as with Chintan, it's possible I didn't need to do this demo. You may just need to update to newest Flex compiler - https://forums.parallax.com/discussion/comment/1543685/#Comment_1543685
Hii @evanh ,
I have tested this code with our Rpi and P2 setup in flexProp (version 5.9.17).
I am seeing that, when i am changing the frequency of Rpi (Previously was 5Mhz) to 1Mhz and buffer size set to 256 bytes where P2 frequency is 4Mhz then sometimes I'm getting correct data and if i increasing the buffer more then 256 bytes (ex: 512Bytes, 1024 Bytes .. ) then data getting mismatched . I have also tried with different frequency ranges but result getting same.
The RPi might be the problem then.
PS: I'm planning on testing with two independent boards with different clock sources using a short SPI link between them tomorrow, ~12 hours time.
Here's another test self edition that is doing a 4000 byte block copy using random data over 1-bit SPI at 25 MHz SPI clock rate, then comparing each byte (longwords more accurately) between the copies.
Oh, there is a streamer limit of 64 k transfer cycles per command. That means current max block transmit length is 8 kbytes.
Okey-dokey, it's amazing how different the behaviour is when linking two boards! Noise looms large! First attempt was almost like random data, but not quite. The incrementing count data did show through a little.
First fix was to switch on registered I/O ... bam! perfect outcome. It felt too good to be whole answer though. It's gotta be telling ... Clearly a sampling aliasing thingy. So, on that note, next angle is to engage the debounce hardware circuits ... and the built-in Schmitt Trigger circuits too ... oh, yeah, Schmitt Triggers are the big fix.
So, ground bounce is likely your big problem. The hard digital edges are so strong the cable can't hold a steady ground reference. Lowering the pin drive strength could be an improvement ... Another approach is go differential pairs. That removes the pin drivers from inducing ground bounce.
I've tested both now. Prop2 can do either without any interfacing chips. Longer cables will require differential wiring. Shorter cables can get away with just Schmitt Trigger.
Here's the RX programs. You'll need to modify them or your TX program to suit the pinout and compare function. My TX program adds four bytes to the start of the data block.
EDIT: Err, I've got a smartpin repetitive sequencing problem I think ...
EDIT2: Intriguing, seems I'm getting some sort of clocking issues when RX sysclock is at or above 300 MHz. Doesn't matter what I do with input filtering. Not sure ...
EDIT3: Grr, the streamer/FIFO in my TX program is doing something very unexplainable but very repeatable ...
EDIT4: Working around the streamer issue for the moment - Schmitt inputs are definitely far faster than comparator inputs. I've gone to 100 Mbit/s with Schmitt inputs - Nyquist aliasing limit is rearing up above this rate. Differential input signalling using comparator inputs fades into noise above 35 Mbit/s. Which means my above assertion about Prop2 being natively good for differential inputs is not correct.
EDIT5: Bah! It is the RX smartpin sequencing after all. Enabling it early is glitchy on first data. It's reliable afterwards though since that was my workaround - repeat the same packet.
I've found a series ~120R drive side resistor can help push up workable cable lengths, as the Pi-side will likely lack fine driver strength control.
Maybe this thread can be split, as the OP posted example code in 2021 then another poster asked a Rpi specific use question ?
I'm not sure if the poster in the other thread, is the same as this one ?
Right, took some troubleshooting but got it robust now. I've had to revert to the original late enable of the smartpin. It's too easy for the smartpin to collect spurious clock pulses otherwise. As a result I've now engaged the use of SE4 event source to minimise the time between CS falling and the smartpin getting enabled.
Enjoy
EDIT: Got an idea already
... use the A/B logic on the clock input ... nope, that didn't work. %FFF logic function doesn't carry to other smartpins. duh.
PS: At 300 MHz sysclock, and as a guess, this current approach probably needs about 10 ns between CS falling and first rising clock. If the RPi is quicker than that then it'll be a mess due to the smartpin being disabled during the first SPI clock pulse.
You reminded me to double check my earlier finding ... turns out none of the those noise reduction fixes are actually needed. I'll keep them in place though.
Everything comes back to the TX pin initialising conditions. The RX program could pick up spurious clocks which resulted bytes being offset. Because earlier I was only testing a single block per compile/run meant I was getting good and bad results in varying amounts. Had me chasing my tail.
Things only came together after I was looping the TX rpogram to send multiple data blocks.
Doesn't clearly explain why shorter blocks tended to have better outcomes but I do know shorter wasn't any guarantee of a pass.
Got an update that should handle the tightest clock start on CS falling. It requires building flexspin from today's bug fix though - https://forums.parallax.com/discussion/comment/1543804/#Comment_1543804
EDIT: Extra comments in source
Hii @evanh ,
I have testing this source code. Here, I'm not getting count value. This spi_shift_in() function not returning count . I have also checked my hardware (may be issue in wiring) and from old code I'm getting the count value(not correct).
I gather that means you've compiled Flexspin yourself? If not then that program will be buggy. It'll do random things as it is truly crashing from the JSE2/JNSE1 instructions branching off to unknown addresses.
You'll need to check over the ENUMs. I've not tried to follow your setup so the pins won't suit.
The file posted a few posts back named "spi_shiftin_Schmitt.c" is limited to minimum clock delay of 33 ns after CS falling edge, not the guessed 10 ns I'd posted with it.
The newer "spi_shiftin.c" handles at least down to 5 ns. That's the fastest I tested (100 Mbit/s), just completed now, with a crafted streamer data pattern containing all three pins to control those timings. It should be fine even at 0 ns.
What the latter program won't handle is a pre-ambled continuous clock leading CS falling. At least not at speed. I don't think proper SPI controllers ever do that though.
Here's a patched version of the latter program that compiles correctly with the unfixed Flexspin:
Grr, that's still not reliable with tight start timing. It can miss the start CS low edge somehow, I'll try using level event instead of edge event ...
EDIT: Okay, looks like it's more about the CLK event getting tied up on fast toggling before the CS event can get a leg in. I've replaced the SE2 event with a PAT event instead. It's behaving correctly now with the more substantial testing today. Have to say, SETPAT is a little messy to use though.
EDIT2: Added the partnering tx shiftout.c that produces the tight timings of full SPI Master hardware, and the patched rx shiftin.c that compiles correctly with current release of Flexspin.
Man, it's a lot of detail to manage that single state change in a timely manner. I never imagined handling SPI Slave operation would need such attention using a smartpin. I've learnt now that a bit-shifter without a reset input fails the minimum SPI requirement. In hindsight, no wonder it didn't work initially.
The weirdest thing ... I can't replicate the mishandled CLK glitches any longer. I've gone back to post #24 and removed the deglitcher code. So now it just simply waits for CS low to start. It works nice and clean.
Must be the tx program working better maybe ... yep, an intentionally inserted CLK glitch during CS high does the job of fooling the rx code when the deglitcher is missing.