Has anybody got a Picaxe to read/write serial RAM using SDI or SQI mode ?

[Buzby]

I'm looking to build a project that will need a lot of RAM. One chip I'm looking at is the 23LC1024.
This chip supports 'normal' SPI with 1 bit per clock cycle, but can also do SDI 2 at bits, and SQI at 4 bits per cycle.

As my project will need to quickly shuffle thousands of bytes around into different parts of this RAM, a faster method of R/W maybe useful.

As both Picaxe and the 23LC1024 are Microchip devices, it might be that a Picaxe can do SDI and SQI by tweaking some SFR registers. Can @Technical or @hippy advise ?

If not, I could easily bit-bang the protocol, but I'm not sure if this would be faster overall than HSPI, even at 4 bits per clock.

Has anybody any ideas ?.

Cheers,

Buzby

 

[bpowell]

Which Picaxe are you planning to use? I'd expect the capabilities of the silicon via SFR probably depends on which PIC you're talking about.

 

[Buzby]

Probably 28X2 or 40X2

 

[bpowell]

I don't think either of those PICs support dual SDI or quad SDI ... There *are* chips with this ability, but I don't see it as an option on the 8-bit lineup.

 

[inglewoodpete]

If these devices require "full duplex" SPI, then you're out of luck. By "full duplex", I mean sending and receiving data in the same command. I've tried all sorts of direct SFR manipulation to no avail.

 

[bpowell]

I haven't dug into it much; but I believe "Dual SPI" and QSPI are actually half-duplex...In dual-mode, the MISO and MOSI both become outputs, and clock odd and even bits .... so the receiver can get 2 bits per clock cycle...in QSPI, 2 more lines are used....so 4-bits per clock cycle.

 

[Buzby]

SDI and SQI are half-duplex.

When I first saw mention of SDI and SQI I imagined all kinds of complicated clock edge or phase requirements, in order to get multiple bits per clock. It's nowhere near as complicated as that. For SDI there are two data pins, and for SQI 4 data pins.

In effect, SQI is similar to a 4-bit parallel buss, with all the bits clocked by the same clock. It could be easily bit-banged, but this would be much slower than HSPI.

This gave me an idea. My proposed project needs to copy thousands of bytes from one area of memory to another. This means if I used a single serial RAM chip I would need to change the to/from addresses for each byte ( or chunk of bytes ), and this takes time.

Parallel addressing, and using two chips, means I could use use dedicated Picaxe ports as direct address counters, one for each chip. This would make the code simpler, and also transfer 8 bits at a time. This might be faster.

I need to step back and do some tests to determine which would be fastest. Because there are no 'wait for reply' conditions in either of these solutions, it should be possible to write test code which will run at the correct speed, even with no hardware attached.

Unfortunatley ( ! ) paid work has just got in the way, so this this going to have to wait.

Cheers,

Buzby

 

[papaof2]

That thing called "the real world" does tend to intrude on the time needed for useful and interesting projects :-(

 

[hippy]

When I first saw mention of SDI and SQI I imagined all kinds of complicated clock edge or phase requirements ...

In effect, SQI is similar to a 4-bit parallel buss, with all the bits clocked by the same clock.

Yes, not much different to driving a parallel LCD. I think there might be a mode where data is clocked on rising and falling edge but that might be something else.

I don't think any of the PICAXE support more than the traditional one data line SPI mode. I vaguely recall something may have had some kind of 8-bit bus interface but don't know which and am not sure that could actually be used. I think I would have commented on it if it could.

 

[Buzby]

It looks like SQI support is only on PIC32 devices, so we might see it on a later generation of Picaxe !.

Regarding clocking on both edges, yes, it's a thing. See section 46.5.2 in datasheet below.
It can do 4 pin SQI using both clock edges, giving 8 bits per full clock cycle.

https://ww1.microchip.com/downloads/en/DeviceDoc/60001244C.pdf

 

[bpowell]

It looks like SQI support is only on PIC32 devices, so we might see it on a later generation of Picaxe !.

Wait!! There's a 32-bit PICAXE releasing soon?!

(And the rumors have started!)

 

[neiltechspec]

Dream on !.
Probably insufficient demand from the "main" market to warrant development.

 

[hex]

I agree that 32 bit PICAXE is probably impractical, but I wonder?
... might PIC18F47Q83 be pic-axeable?

Lots of memory and peripherals, but still 5 Volt / 3v3 8-bit
Compatible with earlier 40 pin devices, 28 pin same

This is what I dream of anyway

 

[bpowell]

I agree that 32 bit PICAXE is probably impractical, but I wonder?
... might PIC18F47Q83 be pic-axeable?

It would be quite a lift I'd imagine ... the Q-series chips have a lot of changes "under the hood" that Reved would need to deal with ... how I2C is implemented, different SFRs, etc. It would be a job for sure, but would be cool!

 

[pxgator]

I've been a long time PICAXE user and would love to see PICAXE and Reved survive. I don't like having to use ARDxx
for some projects because PICAXE limitations. What do you guys and gals think Reved should do ?

 

[papaof2]

IF the UK educational market is ready to spend the £££ for the enhanced learning potential a 32 bit PICAXE could provide
THEN RevEd will produce a new line of 32 bit PICAXE chips.

Does anyone here have any influence on one or more people in the UK education hierarchy?

Having used many flavors of BASIC in commercial settings, I can see all sorts of possibilities for next generation of "turbo" PICAXE ;-)

 

[pxgator]

I hope they do something. I love using PICAXE and dream about PICAXE that does floating point, extensive string
handling, mapping functions, etc., etc. And of course blazing speed.

 

[Buzby]

Mapping functions, floating point, and lots of strings are all software dependant. They would need a completely new Picaxe interpreter architecture, with a completely new compiler. I don't see that happening in the next 15 years, unless Elon Musk buys RevEd !.

However, access to the new peripheral hardware in the latest 8 bit PICs would not need much to implement.

We have the M2 and X2 because the underlying PIC hardware is different.

Just like we have HSER and HIC2 and HSPI on the X2, the X3 could have HCMP, HZCD, HCLC etc.

These need no changes to the architecture of the interpreteter, just additions in the same manner as was used to move from X1 to X2.

Its been a long time since we've had a new Picaxe, and I complained years ago that PIC hardware was far outstripping Picaxe BASIC.

We can live in hope.

 

[Gramps]

That thing called "the real world" does tend to intrude on the time needed for useful and interesting projects :-(

Tell me about it! Especially since I retired a year ago.

 

[inglewoodpete]

Tell me about it! Especially since I retired a year ago.

I often wonder how I used to find time to go to work . (Now semi-retired).