@Kye: Thanks! Yep, I'm pretty sure everyone on the forum has been following your thread with interest. [noparse][[/noparse]8^) Regarding a format command, there is a nice bit of information on a simple FAT16 data layout in the MMC spec (version 1.3) www.sandisk.com/Assets/File/OEM/Manuals/ProdManRS-MMCv1.3.pdf, section 3.6 File System Format.
@David B: Thanks for the numbers! Regarding the date/timestamp: Tom and I are planning on adding a SetTimeDate type function, which is why the assembly block layer now has a get_seconds function The idea will be to set the correct time and date once, and then fsrw would track time for you, limited, of course, by the accuracy of your crystal. Equally of course you could always call SetTimeDate again with new info. I'm not sure the order that this feature will be added, or even the exact functionality, but knowing that there is interest definitely bumps up the priority a bit.
@Cluso99: Thanks for the kind words! I think I can tristate DO when not in use without ill effect. Readahead and writebehind are potential features of a future version of the block layer, and at that time a return from fsrw does not guarantee that the card is not in use. Would you be open to some kind of IsBusy query (and the attendant requirement to not start another block transaction until fsrw can control DO again)? Or we could actually use a lock. Anyway, this is all in the future, so I'll look into tristating DO for you when not in use. Please PM me if I misunderstood anything.
@Ross: Thanks for being willing to test this out for us on the TriBlade! I'm looking forward to the numbers!
Thanks, everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
If you can enforce the condition that the file you are reading is contiguous, you could use the raw block layer for much faster access. You would get a block of 512 bytes at a time, but obviously you could just read N of them back to back before processing the video and audio. However, that is a pretty large restriction to place on the user. What is your desired read data-rate? There are a few things I could do to optimize throughput a little bit, especially if you only ever need to read data, not write.
I'm pretty pleased with the current speed!· But maybe just for fun...· I can make the file contiguous, I believe by formatting the card and then loading just that file...· I can make the buffer an even number of 512 bytes without too much trouble...·
Can you make a routine that quickly reads the next N blocks into a buffer?· I guess one problem is that the first next block is already loaded into the internal buffer, right?
CassLan said...
Hey Guys I tested 2 SD Cards and 1 microSD Card. 3 Different Brands.
I have never had a problem copying text from PST, I do it all the time, I often will copy values into excell for graphs. You just can't right click....CTRL+C instead.
Also..dont highlight past what your readout is..if that makes any sense.
Thanks Again for all the effort being put into media reading/writing!
Rick
Hi, Rick.
Thanks for testing! (And who in their right mind posts at 2:32AM? [noparse][[/noparse]8^) Thanks for the info on CTRL+C, I sometimes miss the obvious. (BTW, thanks for posting the numbers...I especially like that you can see the obvious speed hit for pwrite using small clusters on that PQI 256MB card, but of course if you go to large clusters then you start wasting space if you are only writing small files.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
@Rayman: I think we can hijack some fsrw functionality to get you going with raw reads. We'll also need to make a change inside mb_spi. Inside fsrw there is a line that says:
pri datablock
change that to:
pub datablock
In mb_spi I declare:
VAR
long SPI_engine_cog
' these are used for interfacing with the assembly engine | temporary initialization usage
long SPI_command ' "t", "r", "w", 0 =>done, <0 => error | pin mask
long SPI_block_index ' which 512-byte block to read/write | cnt at init
long SPI_buffer_address ' where to get/put the data in Hub RAM | unused
If we move all those from VAR to a DAT section, then you could also include a copy of the mb_spi object inside your code and it would end up using the same driver cog and command registers.
Then I think you could do something like this:
Cluso99 said...
Lonesock: Did I miss something - are you planning to remove the raw access function? (i.e. pass the physical sector number for read/write?
I think _I'm_ missing something! Was there a version of fsrw where there was a raw read access function? I know it would be fairly trivial to add one, but the pass-through to the block layer would slow it down a tiny bit, so I was just directing Rayman to have direct access for maximum throughput.
@Tom: Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
You guys appear to be making great progress[noparse]:)[/noparse] Keep it up! For now, I can only cheer you on ... will test later.
What is the API for having multiple files open at once?
No API right now. But I suspect what I'll do for multiple files, just to keep it compatible and simple, is make the
filesystem portion of fsrw implicitly a singleton (move all those vars to DAT). So to open three files, you might do
object:
sdfat[noparse][[/noparse] 3]: "fsrw"
and then do the file system "calls" on any object:
sdfat[noparse][[/noparse] 0].mount(...)
and file-specific calls on whichever object matters:
Jonathan I guess you'll have to change your nickname from lonesock, as you have a clingon now too [noparse];)[/noparse] welcome to parenthood also [noparse]:D[/noparse]
Lonesock: yes she is beautiful. I also have a 3mth old grandson - nice to be able to hand them back though
Yes, there is a direct block access function for read and write in the spisd pasm routine. That is what we use for ZiCog. I will dig it out and post it (part of the PropDos/Femto object).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Test results with Sandisk 1Gb MicroSD on the TriBladeProp are below. Does anyone know if the "0 kB/s" reported for pputc is an error? I noticed some of the previously posted results show the same.
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 3968 kB in 2654 ms at 1494 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 1920 kB in 2049 ms at 936 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 32 kB in 5132 ms at 6 kB/s
How fast can we read using pread?
fsrw pread 32 kB in 53 ms at 595 kB/s
How fast can we write using pputc?
FSRW pputc 1 kB in 5096 ms at 0 kB/s
How fast can we read using pgetc?
FSRW pgetc 1 kB in 31 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 16384 ClusterCount: 61977
Raw write 3968 kB in 2654 ms at 1494 kB/s
Raw read 1920 kB in 2049 ms at 936 kB/s
fsrw pwrite 32 kB in 5132 ms at 6 kB/s
fsrw pread 32 kB in 53 ms at 595 kB/s
FSRW pputc 1 kB in 5096 ms at 0 kB/s
FSRW pgetc 1 kB in 31 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The "0kB/s" isn't *really* an error. What's probably happening there is the directory is so full,
or the card itself is so full, that scanning the directory and/or FAT takes so long, and that
causes problems.
Essentially, each test is dynamically sized to take a couple of seconds; the tests get bigger and
bigger until a test takes a few seconds. At that point, the results are reported.
In this case, scanning *something*, or maybe writing the directory, took so long that the test
stopped at the first iteration.
It's worth figuring out what happened here. How full is the card? I suppose I should make
some tests with cards that are pretty full.
Note that if the card is this full, the raw write test may well have trashed some of the data on
the card.
I am a bit surprised, though; you have < 64K clusters, so FAT16, so only about 128KB in the
FAT. It might be that the spin code overhead to scan that FAT was simply too slow (so we
could *read* the FAT fast enough, but the spin code to scan it was slow). I'll have to look at
that code and optimize it after reproducing the 0kB/s.
For fun, if you have patience, bump the test duration at the top of test.spin to, say, 10, and
see what numbers you get then. (You can't bump this number too high because you may
flirt with clock wraparound and then the results will be *truly* bogus.)
That could be it - this card is pretty full (835MB occupied). I noticed that writing to this card is also very slow from Catalina - but it was fast if I reformatted it first.
I upped the duration to 10 and reran the tests - results below. I reformatted and reloaded the card after the test, so no worries if it overwrote something.
Ross.
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 16256 kB in 10745 ms at 1512 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 16256 kB in 17344 ms at 937 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 4064 kB in 13057 ms at 311 kB/s
How fast can we read using pread?
fsrw pread 4064 kB in 6566 ms at 618 kB/s
How fast can we write using pputc?
FSRW pputc 255 kB in 13724 ms at 18 kB/s
How fast can we read using pgetc?
FSRW pgetc 255 kB in 7646 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 16384 ClusterCount: 61970
Raw write 16256 kB in 10745 ms at 1512 kB/s
Raw read 16256 kB in 17344 ms at 937 kB/s
fsrw pwrite 4064 kB in 13057 ms at 311 kB/s
fsrw pread 4064 kB in 6566 ms at 618 kB/s
FSRW pputc 255 kB in 13724 ms at 18 kB/s
FSRW pgetc 255 kB in 7646 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Presuming Ross is still using my 1GB uSD card I thought I formatted it with cluster size of 32KB but guess I was wrong. There are about 10 files, each contiguous·32MB long.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Sorry, I forgot that I had reformatted the card from Cluso's original 32k clusters.
Tests redone with 32k cluster size:
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 16256 kB in 10863 ms at 1496 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 16256 kB in 17344 ms at 937 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 8160 kB in 15882 ms at 513 kB/s
How fast can we read using pread?
fsrw pread 8160 kB in 13130 ms at 621 kB/s
How fast can we write using pputc?
FSRW pputc 255 kB in 11069 ms at 23 kB/s
How fast can we read using pgetc?
FSRW pgetc 255 kB in 7644 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 30871
Raw write 16256 kB in 10863 ms at 1496 kB/s
Raw read 16256 kB in 17344 ms at 937 kB/s
fsrw pwrite 8160 kB in 15882 ms at 513 kB/s
fsrw pread 8160 kB in 13130 ms at 621 kB/s
FSRW pputc 255 kB in 11069 ms at 23 kB/s
FSRW pgetc 255 kB in 7644 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I think this new fsrw may be outputting something on other pins... While testing with my PSM units, I notice the screen goes white with your new code... Maybe your DIRA masks aren't right?
Rayman said...
It's something in the "mount_explicit" command that's doing it...
If I startup the LCD after that, it's fine...
OK, I will definitely look into that!! (can you tell me what pins you are using for the SD and LCD devices, so I can try to narrow the problem down?) I do all the card init in Spin, then hand off the pin control to my PASM cog, so I know where to look.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
If I change this line in mb_spi: Start_Explicit, the problem goes away:
dira |= SPI_command
to
dira := SPI_command
That's a bit dangerous, as the initialization routine is in the same cog as whoever called it. So if you already set the dira mask elsewhere I think that would clobber it. Or maybe I misunderstood that in the docs.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Comments
@David B: Thanks for the numbers! Regarding the date/timestamp: Tom and I are planning on adding a SetTimeDate type function, which is why the assembly block layer now has a get_seconds function
@Cluso99: Thanks for the kind words! I think I can tristate DO when not in use without ill effect. Readahead and writebehind are potential features of a future version of the block layer, and at that time a return from fsrw does not guarantee that the card is not in use. Would you be open to some kind of IsBusy query (and the attendant requirement to not start another block transaction until fsrw can control DO again)? Or we could actually use a lock. Anyway, this is all in the future, so I'll look into tristating DO for you when not in use. Please PM me if I misunderstood anything.
@Ross: Thanks for being willing to test this out for us on the TriBlade! I'm looking forward to the numbers!
Thanks, everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Can you make a routine that quickly reads the next N blocks into a buffer?· I guess one problem is that the first next block is already loaded into the internal buffer, right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Thanks for testing! (And who in their right mind posts at 2:32AM? [noparse][[/noparse]8^) Thanks for the info on CTRL+C, I sometimes miss the obvious. (BTW, thanks for posting the numbers...I especially like that you can see the obvious speed hit for pwrite using small clusters on that PQI 256MB card, but of course if you go to large clusters then you start wasting space if you are only writing small files.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
@lonesock - Your more than welcome! Its 6am here...imagine my shock when I posted and there were already 2 posts after mine when the page refreshed!
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
pri datablock
change that to:
pub datablock
In mb_spi I declare:
VAR
long SPI_engine_cog
' these are used for interfacing with the assembly engine | temporary initialization usage
long SPI_command ' "t", "r", "w", 0 =>done, <0 => error | pin mask
long SPI_block_index ' which 512-byte block to read/write | cnt at init
long SPI_buffer_address ' where to get/put the data in Hub RAM | unused
If we move all those from VAR to a DAT section, then you could also include a copy of the mb_spi object inside your code and it would end up using the same driver cog and command registers.
Then I think you could do something like this:
OBJ sdfat : "fsrw_modified" block : "mb_spi_modified" '... sdfat.popen(string("speed.tst"),"r") idx := sdfat.datablock ptr := @buffer repeat Nblocks block.readblock( idx++, ptr ) ptr += 512The is untested, but I hope it points you in the right direction.
@Rick: Exactly! Here I am trying to get to bed and these ill-mannered louts continue to respond and be helpful and the like! [noparse][[/noparse]8^)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Lonesock, that looks good, and that will probably work just fine! Very clever, very very clever.
@Tom: Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
What is the API for having multiple files open at once?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
filesystem portion of fsrw implicitly a singleton (move all those vars to DAT). So to open three files, you might do
and then do the file system "calls" on any object:
and file-specific calls on whichever object matters:
sdfat[noparse][[/noparse] 0].popen("file1.txt","r") sdfat[noparse][[/noparse] 1].popen("file2.txt","w") repeat while (c:=sdfat[noparse][[/noparse] 0].pgetc)>=0 sdfat[noparse][[/noparse] 1].pputc(c) sdfat[noparse][[/noparse] 0].pclose sdfat[noparse][[/noparse] 1].pcloseThere are a number of loose ends to clear up and I'm not 100% sure this will work.
But this is the initial idea.
I've always been very pleased with your Linux-like function names.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
...and now, back to our regularly scheduled program, already in progress...
[noparse][[/noparse]8^)
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Yes, there is a direct block access function for read and write in the spisd pasm routine. That is what we use for ZiCog. I will dig it out and post it (part of the PropDos/Femto object).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Test results with Sandisk 1Gb MicroSD on the TriBladeProp are below. Does anyone know if the "0 kB/s" reported for pputc is an error? I noticed some of the previously posted results show the same.
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 3968 kB in 2654 ms at 1494 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 1920 kB in 2049 ms at 936 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 32 kB in 5132 ms at 6 kB/s
How fast can we read using pread?
fsrw pread 32 kB in 53 ms at 595 kB/s
How fast can we write using pputc?
FSRW pputc 1 kB in 5096 ms at 0 kB/s
How fast can we read using pgetc?
FSRW pgetc 1 kB in 31 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 16384 ClusterCount: 61977
Raw write 3968 kB in 2654 ms at 1494 kB/s
Raw read 1920 kB in 2049 ms at 936 kB/s
fsrw pwrite 32 kB in 5132 ms at 6 kB/s
fsrw pread 32 kB in 53 ms at 595 kB/s
FSRW pputc 1 kB in 5096 ms at 0 kB/s
FSRW pgetc 1 kB in 31 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
or the card itself is so full, that scanning the directory and/or FAT takes so long, and that
causes problems.
Essentially, each test is dynamically sized to take a couple of seconds; the tests get bigger and
bigger until a test takes a few seconds. At that point, the results are reported.
In this case, scanning *something*, or maybe writing the directory, took so long that the test
stopped at the first iteration.
It's worth figuring out what happened here. How full is the card? I suppose I should make
some tests with cards that are pretty full.
Note that if the card is this full, the raw write test may well have trashed some of the data on
the card.
I am a bit surprised, though; you have < 64K clusters, so FAT16, so only about 128KB in the
FAT. It might be that the spin code overhead to scan that FAT was simply too slow (so we
could *read* the FAT fast enough, but the spin code to scan it was slow). I'll have to look at
that code and optimize it after reproducing the 0kB/s.
For fun, if you have patience, bump the test duration at the top of test.spin to, say, 10, and
see what numbers you get then. (You can't bump this number too high because you may
flirt with clock wraparound and then the results will be *truly* bogus.)
That could be it - this card is pretty full (835MB occupied). I noticed that writing to this card is also very slow from Catalina - but it was fast if I reformatted it first.
I upped the duration to 10 and reran the tests - results below. I reformatted and reloaded the card after the test, so no worries if it overwrote something.
Ross.
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 16256 kB in 10745 ms at 1512 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 16256 kB in 17344 ms at 937 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 4064 kB in 13057 ms at 311 kB/s
How fast can we read using pread?
fsrw pread 4064 kB in 6566 ms at 618 kB/s
How fast can we write using pputc?
FSRW pputc 255 kB in 13724 ms at 18 kB/s
How fast can we read using pgetc?
FSRW pgetc 255 kB in 7646 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 16384 ClusterCount: 61970
Raw write 16256 kB in 10745 ms at 1512 kB/s
Raw read 16256 kB in 17344 ms at 937 kB/s
fsrw pwrite 4064 kB in 13057 ms at 311 kB/s
fsrw pread 4064 kB in 6566 ms at 618 kB/s
FSRW pputc 255 kB in 13724 ms at 18 kB/s
FSRW pgetc 255 kB in 7646 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Sorry, I forgot that I had reformatted the card from Cluso's original 32k clusters.
Tests redone with 32k cluster size:
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 16256 kB in 10863 ms at 1496 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 16256 kB in 17344 ms at 937 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 8160 kB in 15882 ms at 513 kB/s
How fast can we read using pread?
fsrw pread 8160 kB in 13130 ms at 621 kB/s
How fast can we write using pputc?
FSRW pputc 255 kB in 11069 ms at 23 kB/s
How fast can we read using pgetc?
FSRW pgetc 255 kB in 7644 ms at 33 kB/s
Repeating all the speed results:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 30871
Raw write 16256 kB in 10863 ms at 1496 kB/s
Raw read 16256 kB in 17344 ms at 937 kB/s
fsrw pwrite 8160 kB in 15882 ms at 513 kB/s
fsrw pread 8160 kB in 13130 ms at 621 kB/s
FSRW pputc 255 kB in 11069 ms at 23 kB/s
FSRW pgetc 255 kB in 7644 ms at 33 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
If I startup the LCD after that, it's fine...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
If I change this line in mb_spi: Start_Explicit, the problem goes away:
dira |= SPI_command
to
dira := SPI_command
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
' get the card in a ready state: set DI and CS high, send => 74 clocks
outa :=SPI_command
to
outa |=SPI_command
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
THANKS!!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.