polpo / rp2040-psram Goto Github PK

Hi,

I just wanted to let you know that I have the communication working using the spi hardware (+dma) of the rp2040. Actually you provided the trick:

	aspAcquire(aps);

	/* inititate read */
	uint8_t cmd[5] = { APS_FASTREAD };
	cmd[1] = addr >> 16;
	cmd[2] = addr >> 8;
	cmd[3] = addr & 0xFF;
	cmd[4] = 0;				//dummy
	spi_transfer(aps->spi, cmd, NULL, sizeof(cmd));

	/* receive data */
	//note: for fastread (>33Mhz) we need to switch to sampling on the falling egde
	if(aps->spi->baud_rate > 33000000)
		spi_set_format(aps->spi->hw_inst, 8, SPI_CPOL_0, SPI_CPHA_1, SPI_MSB_FIRST);
	spi_transfer(aps->spi, NULL, buf, size);
	if(aps->spi->baud_rate > 33000000)
		spi_set_format(aps->spi->hw_inst, 8, SPI_CPOL_0, SPI_CPHA_0, SPI_MSB_FIRST);

	aspRelease(aps);

Prior to the read operation I reconfigure the spi hardware to do sampling on the falling edge.
I have it tested at 62.5Mhz (maximum for a pico running at default speed (125Mhz)).

Cheers,
Juergen

Hi - It seems that the included example does not build.

I am using commit 36f272178abb21370a7087bf9506a055feedfd39 which is the latest.

$ git rev-parse HEAD
36f272178abb21370a7087bf9506a055feedfd39

$ pwd
rp2040-psram/examples

$ cmake .

$ make
...
rp2040-psram/examples/psram-test.c:7:1: error: unknown type name 'pio_spi_inst_t'; did you mean 'psram_spi_inst_t'?
    7 | pio_spi_inst_t psram_spi;
      | ^~~~~~~~~~~~~~
      | psram_spi_inst_t

It seems that the API has changed underneath.

Thanks for the help with this.

I have removed issue, problem solved. Thanks for your job!

The PSRAM modules support QSPI mode. I have some PIO code to support quad writes and reads, but I haven't completed the C interface around it because PicoGUS's small writes and reads do not benefit from the burst speeds possible in quad mode.

Thanks for the fantastic work.

For those of us who are considering RP2040+PSRAM as a solution for a project and don't have a PSRAM chip handy to run the test ourselves, it would be very useful if the README (main or in /examples) provided the output from a psram-test run on your, or other, known-good hardware.

In simple terms, it would be useful to know ahead of time what sort of performance we can expect (at least the top end limit, obviously using DMA/internal RAM might interfere in real world use cases).

Hi Polpo,
I don't think this is a issue but mostly my understanding of the documentation, I am new to programming the PICO using C/C++, I have interfaced the PSRAM with Pico and I build the example file successfully but I dont know why it shows up this address error -

I see that the defines have to be made in the program which is using the library but when I define the Pins in the example code
" warning: "PSRAM_PIN_MOSI" redefined " so if you could help me with getting this sorted out would be helpful.
I did not know how to reach you so I opened a issue sorry if this is a mistake.

Thank you

This should be configurable by the user. Doing it by a #define should be straightforward.

Writes are currently purely asynchronous – there is no facility to add a callback that can be called when a write completes.

How can psram_write write more bit data at once? Currently, n bit write cannot exceed 256. Thank you