hspiout (@ptrinc,@ptrinc...)

[Jeremy Leach]

The syntax checker likes this, but I just want to check this is really valid for a 28X2? Nice if it is, because it will allow up to 256 bytes of scratchpad to be dumped via spi . Anyone know for sure? Thanks.

 

[hippy]

Should work ... of course the only way to prove it does ...

 

[Jeremy Leach]

Ok, trying to prove it, but have stumbled right away. This doesn't work ..

#picaxe 28x2
'TEST OF HSPIOUT ON 28X2
'=======================
'8MHz Default clock
hspisetup spimode00,spifast
hspiout (3)
Sertxd ("Done!")

Firmware B.1 on 28X2. If I rem out the hspiout (3) it displays Done as expected. No connections to any of the spi pins, just trying to do a test first. Any ideas, have I done something stupid?!

 

[Technical]

You can't test hspi if nothing is connected. If you have nothing connected, the hspiout simply can't function. Therefore the chip will continue trying to hspiout for up to 2.1s. After this timeout the PICAXE gives up and resets.

 

[Jeremy Leach]

I'm probably showing my ignorance here, but I don't get this . I can't see why there needs to be any connection, because as I understand SPI there isn't any handshaking, it just receives data on Master's SDI (if any) while it transmits on Master's SDO.

If there's no connections on the pins then I'd have thought the SpiCLK and SpiSDO on the 28X2 would just function and the fact that there isn't any signal coming in on the spiSDI wouldn't matter.

EDIT: I need to understand this because I'm wanting to just serially dump data to a device that just uses the clock and data lines and doesn't send any data back. The data is just a stream of bytes/bits with no start/stop/parity.

 

[Technical]

The hspi module always enables the hspiin (SDI) pin whether you intend using it or not. If this pin is simply left floating it will at random float high and low and hence look like it is sending data into the hpsi module. This will then generate a 'fault' condition within the hspiin module, even if the module is just sending data via hpsiout commands.

To do what you are wanting to do you might get away with permanently pulling the hspiin pin to the default low/high condition (polarity varies with the different modes). But leaving it unconnected (just floating) will definately not work.

 

[Jeremy Leach]

Thanks - I need to have an indepth read up about SPI, because I still don't understand why random received data would generate a fault

Is it because the master and slave are in a ring and the slave sends back the byte that the master has just sent and the software in the master does a check to see if the slave received the byte correctly, and generates a fault if not?

ALSO ... "spifast (clock freq / 4 ) (= 1MHz with 4MHz resonator)"
Could you possibly explain how the picaxe processes the hspiout command to be able to acheive this data rate? If there's a picaxe basic command with a load of data (including some @ptrinc etc), does the interpreter do some preprocessing to prepare all the data, and only then blast the data out using spi?

If this isn't the case then I can't see how @ptrinc in the data stream could be interpreted fast enough.

 

[Jeremy Leach]

Even reading the microship datasheet for the PIC18F2520 (page 161 onward) I can't see why garbage input data would stop Master SPI working at the lowest level. I must be missing something !

 

[hippy]

I believe the random receive data issue is a 'feature' of the way Microchip implemented the SPI interface.

On SPIFAST, I may be wrong, but I understand that to be the data rate for each byte sent, not the data rate over a burst of bytes. I believe it's similar with HSEROUT, you can set a 1Mbps baud rate ( 1us per bit ) and each serial byte will go out with 1us per bit, 10us per byte, but you won't send two bytes in 20uS because it does take time to fetch the next byte.

HSPI and HSEROUT advantages are that once the byte to send is dropped in the 'letter box' for sending the PICAXE can continue with getting the next data, obeying the next command, while the sending happens in parallel. Maximum throughput is achieved when the time taken to get the next byte is the same or less as the time it takes to send. When the new byte can be sent a new byte is ready to be sent. When you have a 'super-fast postman' picking up and delivering the throughput is limited to how quickly the next byte can be readied, even though the postman delivers each blindingly fast.

 

[Jeremy Leach]

Ok Hippy, I get the data-rate side of things, and it makes sense. So the picaxe interpreter (postman) 'probably' just trundles through the data in the basic statement sending spi a byte at a time, getting the letters from all different sources (scratchpad via @ptrinc etc) as necessary. He might even get interrupted and go off and do something else for a while ?

I still don't get the 'garbage on Spi' issue though. I've just tied the Spi low (via 10k resistor) and the code still doesn't get past the hspiout statement. And there isn't any timeout.

I can see that IF there was a software protocol built on top of the low level Spi, that did some sort of handshake with the slave to confirm data, then lack of meaningful data coming back on spi would cause an issue.

 

[hippy]

Think more of the PICAXE having a secretary who collects mail form variables and @ptrinc etc, posts into the letter box ( the SPI hardware ) and the postman only works within the SPI hardware itself, feet-up and idle when nothing to do, working at SPIFAST / SPISLOW rate when mail arrives at his side of the letter box. The secretary posts the mail, goes off and does something else, working at SETFREQ rate.

