Yes Duane. This has been a great!!!! experience for me. As for your Demo I have a question. Have you tried running it multiple times without clearing the card? I found that to be very interesting. I even took the card out and looked at the data on my computer. Every time it created a file it gave the next file created the next number in the logical order. I only ran it to four but I found it to be really interesting. And thank you for providing it.
I even took the card out and looked at the data on my computer. Every time it created a file it gave the next file created the next number in the logical order. I only ran it to four but I found it to be really interesting.
Dave,
Yes, the program creates consecutively numbered files. I've seen several questions on the forum about how to create consecutive file names, so I thought I'd add it to the demo. I think it's limited to files named "LOG_0000.TXT" to "LOG_9999.TXT". I don't know if the SD card would really let you have 10,000 files in the root directory though.
Use one file with fixed width records and add an index column. Do not put the index in the file name.
Agreed, this is a better way. But if you don't have many files, just using a number in the name adds a few seconds as the Prop finds the correct file and I think it's probably an easier method to use for those new to the Prop and SD cards (though I'm not sure about this).
I personally like it (numbered file names) because it makes finding the data to load into a spreadsheet program (on a PC) easier than having to first open an index file to see where the data you're after is stored (not a very good excuse, but I'll go with it).
It does seem like a good idea to use an index file. Truthfully, I haven't yet.
I actually enjoy watching the various log files pass by on a display while the Propeller is looking for the next available file name to use. With some of my projects, I keep the last fine name used in EEPROM, but even then I still list the files on the card because I like to see them. (I also like to hear relays click.)
I'm generally only interested in the last data collected on the card. With my day job, this data is weights, barcode label readings and spectrometer readings. When I'm ready to analyze the data, I put the SD card in the PC, open the file with OpenOffice Calc and manipulate the data.
I'd rather not have all the data in one file for three reasons (that I can think of right now).
1. If a file isn't closed properly while it's being written to, only the active file's data is compromised. This is probably the main reason I don't want one large file. If the Propeller board is bumped, I accidentally press reset while the file is open, there's a power failure or some other problem while the file is open, the file becomes corrupted and the file can't be read by a PC (at least not without special software).
If I used one large file for all the data, any time the file became corrupted, I wouldn't be able to access the previous data.
I use two Propeller boards when collecting data. One board records the data to a USB thumb drive and also sends the data wirelessly across the room to a second Propeller that records the data to a SD card. This way, if there's a problem with one of the Propeller boards that causes a corrupt file, I'll have a backup copy of the data. I've had to use the back up data many times.
One of the first things I do when I realize there's been a problem with one of the Propeller boards, is to close the active file on the other board to protect its data. Once the problem board is fixed and restarted the other board is also restarted creating a new file. The data, to which there is only one copy, is safe in a closed file. The new data being collected and vulnerable to corruption, is being recorded once again in two places.
2. Another reason I like separate files for data is the time stamp on the file. While I timestamp all the data within a file, the timestamp on the file gives me another way to find the data I'm after once I've transferred the files to a PC.
3. Related to reason #2, having the data on smaller files makes it easier for me to find the data I'm after when I'm ready to manipulate the data.
There's also probably a #4 which is, this was the easiest way for me to do it when I was learning to use the Propeller. I think I've now learned enough to program the Prop to create an index file to keep track of all the data, but I have a bunch of other projects I want to work on and my current system works well enough for now.
CON _AUTONAME_SIZE = 5 ' Five digits.
DAT AUTONAMEArray byte "00000BM.BMP", _NULL
PRI mainAutoName | nameBuffer, nameCounter ' Auto names a file in the current directory.
fat.listEntries("W") ' Goto the top of the directory.
repeat while(nameBuffer := fat.listEntries("N"))
result #>= DECIn(nameBuffer) ' Find the largest file name that starts with a number.
nameBuffer := DECOut((1 + (result~)) // 65_536)
nameCounter := strsize(nameBuffer)
bytemove(@AUTONAMEArray, string("00000"), _AUTONAME_SIZE)
bytemove((@AUTONAMEArray + (_AUTONAME_SIZE - nameCounter)), nameBuffer, nameCounter)
fat.openFile(fat.newFile(@AUTONAMEArray), "W")
Note that the above code can abort on you... So you need to abort trap it somewhere.
Assume the DEIn and DECOut functions are just your general purpose string manipulation functions.
Okay so I have an SD that I can read and write to. Now I need some education on terminology. In this code they are asking for me to exchange the pin numbers they used with the pin numbers that I have actually set up on my board. Here is part of the code:
pub main | sdBasePin, HeadphoneRightPin, HeadphoneLeftPin
ser.start(31,30,0,19200)
'wait for any input from terminal
'ser.rx
'change values to match your setup
sdBasePin := 12
HeadphoneRightPin := 26
HeadphoneLeftPin := 27
wpl.start(sdBasePin, HeadphoneRightPin, HeadphoneLeftPin, @buff, bufferLen)
I changed the headphone pins but I am unsure of what they are asking for on the sdBasePin (sdBasePin=12). Is this the DI pin (my pin 24) or are they only interested in receiving output from DO (my pin 22).
Some SD drivers assume you have your SD card pins consecutively numbered Propeller pins. I'm not positive the PropBOE has the pins in the same order assumed by the other object but it probably does.
I would be helpful if you provided a link to the object in question.
I changed the headphone pins but I am unsure of what they are asking for on the sdBasePin (sdBasePin=12). Is this the DI pin (my pin 24) or are they only interested in receiving output from DO (my pin 22).
SD base pin on the PropBOE is 22. The pins and their functions are labeled right on the board, and you can trust them. The order (DO, CLK, DI, CS) follows the standard used in all the SD objects that ask for a base pin. The pins you have for right and left headphone connections are also correct.
So Pin 22 (DO) is always the base pin. So the base pin islow on boot and then the program sets it high until it reads data and then goes low to receive the data? Or do I have it backwards?
The Prop still uses four pins of the SD card. The program assumes the other pins are connected in order after the base pin.
So if the base pin was set as zero the program would use pins 0, 1, 2 and 3 to read and write to the SD card.
With the PropBOE if you state pin 22 is the base pin, then the program will assume pins 23, 24 and 25 are connected to the SD card also.
I believe the order stays the same (DO, CLK, DI and CS) because that's the way they are arranged on the SD card so it makes since to use the same order when connecting a SD card to a Prop.
Okay.......now I understand. It is looking for the start of a logical progression. If I gave it Pin 32 then the progression would be 33, 34, 35. Is there a coralation with LSB to MSB in the progression or is it just data labeling and nothing more? By the way Duane. I have gotten a little side ways here with other uses for my Bs2 when I retire it. I will be posting about Gyros so please look for it. I think you told me that you are a R/C Helio buff like me so it should be right up your ally.
Comments
Dave,
Yes, the program creates consecutively numbered files. I've seen several questions on the forum about how to create consecutive file names, so I thought I'd add it to the demo. I think it's limited to files named "LOG_0000.TXT" to "LOG_9999.TXT". I don't know if the SD card would really let you have 10,000 files in the root directory though.
Don't actually ever do that though. File system operations will get really slow.
I wasn't planning on it. I rarely have more than a couple of dozen log files on a card myself.
Agreed, this is a better way. But if you don't have many files, just using a number in the name adds a few seconds as the Prop finds the correct file and I think it's probably an easier method to use for those new to the Prop and SD cards (though I'm not sure about this).
I personally like it (numbered file names) because it makes finding the data to load into a spreadsheet program (on a PC) easier than having to first open an index file to see where the data you're after is stored (not a very good excuse, but I'll go with it).
It does seem like a good idea to use an index file. Truthfully, I haven't yet.
I actually enjoy watching the various log files pass by on a display while the Propeller is looking for the next available file name to use. With some of my projects, I keep the last fine name used in EEPROM, but even then I still list the files on the card because I like to see them. (I also like to hear relays click.)
I'm generally only interested in the last data collected on the card. With my day job, this data is weights, barcode label readings and spectrometer readings. When I'm ready to analyze the data, I put the SD card in the PC, open the file with OpenOffice Calc and manipulate the data.
I'd rather not have all the data in one file for three reasons (that I can think of right now).
1. If a file isn't closed properly while it's being written to, only the active file's data is compromised. This is probably the main reason I don't want one large file. If the Propeller board is bumped, I accidentally press reset while the file is open, there's a power failure or some other problem while the file is open, the file becomes corrupted and the file can't be read by a PC (at least not without special software).
If I used one large file for all the data, any time the file became corrupted, I wouldn't be able to access the previous data.
I use two Propeller boards when collecting data. One board records the data to a USB thumb drive and also sends the data wirelessly across the room to a second Propeller that records the data to a SD card. This way, if there's a problem with one of the Propeller boards that causes a corrupt file, I'll have a backup copy of the data. I've had to use the back up data many times.
One of the first things I do when I realize there's been a problem with one of the Propeller boards, is to close the active file on the other board to protect its data. Once the problem board is fixed and restarted the other board is also restarted creating a new file. The data, to which there is only one copy, is safe in a closed file. The new data being collected and vulnerable to corruption, is being recorded once again in two places.
2. Another reason I like separate files for data is the time stamp on the file. While I timestamp all the data within a file, the timestamp on the file gives me another way to find the data I'm after once I've transferred the files to a PC.
3. Related to reason #2, having the data on smaller files makes it easier for me to find the data I'm after when I'm ready to manipulate the data.
There's also probably a #4 which is, this was the easiest way for me to do it when I was learning to use the Propeller. I think I've now learned enough to program the Prop to create an index file to keep track of all the data, but I have a bunch of other projects I want to work on and my current system works well enough for now.
CON _AUTONAME_SIZE = 5 ' Five digits. DAT AUTONAMEArray byte "00000BM.BMP", _NULL PRI mainAutoName | nameBuffer, nameCounter ' Auto names a file in the current directory. fat.listEntries("W") ' Goto the top of the directory. repeat while(nameBuffer := fat.listEntries("N")) result #>= DECIn(nameBuffer) ' Find the largest file name that starts with a number. nameBuffer := DECOut((1 + (result~)) // 65_536) nameCounter := strsize(nameBuffer) bytemove(@AUTONAMEArray, string("00000"), _AUTONAME_SIZE) bytemove((@AUTONAMEArray + (_AUTONAME_SIZE - nameCounter)), nameBuffer, nameCounter) fat.openFile(fat.newFile(@AUTONAMEArray), "W")Note that the above code can abort on you... So you need to abort trap it somewhere.
Assume the DEIn and DECOut functions are just your general purpose string manipulation functions.
pub main | sdBasePin, HeadphoneRightPin, HeadphoneLeftPin
ser.start(31,30,0,19200)
'wait for any input from terminal
'ser.rx
'change values to match your setup
sdBasePin := 12
HeadphoneRightPin := 26
HeadphoneLeftPin := 27
wpl.start(sdBasePin, HeadphoneRightPin, HeadphoneLeftPin, @buff, bufferLen)
I changed the headphone pins but I am unsure of what they are asking for on the sdBasePin (sdBasePin=12). Is this the DI pin (my pin 24) or are they only interested in receiving output from DO (my pin 22).
I would be helpful if you provided a link to the object in question.
SD base pin on the PropBOE is 22. The pins and their functions are labeled right on the board, and you can trust them. The order (DO, CLK, DI, CS) follows the standard used in all the SD objects that ask for a base pin. The pins you have for right and left headphone connections are also correct.
-- Gordon
So if the base pin was set as zero the program would use pins 0, 1, 2 and 3 to read and write to the SD card.
With the PropBOE if you state pin 22 is the base pin, then the program will assume pins 23, 24 and 25 are connected to the SD card also.
I believe the order stays the same (DO, CLK, DI and CS) because that's the way they are arranged on the SD card so it makes since to use the same order when connecting a SD card to a Prop.