I found some code for another micro to drive a SD card in SD-mode. Do you think it's worth a try to translate it to PASM or would the extra efford in reading 4 bits and putting them to the right place eat up the advantage of having 4 data lines?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
How funny! I found some old electronics boards with different capacitors. I tried several and I always got different return values for the boot-sector check. The closest I could get was $56, $AA .... ;o)
So, tomorrow I'll put my SD card adapter on a prototype PCB with short wires and plug it directly into the breadboard besides the propeller. Hope that solves my problem.
not to beat a dead horse.
but I was having major trouble with the SD card stuff when I had the prop-plug constantly plugged in on my protoboard.
the process that solved it was:
download new change to eeprom
power off switch
remove prop plug
power switch back on
plug prop-plug back in for serial comm stuff
I was literally tearing my hair out.
granted, it had something to do with the card communication being interrupted mid-stream by forced reset or power-off (my code couldn't always unmount, got stuck in a loop waiting on something else).
But having that little bit of voltage there, just kept the card locked up.
I believe lonesock through heroic effort has solved that problem. I think he's found an
initialization sequence that will get cards out of a "bad" state pretty reliably.
If you still find it necessary to power cycle, let us know.
Can you guys say what kind of actual variation in read speeds you see with your new driver? Is it limited by the Prop, so that a faster card doesn't buy you anything?
Just asking because I'm using the SD card as a video buffer. It's an old 256 MB card and I'm wondering if it's worth trying an "extreme" SD card...
For reading, it probably doesn't make much difference. For writing, it can definitely make a difference, especially with
respect to "stuttering" (i.e., the overall bandwidth may be high, but some cards will pause on very big writes for quite some time).
For reads, as long as you are doing big sequential reads, it probably doesn't make much difference. Indeed, it may be possible to get even
faster for reads by arranging things so the PASM dumps the data where you want it rather than requiring a separate longmove() to move
every chunk of data. Of course make sure you are using 32K sectors, and make sure your destination buffer is longword aligned.
You should see about 1.6MB/sec; time it and if you're not seeing that, then we'll have to figure out why not.
We had a table, but I notice the table is out of date, so I'll have to rerun the tests on my collection of cards.
So the read speed is limited by fsrw and not the card?· The wikipedia site seems to indicate that max read speed is higher in higher end cards:
SanDisk classifies their cards as: [list][*]Ultra II — minimum read speed of 15 MByte/s (100x) [*]Extreme III — maximum speed of 30 MByte/s (200x) [*]Extreme IV — up to 45 MByte/s (300x) [/list]
Yep, pretty much limited by fsrw. We're using a one-pin SPI interface that tops out at, I think, 25MHz, and there's overhead to
issue commands and the like. There may be a bit more headroom, but the one-pin/25MHz will limit us to just about 3MB/sec
best case, and I think almost all cards can do that pretty easily.
Note that at our current 1.6MB/sec we're doing single-instruction-per-bit collection, and then there's the loop overhead and
the overhead to store to RAM. We might be able to improve things a bit more, but it's quickly getting into diminishing
returns.
But again, are you actually *seeing* 1.6MB/sec? If you're not, the first thing to figure out is, why not.
If you're only seeing 200kB/sec, something's very wrong. Most likely you're using the wrong version of fsrw, or you're using ppgetc() or something.
Are you willing to put a zip file up here, or send it to me by private email?
Here's the SPIN loop that fills the HUB RAM buffer on command from the ASM video driver:
sd.popen(STRING("jeanluc.dat"),"r")
i:=@buffer
sd.pread6(i,buffersectors) 'modified FSRW to read fixed #sectors directly to HUB RAM buffer
BufferFlag:=1
lcd.start(@lcd_status) 'buffer is filled before starting video driver here
'start buffer fill loop
repeat
repeat until bufferFlag==2 'video driver sets flag to 2 when starting new video frame
repeat 16
repeat until bufferFlag==0 'video driver sets flag to 0 sometime while reading buffer
sd.pread6(i,buffersectors)
bufferFlag:=1
'start over
sd.seek(0) 'reset everything
sd.pread6(i,buffersectors)
And, here are the two constants in the video driver that I use to slow things down:
PixelClock long 500_000 '500_000+ read-only
_hd long 1200'512'512 '1+ read-only
I would start by eliminating the buffer flag waiting and just do the I/O and see how fast that is.
It looks like you are reading 15*512=7680 bytes for each image, and you are reading 17 images,
so the total I/O is 130K. That should take a small fraction of a second.
If the I/O is fast after removing the two "repeat untils" then the problem is somewhere in your
code. If it's not, we'll continue digging in the SD stuff.
I will mention here that you probably want to be double-buffering anyway, letting the SD fill
one buffer while the LCD is rendering from the other, and then swap. If you have the memory.
Is pread6() mainly there for speed? I'd also try using just pread() since with aligned buffers
it should be pretty quick.
getnextcluster() should *not* take too long but there's always that possibility. The first way to
try to "fix" that would be to just put the data on an empty card; that will make sure that it is
contiguous.
Rayman: I find the file start location. I require the file to be contiguous. So from then on I use the fsrw low level to just read and write sectors directly. No file overhead. This may help you if you are not doing it that way now.
The code is in the TriBlade thread (was the last page) version _rr130. FYI I also have to tristate the bus so there are a few extra calls to enable/disable the bus which you will not require and I disabled the read ahead (it's all commented).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I simplified your code so I could run it without the LCD; the archive attached is what I ended up with.
It talks to the serial port (and uses pin definitions as defined in sysdep.spin which you'll have to update for
your system). I get a time of 6.24M clocks at 100MHz which is 62.4ms per loop. Each loop is reading
131K so that works out to be 2.1MB/sec. Admittedly this is at 100MHz, but at 80MHz it shouldn't be
slower than 0.8 times this or 1.7MB/sec.
So it looks to be the waits, which implies it's the code updating the LCDs that is causing the slowdown.
Run the attached code on your system (after updating sysdep.spin to adjust the clock frequency and
the SD pins) and let me know what number you get on your serial port.
Here is what I use to get the first sector of the file
r := sd.popen(st,"r")································ 'Open file for read (blank image)
CheckError(r)
drive_base[noparse][[/noparse]n] := sd.getSDdatablock··················· 'get the sectorno of the file (returns the sector+1) ·
I haven't checked the whole code, but I think the comment "sector+1" is wrong. I think its the first sector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
But after my last post I had to go to bed. 5 hours sleep is minimum I need to make it through the week.
Now I'm at work and can't provide a picture.
Believe it or not, but I don't have a single tantalum capacitor left to try that. Hope to find one on a board in my trash-box that I can desolder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Can You post that code on Forum ?
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
ZIP-file in the first post. Text says that this code is damn slow currently, but I think the important thing is to see how it works in 4-bit mode.
So, tomorrow I'll put my SD card adapter on a prototype PCB with short wires and plug it directly into the breadboard besides the propeller. Hope that solves my problem.
but I was having major trouble with the SD card stuff when I had the prop-plug constantly plugged in on my protoboard.
the process that solved it was:
download new change to eeprom
power off switch
remove prop plug
power switch back on
plug prop-plug back in for serial comm stuff
I was literally tearing my hair out.
granted, it had something to do with the card communication being interrupted mid-stream by forced reset or power-off (my code couldn't always unmount, got stuck in a loop waiting on something else).
But having that little bit of voltage there, just kept the card locked up.
initialization sequence that will get cards out of a "bad" state pretty reliably.
If you still find it necessary to power cycle, let us know.
Just asking because I'm using the SD card as a video buffer. It's an old 256 MB card and I'm wondering if it's worth trying an "extreme" SD card...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
respect to "stuttering" (i.e., the overall bandwidth may be high, but some cards will pause on very big writes for quite some time).
For reads, as long as you are doing big sequential reads, it probably doesn't make much difference. Indeed, it may be possible to get even
faster for reads by arranging things so the PASM dumps the data where you want it rather than requiring a separate longmove() to move
every chunk of data. Of course make sure you are using 32K sectors, and make sure your destination buffer is longword aligned.
You should see about 1.6MB/sec; time it and if you're not seeing that, then we'll have to figure out why not.
We had a table, but I notice the table is out of date, so I'll have to rerun the tests on my collection of cards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
issue commands and the like. There may be a bit more headroom, but the one-pin/25MHz will limit us to just about 3MB/sec
best case, and I think almost all cards can do that pretty easily.
Note that at our current 1.6MB/sec we're doing single-instruction-per-bit collection, and then there's the loop overhead and
the overhead to store to RAM. We might be able to improve things a bit more, but it's quickly getting into diminishing
returns.
But again, are you actually *seeing* 1.6MB/sec? If you're not, the first thing to figure out is, why not.
Right now, I use that rate but add in extra front porch to slow things down because my actual read rate is closer to ~200 kB/sec.
I've already modified FSRW to write directly blocks to my HUB buffer, so I'm not sure what else I can do (easily)...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Are you willing to put a zip file up here, or send it to me by private email?
Here's the SPIN loop that fills the HUB RAM buffer on command from the ASM video driver:
sd.popen(STRING("jeanluc.dat"),"r") i:=@buffer sd.pread6(i,buffersectors) 'modified FSRW to read fixed #sectors directly to HUB RAM buffer BufferFlag:=1 lcd.start(@lcd_status) 'buffer is filled before starting video driver here 'start buffer fill loop repeat repeat until bufferFlag==2 'video driver sets flag to 2 when starting new video frame repeat 16 repeat until bufferFlag==0 'video driver sets flag to 0 sometime while reading buffer sd.pread6(i,buffersectors) bufferFlag:=1 'start over sd.seek(0) 'reset everything sd.pread6(i,buffersectors)And, here are the two constants in the video driver that I use to slow things down:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
long Buffer[noparse][[/noparse]bufferlongs]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
But, any chance the "GetNextCluster" routine takes a long time?
Just in case we can't find the problem, can I just make a list of datablocks used by the file and then call
sdspi.readblock(datablock, @buf)
for each block?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Post Edited (Rayman) : 12/2/2009 12:58:11 AM GMT
It looks like you are reading 15*512=7680 bytes for each image, and you are reading 17 images,
so the total I/O is 130K. That should take a small fraction of a second.
If the I/O is fast after removing the two "repeat untils" then the problem is somewhere in your
code. If it's not, we'll continue digging in the SD stuff.
I will mention here that you probably want to be double-buffering anyway, letting the SD fill
one buffer while the LCD is rendering from the other, and then swap. If you have the memory.
Is pread6() mainly there for speed? I'd also try using just pread() since with aligned buffers
it should be pretty quick.
try to "fix" that would be to just put the data on an empty card; that will make sure that it is
contiguous.
Are you sure this card is using 32K clusters?
So, I'm pretty confident now that it's the SD card reading that is slow somehow...
Maybe it's the seek(0)? But, I don't see why that should be slow either...
I don't know for sure my clustersize... Do I have to format to know?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
The code is in the TriBlade thread (was the last page) version _rr130. FYI I also have to tristate the bus so there are a few extra calls to enable/disable the bus which you will not require and I disabled the read ahead (it's all commented).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
sdspi.readblock(datablock++, @buf)
??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Andy
I simplified your code so I could run it without the LCD; the archive attached is what I ended up with.
It talks to the serial port (and uses pin definitions as defined in sysdep.spin which you'll have to update for
your system). I get a time of 6.24M clocks at 100MHz which is 62.4ms per loop. Each loop is reading
131K so that works out to be 2.1MB/sec. Admittedly this is at 100MHz, but at 80MHz it shouldn't be
slower than 0.8 times this or 1.7MB/sec.
So it looks to be the waits, which implies it's the code updating the LCDs that is causing the slowdown.
Run the attached code on your system (after updating sysdep.spin to adjust the clock frequency and
the SD pins) and let me know what number you get on your serial port.
-tom
r := sd.popen(st,"r")································ 'Open file for read (blank image)
CheckError(r)
drive_base[noparse][[/noparse]n] := sd.getSDdatablock··················· 'get the sectorno of the file (returns the sector+1)
·
I haven't checked the whole code, but I think the comment "sector+1" is wrong. I think its the first sector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
edit: ignore that, just looked at source, the thread opened at page 9, lol, I didn't see page 10 [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
Post Edited (Baggers) : 12/2/2009 9:17:19 AM GMT