I don't fully understand ( nor investigated ) the SPI issue myself but the problem as described does seem to manifest itself when trying to use the SPI as output only but not when connected to SPI chips which provide data clocked back at the same time as data is being put out.

 

[Jeremy Leach]

I've looked at the datasheet for the 25LC160 SPI EEPROM to understand the signal flow for when a microcontroller writes data to the EEPROM via spi. There's no return of data during a write unless the software wants to inspect the Status register in the EEPROM.

But the picaxe hspiout command is general and not a hspiWriteToEeprom specifically for EEPROMs- so it's not like there's any expected data to be returned from the slave. So I really can't see why the SPI data matters when you are sending

 

[Technical]

No matter how much you argue the theory, you can't get past the way that Microchip has implemented the silicon. If the SDI is in the wrong state the silicon, quite correctly, assumes there to be a fault condition on the SPI bus and hence stops sending data until the fault is cleared. There is nothing wrong with this logic - it is correct.

 

[Jeremy Leach]

I'm not just going by theory - I might be missing it but I can't see in the PIC18F2420/2520/4420/4520 datasheet (page 163 onward) anything that mentions the SDI should be in a particular state during/after the master transmission on SDO. That's why I'm puzzled.

I haven't got an SPI device at the moment, to see if my test code works with it and doesn't without it attached.

What I was hoping is that if I understood why it doesn't work then I could understand how to make it work for my purposes (or accept it can't work)!

 

[Technical]

I'm not just going by theory - I might be missing it but I can't see in the PIC18F2420/2520/4420/4520 datasheet (page 163 onward) anything that mentions the SDI should be in a particular state during/after the master transmission on SDO.

There are lots of things that are not mentioned in the datasheets. Just because they are not there doesn't mean they are not true.

We have done hours of testing with spi devices in assembler code. If the SDI pin is floating the internal module goes into error condition. We do not understand why you find this so strange - if an SPI input is changing state when no clock is being output on a real system there is quite definately a fault on the bus. It is therefore quite proper and correct then that the device errors and refuses to output any more data until the error condition is cleared.

 

[Jeremy Leach]

