rockiki: Tried your test and got a number like 6 million... That should translate into a refresh rate of 13 fps or so. But, I don't think I'm getting that...
So, I think there is something wrong in the code... Or, the refresh rate is higher than I think (looks like I need to measure that...)...
Rayman, I'm hoping to get one of the breakout boards soon, so if you've not fixed it by then I'll have a look to see if I can see what the issue is. the more look at it the better the chance of fixing it is. [noparse]:D[/noparse]
Remember, I'm timing *17* frames, not just one. So 6 million at 80MHz is 75ms, which is 4.4ms/frame, which should be a refresh rate of
more than 200fps. [noparse][[/noparse]Actually, I'm not sure about this; how big is a frame? I'm assuming one of those pread6() calls is a frame, but if
it takes 17 pread6()s to make a frame, then you're bandwidth limited for sure.]
The reason I cut it down is so you could put it back. Add individual timing for each of the wait statements, and figure out which is taking
the most time, and then figure out how to improve the LCD transfer code, or else overlap it by using two buffers so you're transferring
to the LCD at the same time you're transferring from the SD.
The main thing is, the SD code, fsrw as-is, appears to be plenty fast for what you're doing, so you shouldn't need to resort to tricks like
getting buffer addresses and using low-level buffer reads or anything like that. Also, I used the fsrw you have in your archive, just to be
sure I was using the exact same version as you.
What I'd do as the next step is take your original code, comment out the pread parts (so you're not actually doing *any* SD I/O) and
see what sort of speed you get with just that, just your LCD updating code. If that's not at least 200 fps, then that's further confirmation
that the LCD updating code needs work.
Rayman said...
rockiki: Tried your test and got a number like 6 million... That should translate into a refresh rate of 13 fps or so. But, I don't think I'm getting that...
So, I think there is something wrong in the code... Or, the refresh rate is higher than I think (looks like I need to measure that...)...
rokicki: Just to clarify... I didn't use your code exactly... It was easier for me just to display the result on the connected LCD than to set up a serial terminal... I was looking at the timing for one complete reading of the file (17 fillings of the buffer). That is 6 million or ~13 fps...
More clarification: The file size is 480x272= 131 kB. The buffer size is 480x16= 7.7 kB. So, I have to fill the buffer 17 times for a full screen (480x272) image...
With my tweaks, FSRW seems to be doing an average throughput of 1.7 MB/s.
That seems pretty good to me. I thought that 13 fps would be plenty fast. And, maybe it is. I thought the rate was more like 6 fps, but I'll do an actual measurement to see for sure...
Okay, great. 13fps isn't *that* fast, but 1.7MB/s is pretty good. You're just moving a lot of data. Glad to hear you're not just seeing 200KB/sec; that
would be disappointing!
Okay, I just measured actual best frame rate with a scope and it is 13 fps.
It does look pretty good, except for a few pixels that seem to flicker...· I think I'll double check setup and hold times on the pixel clock to see if something is screwy there...
In case I have to bump it up a few fps, I suppose the first thing I should do is compress the 6-bit data so that it only uses 6-bits, instead of the 8 it does now...· That should bump it up to 17 fps.
If that's still not enough, then I'll look into make a table of SD card blocks to read from and call the SD code directly from the video driver...
rokicki said...
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.
I've though just a little about this and decided (at least for the moment) that one buffer is the way to go (keeping it simple)....
I require that the SD pixel read rate, Fsd,·is greater than the Video pixel rate, Fvid.· Or, Fvid<Fsd.· Also, I will run the video fast enough to ensure that Fvid>Fsd*2.
Under these conditions, I can just command the SD driver to fill the buffer when half empty.· There's no way for the SD to fill to the current position in the buffer.· And we are sure the·sd driver will be done filling·before the video driver is once again to the halfway point.
This is true. You're guaranteed no faster than one instruction per bit currently (but remember there is a single-sector readahead in the cog,
so you may get 512 bytes faster than you expect). So you might be able to command it to fill the buffer when only 1/4th empty or some such.
(Indeed, I hope to put together a simple DMA scheme for fsrw that uses a ring buffer and two pointers, so that all you need to do is tell it
when you're done with data by advancing a pointer and it will fill in the next buffer for you. This for reading and writing.)
I seriously doubt a table of SD card blocks will speed things up much; you're not too far off our theoretical peak of the raw card.
Why don't you take the raw sd-driver and rip of all parts that you don't need. You only need to adress sectors and read em. No write, no HUB-command (other than fetching the next start-sector), no decision making ..... Not to make it faster, but to make room for adding your LCD code directly.
That's what I plan to do for my LCD driver.
What I already did is directly incorporate my driver stuff in a 1.7 version of FSRW. And it was ~30% faster. And there is no more need to have a buffer.
Put all your images in a big file. So for each image you can easyly calculate the sector number where it starts. If you copy that file to a fresh formatted card, the sectors will be in a row. The FSRW part is of no use in your case, as you don't have time to read other stuff from that card when displaying.
Maybe it's possible to simply put one row into one sector and stop reading when you got 480 bytes. In the hsync-phase you could possibly adress the next sector.
I guess saving the 2 dummy bits per pixel will not help very much because you need additional shift operations then. Why don't you connect those 2 pins to the LCD as well. Then you have 3/3/2 color scheme.
I think I see now what threw me off... I set the Pixel clock to what the driver says is the minimum value, 500_000. But, there's something wrong with either Chip's code or the PLL because it doesn't work right below 4_000_000. It looks like that's the minimum pixel clock...
I am just updating to the latest version fsrw26 and have a few questions...
pub mount_explicit(DO, CLK, DI, CS) : r | start, sectorspercluster, reserved, rootentries, sectors
{{
' Mount a volume. The address passed in is passed along to the block
' layer; see the currently used block layer for documentation. If the
' volume mounts, a 0 is returned, else abort is called.
}}
if (pdate == 0)
pdate := constant(((2009-1980) << 25) + (1 << 21) + (27 << 16) + (7 << 11))
I have a question, which is different that Cluso's.
pub nextfile(fbuf) | i, t, at, lns
{{
' Find the next file in the root directory and extract its
' (8.3) name into fbuf. Fbuf must be sized to hold at least
' 13 characters (8 + 1 + 3 + 1). If there is no next file,
' -1 will be returned. If there is, 0 will be returned.
}}
repeat
if (bufat => bufend)
t := pfillbuf
if (t < 0)
return t
if (((floc >> SECTORSHIFT) & ((1 << clustershift) - 1)) == 0)
fclust++
at := @buf + bufat
if (byte[noparse][[/noparse]at] == 0)
return -1
bufat += DIRSIZE
if (byte[noparse][[/noparse]at] <> $e5 and (byte[noparse][[/noparse]at][noparse][[/noparse]$0b] & $18) == 0)
lns := fbuf
repeat i from 0 to 10
byte[noparse][[/noparse]fbuf] := byte[noparse][[/noparse]at][noparse][[/noparse] i ]
fbuf++
if (byte[noparse][[/noparse]at][noparse][[/noparse] i ] <> " ")
lns := fbuf
if (i == 7 or i == 10)
fbuf := lns
if (i == 7)
byte[noparse][[/noparse]fbuf] := "."
fbuf++
byte[noparse][[/noparse]fbuf] := 0
return 0
I like this method, and I'm wondering if a "prevfile" could be done as well. It would be great to be able to go backwards as well in the directory. I know it is sort of a strange thing because it isn't typical.
I would probably do it myself, but I'm somewhat confused at all that is going on here.
Opinions?
James L
Edit: I had to space the [noparse][[/noparse] i ] tags to prevent italics thing from happening
Maybe; I'll have to look more carefully. In any case, it's probably not a big deal.
[noparse][[/noparse]quote]
And would it be simpler (& shorter) to remove the if statement completely and define pdate as...
pdate long (((2009-1980) << 25) + (7 << 21) + (27 << 16) ' current date (default 27 July 2009)
Yes; this is good. It *slightly* changes the semantics, but that's okay.
[noparse][[/noparse]quote]
I presume that seconds can only be even (this is the FAT definition)? (last bit lost)
I'll have to review this, but yeah, I think they ran out of bits or something.
[noparse][[/noparse]quote]
Should I be using "safe_spi.spin" or "mb_raw_spi.spin" ??? And what is the difference (presume it is just slower clocking) ?
In general unless you need the speed set to *awesome* I recommend going with safe_spi.spin. If you need the
best read speed (and note that mb_rw and safe_spi differ only on read speed) you can try mb_raw_spi and if it
works on your hardware go with that. But we have had some reports that in certain situations mb_raw_spi may
not work, so we've made safe_spi be the default.
For most people, safe_spi will not only be plenty fast, but the overhead of the *other* code will mean there will be
no difference between safe_spi and mb_rw.
[noparse][[/noparse]quote]
I have made datablock public... (returns current SD sector)
rokicki said...
Prevfile? I don't think it would get much use; why would you want something like that?
Certainly doable though.
I'm using the system with limited user input. I figured it would be nice for the user to be able to back up the the directory if they accidentally passed what they were looking for.
If it's not usable, and others don't want it, I may have to decipher what is happening here, and do it myself.
I'm using it for a user interface, so i really need to have the ability to change the file name in both directions. This may be doable now, I just don't know how. I haven't played with FSRW much (not directly any how).
rokicki: Thanks for the reply. I have an interesting?? situation where one Sandisk 1GB microSD is giving some reads with errors but a Sandisk 2GB microSD works fine. It must be marginal as both work on the TriBlade (6MHz), but only the 2GB on RamBlade (5MHz). I have yet to track this down, but will try "safe_spi.spin".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
rokicki: Further to my read problem and Sandisk 1GB microSD...
It runs much better with 6MHz and 6.5MHz but not totally - fails on one cpm program. I have tried safe_spi and it is the same. I tried adding an extra set of clocks to disable DO (call #in8) with the same results.
Still testing....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I am only reading, but writing seems ok, but minimal anyway. I believe the cards are real SanDisk - the 1GB came with my wireless broadband modem.
The RamBlade uses P24-27 for the DI,DO,CLK whereas the TriBlade uses P8=DI, P9=DO, P28=CLK. The RamBlade is QFP and the TriBlade is DIP.
I am going to try loading the spi driver in the relevant cog close to the pins and see what that does. I am pretty certain it is not a pcb layout issue.
Postedit: A smarter thing to do would be to run your test program - I will do that first. It is still possibly a software issue on my end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OK, I believe my problem must be with my software and something different with the 1GB card. It's a timing issue.
Here are some microSD timing results.
Note I have the RamBlade·overclocking at 114.5MHz
fsrw23 mb_rawb_spi test result on TriBlade SanDisk 1GB uSD
Clock: 96000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 3968 kB in 2059 ms at 1926 kB/s
Raw read 8064 kB in 3982 ms at 2025 kB/s
fsrw pwrite 4064 kB in 3396 ms at 1196 kB/s
fsrw pread 4064 kB in 2670 ms at 1522 kB/s
FSRW pputc 127 kB in 3613 ms at 35 kB/s
FSRW pgetc 127 kB in 3087 ms at 41 kB/s
All done!
fsrw26 safe_spi test result on TriBlade SanDisk 1GB uSD
Clock: 96000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 3968 kB in 2018 ms at 1966 kB/s
Raw read 3968 kB in 3752 ms at 1057 kB/s
fsrw pwrite 4064 kB in 3654 ms at 1112 kB/s
fsrw pread 4064 kB in 3848 ms at 1056 kB/s
FSRW pputc 127 kB in 3612 ms at 35 kB/s
FSRW pgetc 127 kB in 3085 ms at 41 kB/s
All done!
fsrw26 mb_rawb_spi test result on TriBlade SanDisk 1GB uSD
Clock: 96000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3752 ms at 2149 kB/s
Raw read 8064 kB in 3829 ms at 2106 kB/s
fsrw pwrite 4064 kB in 3483 ms at 1167 kB/s
fsrw pread 4064 kB in 3848 ms at 1056 kB/s
FSRW pputc 127 kB in 3611 ms at 35 kB/s
FSRW pgetc 127 kB in 3085 ms at 41 kB/s
All done!
fsrw26 safe_spi test result on RamBlade SanDisk 1GB uSD
Clock: 96000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3772 ms at 2137 kB/s
Raw read 3968 kB in 3752 ms at 1057 kB/s
fsrw pwrite 4064 kB in 3609 ms at 1125 kB/s
fsrw pread 4064 kB in 3848 ms at 1056 kB/s
FSRW pputc 127 kB in 3612 ms at 35 kB/s
FSRW pgetc 127 kB in 3085 ms at 41 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD
Clock: 96000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3752 ms at 2149 kB/s
Raw read 8064 kB in 3829 ms at 2106 kB/s
fsrw pwrite 4064 kB in 3565 ms at 1140 kB/s
fsrw pread 4064 kB in 3848 ms at 1056 kB/s
FSRW pputc 127 kB in 3729 ms at 34 kB/s
FSRW pgetc 127 kB in 3085 ms at 41 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD
Clock: 80000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 3968 kB in 2182 ms at 1818 kB/s
Raw read 3968 kB in 2261 ms at 1755 kB/s
fsrw pwrite 2016 kB in 2116 ms at 952 kB/s
fsrw pread 2016 kB in 2292 ms at 879 kB/s
FSRW pputc 63 kB in 2209 ms at 28 kB/s
FSRW pgetc 63 kB in 1838 ms at 34 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD (with tristate DO, disable r.ahead)
Clock: 80000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 3968 kB in 2223 ms at 1784 kB/s
Raw read 3968 kB in 2909 ms at 1363 kB/s
fsrw pwrite 2016 kB in 2096 ms at 961 kB/s
fsrw pread 2016 kB in 2292 ms at 879 kB/s
FSRW pputc 63 kB in 2210 ms at 28 kB/s
FSRW pgetc 63 kB in 1838 ms at 34 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD (with tristate DO, disable r.ahead)
6.5MHz * 16 (note 7.3728MHz * 16 fails)
Clock: 104000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3501 ms at 2303 kB/s
Raw read 3968 kB in 2238 ms at 1773 kB/s
fsrw pwrite 4064 kB in 3243 ms at 1253 kB/s
fsrw pread 4064 kB in 3552 ms at 1144 kB/s
FSRW pputc 127 kB in 3334 ms at 38 kB/s
FSRW pgetc 127 kB in 2848 ms at 44 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD (with tristate DO, disable r.ahead)
13.5MHz * 8
Clock: 108000000 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3347 ms at 2408 kB/s
Raw read 3968 kB in 2155 ms at 1841 kB/s
fsrw pwrite 4064 kB in 3173 ms at 1280 kB/s
fsrw pread 4064 kB in 3421 ms at 1187 kB/s
FSRW pputc 127 kB in 3212 ms at 39 kB/s
FSRW pgetc 127 kB in 2743 ms at 46 kB/s
All done!
fsrw26 mb_rawb_spi test result on RamBlade SanDisk 1GB uSD (with tristate DO, disable r.ahead)
14.31818MHz * 8 (note 15MHz * 8 fails)
Clock: 114545440 ClusterSize: 32768 ClusterCount: 30989
Raw write 8064 kB in 3165 ms at 2547 kB/s
Raw read 3968 kB in 2032 ms at 1952 kB/s
fsrw pwrite 4064 kB in 3079 ms at 1319 kB/s
fsrw pread 4064 kB in 3226 ms at 1259 kB/s
FSRW pputc 127 kB in 3048 ms at 41 kB/s
FSRW pgetc 127 kB in 4570 ms at 27 kB/s
All done!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I've tried fsrw23 and fsrw26, spispin, spiasm, spiqasm
I also tried Dongle Basic.
I tried both a 32MB Sandisk uSD with the SD adapter it came with, and a Patriot 1GB SD card.
fsrw speed test reports Mount failed, sometimes with -13, sometimes with -41
I did eventually find -13, it appears to be a timeout, but I have no idea what -41 is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Bought two brand new 2GB cards to try, on top of the three others I've already tried.
Buzzed out circuit, everything checks just fine. No shorts between pins (well, except two grounds), pullups on six pins (not on + and GNDs)
SD Card just won't mount :-(
All cards read just fine under Linux and Windows.
VERY VERY WEIRD.
I never had problems like this with the original FSRW 1.0 release... which is no longer in the original thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
After some googling for docs, unless I am missing something, it looks like FSRW may not be sending out the full initialization sequence SD/MMC cards expect.
Stay tuned for these important messages...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Bill Henning said...
...
I've tried fsrw23 and fsrw26, spispin, spiasm, spiqasm
...
fsrw speed test reports Mount failed, sometimes with -13, sometimes with -41
spispin, spiasm, spiqasm remain unchanged from the FSRW 1.6 release. The new "safe_spi.spin" default block driver for the 2.6 release does in fact have a different initialization sequence from the old ones, but it actually conforms better to the standard while supporting MMC/SD/SDHC cards. It's definitely possible that the issue is there, however I have tested it on ~6 SanDisk cards, most 2GB, but ranging up to 4GB SDHC. Others have tried even larger cards.
Is there any chance you could post a zip of your schematic and source code? If you do not wish to post them on the forum you can email them to me at this username at gmail.com.
The return code of -41 is a mystery...the only places an unspecified code can come back are:
* the send_SPI_command_fast does not get a valid response from the SD card (in the block layer)
* pflushbuf fails (in FSRW, not sure why this would fail here, though)
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Comments
So, I think there is something wrong in the code... Or, the refresh rate is higher than I think (looks like I need to measure that...)...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
http://forums.parallax.com/showthread.php?p=852123
more than 200fps. [noparse][[/noparse]Actually, I'm not sure about this; how big is a frame? I'm assuming one of those pread6() calls is a frame, but if
it takes 17 pread6()s to make a frame, then you're bandwidth limited for sure.]
The reason I cut it down is so you could put it back. Add individual timing for each of the wait statements, and figure out which is taking
the most time, and then figure out how to improve the LCD transfer code, or else overlap it by using two buffers so you're transferring
to the LCD at the same time you're transferring from the SD.
The main thing is, the SD code, fsrw as-is, appears to be plenty fast for what you're doing, so you shouldn't need to resort to tricks like
getting buffer addresses and using low-level buffer reads or anything like that. Also, I used the fsrw you have in your archive, just to be
sure I was using the exact same version as you.
What I'd do as the next step is take your original code, comment out the pread parts (so you're not actually doing *any* SD I/O) and
see what sort of speed you get with just that, just your LCD updating code. If that's not at least 200 fps, then that's further confirmation
that the LCD updating code needs work.
Post Edited (rokicki) : 12/2/2009 4:39:01 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
With my tweaks, FSRW seems to be doing an average throughput of 1.7 MB/s.
That seems pretty good to me. I thought that 13 fps would be plenty fast. And, maybe it is. I thought the rate was more like 6 fps, but I'll do an actual measurement to see for sure...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
would be disappointing!
It does look pretty good, except for a few pixels that seem to flicker...· I think I'll double check setup and hold times on the pixel clock to see if something is screwy there...
In case I have to bump it up a few fps, I suppose the first thing I should do is compress the 6-bit data so that it only uses 6-bits, instead of the 8 it does now...· That should bump it up to 17 fps.
If that's still not enough, then I'll look into make a table of SD card blocks to read from and call the SD code directly from the video driver...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I require that the SD pixel read rate, Fsd,·is greater than the Video pixel rate, Fvid.· Or, Fvid<Fsd.· Also, I will run the video fast enough to ensure that Fvid>Fsd*2.
Under these conditions, I can just command the SD driver to fill the buffer when half empty.· There's no way for the SD to fill to the current position in the buffer.· And we are sure the·sd driver will be done filling·before the video driver is once again to the halfway point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
so you may get 512 bytes faster than you expect). So you might be able to command it to fill the buffer when only 1/4th empty or some such.
(Indeed, I hope to put together a simple DMA scheme for fsrw that uses a ring buffer and two pointers, so that all you need to do is tell it
when you're done with data by advancing a pointer and it will fill in the next buffer for you. This for reading and writing.)
I seriously doubt a table of SD card blocks will speed things up much; you're not too far off our theoretical peak of the raw card.
That's what I plan to do for my LCD driver.
What I already did is directly incorporate my driver stuff in a 1.7 version of FSRW. And it was ~30% faster. And there is no more need to have a buffer.
Put all your images in a big file. So for each image you can easyly calculate the sector number where it starts. If you copy that file to a fresh formatted card, the sectors will be in a row. The FSRW part is of no use in your case, as you don't have time to read other stuff from that card when displaying.
Maybe it's possible to simply put one row into one sector and stop reading when you got 480 bytes. In the hsync-phase you could possibly adress the next sector.
I guess saving the 2 dummy bits per pixel will not help very much because you need additional shift operations then. Why don't you connect those 2 pins to the LCD as well. Then you have 3/3/2 color scheme.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
pub mount_explicit(DO, CLK, DI, CS) : r | start, sectorspercluster, reserved, rootentries, sectors {{ ' Mount a volume. The address passed in is passed along to the block ' layer; see the currently used block layer for documentation. If the ' volume mounts, a 0 is returned, else abort is called. }} if (pdate == 0) pdate := constant(((2009-1980) << 25) + (1 << 21) + (27 << 16) + (7 << 11))Shouldn't the·last line be ?
And would it be simpler (& shorter) to remove the if statement completely and define pdate as...
I presume that seconds can only be even (this is the FAT definition)? (last bit lost)
Should I be using "safe_spi.spin" or "mb_raw_spi.spin" ??? And what is the difference (presume it is just slower clocking) ?
I have made datablock public... (returns current SD sector)
Thanks lonesock & rokicki for a fantastic SD object
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
pub nextfile(fbuf) | i, t, at, lns {{ ' Find the next file in the root directory and extract its ' (8.3) name into fbuf. Fbuf must be sized to hold at least ' 13 characters (8 + 1 + 3 + 1). If there is no next file, ' -1 will be returned. If there is, 0 will be returned. }} repeat if (bufat => bufend) t := pfillbuf if (t < 0) return t if (((floc >> SECTORSHIFT) & ((1 << clustershift) - 1)) == 0) fclust++ at := @buf + bufat if (byte[noparse][[/noparse]at] == 0) return -1 bufat += DIRSIZE if (byte[noparse][[/noparse]at] <> $e5 and (byte[noparse][[/noparse]at][noparse][[/noparse]$0b] & $18) == 0) lns := fbuf repeat i from 0 to 10 byte[noparse][[/noparse]fbuf] := byte[noparse][[/noparse]at][noparse][[/noparse] i ] fbuf++ if (byte[noparse][[/noparse]at][noparse][[/noparse] i ] <> " ") lns := fbuf if (i == 7 or i == 10) fbuf := lns if (i == 7) byte[noparse][[/noparse]fbuf] := "." fbuf++ byte[noparse][[/noparse]fbuf] := 0 return 0I like this method, and I'm wondering if a "prevfile" could be done as well. It would be great to be able to go backwards as well in the directory. I know it is sort of a strange thing because it isn't typical.
I would probably do it myself, but I'm somewhat confused at all that is going on here.
Opinions?
James L
Edit: I had to space the [noparse][[/noparse] i ] tags to prevent italics thing from happening
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
Post Edited (James Long) : 12/29/2009 3:29:07 AM GMT
pdate := constant(((2009-1980) << 25) + (7 << 21) + (27 << 16)) '27 July 2009Maybe; I'll have to look more carefully. In any case, it's probably not a big deal.
[noparse][[/noparse]quote]
And would it be simpler (& shorter) to remove the if statement completely and define pdate as...
Yes; this is good. It *slightly* changes the semantics, but that's okay.
[noparse][[/noparse]quote]
I presume that seconds can only be even (this is the FAT definition)? (last bit lost)
I'll have to review this, but yeah, I think they ran out of bits or something.
[noparse][[/noparse]quote]
Should I be using "safe_spi.spin" or "mb_raw_spi.spin" ??? And what is the difference (presume it is just slower clocking) ?
In general unless you need the speed set to *awesome* I recommend going with safe_spi.spin. If you need the
best read speed (and note that mb_rw and safe_spi differ only on read speed) you can try mb_raw_spi and if it
works on your hardware go with that. But we have had some reports that in certain situations mb_raw_spi may
not work, so we've made safe_spi be the default.
For most people, safe_spi will not only be plenty fast, but the overhead of the *other* code will mean there will be
no difference between safe_spi and mb_rw.
[noparse][[/noparse]quote]
I have made datablock public... (returns current SD sector)
Certainly doable though.
I'm using the system with limited user input. I figured it would be nice for the user to be able to back up the the directory if they accidentally passed what they were looking for.
If it's not usable, and others don't want it, I may have to decipher what is happening here, and do it myself.
I'm using it for a user interface, so i really need to have the ability to change the file name in both directions. This may be doable now, I just don't know how. I haven't played with FSRW much (not directly any how).
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
It runs much better with 6MHz and 6.5MHz but not totally - fails on one cpm program. I have tried safe_spi and it is the same. I tried adding an extra set of clocks to disable DO (call #in8) with the same results.
Still testing....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The RamBlade uses P24-27 for the DI,DO,CLK whereas the TriBlade uses P8=DI, P9=DO, P28=CLK. The RamBlade is QFP and the TriBlade is DIP.
I am going to try loading the spi driver in the relevant cog close to the pins and see what that does. I am pretty certain it is not a pcb layout issue.
Postedit: A smarter thing to do would be to run your test program - I will do that first. It is still possibly a software issue on my end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 12/30/2009 6:14:10 AM GMT
Here are some microSD timing results.
Note I have the RamBlade·overclocking at 114.5MHz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
What are errors -41 and -13?
Is there an error code list somewhere?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I've tried fsrw23 and fsrw26, spispin, spiasm, spiqasm
I also tried Dongle Basic.
I tried both a 32MB Sandisk uSD with the SD adapter it came with, and a Patriot 1GB SD card.
fsrw speed test reports Mount failed, sometimes with -13, sometimes with -41
I did eventually find -13, it appears to be a timeout, but I have no idea what -41 is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Bought two brand new 2GB cards to try, on top of the three others I've already tried.
Buzzed out circuit, everything checks just fine. No shorts between pins (well, except two grounds), pullups on six pins (not on + and GNDs)
SD Card just won't mount :-(
All cards read just fine under Linux and Windows.
VERY VERY WEIRD.
I never had problems like this with the original FSRW 1.0 release... which is no longer in the original thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
After some googling for docs, unless I am missing something, it looks like FSRW may not be sending out the full initialization sequence SD/MMC cards expect.
Stay tuned for these important messages...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Is there any chance you could post a zip of your schematic and source code? If you do not wish to post them on the forum you can email them to me at this username at gmail.com.
The return code of -41 is a mystery...the only places an unspecified code can come back are:
* the send_SPI_command_fast does not get a valid response from the SD card (in the block layer)
* pflushbuf fails (in FSRW, not sure why this would fail here, though)
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.