SPI Coms: Smart Pins vs Bit-Banged

Comments

• cgracey Posts: 14,133

  2020-09-01 18:00 edited 2020-09-01 18:01

  In the 2nd-stage flash loader, the CK pin is transitioned once every system clock and DI is read on every 2nd system clock, where the bits are assembled into bytes and written into hub RAM. This works at 20MHz, but wouldn't work at 300MHz because of pin delays and SPI flash limitations. It uses a smart pin in 'transition' mode to drive CK and uses the streamer to read bits in from DI and write them into hub RAM.
  

  '
  '
  ' Read in remaining application longs (read command $03 already issued to flash)
  '
  		wrpin	#%01_00101_0,#spi_ck	'set spi_ck smart pin for transitions, drives low
  		fltl	#spi_ck			'reset smart pin
  		wxpin	#1,#spi_ck		'set transition timebase to clk/1
  		drvl	#spi_ck			'enable smart pin
  
  		setxfrq	clk2			'set streamer rate to clk/2
  
  		wrfast	#0,##$400-app_start*4	'ready to write to hub at application continuation
  
  .block		bmask	x,#10			'try max streamer block size for longs ($7FF)
  		fle	x,app_longs		'limit to number of longs left
  		sub	app_longs,x		'update number of longs left
  
  		shl	x,#5			'get number of bits
  		setword	wmode,x,#0		'insert into streamer command
  		shl	x,#1			'double for number of spi_ck transitions
  
  		wypin	x,#spi_ck		'2	start spi_ck transitions
  		waitx	#3			'2+3	align spi_ck transitions with spi_do sampling
  		xinit	wmode,#0		'2	start inputting spi_do bits to hub, bytes-msb-first
  		waitxfi				'?	wait for streamer to finish
  
  		tjnz	app_longs,#.block	'if more longs left, read another block
  
  		wrpin	#0,#spi_ck		'clear spi_ck smart pin mode
  '
  '
  ' Verify application checksum
  '
  		rdfast	#0,#0			'sum all application longs
  		rep	#2,app_longs2
  		rflong	x
  		add	app_sum,x	wz	'z=1 if verified
  
  stop	if_nz	fltl	#spi_di addpins 2	'if checksum failed, float spi_cs/spi_ck/spi_di pins
  	if_nz	hubset	#%0010			'..and stop clock until next reset
  
  		coginit	#0,#$00000		'checksum verified, run application
  '
  '
  ' Data
  '
  clk2		long	$4000_0000		'clk/2 nco value for streamer
  wmode		long	$C081_0000 + spi_do<<17	'streamer mode, 1-pin input, bytes-msb-first, bytes to hub
  
  zeroa						'(used by programmer as long 0)
  app_longs	long	0			'number of longs in application		(set by programmer)
  zerob						'(used by programmer as long 0)
  app_longs2	long	0			'number of longs in application		(set by programmer)
  zeroc						'(used by programmer as long 0)
  app_sum		long	0			'-sum of application longs		(set by programmer)
  x						'(used by loader as variable)
  loader_sum	byte	-"P",!"r",!"o",!"p"	'"Prop" - sum of $100 loader longs	(set by programmer)
  

  
  The four instructions from WYPIN to WAITXFI form the code that reads in up to 65,504 bits at a whack from the flash chip. That's one byte every 16 clocks.
  
  Here are the program and boot times from the flash loader, assuming a 20MHz RCFAST clock, which is actually more like 24MHz, but that wouldn't speed up programming, only booting:
  

  '			program		boot
  '	bytes		time		time
  '	-------------------------------------
  '	0..2KB		30ms		10ms
  '	   4KB		60ms		11ms
  '	   8KB		94ms		14ms
  '	  16KB		170ms		20ms
  '	  32KB		200ms		30ms
  '	  64KB		300ms		52ms
  '	 128KB		570ms		95ms
  '	 256KB		1.1s		184ms
  '	 512KB		2.2s		358ms
  
• JonnyMac Posts: 8,927

  2020-09-01 18:03 edited 2020-09-01 18:08

  I haven't figured out the streamer yet, and I wanted to make straightforward code that could be easily applied elsewhere. My generic SPI object is going to be bit-banged so that all SPI modes can be supported. I have some other objects, though -- like the MAX7219 -- that might benefit from smart pin SPI.
  
  The forums is doing that glitchy thing again where updated code doesn't show up. If you click on the data/time of the edit in my original post, the link to the code will re-appear.
• cgracey Posts: 14,133

  2020-09-01 18:13

  To use smart pins in tight places, you have to slow way down and think about your approach. In the end, the code is always short and the results are as fast as they could be, but it's hard to come up the plan. Then, it takes some experimentation to get a handle on it.
  
  When Jon and I spoke about this yesterday, we were talking about using the 'synchronous serial' smart-pin mode for this job, and my mind immediately got plugged up with details that would need to be worked through. Eventually, we will have enough samples and documentation that all the difficulty will be tamed, but for now it's still challenging. Part of my mental block was that I remembered that I used the 'transition' smart-pin mode and the streamer to accomplish all this in the flash loader, with the added benefit of having the streamer handle all the data I/O to and from hub RAM, without any extra activity in my code. So, I was kind of spoiled with one solution that I know works best for flash I/O.
• JonnyMac Posts: 8,927

  2020-09-01 18:28 edited 2020-09-01 18:28

  What was ultimately kicking me around was that I left the DO and DI smart pins enabled when I wasn't using them. Being attached to SCK, this created problems. The current code disconnects DO when not in use, and resets DI just before use to clear the internal result before the clocking starts.
  
  While frustrating, this turned out to be a worthwhile learning experience, and now there is a bit of code in both styles (bit-bang vs smart pin) and languages (Spin2 vs PASM2) that may help others get into the grove.
  
  Ultimately, a flash object will benefit from a very fast sector<-->buffer transfer. I'm going to do it with the code I have, then may ask for help in updating it to use the streamer.
• Ariba Posts: 2,682

  2020-09-01 18:52 edited 2020-09-01 18:54

  The biggest disadvantage of the smartpin solution is that the clock at input B can be maximum 3 pins away from the datapin. This means that an SPI driver with smartpins is not universally usable.
  And smartpin SPI only works up to 1/5 or 1/6 of the system clock, while bitbanged, or with Streamer together with a smartpin for clocks can go up to 1/2 sysclock and has no pinlayout limitations.
  But for inline assembly-SPI for SD cards smartpin SPI is probably still the best solution.
  
  Andy
  
• avsa242 Posts: 430

  2020-09-01 20:44

  Yeah I've run into the pin layout issue, too. In my library, I have a smartpin-based SPI engine (fastspin) that I've tested to 25MHz (with an SSD1331 OLED, IIRC) https://github.com/avsa242/p2-spin-standard-library/blob/testing/library/com.spi.spin2. There have been a few devices I couldn't get it to work with, though, and the on-board flash chip was one of them - and I think it was due to the pin-relationship limitation. It's also limited to mode 0, at the moment, so it could definitely use some work.