The code I posted last night on TriBlade can start displaying (using spin and FDX) the sector information from any fixed start sector onwards. Perhaps this may make the basis of some tests for you heater.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
lonesock: I am trying to put your code mb_spi.spin into the TriBlade.
I use the pins to the SD card on a bus so I must release them after use, just as DO must be forced into tristate. Looking at the pasm code, I can reset DIRA to all inputs after I use your code to force DO tristate. I need to also add setting DIRA outputs for each r & w command. (It is possible to leave -CS an output but DO,DI & CLK must be made inputs.)
Will the following work? Any delay required after the dira pins are set to outputs, particularly the -CS pin?
I declare a long setdira
setdira LONG 0 'store the output pin mask
I change the SPI_engine_entry instruction "RDLONG DIRA,PAR" to
RDLONG setdira,PAR 'save the output pin mask
MOV DIRA,setdira 'set the output pins
I add the following line immediately after start_mb_read and start_mb_write
MOV DIRA,setdira 'set the output pins
I add the following line immediately before release_DO_ret
MOV DIRA,#0 'make all inputs
Any other comments??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm not sure about the mb_spi code (as that was a slightly older incarnation), but the mb_rawb_spi code should do what you want already. There is a line in the PASM release_DO subroutine that you need to uncomment (tip: search for your user name [noparse][[/noparse]8^). mb_small_spi should also work if you uncomment the line. It is smaller but slower. Both of these versions implement a read-ahead / write-behind strategy that should help performance while not costing you much more than a little extra PASM code (the buffered data is in cog RAM). I think the mb_spi _could_ be made to work...the problem was not in releasing the data lines, but in making sure they are outputs again as needed.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Thanks for your reply Jonathan. Postedit: Aha! I see where to uncomment the line to tristate the outputs - I missed that before
I cannot use read ahead or write behind because I use the SD pins as a bus to the SRAM. They must be released before I can continue as I need to retake control with another pasm program. So I need a routine/command that releases the lines and a routine/command that retakes the lines so that I can do a block read/write.
Thanks,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The RA/WB stuff is inside a state machine. It will only perform read-ahead if you are reading, and write-behind if you are writing. As soon as you give the release command, it will finish what it is doing, release the pins, and return control to you (i.e. "release" is a blocking call). Then absolutely nothing happens until you request another read or write, so it should be safe for your application.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
lonesock: Here is some code·that I cannot get working once I release the pins, although release is not the problem as I can comment this out.
Perhaps I am missing something in trying to drive the mb_rawb_spi.spin directly, passing it a block number and buffer and expecting a read/write to work.
I haven't had time to look at your code yet, sorry. One possibility I forgot to mention, though, is that my low-level code requires that your buffer be long-aligned.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Propeller Demo Board + uController.Com SD card adapter, with a 1GB SD card
with no maker...cheap from MicroCenter. I used Parallax Serial Terminal with FullDuplexSerial.
Worked GREAT and GOOD speeds. here are the results.....
But before that a comment on the Parallax Serial Terminal (I used it) inability to
cut text in its window to the clipboard.....IT CAN.....use CTRL+C...see this posting.
That is how I got the text data below.
Here are my results.....Thanks Tomas Rokicki and Jonathan Dummer for this great Object.
Notice my great speeds....good for a cheapy card.
Size: 1GB....formatted for FAT16 and 64K clusters
Type: Unknown...cheapy bought from MicroCenter
Test: Succeeded all throughout
Clock: 80_000_000 ClusterSize: 65536 ClusterCount: 15622
Raw write 3968 kB in 2331 ms at 1702 kB/s
Raw read 3968 kB in 2371 ms at 1673 kB/s
fsrw pwrite 4064 kB in 3620 ms at 1122 kB/s
fsrw pread 4064 kB in 3191 ms at 1273 kB/s
FSRW pputc 63 kB in 2087 ms at 30 kB/s
FSRW pgetc 63 kB in 1836 ms at 34 kB/s
All done!
Problems: I had no problems whatsoever.
Here are results with FAT16 with 32K clusters....not much slower
Clock: 80000000 ClusterSize: 32768 ClusterCount: 31241
Raw write 3968 kB in 2335 ms at 1699 kB/s
Raw read 3968 kB in 2371 ms at 1673 kB/s
fsrw pwrite 4064 kB in 3891 ms at 1044 kB/s
fsrw pread 4064 kB in 3203 ms at 1268 kB/s
FSRW pputc 63 kB in 2089 ms at 30 kB/s
FSRW pgetc 63 kB in 1837 ms at 34 kB/s
All done!
Regards
Samuel
Post Edited (SamMishal) : 9/19/2009 6:41:20 AM GMT
I got the SEEK method working, just not sure how to post the code.
It basically works by keeping track of the first sector when the file is opened. When the SEEK method is called, it checks to see if the desired position is before or after the current position in the file. If it's before, then it resets to the first location and quickly follows the chain to the desired position. If its after, then in quickly folows the chain to the desired position.
I have done limited testing with a 300K file and it works perfectly. I have only tested·for 'r' mode. I have no idea
Do I just add it as an attachment here, or does it need to go through source forge?
I mad ethe following changes in the fsrw.spin file...
Add this to your VAR section
Long InitialCluster ' First Cluster of file.
·Added the following code to the popen method...
if (i == 11 and 0 == (byte[noparse][[/noparse]s][noparse][[/noparse]$0b] & $18)) ' this always returns
fclust := brword(s+$1a)
InitialCluster := fclust ' Used later for seek function <<<<<<<<------ Only added this line, others are for position reference
I added these two methods...
Pub Seek(Position)| r, t
' Added to allow the quick seeking to a specific location in the file
' The file first has to be open in Read Mode
' You can't seek past the end of the file
' First check to see if we want to seek to a location lower in the current
' location.
If Position==floc ' We must already be at the proper location
Return
if Position<floc
' We need to move backwards, it's just easier to start at the begining
' of the file and scan forward.
if (direntry)
pflush
bufat := 0
bufend := 0
floc := 0
writelink := 0
direntry := 0
fclust := InitialCluster
frem := (SECTORSIZE << clustershift) <# (filesize)
else
' We're moving forward so simply scan forward
Position := Position - floc
repeat while (Position > 0)
if (bufat => bufend)
t := _SeekForward ' Read more Data from Media
if (t =< 0)
return
t := (bufend - bufat) <# (Position) ' Calcilate how many bytes to read and limit to Count
bufat += t
r += t
Position -= t
Return
pri _SeekForward : r
' This sub is only called by the Seek method.
' It simulates the reading of bytes without actualy reading any bytes
'
if (floc => filesize)
return -1
if (frem == 0)
fclust := nextcluster
frem := (SECTORSIZE << clustershift) <# (filesize - floc)
'sdspi.readblock(datablock, @buf)
r := SECTORSIZE
if (floc + r => filesize)
r := filesize - floc
floc += r
frem -= r
bufat := 0
bufend := r
' return r (default return)
Thanks! While this technique will work, and is suitable for the moment, absolutely, I was hoping
to do it in a slightly different way.
The technique I was going to use was to take the existing code I have for seeking within a cluster
and use that, and only use *this* technique if the seek position was outside the cluster.
I need to just sit down and write the code.
I'm not sure I see how it reads the first block after the seek, in addition, so I'll have to study
the code some more.
In any case, if this works, that's great! I need now to decide if I'm going to test and integrate
what you've sent, or just write it the way I was planning to.
Maybe this is the incentive I need to sit down and write this and get it out the door.
This is how I got the seek method working for my code. If it applies to you then it may be helpful. I believe my method waste as little time as possible seeking.
if(cardFileInUseFlag)
position := ((position <# (previousSize - 1)) #> 0)
' If in current sector then done.
if((currentByte >> 9) <> (position >> 9))
' If not in current sector then flush out working sector in in write mode.
if(filereadWriteFlag)
ifnot(readWriteCurrentSector(true))
return false
' If in current cluster then go to that cluster.
if(((currentByte >> 9) / sectorsPerCluster) <> ((position >> 9) / sectorsPerCluster))
' In the cluster is in front of us start from current position, or go back to the begining of the cluster chain.
if(position < currentByte)
currentByte := 0
currentCluster := currentFile
' Seek until you reach teh cluster from the start of teh chain.
repeat until(((currentByte >> 9) / sectorsPerCluster) == ((position >> 9) / sectorsPerCluster))
currentByte += (sectorsPerCluster << 9)
result := (readFATBlock(currentCluster) & readFATEntry(currentCluster))
' Parse FAT code for errors.
if((result =< 1) or ((not(FATType)) and (result => $FFF0)) or (FATType and (result => $0FFFFFF0)))
return false
' Set new position.
currentCluster := result
' Set switch flag for reading in new sector if you went to a new sector.
result := true
' Set new position.
currentByte := position
' Read in new sector.
if(result)
ifnot(readWriteCurrentSector(false))
return false
' Success.
return true
Sorry about the lack of comments. For anyone who knows what is happening behind the scenes in a FAT file system driver the code should be pretty readable however.
How fast do you guys think I can read a 131kB file over and over again?
Going to try showing a 6-bit photo directly from the SD card...
Is doing seek(0) the best way to restart reading the file from the beginning?
Pretty fast. Seek(0) should be really fast. And the actual reading should be fast if
you pread(); the bigger buffer the better.
If you're talking at screen rates, though, no, I don't think it's going to be *that* fast,
primarily due to Spin overhead.
Rayman said...
How fast do you guys think I can read a 131kB file over and over again?
Going to try showing a 6-bit photo directly from the SD card...
Is doing seek(0) the best way to restart reading the file from the beginning?
I read files and get the physical sector address on the card. Later I use that to do a low level sector(s) read. Works providing the sectors are contiguous. (see ZiCog and TriBlade threads).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Well, I'm just trying the dumb way with seek(0) and pread and guess what...· It works!
It's not perfect yet, and there is a somewhat noticeable flicker, and the screen position isn't entirely stable, but this is pretty amazing, I think...
Here's a photo of the screen cyclically reading from SD.· The vertical position is off, but you get the idea...
lonesock: Many thanks Jonathan. The bugfix works·· Sorry to take so long to test it. While I have not given it a rigerous workout, I have seen no errors on booting CPM and doing a "ls" (like a dir). BTW I am using 6MHz xtal for 96MHz operation
FYI: Posted are the 2 mods that I do (disable readahead and enable the tri-stating). Also the mods for Femto call compatibility (although I will be able to remove this, it may be useful to post it here)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Is there a chance to get SD card running with FSWR24 on a breadboard?
SD card works fine with a FSWR 1.7, but when I switch to 24 it does not pass the boot-block-test. And in fact it reads $d0 $02 instead of the right values. But the boot sector is fine on the card. I had very long wires, so I shortened them. I replaced the 20kOhm resistors proposed in the old FSWR with 10kOhm - but it did not help.
Try reducing your clock frequency way down; if it works at 10MHz but fails at 80MHz, it's the wires
or capacitance or something. If it fails at 10MHz, then it's something else.
I have a 10MHz crystal, so I changed to PLL4x and FSWR24 works then. As I said it already worked with FSWR1.7 which is half the speed of FSWR24, so I expected the breadboard setup being the problem.
Guess now time has come where I need some kind of board with SD card ;o)
One of the SD recomendations is for a bulk capacitor close to the card power supply pins. That is why I suggested this and it could manifest by looking like it is too fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
You need to add backslashes to your calls to sdfat methods in serial_terminal.spin else the aborts don't get caught. For example:
This why it hangs.
With this is in place I get:
mount returned -1000
for my dead card. Which I guess is ERR_CARD_BUSY_TIMEOUT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/12/2009 1:53:51 AM GMT
The code I posted last night on TriBlade can start displaying (using spin and FDX) the sector information from any fixed start sector onwards. Perhaps this may make the basis of some tests for you heater.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I use the pins to the SD card on a bus so I must release them after use, just as DO must be forced into tristate. Looking at the pasm code, I can reset DIRA to all inputs after I use your code to force DO tristate. I need to also add setting DIRA outputs for each r & w command. (It is possible to leave -CS an output but DO,DI & CLK must be made inputs.)
Will the following work? Any delay required after the dira pins are set to outputs, particularly the -CS pin?
I declare a long setdira
setdira LONG 0 'store the output pin mask
I change the SPI_engine_entry instruction "RDLONG DIRA,PAR" to
RDLONG setdira,PAR 'save the output pin mask
MOV DIRA,setdira 'set the output pins
I add the following line immediately after start_mb_read and start_mb_write
MOV DIRA,setdira 'set the output pins
I add the following line immediately before release_DO_ret
MOV DIRA,#0 'make all inputs
Any other comments??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Postedit: Aha! I see where to uncomment the line to tristate the outputs - I missed that before
I cannot use read ahead or write behind because I use the SD pins as a bus to the SRAM. They must be released before I can continue as I need to retake control with another pasm program. So I need a routine/command that releases the lines and a routine/command that retakes the lines so that I can do a block read/write.
Thanks,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 9/17/2009 3:30:00 AM GMT
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Perhaps I am missing something in trying to drive the mb_rawb_spi.spin directly, passing it a block number and buffer and expecting a read/write to work.
Basically this is the sequence
v122 runs on fsrwFemto (and modified)
v123 runs with fsrw23 (and modified)
ZIBOOT.COM is the SD file, although it can be any file for the test.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I have just tried the FSRW2.3 test using a
Propeller Demo Board + uController.Com SD card adapter, with a 1GB SD card
with no maker...cheap from MicroCenter. I used Parallax Serial Terminal with FullDuplexSerial.
Worked GREAT and GOOD speeds. here are the results.....
But before that a comment on the Parallax Serial Terminal (I used it) inability to
cut text in its window to the clipboard.....IT CAN.....use CTRL+C...see this posting.
That is how I got the text data below.
Here are my results.....Thanks Tomas Rokicki and Jonathan Dummer for this great Object.
Notice my great speeds....good for a cheapy card.
Size: 1GB....formatted for FAT16 and 64K clusters Type: Unknown...cheapy bought from MicroCenter Test: Succeeded all throughout Clock: 80_000_000 ClusterSize: 65536 ClusterCount: 15622 Raw write 3968 kB in 2331 ms at 1702 kB/s Raw read 3968 kB in 2371 ms at 1673 kB/s fsrw pwrite 4064 kB in 3620 ms at 1122 kB/s fsrw pread 4064 kB in 3191 ms at 1273 kB/s FSRW pputc 63 kB in 2087 ms at 30 kB/s FSRW pgetc 63 kB in 1836 ms at 34 kB/s All done! Problems: I had no problems whatsoever. Here are results with FAT16 with 32K clusters....not much slower Clock: 80000000 ClusterSize: 32768 ClusterCount: 31241 Raw write 3968 kB in 2335 ms at 1699 kB/s Raw read 3968 kB in 2371 ms at 1673 kB/s fsrw pwrite 4064 kB in 3891 ms at 1044 kB/s fsrw pread 4064 kB in 3203 ms at 1268 kB/s FSRW pputc 63 kB in 2089 ms at 30 kB/s FSRW pgetc 63 kB in 1837 ms at 34 kB/s All done!Regards
Samuel
Post Edited (SamMishal) : 9/19/2009 6:41:20 AM GMT
It basically works by keeping track of the first sector when the file is opened. When the SEEK method is called, it checks to see if the desired position is before or after the current position in the file. If it's before, then it resets to the first location and quickly follows the chain to the desired position. If its after, then in quickly folows the chain to the desired position.
I have done limited testing with a 300K file and it works perfectly. I have only tested·for 'r' mode. I have no idea
Do I just add it as an attachment here, or does it need to go through source forge?
I mad ethe following changes in the fsrw.spin file...
Add this to your VAR section
·Added the following code to the popen method...
if (i == 11 and 0 == (byte[noparse][[/noparse]s][noparse][[/noparse]$0b] & $18)) ' this always returns fclust := brword(s+$1a) InitialCluster := fclust ' Used later for seek function <<<<<<<<------ Only added this line, others are for position referenceI added these two methods...
Pub Seek(Position)| r, t ' Added to allow the quick seeking to a specific location in the file ' The file first has to be open in Read Mode ' You can't seek past the end of the file ' First check to see if we want to seek to a location lower in the current ' location. If Position==floc ' We must already be at the proper location Return if Position<floc ' We need to move backwards, it's just easier to start at the begining ' of the file and scan forward. if (direntry) pflush bufat := 0 bufend := 0 floc := 0 writelink := 0 direntry := 0 fclust := InitialCluster frem := (SECTORSIZE << clustershift) <# (filesize) else ' We're moving forward so simply scan forward Position := Position - floc repeat while (Position > 0) if (bufat => bufend) t := _SeekForward ' Read more Data from Media if (t =< 0) return t := (bufend - bufat) <# (Position) ' Calcilate how many bytes to read and limit to Count bufat += t r += t Position -= t Return pri _SeekForward : r ' This sub is only called by the Seek method. ' It simulates the reading of bytes without actualy reading any bytes ' if (floc => filesize) return -1 if (frem == 0) fclust := nextcluster frem := (SECTORSIZE << clustershift) <# (filesize - floc) 'sdspi.readblock(datablock, @buf) r := SECTORSIZE if (floc + r => filesize) r := filesize - floc floc += r frem -= r bufat := 0 bufend := r ' return r (default return)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
to do it in a slightly different way.
The technique I was going to use was to take the existing code I have for seeking within a cluster
and use that, and only use *this* technique if the seek position was outside the cluster.
I need to just sit down and write the code.
I'm not sure I see how it reads the first block after the seek, in addition, so I'll have to study
the code some more.
In any case, if this works, that's great! I need now to decide if I'm going to test and integrate
what you've sent, or just write it the way I was planning to.
Maybe this is the incentive I need to sit down and write this and get it out the door.
I agree this is probably not the best way. It was justa quick stab at it as I don't fully understand the rest of the driver.
Let me know if you need help testing with your approach.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
if(cardFileInUseFlag) position := ((position <# (previousSize - 1)) #> 0) ' If in current sector then done. if((currentByte >> 9) <> (position >> 9)) ' If not in current sector then flush out working sector in in write mode. if(filereadWriteFlag) ifnot(readWriteCurrentSector(true)) return false ' If in current cluster then go to that cluster. if(((currentByte >> 9) / sectorsPerCluster) <> ((position >> 9) / sectorsPerCluster)) ' In the cluster is in front of us start from current position, or go back to the begining of the cluster chain. if(position < currentByte) currentByte := 0 currentCluster := currentFile ' Seek until you reach teh cluster from the start of teh chain. repeat until(((currentByte >> 9) / sectorsPerCluster) == ((position >> 9) / sectorsPerCluster)) currentByte += (sectorsPerCluster << 9) result := (readFATBlock(currentCluster) & readFATEntry(currentCluster)) ' Parse FAT code for errors. if((result =< 1) or ((not(FATType)) and (result => $FFF0)) or (FATType and (result => $0FFFFFF0))) return false ' Set new position. currentCluster := result ' Set switch flag for reading in new sector if you went to a new sector. result := true ' Set new position. currentByte := position ' Read in new sector. if(result) ifnot(readWriteCurrentSector(false)) return false ' Success. return trueSorry about the lack of comments. For anyone who knows what is happening behind the scenes in a FAT file system driver the code should be pretty readable however.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 9/22/2009 1:12:15 AM GMT
Going to try showing a 6-bit photo directly from the SD card...
Is doing seek(0) the best way to restart reading the file from the beginning?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
you pread(); the bigger buffer the better.
If you're talking at screen rates, though, no, I don't think it's going to be *that* fast,
primarily due to Spin overhead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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's not perfect yet, and there is a somewhat noticeable flicker, and the screen position isn't entirely stable, but this is pretty amazing, I think...
Here's a photo of the screen cyclically reading from SD.· The vertical position is off, but you get the idea...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
Glad it works!
The main limiter on the speed is probably the memory copy (but that's done a long at a time so should be pretty fast).
FYI: Posted are the 2 mods that I do (disable readahead and enable the tri-stating). Also the mods for Femto call compatibility (although I will be able to remove this, it may be useful to post it here)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 11/24/2009 6:23:52 AM GMT
SD card works fine with a FSWR 1.7, but when I switch to 24 it does not pass the boot-block-test. And in fact it reads $d0 $02 instead of the right values. But the boot sector is fine on the card. I had very long wires, so I shortened them. I replaced the 20kOhm resistors proposed in the old FSWR with 10kOhm - but it did not help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
or capacitance or something. If it fails at 10MHz, then it's something else.
Please report back.
-tom
Guess now time has come where I need some kind of board with SD card ;o)
"slower" ones may be just the ticket.
Would it be asking too much to see a picture of your setup? I am using a breadboard for my tests and it
works fine there, but the wires are short.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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