Oh, I'd missed the default "variable" config, MR0[5]=0. Opposite to HyperRAM default. That means I either need to test the DQS signal on each read or program the config bits for fixed latency.
EDIT: Err, hmm, looks like DQS works quite differently than with hyperRAMs. It seems to rely on a delayed first-byte strobe to signal "pushout" of latency. There's no way to handle that at burst speeds other than to use a post-read temporary buffer to later analyse to extract the data from. Which is hardly an efficient solution.
@Rayman said:
How do these results compare with hyperram?
Looks same. The real test is at sysclock/1 but both existing designs are known flawed for that test so no point trying until a better board layout is done.
I think fixed latency is not needed for linear burst mode, right?
Fixed is needed. Otherwise a DRAM refresh can glitch the assumed timing.
@evanh said:
Fixed is needed. Otherwise a DRAM refresh can glitch the assumed timing.
HyperRAM is superior here. It pre-warns of an additional LC with a long RWDS signal for the duration of CA phase. So it's much easier to check for and adjust the number of extra clocks needed on the fly. (EDIT: Not that I ever did this. Fixed latency is the default for HyperRAM and it's much easier to just leave it that way.)
I am just asking for SPIN code to use Hyper SPI RAM Aps6404 / Aps12808 etc on Propeller1.
-- The Hyper SPI RAM Aps6404 / Aps12808 communication is close to same as 24c32 chips etc.
I see 24c32 Spin code - but it only uses 2 byte addressing.
Aps6404 - uses 3 byte addressing.
AT24C32 is I2C interface. That's quite different to any of the SPIs. Hyperbus is not a regular SPI either. That said, there must already be SPI objects for the Prop1 surely. The Obex is offline right now though - https://obex.parallax.com/obex/
Just need to figure out how to convert it to Ips6404 chips (with 3 byte adressing).
Single_23LC1024.spin
-- need to remove the confusing Cache code though ...
-- read/write string Functions :
PUB RamRead/WriteString(plSrcRamAddr, plDstAddr, pwQtyBytes, plRtnBusyFlagAddr) | tmpTest, tmpFlag, tmpCount
-- -- is a misnomer , this is a memcpy() , strcpy() checks for CR/NL , these routines do Not.
23lc1024.spin
-- don't feel like learning PASM - so skip this
Ada is very skilled. If she wrote it then it'll be fast. Are you wanting to handle much runtime data, or is this just for config store?
Andre was also highly skilled. Before my time though. Don't know where the referenced SRAM_driver_23K256_v010.spin object is.
Yup. Sorry, I was talking about another PSRAM again. When I tweaked a bit-bashed booter to use smartpins I used a fancy mode that was in the EEPROM on the Prop2 Eval Board. I never really looked nor considered if it was a common mode or not at the time. My mistake because after a while people wanted to use the Prop2 with other EEPROMs and started finding problems with the code.
Comments
This simple spin2 code now can read/write memory
@evanh Sorry, still all 0%
Huh, your read latency is only 1 x LC, the datasheet says 2 x I thought ... try this then:
Oh, I'd missed the default "variable" config, MR0[5]=0. Opposite to HyperRAM default. That means I either need to test the DQS signal on each read or program the config bits for fixed latency.
EDIT: Err, hmm, looks like DQS works quite differently than with hyperRAMs. It seems to rely on a delayed first-byte strobe to signal "pushout" of latency. There's no way to handle that at burst speeds other than to use a post-read temporary buffer to later analyse to extract the data from. Which is hardly an efficient solution.
@evanh That works!
Got a lot more 100%s when I increased drive strength to full
Nice. I guess I should add the register read/write routines now. So the drive strength can be set ... and set fixed read latency too.
How do these results compare with hyperram?
I think fixed latency is not needed for linear burst mode, right?
Looks same. The real test is at sysclock/1 but both existing designs are known flawed for that test so no point trying until a better board layout is done.
Fixed is needed. Otherwise a DRAM refresh can glitch the assumed timing.
Here's another update with MR0 blindly set to $28 - Fixed latency + 50 Ohm drive strength. And I've changed the base pin to 0 now too.
HyperRAM is superior here. It pre-warns of an additional LC with a long RWDS signal for the duration of CA phase. So it's much easier to check for and adjust the number of extra clocks needed on the fly. (EDIT: Not that I ever did this. Fixed latency is the default for HyperRAM and it's much easier to just leave it that way.)
Can we convert this Hyper RAM Spin2 code be converted to SPIN ?
Because the code uses the smartpins and streamer (P2 only hardware features) it cannot run on P1, if that's what you're thinking of.
I am just asking for SPIN code to use Hyper SPI RAM Aps6404 / Aps12808 etc on Propeller1.
-- The Hyper SPI RAM Aps6404 / Aps12808 communication is close to same as 24c32 chips etc.
I see 24c32 Spin code - but it only uses 2 byte addressing.
Aps6404 - uses 3 byte addressing.
AT24C32 is I2C interface. That's quite different to any of the SPIs. Hyperbus is not a regular SPI either. That said, there must already be SPI objects for the Prop1 surely. The Obex is offline right now though - https://obex.parallax.com/obex/
i found some SPI code examples..
Just need to figure out how to convert it to Ips6404 chips (with 3 byte adressing).
Single_23LC1024.spin
-- need to remove the confusing Cache code though ...
-- read/write string Functions :
PUB RamRead/WriteString(plSrcRamAddr, plDstAddr, pwQtyBytes, plRtnBusyFlagAddr) | tmpTest, tmpFlag, tmpCount
-- -- is a misnomer , this is a memcpy() , strcpy() checks for CR/NL , these routines do Not.
23lc1024.spin
-- don't feel like learning PASM - so skip this
https://forums.parallax.com/discussion/174269/has-anyone-written-a-driver-for-microchip-23lc1024-sram-chip
Ada is very skilled. If she wrote it then it'll be fast. Are you wanting to handle much runtime data, or is this just for config store?
Andre was also highly skilled. Before my time though. Don't know where the referenced SRAM_driver_23K256_v010.spin object is.
I do Robotocs & Programming & Electronics - as both Hobby and as a Career.
I intend to use this RAM for AI & Robotics & Visual Recognition.
I already use this PSRAM Ips6404 on both Arduino and ARM chips.
-- Thought that I would play with the Propeller/2 - and see what it is really capable of ...
ps: Your SRAM_driver_23K256_c010.spin :
https://parallax.com/package/an012-interfacing-the-propeller-to-external-sram-with-spi/
-- looks easier , still need to expand the address bytes from 16 to 24bits ... maybe just a quick patching job ...
From Single_23LC1024.spin - may already work :
For image data?
Prop2 can definitely go much faster than the Prop1. Not to mention it has more pins. Streamer hardware is good as a master.
23LC1024 Cmds :
-
-
-- Pretty Close - no Conflict , just Exit Differs : 0xFF / 0xF5
There sure is a lot of mode variations. In one device I remember it supporting six distinct transfer modes: Slow, Fast, Dual, Quad, DPI, and QPI.
But, I only see SPI and Fast SPI and SQuad and FastReadQuad on the Aps6404
Yup. Sorry, I was talking about another PSRAM again. When I tweaked a bit-bashed booter to use smartpins I used a fancy mode that was in the EEPROM on the Prop2 Eval Board. I never really looked nor considered if it was a common mode or not at the time. My mistake because after a while people wanted to use the Prop2 with other EEPROMs and started finding problems with the code.