Yes, but when I tied the SDI to ground via a resistor (so it's not changing state) it didn't work either (at spifast).

However, there's more to this. I've found it DOES work when I use spimedium and spislow, rather than spifast, even with the pin floating. So, to recap, I've got a 28X2 running at default 8MHz. Here's some test code...

#picaxe 28x2
'TEST OF HSPIOUT ON 28X2
'=======================
'8MHz Default clock
Main:
 'Test spiSlow
 hspisetup spimode00e,spislow
 Gosub Test256K
 
 'Test spiMedium
 hspisetup spimode00e,spiMedium
 Gosub Test256K
 
 'Test spiFast
 hspisetup spimode00e,spiFast
 Gosub Test256K
End

Test256K:
 Sertxd ("Start...",cr,lf)
 For b0 = 1 to 10 
  
  For b1 = 1 to 100
   hspiout (@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc)
  Next
  
  Sertxd (#b0,cr,lf)
 Next
 Sertxd ("Done. SPO 256000 bytes",cr,lf)
 Pause 4000
Return

When it gets to the test for spifast it just resets.

Timing with stopwatch I get:
51 secs for 256000 bytes at spislow = 5019 bytes per second
38 seconds for 256000 bytes at spimedium = 6737 bytes per second.
All bytes are sent from Scratchpad using @ptrinc.

I'm not sure if the bytes are being sent correctly, this is the next thing!

 

[inglewoodpete]

For the excercise, what happens when you connect the SPI-Out and SPI-In pins together and send at spifast? The high speed data being sent should be exactly what the reciever is expecting.

 

[Jeremy Leach]

Nope I thought of that Pete, and I read on the Microchip forum yesterday that some people do this for different reasons. I connected a 2k2 resistor between SDO and SDI but my test code still resets at spifast.

I admit I hadn't tested my code at slower spi speeds until yesterday - I was just assuming that because I was only running the picaxe at default 8MHz then spifast would have no problem. I've not got a way at the moment to test the data is being sent out correctly at slower speeds but I'm assuming that if the picaxe code runs then it's working.

To me, the whole thing about whether SPI transmission should work if there's no actual data coming into SDI is probably a red-herring - everything points to it will work (this seems to be confirmed by a post I raised on the Microchip site yesterday). I can understand why floating SDI pin could be detected as a fault condition and stop it working. So this makes me think there's some sort of issue with the picaxe spifast setting - perhaps some issue with the picaxe low level interpreter interacting with the MSSP and perhaps causing write collisions ??? Just guessing !

I'd like to test the picaxe at higher clock speeds and see if spislow and medium still work - but I've only got a 16MHz crystal which won't work with the 28X2 if the PLL multiplies by 4 (manual says max clock on 28X2 = 40 MHz).

 

[Technical]

As we've already mentioned, leaving the SPI pin floating is going to cause issues at some point - it may work/may not depending on how the pin floats. However what you are trying to do should work fine if you permanently tie SPI high/low as already suggested.

Try using the number '4' rather than 'spifast' keyword as the second parameter in the setup command and see if that fixes your issue with spifast.

10MHz is indeed the fastest resonator to use with that chip (10x4=40)

 

[Jeremy Leach]

Thanks Technical, using '4' instead of 'spifast' works . Great.

So now it works at all 3 spi speeds (8MHz picaxe clock) and just for the interest of it, I plotted the graph below. It shows how the processing overhead of the picaxe is eventually the limiting factor as the SPI speed setting goes up - which is what you'd expect. e.g spifast works 4 times as fast as spimedium at the hardware level on the chip, but the resulting data rate is only 8% faster.

 

[eclectic]

@Jeremy.

Based on Technical's advice re “4”,
I've slightly modified your program.

'TEST OF HSPIOUT ON 28X2
'=======================
; 28X2 3 volt version

setfreq m8 
;  THEN tried em64 

Main:
 'Test spiSlow
 hspisetup spimode00e,spislow
 sertxd ("SLOW   ") ; ***********
 Gosub Test256K
 
 'Test spiMedium
 hspisetup spimode00e,spiMedium
 sertxd ("MEDIUM  ") ;************
 Gosub Test256K
 
 'Test spiFast
 hspisetup spimode00e,4;   spiFast *************
 sertxd ("FAST   ") ; *************
 Gosub Test256K
;End
goto main ; *****

Test256K:
 Sertxd ("Start...",cr,lf)
 For b0 = 1 to 10 
  
  For b1 = 1 to 10 ;0; 0 ****************  to speed up readings
   hspiout (@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc)
  Next
  
  Sertxd (#b0," ") ;****************************
 Next
 Sertxd ("Done. SPO 256000 bytes",cr,lf) ;************
 Pause 4000
Return

28X2 3 volt version.
SDI (leg 15) grounded via 4k7 resistor.

Hspi sck (leg 14) to 'scope.

Plenty of activity on the sck pin,
and NO resets.

Pics show results at 8MHz and 64MHz

e

Editadded:
Just noticed that you've answered.

 

[Jeremy Leach]

Hey, nice one e ! Your results don't show the actual timing @64MHz though - would be interesting. i.e get stopwatch and see how long each takes. I know could do it in more scientific ways, but I was only interested in a rough feel for the speeds, not precision

 

[eclectic]

@Jeremy

Rough timings, via uncalibrated/butterfingers stopwatch.

Using this program, and timing between
“Start” and “Done”

#picaxe 28x2
'TEST OF HSPIOUT ON 28X2
'=======================
; 28X2 3 volt version

setfreq em64
;  THEN tried m16,Em32, Em64) 

Main:
 'Test spiSlow
 hspisetup spimode00e,spislow
 sertxd ("SLOW   ") ; ***********
 Gosub Test256K
 
 'Test spiMedium
 hspisetup spimode00e,spiMedium
 sertxd ("MEDIUM  ") ;************
 Gosub Test256K
 
 'Test spiFast
 hspisetup spimode00e,4;   spiFast *************
 sertxd ("FAST   ") ; *************
 Gosub Test256K
;End
goto main ; *****

Test256K:
 Sertxd ("Start...",cr,lf)
 For b0 = 1 to 10 
  
  For b1 = 1 to 100; 0 ****************  to speed up readings
   hspiout (@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc)
  Next
  
  Sertxd (#b0," ") ;****************************
 Next
 Sertxd ("Done. SPO 256000 bytes",cr,lf) ;************
 Pause 4000
Return

e

 

[Jeremy Leach]

That's great. Deserves a new graph !! ...
Well at least it's a reference if anyone else is interested (if I've plotted it correctly!).

EDIT: Got to point out that this is based on test code above, which is totally about transferring data from the scratchpad using @ptrinc. I 'guess' the results might be even faster for just raw data in the hspiout command, although I'm not interested in this myself at the moment (if you want to test then I can plot results though!) Oh, and it's only approximate timings !

 

[hippy]

I 'guess' the results might be even faster for just raw data in the hspiout command

Probably, but perhaps not a great deal faster. Using @ptrinc involves fetching the token which indicates '@ptrinc', getting the data pointed to, passing it to SPI hardware, updating the pointer, check for wrap-round, write the pointer back. For variables it's get the token, find what it represents, get the data, put to SPI hardware, for constants it's more simply get the token value, put it to SPI hardware.

Around 50,000 bytes per second is 20us per byte which isn't bad, that works out at 320us per byte at 4MHz which is in the ballpark I'd have expected to handle an '@ptrinc' as described above.