Yes Kye, I think if anything was going to break I would have found it, having spent several whole days testing this code. I think it is ready for the Obex. Fantastic work. Complicated coding behind the scenes but so easy to use.
On the TriBlade board (blade 2) and RamBlade the SD card pins are shared with the external RAM "bus".
In order to use SD card and external RAM in an application it is necessary to tristate the RAM bus and the SD pins alternately, say when loading data from SD to RAM.
Is there a way to do that in FATE? On a quick scan through your code I did not see it. Is it possible to add such a feature?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now that xmodem is working in KyeDOS, I'm wondering about taking networking on the propeller a little further. I'm thinking of a very simplified bittorrent protocol, where boards might exchange pieces of files in a peer to peer network. This could be a very efficient way to broadcast a new file to a network, as a broadcast of 1 packet might go to n boards all at the same time.
I've been working on some packet descriptors - take a xmodem 132 byte packet, put in a 8.3 filename, source, destination, packet number, total packets and it still comes in well under 256 bytes.
I'm thinking of ways to integrate a random packet into a partially completed file using the FAT drivers.
Two ways seem possible:
1) store each packet as a seperate file, then build them all into a big file at the end.
2) Splice each packet as it arrives.
Option 1 is possibly the simplest to code as the buffer only needs to be 128 bytes so that can be an array in spin. Big files might end up with lots of pieces so lots of temporary files on the sd card. Is there a max number of files on the sd card? (a typical number might be 256 files of 128 bytes = a 32k binary file)
Option 2 I think needs the ability to have two files open at once. That is not possible, right? Unless you use an external ram chip as the temporary store for the big file.
I just noticed there is an "append" mode.
PUB openFile(fileName, mode) '' 33 Stack Longs
'' │ Mode - A character specifing the mode to use. R-Read, W-Write, A-Append. By default the file is opended for reading. │
This could be a very neat answer for boards without external memory. Save all the 128 byte packets as individual files. Then read them in one at a time to a spin array, then open the big file for append and add the array data at the end.
You can have up to 65536 files in one directory.... well, more like ~60000 files but you can have alot. So if you keep track of names you could save each packet as a seperate file.
...
Okay, I'll add tristating features... but how do you want that to work? My driver polls the SD card regularly to make sure it it still there... and this is a nice safety feature that can prevent some nasty problems that can come from user error. So, I would like to leave it in place. However, when the card is unmounted my driver does nothing. So, I can make it tristate the pins when the card is unmounted. Or would that not be acceptable?
As I can see it - That polls feature needs only before READ/WRITE to be sure card is still mounted.
Rest of time it is unnecessary.
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.
Kye: Here is an example of how tristating is done on the TriBladeProp using the slightly modified
fsrwfemto and sdspifemto that Cluso created for the TriBlade. All error checking removed.
err := sd.startSD(@ioControl) 'Start the SD routines
.
.
err := \sd.mount_explicit(spiDO,spiClk,spiDI,spiCS) 'Mount the SD
.
.
err := \sd.popen(string("fibo.bin"), "r")
'Read image file into external RAM
bytes := 1
repeat while bytes > 0
bytes := sd.pread(@diskbuff, 512)
err := sd.stopSDCard 'stop SD card, but do not stop SD cog (tristate)
repeat i from 0 to bytes - 1
vm.wrvbyte(ramaddr ^ %11, diskbuff[noparse][[/noparse] i ]) 'To virtual memory. XOR here is an endianess fix.
ramaddr++
err := \sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'Init the SD (un-tristate)
err := sd.stopSDCard 'stop SD card, but do not stop cog
Note that the vm.wrvbyte also leaves the bus tristated when done.
Also sd.initSDCard method is just passed through to the SD driver by fsrwfemto.
Cluso's has a block read/write driver for ext RAM that include "idle" and "active" methods to do tristating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Okay, so there should be pull ups on the I/O lines in general in you want to go in and out of tristating mode because the lines will float otherwise and their default state needs to be high.
My driver works without pull ups so I will not make the default behaviour tristating when not in use. To make things simple I will add the ability for my driver to tristate its lines in the ASM code.
To expose the tristating feature you will have to make the "readWriteBlock" a public function and then pass it some letter to activate tristating and another letter to deactivate tristating. Also by exposing that function you will be able to have RAW read/write mounting and booting functionality.
Is that okay?
I'll post more information about what I have done when I finish.
It is NOT at this lines need be HIGH -- Them need floating on SD as in other way this pin can't be used to other things that need change state.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Kye: The problem is that the SD card does not release driving the DO pin when -CS=1 (disabled). If this pin is used for other purposes as well, such as sharing with the SRAM which I do on the TriBlade and RamBlade boards, then the SD card must be forced to release the DO pin when -CS returns high. What needs to be done is to supply a number of clocks after -SD returns high. While my pcbs have pullups on all 4 SD pins, it certainly seems that only the -CS pullup is required. The spec calls for pullups to minimise current when the pin floats but it seems now a weak pullup may in fact be on newer SD cards nowadays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You would need pullups because all the pins would be left floating otherwise... which is bad.
Anyway, here is the newest version with tristating added.
To acess the tristating you will need to make the readWriteBlock function public. Then just pass "T" (capital) as the command,
the rest of the fields are ignored.
Also note that if no other commands may be issued or the block driver will return an error until the card is untristated.
To untristate the card call the command again.
-- Okay that was 12 longs of code space to add that feature. So... please let that be the end of your requests. ·
Also, I do not know if the SD card will release the DO pin. I send it 8 clocks after setting the CS pin to high. I did not test any of the tristating stuff but it should work.
That was GOOD news.
I don't think that Low level driver needs more REQUEST's.
And HI level before MS give permission to use long Names - I see no needs for more
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
I was wondering what you would think about adding another tiny function to the FATengine to see if a file exists?
Maybe this is already there, but if not, the general concept is to pass a filename and it returns true or false if the file exists.
Currently I'm trying to open the file, seeing what the error is, closing the file then passing back the error. You might be able to tweak that using 'result' and save creating a variable?
And just double check the true/false variable that comes back - I always get confused as to whether true is 0 or 1!
Hopefully this is only a few lines.
i:=\fat.openfile(Filename,"R") ' does this file already exist? The \ says to keep going even if there is an error
i:=fat.checkerrornumber ' 0 if it does exist
fat.closefile ' close this file
Cluso99 said...
Kye: The problem is that the SD card does not release driving the DO pin when -CS=1 (disabled). If this pin is used for other purposes as well, such as sharing with the SRAM which I do on the TriBlade and RamBlade boards, then the SD card must be forced to release the DO pin when -CS returns high. What needs to be done is to supply a number of clocks after -SD returns high. While my pcbs have pullups on all 4 SD pins, it certainly seems that only the -CS pullup is required. The spec calls for pullups to minimise current when the pin floats but it seems now a weak pullup may in fact be on newer SD cards nowadays.
Even the CS pin should not have a pullup for the reason that card detect can be implemented in software by detecting whether the CS pin is pulled up by the SD card or not. The SD spec says that the CS pin on the card has a weak pullup and that this can be used for card detect. In my drivers I pulse this line low, change to input mode, wait a couple of microseconds and read the state of the CS pin. This proves very reliable and I make a point of detecting this in the low-level command loop and also during initialization. In the real world you need to react to and recover from card removals and insertions.
SD Card Spec V2.2
1.12.3 Card Acquisition and Identification
<snip>
An internal pull-up resistor on the DAT3 line may be used for card detection
(insertion/removal). The resistor can be disconnected during data transfer (using
ACMD42). Additional practical card detection methods can be found in SD Physical
Specification’s application notes given by the SDA.
heater said...
Peter Jakacki - "In the real world...."
I thought there was something odd about Propeller land[noparse]:)[/noparse]
aw mate, there is something absolutely odd about Prop land, it attracts all kinds of odd sorts
My comment about the "real world" though is probably more to do with the state of some objects that I find are lacking certain necessary features vs some other objects that are excessively didactic but still lack certain necessary features. When I am doing a commercial product I find that there is a big gulf between demos and what it takes to get them to be reliable and usable.
But that's not to say that I don't appreciate them, I certainly do, very much. I just don't have enough arms and hours in a day to do a fraction of the things I need to do, let alone what I want to do
Peter Jakacki said...
In the real world you need to react to and recover from card removals and insertions.
I would go even further and suggest that one should monitor the write-protect status of the SD card in "real world"...
I usually add 4 resistors to the SD card circuit in order to monitor the card-detect and write-protect switches
on the SD card jack.· Here's the circuit:
I'm debugging a rather strange fault where my LCD display is corrupted if running a program from the KyeDOS operating system, but reloading the eeprom with the program and directly booting it has no problems.
I was wondering if the reboot code explicitly stops all (or most) of the cogs before rebooting?
PUB bootPartition(fileName) | bootSectors[noparse][[/noparse]64] '' 101 Stack Longs
'' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
'' │ Reboots the propeller chip to run the selected valid spin BIN or EEPROM file. │
'' │ │
'' │ If an error occurs this function will abort and return a pointer to a string describing that error. │
'' │ │
'' │ FileName - The name of the file to reboot from in the current directory. │
'' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
longfill(@bootSectors, 0, 64)
openFile(fileName~, "R")
repeat (listSize <# 32768)
result += readByte
ifnot($1FF & fileName++)
bootSectors[noparse][[/noparse]fileName >> 9] := (partitionStart + FATFirstSectorInCluster(currentCluster) + FATWorkingSectorInCluster)
result &= $FF
changeFilePosition(6)
fileName := readShort
closeFile
' if((result and (result <> $14)) or (fileName <> $10))
' errorNumberFlag := Checksum_Error
' abort string("Checksum Error")
unmountPartition
readWriteBlock(@bootSectors, "B")
partitionMountedFlag := false
errorNumberFlag := Reboot_Error
abort string("Reboot Error")
@Dr_Aculam, Yes, in the ASM driver it stops all other processors before rebooting. This is has to be done however as I zero all memory.
Also, I'm thinking about making a if file exist function that also valids the listing information. I've also found several uses for somthing like that. Additionally I plan to make a function that just returns all the names in a file sequentially even through file open and close calls. This will be useful for examining all files in a directory.
However, I want to free up some space before making those.
Peter Jakacki said...
In the real world you need to react to and recover from card removals and insertions.
I think you'll really like my code then. It is ALOT more robust against card removals or insertions vs FSRW. Since I have all the mounting rountines in ASM, my driver can recover from card removals easily.
@Everyone
Using the Write Protect and Card Detect switches is pointless. You get the same functionality by just asking the card are you write protected or just by trying to communicate to it to see if its there.
I'll admit however, my block driver tries very hard to mount every SD card it uses... So, if the card does not mount then you may wait a while for it to give up. Can be in the seconds range or WAYYY... more sometimes. I like Peter's idea. But it will just take more code space. Ahhh! I'm already at 1920 Longs.
>I've heard the the write protect switch on SD cards is purely mechanical and not connected to internal electronics.
both systems are in in use I believe. There are SPI commands to lock/unlock a range.
Yes, the write protect switch is purely mechanical. However, you can also use software to lock portitions of an SD card. So why bother with the write protect switch since it really does nothin more than say please don't write to me.
SD cards have ALOTTTTTTTTTTTTT o security features at are not documented publicly.
Kye said...
Yes, the write protect switch is purely mechanical. However, you can also use software to lock portitions of an SD card. So why bother with the write protect switch since it really does nothin more than say please don't write to me.
Umm.. maybe because its the only way to tell if I've flipped the write protect on before I stick the card in the slot. Look at it another way, if I flip that switch and stick the card in your product, and your product writes to the card because it's too lazy to check the switch I'm going to be extremely irritated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Kye: I use the open/find file in the fsrw driver to find the first sector address used. This is what ZiCog does. Wouldn't this do for what Drac is asking?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
i:=\fat.openfile(Filename,"R") ' does this file already exist? The \ says to keep going even if there is an error
i:=fat.checkerrornumber ' 0 if it does exist
fat.closefile ' close this file
If you open a file, presumably you have to close it too.
I was thinking more about asking Kye to include this as a new function - it would only take a tiny amout of space. And also whether it can be shrunk even further, eg by not having a variable 'i'
BTW Kye, if you are running out of space, compiling with BST and checking the box that excludes unused functions - this saved quite a bit of space for me.
Also - with KyeDOS - you can recompile code with lots of variations, eg compile a version with no audio, and it saves space and you can use that space for other things. It is easy to organise all these .bin files as different variants.
@BradC - Yeah, you're right. Sorry I was being cheeky there . I'll have to use more I/O pins however to support WP features.
Mmm, I have an idea. I can easily support the CardDetect feature and incorporate that into mounting. However, it really is not needed.
As for supporting the WriteProtect feature that would be a bit more complicated as my upper level code writes out last acess information on every file close. I could just make the lower level driver ignore writes when the write protect switch is low and then return to the upper level code as if it did the write to make everything seamless... but this could confuse a user of my code very easily.
Both these features could be optional... Maybe I'll add this feature in another release.
@Cluso99 - Oh... it won't end.... if you look how the bootParition function works you can see how to do this easily.
Kye: Most SD card designs on the prop that I have seen do not support card select and write protect pins. They only use a 4 pin interface. Note also that the microSD socket that I use, and now some others also use, only supports the Card Select switch. I am fairly sure the Write Protect switch is not fitted in the socket, so it would be pointless trying to use it. The Card Detect switch is fitted, but I do not even wire it anywhere on either the TriBlade or RamBlade and do not intend to do so on the new RamBladeII or IOBlade. I fit pullups on all 4 pins (-CS, CLK, DI, DO) on TriBlade & RamBlade and intend to do likewise on the new pcbs too. The hardware method I use requires a pullup to be always present on the -CS pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
>_ Running command: test
Creating test file "testfile" ... Success
Wrote 131,072 bytes at 0000046501 bytes per second
Running byte stride write test...
Wrote 32,768 bytes at 0000004297 bytes per second
Running byte stride read test...
Read 32,768 bytes at 0000004297 bytes per second
Running word stride write test...
Wrote 65,5536 bytes at 0000008315 bytes per second
Running word stride read test...
Read 65,5536 bytes at 0000008454 bytes per second
Running long stride write test...
Wrote 131,072 bytes at 0000015547 bytes per second
Running long stride read test...
Read 131,072 bytes at 0000016804 bytes per second
Running speed writing test (512 bytes at a time)...
Wrote 131,072 bytes at 0000107328 bytes per second
Running speed reading test (512 bytes at a time)...
Read 131,072 bytes at 0000250432 bytes per second
Running append test... Success
Running seek test... Success
Deleting test file "testfile" ... Success
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
On the TriBlade board (blade 2) and RamBlade the SD card pins are shared with the external RAM "bus".
In order to use SD card and external RAM in an application it is necessary to tristate the RAM bus and the SD pins alternately, say when loading data from SD to RAM.
Is there a way to do that in FATE? On a quick scan through your code I did not see it. Is it possible to add such a feature?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now that xmodem is working in KyeDOS, I'm wondering about taking networking on the propeller a little further. I'm thinking of a very simplified bittorrent protocol, where boards might exchange pieces of files in a peer to peer network. This could be a very efficient way to broadcast a new file to a network, as a broadcast of 1 packet might go to n boards all at the same time.
I've been working on some packet descriptors - take a xmodem 132 byte packet, put in a 8.3 filename, source, destination, packet number, total packets and it still comes in well under 256 bytes.
I'm thinking of ways to integrate a random packet into a partially completed file using the FAT drivers.
Two ways seem possible:
1) store each packet as a seperate file, then build them all into a big file at the end.
2) Splice each packet as it arrives.
Option 1 is possibly the simplest to code as the buffer only needs to be 128 bytes so that can be an array in spin. Big files might end up with lots of pieces so lots of temporary files on the sd card. Is there a max number of files on the sd card? (a typical number might be 256 files of 128 bytes = a 32k binary file)
Option 2 I think needs the ability to have two files open at once. That is not possible, right? Unless you use an external ram chip as the temporary store for the big file.
I just noticed there is an "append" mode.
This could be a very neat answer for boards without external memory. Save all the 128 byte packets as individual files. Then read them in one at a time to a spin array, then open the big file for append and add the array data at the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
...
Okay, I'll add tristating features... but how do you want that to work? My driver polls the SD card regularly to make sure it it still there... and this is a nice safety feature that can prevent some nasty problems that can come from user error. So, I would like to leave it in place. However, when the card is unmounted my driver does nothing. So, I can make it tristate the pins when the card is unmounted. Or would that not be acceptable?
Please tell me how the tristating will be used.
Thanks,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
As I can see it - That polls feature needs only before READ/WRITE to be sure card is still mounted.
Rest of time it is unnecessary.
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
fsrwfemto and sdspifemto that Cluso created for the TriBlade. All error checking removed.
err := sd.startSD(@ioControl) 'Start the SD routines . . err := \sd.mount_explicit(spiDO,spiClk,spiDI,spiCS) 'Mount the SD . . err := \sd.popen(string("fibo.bin"), "r") 'Read image file into external RAM bytes := 1 repeat while bytes > 0 bytes := sd.pread(@diskbuff, 512) err := sd.stopSDCard 'stop SD card, but do not stop SD cog (tristate) repeat i from 0 to bytes - 1 vm.wrvbyte(ramaddr ^ %11, diskbuff[noparse][[/noparse] i ]) 'To virtual memory. XOR here is an endianess fix. ramaddr++ err := \sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'Init the SD (un-tristate) err := sd.stopSDCard 'stop SD card, but do not stop cogNote that the vm.wrvbyte also leaves the bus tristated when done.
Also sd.initSDCard method is just passed through to the SD driver by fsrwfemto.
Cluso's has a block read/write driver for ext RAM that include "idle" and "active" methods to do tristating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/17/2010 12:26:08 PM GMT
My driver works without pull ups so I will not make the default behaviour tristating when not in use. To make things simple I will add the ability for my driver to tristate its lines in the ASM code.
To expose the tristating feature you will have to make the "readWriteBlock" a public function and then pass it some letter to activate tristating and another letter to deactivate tristating. Also by exposing that function you will be able to have RAW read/write mounting and booting functionality.
Is that okay?
I'll post more information about what I have done when I finish.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
RAW sector/block access might keep some emulator guys happy. Is there a way to get the first sector of a a file to make that useful?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
It is NOT at this lines need be HIGH -- Them need floating on SD as in other way this pin can't be used to other things that need change state.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway, here is the newest version with tristating added.
To acess the tristating you will need to make the readWriteBlock function public. Then just pass "T" (capital) as the command,
the rest of the fields are ignored.
Also note that if no other commands may be issued or the block driver will return an error until the card is untristated.
To untristate the card call the command again.
-- Okay that was 12 longs of code space to add that feature. So... please let that be the end of your requests.
·
Also, I do not know if the SD card will release the DO pin. I send it 8 clocks after setting the CS pin to high. I did not test any of the tristating stuff but it should work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 6/17/2010 5:06:38 PM GMT
That was GOOD news.
I don't think that Low level driver needs more REQUEST's.
And HI level before MS give permission to use long Names - I see no needs for more
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I was wondering what you would think about adding another tiny function to the FATengine to see if a file exists?
Maybe this is already there, but if not, the general concept is to pass a filename and it returns true or false if the file exists.
Currently I'm trying to open the file, seeing what the error is, closing the file then passing back the error. You might be able to tweak that using 'result' and save creating a variable?
And just double check the true/false variable that comes back - I always get confused as to whether true is 0 or 1!
Hopefully this is only a few lines.
i:=\fat.openfile(Filename,"R") ' does this file already exist? The \ says to keep going even if there is an error i:=fat.checkerrornumber ' 0 if it does exist fat.closefile ' close this file▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Even the CS pin should not have a pullup for the reason that card detect can be implemented in software by detecting whether the CS pin is pulled up by the SD card or not. The SD spec says that the CS pin on the card has a weak pullup and that this can be used for card detect. In my drivers I pulse this line low, change to input mode, wait a couple of microseconds and read the state of the CS pin. This proves very reliable and I make a point of detecting this in the low-level command loop and also during initialization. In the real world you need to react to and recover from card removals and insertions.
SD Card Spec V2.2 1.12.3 Card Acquisition and Identification <snip> An internal pull-up resistor on the DAT3 line may be used for card detection (insertion/removal). The resistor can be disconnected during data transfer (using ACMD42). Additional practical card detection methods can be found in SD Physical Specification’s application notes given by the SDA.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I thought there was something odd about Propeller land[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
aw mate, there is something absolutely odd about Prop land, it attracts all kinds of odd sorts
My comment about the "real world" though is probably more to do with the state of some objects that I find are lacking certain necessary features vs some other objects that are excessively didactic but still lack certain necessary features. When I am doing a commercial product I find that there is a big gulf between demos and what it takes to get them to be reliable and usable.
But that's not to say that I don't appreciate them, I certainly do, very much. I just don't have enough arms and hours in a day to do a fraction of the things I need to do, let alone what I want to do
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I usually add 4 resistors to the SD card circuit in order to monitor the card-detect and write-protect switches
on the SD card jack.· Here's the circuit:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm
My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
I'm debugging a rather strange fault where my LCD display is corrupted if running a program from the KyeDOS operating system, but reloading the eeprom with the program and directly booting it has no problems.
I was wondering if the reboot code explicitly stops all (or most) of the cogs before rebooting?
PUB bootPartition(fileName) | bootSectors[noparse][[/noparse]64] '' 101 Stack Longs '' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ '' │ Reboots the propeller chip to run the selected valid spin BIN or EEPROM file. │ '' │ │ '' │ If an error occurs this function will abort and return a pointer to a string describing that error. │ '' │ │ '' │ FileName - The name of the file to reboot from in the current directory. │ '' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ longfill(@bootSectors, 0, 64) openFile(fileName~, "R") repeat (listSize <# 32768) result += readByte ifnot($1FF & fileName++) bootSectors[noparse][[/noparse]fileName >> 9] := (partitionStart + FATFirstSectorInCluster(currentCluster) + FATWorkingSectorInCluster) result &= $FF changeFilePosition(6) fileName := readShort closeFile ' if((result and (result <> $14)) or (fileName <> $10)) ' errorNumberFlag := Checksum_Error ' abort string("Checksum Error") unmountPartition readWriteBlock(@bootSectors, "B") partitionMountedFlag := false errorNumberFlag := Reboot_Error abort string("Reboot Error")▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Also, I'm thinking about making a if file exist function that also valids the listing information. I've also found several uses for somthing like that. Additionally I plan to make a function that just returns all the names in a file sequentially even through file open and close calls. This will be useful for examining all files in a directory.
However, I want to free up some space before making those.
I think you'll really like my code then. It is ALOT more robust against card removals or insertions vs FSRW. Since I have all the mounting rountines in ASM, my driver can recover from card removals easily.
@Everyone
Using the Write Protect and Card Detect switches is pointless. You get the same functionality by just asking the card are you write protected or just by trying to communicate to it to see if its there.
I'll admit however, my block driver tries very hard to mount every SD card it uses... So, if the card does not mount then you may wait a while for it to give up. Can be in the seconds range or WAYYY... more sometimes. I like Peter's idea. But it will just take more code space. Ahhh! I'm already at 1920 Longs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I've heard the the write protect switch on SD cards is purely mechanical and not connected to internal electronics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm
My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
both systems are in in use I believe. There are SPI commands to lock/unlock a range.
James
SD cards have ALOTTTTTTTTTTTTT o security features at are not documented publicly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Umm.. maybe because its the only way to tell if I've flipped the write protect on before I stick the card in the slot. Look at it another way, if I flip that switch and stick the card in your product, and your product writes to the card because it's too lazy to check the switch I'm going to be extremely irritated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
i:=\fat.openfile(Filename,"R") ' does this file already exist? The \ says to keep going even if there is an error i:=fat.checkerrornumber ' 0 if it does exist fat.closefile ' close this fileIf you open a file, presumably you have to close it too.
I was thinking more about asking Kye to include this as a new function - it would only take a tiny amout of space. And also whether it can be shrunk even further, eg by not having a variable 'i'
BTW Kye, if you are running out of space, compiling with BST and checking the box that excludes unused functions - this saved quite a bit of space for me.
Also - with KyeDOS - you can recompile code with lots of variations, eg compile a version with no audio, and it saves space and you can use that space for other things. It is easy to organise all these .bin files as different variants.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Mmm, I have an idea. I can easily support the CardDetect feature and incorporate that into mounting. However, it really is not needed.
As for supporting the WriteProtect feature that would be a bit more complicated as my upper level code writes out last acess information on every file close. I could just make the lower level driver ignore writes when the write protect switch is low and then return to the upper level code as if it did the write to make everything seamless... but this could confuse a user of my code very easily.
Both these features could be optional... Maybe I'll add this feature in another release.
@Cluso99 - Oh... it won't end.... if you look how the bootParition function works you can see how to do this easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Corwine