@mjs513 - where does one find :: #include "Streaming.h"
@mjs513 - where does one find :: #include "Streaming.h"
Again you can configure it for normal SPI and not dual/or quad...Originally Posted by defragster
And depending on which device family you configure for, it tries to know the different commands to set it into dual or quad and decode from there...
Right now I have both configured as WINBOND with 24 bit addressing.
Here shows with external flash board, LA pins(11, 12, 13, 3, 4, 5, 6) I have two of the SPI Flash analyzers with CS for 5 and 6. I also have an SPI analyzer with pin 5...
Here is startup of MTP-test sketch
zommed in to read ID...
On TD 1.54 b5 thread the _Program flash moved to 133 MHz by paul. Tested and it worked - but no faster versus p#719 test
Quick Summary:
Code:Big write KBytes per second 532.36 Bytes Used: 3133440, Bytes Total:6291456 printDirectory PRO_DISK -------------- FILE 0_bigfile.txt 3119104 Big read&compare KBytes per second 2686.95 // 100 iterations time 2.83 M [ 2.60 M](0.01360 M elap) Awaiting input 0123456789RdcghkFqvplmusSBbyYxfan+-? loops left 0 >h :: /B_file.txt PRO_DISK +++ Add [sz 0 add 5120] @KB/sec 417.01 {412.34} ++ B Verify /B_file.txt 5120B @KB/sec 2605.60 :: /C_file.txt PRO_DISK +++ Add [sz 0 add 9216] @KB/sec 453.59 {450.24} ++ C Verify /C_file.txt 9216B @KB/sec 2719.39 :: /D_file.txt PRO_DISK +++ Add [sz 0 add 13312] @KB/sec 451.09 {448.47} ++ D Verify /D_file.txt 13312B @KB/sec 2736.84 :: /E_file.txt PRO_DISK +++ Add [sz 0 add 17408] @KB/sec 446.94 {444.77} ++ E Verify /E_file.txt 17408B @KB/sec 2693.90 ... ... :: /Z_file.txt Verify /Z_file.txt 103424B @KB/sec 2764.24 PRO_DISK ----DEL---- -- Z :: /A_file.txt Verify /A_file.txt 41984B @KB/sec 2757.21 PRO_DISK ----DEL---- -- A :: /B_file.txt PRO_DISK +++ Add [sz 0 add 5120] @KB/sec 419.91 {411.51} ++ B Verify /B_file.txt 5120B @KB/sec 2656.98 :: /C_file.txt PRO_DISK +++ Add [sz 0 add 9216] @KB/sec 458.80 {453.81} ++ C Verify /C_file.txt 9216B @KB/sec 2674.41 :: /D_file.txt PRO_DISK +++ Add [sz 0 add 13312] @KB/sec 470.16 {465.02} ++ D Verify /D_file.txt 13312B @KB/sec 2672.02 [ 5.47 M](2.83065 M elap) Awaiting input 0123456789RdcghkFqvplmusSBbyYxfan+-? loops left 0 > Big write /0_2MBfile.txt took 3.87 Sec for 2048000 Bytes : file3.size()=2048000 Big write KBytes per second 529.07
Oops see it now. Answered on the beta5 thread. https://www.arduinolibraries.info/libraries/streaming
Haven’t tried this version yet and I may have made some changes to the orignal
'g' run speedBench() :: Done and integrated - here tested on _Program {ADDED the 1GB NANDs} :: Running at new PJRC 133 MHz setting in bootdata.c
Going to fix Delata - Ran after UPLOAD so all was Formatted.
Did Disk Fill to dirty blocks - made room and redid the new : 'g' run speedBench()
Clean or dirty doesn't matter here - BOTH data for WRITE test below:
Code:write speed and latency // FORMATTED TO START speed,max,min,avg KB/Sec,usec,usec,usec 496.48,4790,3210,4062 528.52,4420,3369,3862 496.48,4420,3369,4112 528.52,4421,3368,3862 512.00,4141,3407,3987 write speed and latency // DIRTY unFORMATTED TO START speed,max,min,avg KB/Sec,usec,usec,usec 481.88,4631,3215,4172 512.00,4421,3229,3862 496.48,4632,3369,4112 528.52,4421,3369,3862 512.00,4632,3368,3987 Starting sequential read test, please wait. read speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 115380.28,32,7,17 297890.91,9,6,6 309132.06,7,6,6 309132.06,7,6,6 315076.94,8,6,6 Done Starting random read test, please wait. Number of random reads: 1 Number of blocks: 8 read speed and latency speed,max,min,avg Position (bytes), Block: 0, 0 Read Time (ARM Cycle Delata): 3946 KB/Sec,usec,usec,usec 33711.93,0,0,60 Position (bytes), Block: 8192, 4 Read Time (ARM Cycle Delata): 4220 KB/Sec,usec,usec,usec 1024000.00,0,0,2 Position (bytes), Block: 10240, 5 Read Time (ARM Cycle Delata): 4706 KB/Sec,usec,usec,usec 963764.69,0,0,2 Position (bytes), Block: 2048, 1 Read Time (ARM Cycle Delata): 3962 KB/Sec,usec,usec,usec 1024000.00,0,0,2 Position (bytes), Block: 6144, 3 Read Time (ARM Cycle Delata): 4933 KB/Sec,usec,usec,usec 963764.69,0,0,2
And for QSPI_NAND: // FORMATTED TO START : and added "szDiskMem" to the BenchMark title::
Code:QSPI_NAND Benchmark: FILE_SIZE = 16384 BUF_SIZE = 2048 bytes Starting write test, please wait. write speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 1170.29,755,705,1750 1260.31,755,704,1658 1260.31,755,704,1658 1260.31,755,704,1646 1170.29,755,704,1659 Starting sequential read test, please wait. read speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 20029.34,103,102,102 20029.34,103,102,102 20029.34,103,102,102 20029.34,103,102,102 20029.34,103,102,102 Done Starting random read test, please wait. Number of random reads: 1 Number of blocks: 8 read speed and latency speed,max,min,avg Position (bytes), Block: 0, 0 Read Time (ARM Cycle Delta): 61371 KB/Sec,usec,usec,usec 147603.61,0,0,13 Position (bytes), Block: 8192, 4 Read Time (ARM Cycle Delta): 61378 KB/Sec,usec,usec,usec 147603.61,0,0,13 Position (bytes), Block: 10240, 5 Read Time (ARM Cycle Delta): 61384 KB/Sec,usec,usec,usec 147603.61,0,0,13 Position (bytes), Block: 2048, 1 Read Time (ARM Cycle Delta): 61374 KB/Sec,usec,usec,usec 147603.61,0,0,13 Position (bytes), Block: 6144, 3 Read Time (ARM Cycle Delta): 61378 KB/Sec,usec,usec,usec 147603.61,0,0,13
And for SPI_NAND: // FORMATTED TO START : and added "szDiskMem" to the BenchMark title::
Updating github now ...Code:SPI_NAND Benchmark: FILE_SIZE = 16384 BUF_SIZE = 2048 bytes Starting write test, please wait. write speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 372.36,1388,1340,5405 409.60,1388,1339,5011 409.60,1388,1340,5011 409.60,1389,1339,5012 409.60,1389,1339,5012 Starting sequential read test, please wait. read speed and latency speed,max,min,avg KB/Sec,usec,usec,usec 4641.36,441,441,441 4640.05,442,440,441 4641.36,441,441,441 4640.05,442,441,441 4641.36,441,441,441 Done Starting random read test, please wait. Number of random reads: 1 Number of blocks: 8 read speed and latency speed,max,min,avg Position (bytes), Block: 0, 0 Read Time (ARM Cycle Delta): 265419 KB/Sec,usec,usec,usec 36328.16,0,0,56 Position (bytes), Block: 8192, 4 Read Time (ARM Cycle Delta): 265425 KB/Sec,usec,usec,usec 36328.16,0,0,56 Position (bytes), Block: 10240, 5 Read Time (ARM Cycle Delta): 265320 KB/Sec,usec,usec,usec 36328.16,0,0,56 Position (bytes), Block: 2048, 1 Read Time (ARM Cycle Delta): 265331 KB/Sec,usec,usec,usec 36328.16,0,0,56 Position (bytes), Block: 6144, 3 Read Time (ARM Cycle Delta): 265394 KB/Sec,usec,usec,usec 36328.16,0,0,56
Last edited by defragster; 12-29-2020 at 11:31 PM.
Looks good, hopefully tomorrow I will run some of these tests as well..
Been hacking MTP instead today and I think I have some events stuff working now also with the T3.x boards
@KurtE = looking good. EF7020 - Winbond W25Q512JV*IM (DTR) from the list of FLASH chipsAgain you can configure it for normal SPI and not dual/or quad...
And depending on which device family you configure for, it tries to know the different commands to set it into dual or quad and decode from there...
Right now I have both configured as WINBOND with 24 bit addressing.
Here shows with external flash board, LA pins(11, 12, 13, 3, 4, 5, 6) I have two of the SPI Flash analyzers with CS for 5 and 6. I also have an SPI analyzer with pin 5...
Here is startup of MTP-test sketch
zommed in to read ID...
Can't wait to see QSPI.
@defragster
Runs look good - just about matches what I saw on the standalone versions. Thanks for adding
@defragster - @KurtE
Pushed a update to the NAND lib to fix a couple of bugs I have in readECC function (SPI and QSPI). Going to see what happens if I add an error to the BBLUT table and enable BBM. Going to take a chance.
Which library? The last one I see up at LFSIntegrity is @defragsters added speedBench
Oops = forgot to push the button. Just did it now - LFSIntegrity PlusNAND branch. Thanks
@defragster - @KurtE
I think I figured out how ECC bad block management works for at least the W25N01 and probably the W25M02 (think I have to fix something with readBLUT function though - maybe). But makes it alot more difficult with LittleFS to implement. With that said I mentioned this before but now up to the point where probably makes a difference. Have a look at this: https://bioreports.net/armmbed-littlefs/#wear-leveling and let me know what you think - is BBM worth trying to figure out on it working with LittlFS.
Good to have Benchmark in there for reference! I did the ones posted but not any FRAM or PSRAM.@defragster
Runs look good - just about matches what I saw on the standalone versions. Thanks for adding
Interesting if the ECC and bad block stuff is functionalfor the NANDs - Paul noted he didn't expect it working in TD 1.54? Seems to work as well as the others - especially if that hole is plugged for bad spots on the media.
Gotta run for now ...
Sorry it may be beyond my pay gradeBut as mentioned, the document you pointed to shows how littleFS detects the bad blocks and tries to recover. Not sure if error detection stuff in the chip would actually help out or not. If it were me I would probably KISS it and maybe ignore the ECC bad block stuff.
thanks Kurt. Thats kind of what I was thinking as well but think its going to be Paul's call.Sorry it may be beyond my pay grade
Pulled that link up quickly before leaving earlier - looked like a better formatted version of the GITHUB .MD one/both if the info files.
So not having read that "above KurtE's paygrade" section - or having any insight into the ECC/BadBlock - if it can be usable and punted that gives Paul the options to : Excluded NAND (), go without that feature, or help resolve it for inclusion.
So far the chips here have worked without the ECC / BMM as written by mjs513.
Right now ECC is enabled but BBM is not enforcedPulled that link up quickly before leaving earlier - looked like a better formatted version of the GITHUB .MD one/both if the info files.
So not having read that "above KurtE's paygrade" section - or having any insight into the ECC/BadBlock - if it can be usable and punted that gives Paul the options to : Excluded NAND (
So far the chips here have worked without the ECC / BMM as written by mjs513.
@defragster - @KurtE
Just pushed a minor change to the readECC function in the lib to correct an addressing issue that was bothering me. Yes I am feeling better now.
Glad you are feeling better! Just did a sync, may play soon...
Cannot get littleFS which I downloaded of github yesterday to build for teensy 4.1. Since I don't really need a filesystem, I have been trying SPIMemory.
SPIMemory works for the default channel and the flash chip on the propshield but for the flash on the back of the Teensy4.1 I think I need:
SPIFlash flash2(51,&SPI2);
and program seems to hang in flash2.begin();
Has anyone confirmed this to work for the winbond flash on back of teensy 4.1?
Not sure what version was downloaded? Also was it on TeensyDuino 1.54 Beta #5?
As far as flash on underside access - those pins are designed for use with QSPI - QUAD not normal SPI. When setup for QSPI access the FLASH reads directly with memory address references and the MCU handles the addressing and overhead to read the desired locations. Writes do take helper functions to enable that process. But enabling the QSPI takes some .begin commands to enable that, they are incorporated in the LFS startup.
There are examples of that and that is how LittleFS works with those functions available to the low level LFS code for block read and write.
PJRC has a version of the LFS - maybe that is what was used? It was working when last used - but has evolved some for new chip support.
The current version supporting NAND as well as the prior NOR flash chips - not sure what is use there ? - is github.com/Defragster/LFSintegrity/tree/PlusNAND
that has been tested to work with the TD 1.54 b5 release.
Easiest and best supported path to use would be LittleFS unless manual personal effort is desired.
Also good would be trying it and posting any errors or problems seen as there may be something missing that is needed. There is an LFSintegrity sketch in the above linked github that should build and work and give example code for simple file operations as used to test the underlying code from a high level.
Using TeensyDuino 1.53, I don't see QSPI library in that (maybe I'm not looking in the right place). I see a lot of recent changes to pjrc website, and now I can't find where to download Teensyduino anymore. Not sure if I want to risk changing to beta with my current project nearly complete. SPI memory access needs are low bandwidth and simple for logging so don't really need a file system. Using Windbond W25Q16JV-DTR, I don't see anthing in data sheet to tell me if its NAND or NOR. The library.properties files says LittleFS is version=0.1.0, which sounds very preliminary and the number of build errors I saw backs that up.
First the W25Q16JV-DTR is a NOR Flash chip, yes I know that the datasheet is silent on it but if you do a searching you will find that Mouser and Winbond shows it as a NOR flash. Second if you don't include the "LittleFS.h" you won't be using that library in you sketch and you won't be using a FileSystem with that flash chip. You can continue to use SPIMemory in your sketch.
Hope this answers your question?
In your prior post you mentioned using SPI2, unfortunately you can't really use it for Serial Flash chips using the underside pins unless you are breaking the connections out to a castellated board or in some other manner. Those underside pins for the PSRAM and FLASH are really meant to be used for QSPI access.
LittleFS is NEW to TD 1.54 in beta as noted in p#771. Not sure if it works on TD 1.53 with the addition of the library also noted in p#771 or the current code on PJRC under LittleFS it is copied from before most recent edits.
The TD 1.54 Beta is linked on post under Announcements Forum. The released TD 1.53 is in the same place it was under TeensyDuino software and IIRC that is now linked on each Teensy product page.
The LittleFS is indeed on initial alpha/beta development version. It has been tested to work well by some # of us in development and with proper install it build without errors or problems and tests show it working. It is new as noted to TD 1.54 and there may be CORES changes to allow it to work not in TD 1.53?
Most typical SMALL FLASH 8MB-32MB are common NOR - NAND's are typically larger and indeed are only recently supported in updates in the p#771 github not the last TD 1.54 beta 5 release.
The NOR Flash have had support capable in TD 1.53 - but takes the extra work shown in examples that were done for testing to orchestrate writes as noted and shown in those examples - most may be in the extmem or SPIFFS related earlier works.
Ok I found the TD 1.54 beta#5, I'll give that a try.
Reply With Quote
