Performance improvement in SPI #27
Comments
|
I'm surprised that works at all. ChaN says
but you're using mode 1? He doesn't cite his source, unfortunately. I looked at SD Specifications, Part 1, Physical Layer Specification, Version 3.01, February 18, 2010, and I couldn't find any mention of the SPI mode, and the bus timing diagrams are omitted in the simplified (free) versions of the SD Physical Layer specification. The Simplified Specifications are a subset of the complete SD Specifications, which I don't have. If you have access to the full Specifications, you might want to check whether SPI mode 1 operation is compliant. |
|
I made the change based on looking at the rp2040 datasheet and scope views. I originally did it for the noOs version of the code to get that little extra performance I needed.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Saturday, January 13, 2024 12:44:00 AM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
I'm surprised that works at all. ChaN says<http://elm-chan.org/docs/mmc/mmc_e.html#spimode>
SPI mode 0 (CPHA=0, CPOL=0) is the proper setting to control MMC/SDC, but mode 3 (CPHA=1, CPOL=1) also works as well in most case.
but you're using mode 1? He doesn't cite his source, unfortunately. I looked at SD Specifications, Part 1, Physical Layer Specification, Version 3.01, February 18, 2010, and I couldn't find any mention of the SPI mode, and the bus timing diagrams are omitted in the simplified (free) versions of the SD Physical Layer specification. The Simplified Specifications are a subset of the complete SD Specifications, which I don't have. If you have access to the full Specifications, you might want to check whether SPI mode 1 operation is compliant.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6ADQORBNJCZ2SXKDATYOINKBAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGMZTAMJZG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Quick question. Have you gotten this to work with pico-w doing tcp? If you have an example that would be great. I've been pulling my hair out for days.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Saturday, January 13, 2024 12:44:00 AM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
I'm surprised that works at all. ChaN says<http://elm-chan.org/docs/mmc/mmc_e.html#spimode>
SPI mode 0 (CPHA=0, CPOL=0) is the proper setting to control MMC/SDC, but mode 3 (CPHA=1, CPOL=1) also works as well in most case.
but you're using mode 1? He doesn't cite his source, unfortunately. I looked at SD Specifications, Part 1, Physical Layer Specification, Version 3.01, February 18, 2010, and I couldn't find any mention of the SPI mode, and the bus timing diagrams are omitted in the simplified (free) versions of the SD Physical Layer specification. The Simplified Specifications are a subset of the complete SD Specifications, which I don't have. If you have access to the full Specifications, you might want to check whether SPI mode 1 operation is compliant.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6ADQORBNJCZ2SXKDATYOINKBAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGMZTAMJZG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
How are you measuring the performance improvement? I can't imagine how changing the phase could significantly change the throughput unless you are also increasing the baud rate. |
|
No baud rate increase. Writing data to the file and get usec time at start and end. Pretty simple. I am running at 25mhz exactly. Tested on 5 different cards from several different manufacturers.
When I find some free time I'll hook up the scope again and do a capture and send it along.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Saturday, January 13, 2024 1:14:39 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
I made the change based on looking at the rp2040 datasheet and scope views. I originally did it for the noOs version of the code to get that little extra performance I needed.
How are you measuring the performance improvement? I can't imagine how changing the phase could significantly change the throughput unless you are also increasing the baud rate.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6H777SQJIKZCBWDMFTYOLFI5AVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGY2TCMRTG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Do you have a theory on how changing the clock phase could improve the data transfer rate? There are many variables that could affect the timing. (See Performance Tuning Tips). For example, the file might span a segment on the SD card. Are you formatting the cards between tests? |
|
The ph0 drops the clock for a longer period. Not sure why. The same sd card, same file that is preallocated before hand. So the same sectors are being read and written.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Saturday, January 13, 2024 4:48:13 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
No baud rate increase. Writing data to the file and get usec time at start and end. Pretty simple. I am running at 25mhz exactly. Tested on 5 different cards from several different manufacturers. When I find some free time I'll hook up the scope again and do a capture and send it along.
Do you have a theory on how changing the clock phase could improve the data transfer rate?
There are many variables that could affect the timing. (See Performance Tuning Tips<https://github.com/carlk3/no-OS-FatFS-SD-SDIO-SPI-RPi-Pico#appendix-d-performance-tuning-tips>. For example, the file might span a segment on the SD card. Are you formatting the cards between tests?
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6CE2TYI2G3IXP7JDRDYOL6J3AVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQG43TMNZRGQ>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I'm not sure what you mean by drops the clock. The clock signal is low for a longer part of the cycle? Does the frequency change? Does the card indicate "busy" for less time?
How much data are you writing? Does big_file_test (which you can run from command_line show a significant difference for, say, a 30 MB file? |
|
Yes, clock is low for a longer period. As far a file size, 8 to 16mb.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Sunday, January 14, 2024 2:34:40 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
The ph0 drops the clock for a longer period.
I'm not sure what you mean by drops the clock. The clock signal is low for a longer part of the cycle? Does the frequency change? Does the card indicate "busy" for less time?
Writing data to the file and get usec time at start and end.
How much data are you writing? Does big_file_test<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/blob/master/examples/command_line/tests/big_file_test.c> (which you can run from command_line<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/tree/master/examples/command_line> show a significant difference for, say, a 30 MB file?
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6EXT4UGKFSRGF4ZKBDYOQXNBAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGA2TANBVGI>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
How does having the clock is low for a longer period improve the performance? Is the overall clock cycle period shorter? I can't understand how it can be moving data faster unless the frequency goes up or somehow there's less host wait time (normally due to card busy time). |
|
Let me rephrase. In ph0 the clock is low longer making each xfer take longer. Ph1 doesn't have that ossue
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Monday, January 15, 2024 2:04:52 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
Yes, clock is low for a longer period.
How does having the clock is low for a longer period improve the performance? Is the overall clock cycle period shorter? I can't understand how it can be moving data faster unless the frequency goes up or somehow there's less host wait time (normally due to card busy time).
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6HEZAEIUSD2OFTJ3NTYOV4VJAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGY2TMNZVG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Ah, so the frequency does change. What if you raise the |
|
It looks like there is no improvement beyond 25mhz.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Monday, January 15, 2024 2:14:51 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
Ah, so the frequency does change. What if you raise the baud_rate in ph0 instead of switching to ph1?
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6DZC6NXSB6QAOBU5WLYOV52XAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGY3DMNBZGU>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I don't understand how the frequency can change. From RP2040 Datasheet:
where SSPCLK is wired to |
|
It's not the frequency per se. It's the time the chip takes to start sending data for each packet. This weekend I'll have time to pull some traces that show what I am talking about. A picture is worth a thousand words.
Btw, I appreciate all the help. I'm way behind on my Flux copier so getting things going with rtos really helped.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Monday, January 15, 2024 2:37:44 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
I don't understand how the frequency can change. From RP2040 Datasheet:
4.4.3.6.1. Bit rate generation
The serial bit rate is derived by dividing down the input clock, SSPCLK. The clock is first divided by an even prescale
value CPSDVSR in the range 2-254, and is programmed in SSPCPSR. The clock is divided again by a value in the range 1-256, that is 1 + SCR, where SCR is the value programmed in SSPCR0.
where SSPCLK is wired to clk_peri. By default clk_peri is attached directly to the system clock. So I would guess that the serial bit rate would be some constant ratio to the clk_peri. How would changing the clock phase affect that?
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6DFBZKQKLFEYTYQRFDYOWAQRAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJSGY4DONRSGY>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I tried using spi_set_format(spi_p->hw_inst, 8, SPI_CPOL_0, SPI_CPHA_1, SPI_MSB_FIRST);and I can't get the card to initialize. Even at 122,070 Hz, it gets CRC errors on CMD0, "Go Idle State", which is the first command. |
|
Wow. That's odd. Every card I use works.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Monday, January 15, 2024 10:03:42 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
I tried using
spi_set_format(spi_p->hw_inst, 8, SPI_CPOL_0, SPI_CPHA_1, SPI_MSB_FIRST);
and I can't get the card to initialize. Even at 122,070 Hz, it gets CRC errors on CMD0, "Go Idle State", which is the first command.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6ERGVJORH4EIFZU7W3YOXUY5AVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJTGAYDCOBVGU>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
So strange. Guess it depends on the card.
On other issues, still getting hangs and unreliable behavior.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Tuesday, January 16, 2024 2:47:32 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
It's the Silicon Power 3D NAND U1 32GB microSD card<https://www.amazon.com/gp/product/B07RSXSYJC/> that refuses to initialize with SPI_CPHA_1. So, I switched to a SanDisk Ultra 16GB<https://www.westerndigital.com/products/memory-cards/sandisk-ultra-uhs-i-microsd?sku=SDSQUNC-016G-AN6MA>. That does work, so I ran some benchmarks with big_file_test.c<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/blob/master/examples/command_line/tests/big_file_test.c> and bench.c<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/blob/master/examples/command_line/tests/bench.c>. My results are summarized here: SPI_CPHA test results<https://docs.google.com/spreadsheets/d/1lDVyZO5_2BJLS-WF96ADBPmk8W7aX-u8vp1t2ejg48g/edit?usp=sharing>.
In general, with SPI_CPHA_1 I found:
big_file_test.c<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/blob/master/examples/command_line/tests/big_file_test.c>, 20 MiB file:
* On average (three trials), it took 6.40% more time to write the file
* No change in time to read a 20 MiB file
bench.c<https://github.com/carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico/blob/master/examples/command_line/tests/bench.c>, 5 MiB file:
* Write speed decreased 5.50% for a 5 MiB file
* Average write latency increased 5.35%
* Read speed decreased 1.18% for a 5 MiB file
* Average read latency increased 1.09%
Writing to SD cards is far from deterministic, there is a lot variance in these results, and I only tested with the SanDisk Ultra 16GB<https://www.westerndigital.com/products/memory-cards/sandisk-ultra-uhs-i-microsd?sku=SDSQUNC-016G-AN6MA>, so more testing would be needed to really quantify the differences, but I'm not seeing the performance improvement.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6AYOVDKPUC7MPCUU33YO3KNJAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGQYDKNBUGQ>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Never mind, I was using the wrong Now that I have gotten that straightened out, I can't get any of these cards to initialize with
In all cases, the SPI CLK is running at 398089 Hz. (The SD Specification says that initialization must happen at 100-400 kHz.) |
|
Probably not worth worrying about then.
I've just about given up on getting wifi and sd card stuff working together. Absolutely unstable.
If you have someplace I can post my code , maybe I'm missing something
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Tuesday, January 16, 2024 3:48:55 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
So strange. Guess it depends on the card.
Never mind, I was using the wrong hw_config.c file. D'oh!
Now that I have gotten that straightened out, I can't get any of these cards to initialize with SPI_CPHA_1:
* Silicon Power 3D NAND U1 32GB microSD card<https://www.amazon.com/gp/product/B07RSXSYJC/>: gets CRC errors in response to CMD0 or no response to CMD59
* SanDisk Ultra 16GB<https://www.westerndigital.com/products/memory-cards/sandisk-ultra-uhs-i-microsd?sku=SDSQUNC-016G-AN6MA>: gets no response to CMD0
* PNY Elite Class 10 U1 microSD Flash Memory Card<https://www.pny.com/en-eu/elite-class-10-u1-microsd-flash-memory-card>: gets no response to CMD0
In all cases, the SPI CLK is running at 398089 Hz. (The SD Specification says that initialization must happen at 100-400 kHz.)
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6CJQK4CHYQOSAMU74LYO3RTPAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGQ4DSMZZGM>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
You can always fork this repository on GitHub. |
|
I created a repo and gave you access.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Carl J Kugler III ***@***.***>
Sent: Tuesday, January 16, 2024 5:05:47 PM
To: carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico ***@***.***>
Cc: Tom ***@***.***>; Author ***@***.***>
Subject: Re: [carlk3/FreeRTOS-FAT-CLI-for-RPi-Pico] Performance improvement in SPI (Issue #27)
If you have someplace I can post my code , maybe I'm missing something
You can always fork <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo> this repository on GitHub.
—
Reply to this email directly, view it on GitHub<#27 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADNHM6HT23O3JE2OPG4UGU3YO32TXAVCNFSM6AAAAABBYRM3UKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGU4TKMZXGY>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Chaning the spi_set_format call in my_spi_init to use SPI_CPHA_1 seems to bring about a 10% improvement in performance.
The text was updated successfully, but these errors were encountered: