Prop BOE SD Card not working

smithdavidp · 2012-04-28 09:04

I am having problems with the Prop recognizing the SD card. When I run the test I get this:

Are there some jumpers I need to hook up. I should also add that I have an XBee module installed over the SD socket. The jumpers for the XBee are installed and the XBee does work. (Jumpers from D0 to Pin0 and DI to pin 1) Tried two different cards and both had the same results.
Both cards are formatted FAT 32 and at 32k. Somthing tells me this has to be a simple thing I am missing but as they say "I may be too close to the problem to see the solution".

Mike G · 2012-04-28 09:17

SD Card on the Prop BOE with fsrw is working great. How about posting your source code.

Duane Degn · 2012-04-28 09:19

Dave,

What program are you using?

It looks like one of Kye's.

I'm pretty sure you don't need to hook anything up to use the SD card with the PropBOE. You do need to have the pins set correctly in the program.

I've used a SD with my PropBOE and I'll cut my program done to just a quick demo for you to try. I'll post it later today. (Probably soon.)

Edit: Kye's driver is very picky about errors on a SD card. I've had to reformat more than one SD card before it would work correctly with Kye's driver. "Quick" format doesn't solve the problem. It needs to be the normal format (that take a long time).

smithdavidp · 2012-04-28 09:55

Yeak, I am pretty sure it is Keys. The file is just called test.spin. I did have to modify the file because it said that a file was missing, sysdep.spin. I found sysdep_demo_ser.spin so I substituted that file for the sysdep file. As far as I can tell the parameters look correct. I am only going by
the etching on the bottom of the board which shows the SD card reader pins on the R/H Side of the XBee socket marked DAT1, DAT2, DO8, and PWM1. The sysdep_demo_ser parameters are set up like this:

con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
sd_DO = 0
sd_CLK = 1
sd_DI = 2
sd_CS = 3
obj
term : "FullDuplexSerial"
{{
This should start stdin and out, but *not* anything on the
secure digital card.
}}
pub start
term.start( 31, 30, 0, 115200 )

The term start is just for the serial terminal interface right?

GordonMcComb · 2012-04-28 10:44

Not all uSD cards are going to be compatible. This goes for any SD-based product, even commercial ones Your best bet is to stick with FAT16 non-HC cards. Once you start getting into FAT32 and 4GB and over the likelihood of running into an incompatible card increases greatly.

Stick with brand name cards only. They're not that much more expensive.

I have had good success with SanDisc 2GB cards. They cost about $4 each in bulk packages of 2 or 4.

As the type, make, and model of your card matters, please share that info, and we can build a database of what cards will work, and what won't.

One last thing: You really have to press that card into the uSD slot. Remove it, and plug it back in. Try it several times. Once seated it should be okay, but several times my card just wasn't making good connection. (I am also using a pre-release board, so this could be something not present in the production models.)

-- Gordon

smithdavidp · 2012-04-28 11:06

I am using 1 SanDisc and 1 Micro SD HC. I will try formating at 16 and see if that helps. But now that I look at it the card parameters may be incorrect. DO does go to P0 But DI goes to pin 1 as far as the XBee is concerned. It shows the SD clock going to pin 1 and CS to pin 3. I have nothing on pin 2 or 3. Aren't the SD I/O on the same data lines as the XBee? If this is the case then the only connection that would be correct would be sd_DO = 0. Think I better remove the XBee module and chase down the lines on the Micro SD socket.

Duane Degn · 2012-04-28 11:18

Dave,

I'm minutes away from posting some demo code.

I don't think you have your pins set correctly.

Here's my pin settings.

  _DoSdPin = 22                 ' SD card pin assignments.
  _ClkSdPin = 23
  _DiSdPin = 24
  _CsSdPin = 25
  _WpSdPin = -1                 ' Write Protect, not used (Micro SD cards don't have a write protect feature).
  _CdSdPin = -1                 ' Card Detect, not used for now.  I think this can be shared with DI pin.
  _RtcPin1 = -1                 ' Pins that would have been used by real time clock.
  _RtcPin2 = -1
  _RtcPin3 = -1

While I agree with Gordon's suggestion to use name brand SD cards. I disagree with his suggestion to avoid the high capacity cards.

I've used several different 4GB and 8GB uSD cards with Kye's driver.

The only SD card (or a dozen or so I've tried) that hasn't worked with his driver is a 256MB card I purchased a long time ago.

I would take Gordon's advice about using the smaller capacity cards if you want to be able to use all the various SD drivers available. Many of them wont work with the HC cards.

I for one, don't see my robots taking over the world using just 1GB and 2GB cards.

Though to tell the truth, I've never needed more than a megabyte of storage so far.

I'll have that demo up shortly.

ratronic · 2012-04-28 11:22

David, Duane is right the pin constants for the sd card connections are wrong for the PropBoe.

smithdavidp · 2012-04-28 12:09

I know that lol. I got the schematic out and traced it down. Then got the manual out and sure enough it gave me the pin outs for the Prop BOE. P22 = DO, P23 = CLK, P24=DI/CD and P25 =CS. I changed them in the program and it worked. Really kewl to see those large numbers jump out. And reading/writting
is comfortable 4096 at 1024 being read/written just a hair over 1050ms. I'm happy........and impressed! Thanks for the help guys!!!!!!!

4x5n · 2012-04-28 12:20

GordonMcComb wrote: »

Not all uSD cards are going to be compatible. This goes for any SD-based product, even commercial ones Your best bet is to stick with FAT16 non-HC cards. Once you start getting into FAT32 and 4GB and over the likelihood of running into an incompatible card increases greatly.

Stick with brand name cards only. They're not that much more expensive.

I have had good success with SanDisc 2GB cards. They cost about $4 each in bulk packages of 2 or 4.

As the type, make, and model of your card matters, please share that info, and we can build a database of what cards will work, and what won't.

One last thing: You really have to press that card into the uSD slot. Remove it, and plug it back in. Try it several times. Once seated it should be okay, but several times my card just wasn't making good connection. (I am also using a pre-release board, so this could be something not present in the production models.)

-- Gordon

I'm not sure how I feel about disagreeing with Gordon about something!

I've been using the "bulk" SD, microSD cards and thumbdrives I get from microcenter for years and have never had a problem with them. This is the lowest priced memory I've found anywhere! I've also dealt with the sub-gig flash memory and found that the smaller cards were much less likely to follow the letter of the standard then the larger ones. It's also getting harder to get small cards. I haven't seen anything smaller then 2gig for years now and even they're getting harder to find.

Currently every propeller board with a microSD card I have has a 4gig card in them and while I agree that it's a stupid amount of space I've never had a problem with them.

smithdavidp · 2012-04-28 12:34

Yeah..... I bought the 4 gig cards. One was for a cell phone but the other one I bought today because of the problem. I just finished running the test on the generic card and it was a bit slower than the SanDisk but it worked okay. My project will be taking up quite a bit of space mostly in the form of sound files and look up tables. The Prop is really an unbelievable board. Parallax hit a home run on that one. Just hard for me to comprehend a functioning device, that sets on my hand, has over 4 gig of memory to use. And to think I was impressed with the Bs2. lol

GordonMcComb · 2012-04-28 13:15

It's okay to disagree! I'm just saying that compatibility is not as assured as you move up the capacity scale, and if you're having trouble it's a always a good place to start. It makes good sense to start from knowns. Once you find an SDHC card that works you can stick with it. That's why I said it would be good to have the exact brand, capacity, and format and maybe we could develop a database of uSD cards known to work with the PropBOE.

Amazon, Computer Geeks, and even Wal-Mart (though mostly online) sell the 1-2GB cards. The cheapest brand at Wal-Mart is WinTec, and they seem to be okay. I try to get them when they're on sale, preferably in the $3/each (or less!) range.

-- Gordon

GordonMcComb · 2012-04-28 13:23

smithdavidp wrote: »

I know that lol. I got the schematic out and traced it down.

You don't really need the schematic, though it's never a bad idea to check it. The pin numbers are printed on the board. The numbers are above the resistors, but as there are no other components or sockets adjacent, the pin numbers there must be for the SD card.

For those not as comfortable reading schematics, as you say the pin numbers for the SD card (and most other integrated components) may be found starting on page 3 of the PropBOE documentation.

-- Gordon

Duane Degn · 2012-04-28 13:26

I've attached a demo of recording data to a SD card.

Sorry, I'm out of time right now so I can't explain the program as much as I'd like. I did try to comment the code some.

Here's the output the first time the program is executed. (The forum software removed some blank lines.)

Press any key to start.
PropBOE SD demo using "SD-MMC_FATEngine" as the SD card driver.
About to mount SD card.
If no new text appears, there was a problem mounting the SD card.
If the SD card fails to mount try re-seating the card in the
socket (after turning off power to PropBOE).
If that doesn't work, open the SD card on a PC.
There might be a "check disk" flag that needs to be cleared.
The final thing to try if the SD card still wont mount is to reformat it.
I believe the cluster size should be 32KB?.
I've always just used the default settings when reformatting.
The "quick" reformatting method hasn't ever worked for me.
It needs to be the standard (long way) of reformatting.
I've had several SD cards that would not work with the above
mentioned SD driver until the card had been reformatted.
****** Attempting to Mount SD Card ******
Looking for file "LOG_0000.TXT"
File "LOG_0000.TXT" not found.
sdErrorString = 6932
sdErrorString "Entry Not Found"
There are not presently any log files on this SD card.
Unmounting Partition
sdErrorNumber = 0
Atempting to create file "LOG_0000.TXT"
Creating file "LOG_0000.TXT".
About to write 10 sets (rows) of 4 data items (columns) to uSD.
EndRecording Method
Unmounting Partition
sdErrorNumber = 0
The data has now been written to the uSD.
Preparing to retrieve data from the uSD.
Looking for file "LOG_0000.TXT"
File "LOG_0000.TXT" found.
1001,2010,3100,5000
1002,2020,3200,6000
1003,2030,3300,7000
1004,2040,3400,8000
1005,2050,3500,9000
1006,2060,3600,10000
1007,2070,3700,11000
1008,2080,3800,12000
1009,2090,3900,13000
1010,2100,4000,14000
9999
Program used to create log PropBoeSdDemo120428D

Unmounting Partition
sdErrorNumber = 0
End of uSD file demo.
Press "r" to reboot.

Subsequent times the program is run, th previous log files will be found and a new log file will be created numbered one higher than the last log file found of the SD card.

Here's a partial output from the second run of the program.

Looking for file "LOG_0000.TXT"
File "LOG_0000.TXT" found.
Closing File
Looking for file "LOG_0001.TXT"
File "LOG_0001.TXT" not found.
sdErrorString = 6932
sdErrorString "Entry Not Found"
There are presently 1 log files on this SD card.
Unmounting Partition
sdErrorNumber = 0
Atempting to create file "LOG_0001.TXT"
Creating file "LOG_0001.TXT".

I used numbered log files in my own projects, and I've seen several requests on the forum on how to number log files, so I thought it would be a good feature to include in the demo.

I'm always unsure how simple to make a demo vs how many features to include.

I tried to take a middle road with a relatively simple demo that has some of the features I've frequently seen questions about.

Kye's driver doesn't have a way to write variable as ASCII characters directly. The "Dec" method in this demo does this.

One thing I really like about Kye's driver is the ability to timestamp the files with a RTC. This code does not use a RTC so the files wont have an accurate timestamp.

You'll see I use a green and red LED in the progarm. The pins used with the LEDs are listed in the "CON" section.

Let me know if you have any questions.

Duane Degn · 2012-04-28 13:36

GordonMcComb wrote: »

It's okay to disagree!

I agree.

Darn it! I was just enjoying my disagreement with you and I go and agree.

Instead of listing the SDHC cards that do work with the PropBOE, I think it would be easier to list those that don't. As I mentioned earlier, I haven't found any SDHC cards that don't work. I suppose I've only tested a few different brands though.

I think it will be the exception to the rule when one is found not to work.

Again, this doesn't pertain to all the SD drivers available for the Prop. Many (most?) wont work with SDHC cards. It's just Kye's driver that doesn't seem to have a problem with any of the SDHC cards I've used with it.

GordonMcComb · 2012-04-28 13:55

Duane Degn wrote: »

I would take Gordon's advice about using the smaller capacity cards if you want to be able to use all the various SD drivers available. Many of them wont work with the HC cards.

Glad you pointed this out because I was going to mention it, as this is something I feel fairly passionate about. People tend to forget there are a lot of examples out there (OBEX, this forum, various blogs and Web sites) with earlier versions of drivers such as fsrw that don't handle FAT32. For first-timers downloading these projects, they'll get stuck when things won't work, and then need to learn all about FAT sizes, clusters, and capacities before they can even move to square one. In the shoes of a beginner imagine how frustrating that is.

Example: If you download Ray's excellent WavePlayers example, you'll get fsrw 1.5. Will beginners know to upgrade?

As the problem is not likely to be the PropBOE hardware, I believe the best way to start the troubleshooting is to suggest to use a 1 or 2 GB card, which are in fact still plentiful and cheap (Parallax could sell 'em, too). By inference the majority of these cards will come formatted FAT16 (that's not always true, of course), and therefore will work on all the SD objects out there. Ray's wonderful examples will suddenly spring to life!

If we want to attract more beginners to the Propeller we need to change our own mindset, especially if we hope for the PropBOE to make strides into the same markets now dominated by the Arduino. That should start, IMO, with an SD object that comes with the IDE. As *experts* we can use anything we want, because we'll know there are later versions of these objects that support FAT32 and SDHC.

Duane, I wonder if that small card was formatted for FAT12. That would be my assumption, anyway.

-- Gordon

4x5n · 2012-04-28 15:15

GordonMcComb wrote: »

Glad you pointed this out because I was going to mention it, as this is something I feel fairly passionate about. People tend to forget there are a lot of examples out there (OBEX, this forum, various blogs and Web sites) with earlier versions of drivers such as fsrw that don't handle FAT32. For first-timers downloading these projects, they'll get stuck when things won't work, and then need to learn all about FAT sizes, clusters, and capacities before they can even move to square one. In the shoes of a beginner imagine how frustrating that is.

Example: If you download Ray's excellent WavePlayers example, you'll get fsrw 1.5. Will beginners know to upgrade?

As the problem is not likely to be the PropBOE hardware, I believe the best way to start the troubleshooting is to suggest to use a 1 or 2 GB card, which are in fact still plentiful and cheap (Parallax could sell 'em, too). By inference the majority of these cards will come formatted FAT16 (that's not always true, of course), and therefore will work on all the SD objects out there. Ray's wonderful examples will suddenly spring to life!

If we want to attract more beginners to the Propeller we need to change our own mindset, especially if we hope for the PropBOE to make strides into the same markets now dominated by the Arduino. That should start, IMO, with an SD object that comes with the IDE. As *experts* we can use anything we want, because we'll know there are later versions of these objects that support FAT32 and SDHC.

Duane, I wonder if that small card was formatted for FAT12. That would be my assumption, anyway.

-- Gordon

I think that we hit on a large issue with the existing sd objects and problems people are having with the larger cards. That being a combination of the objects not supporting sdhc and/or fat32. I don't consider that to be a problem with the cards themselves. The reason I went with the 2gig cards was exactly so I could use the smaller fsrw object. The problem is that around here at least the supply of cards smaller then 2gig is non-existant. and there are fewer types of 2gig cards and they can be hard to come by. After my last post I got interested in cards again and went to microcenter to get a few more of their bulk cards. I ended up getting 3ea of the 2gig and 4gig microSD cards. They cost me $4 ea for the 2gig cards and $5 ea for the 4gig cards and that includes the SD adapter! They didn't have any 1gig cards in stock and a sales person there told me they don't carry 1gig cards period! I then did a bit more shopping and there were no 1gig cards to be seen and the 2gig cards were all sdhc. There were only a handful of different types and counts on the shelf but there were a lot of 4, 8 and 16 gig.

I'm not trying to be argumentative but this is going to become a bigger problem that's going to need to be addressed. I'm not sure how different fat16 and fat32 and how much work it'll take to update fsrw to work with fat32 but I don't see 2gig cards being available for much longer.

Mike Green · 2012-04-28 15:26

The current (2.6) version of FSRW works with FAT16 or FAT32. It also works with high capacity SD cards (SDHC).

4x5n · 2012-04-28 15:43

Mike Green wrote: »

The current (2.6) version of FSRW works with FAT16 or FAT32. It also works with high capacity SD cards (SDHC).

It looks like it has for a while as well. I also need to correct the prices I mentioned for the microSD cards I bought. I quoted the prices on the bin but they were on sale for $3.50 and $4 ea!! :-)

Duane Degn · 2012-04-28 15:45

GordonMcComb wrote: »

For first-timers downloading these projects, they'll get stuck when things won't work, and then need to learn all about FAT sizes, clusters, and capacities before they can even move to square one. In the shoes of a beginner imagine how frustrating that is.

Yes, the wrong size SD card would be one more thing that could go wrong for a beginner.

I remember (just a couple of years ago), when I started using microcontrollers, a couldn't get a lot of my first projects to work correctly. There were just so many little details one needed to know to get sensors and programs to work correctly. Using the wrong object when using a SDHC card would have been frustrating.

So yes, using an 1GB or 2GB card would eliminate some of the possible errors a beginner could make. (Did I just lose a bet?)

Personally, I was very pleased when Kye added SDHC support to his driver. I no longer needed to purchase some cards just to use with the Propeller. With Kye's driver I could use cards purchased for cameras and other devices with the Prop.

Edit: I hadn't read the previous three posts when writting this one.

GordonMcComb · 2012-04-28 16:31

Mike is correct that the current fsrw is pretty much up to date. The problem is a little larger in the mirror now because the PropBOE supports SD right on the board. I'm not sure how much extra support effort Nick & Co had to devote with the SD support on the GG platform board, but I do know his writeup on it mentions only FAT16 (he links to the up-to-date fsrw on the OBEX in any case, but he doesn't promise more than FAT16).

Some palliative steps could include having the authors of objects in the OBEX review their submissions, making sure they include the latest SD driver. The next update to the Propeller Tool should include it, or Kwabena's, or someone's that's been shown to work with FAT32 and SDHC. Many users aren't even aware of the issues of FAT sizes and capacities in these cards, so maybe a writeup on the subject in the learn.parallax.com site for the PropBOE might be useful. I'm pretty sure the latest fsrw is drop-in compatible with the older versions, so it ought to be a case of just replacing files. I hope so.

It might also be useful if Parallax sold some 2 GB non-HC cards. As you've noted, price is very reasonable. I do most of my buying online, where they are still plentiful (for how long, who knows?), but just having them as an option on the Parallax shopping pages would be helpful in establishing a baseline for support.

While I don't get furious about it, a pet peeve of mine from an education standpoint is that the Prop Tool comes with no fewer than three serial objects, and their syntax is completely different. I rather like fsrw's methods -- like just specifying the base pin if the other three are connected consecutively -- and I hope similar objects could be written or revised to be a little more standardized. I like having multiple objects to choose from, but I often pass up the option to switch because it can be such a hassle to go through and change all the code.

Those in the Arduino space know that with their latest release they put a lot of effort into making methods more compatible and self-discoverable across objects. By deriving from a standard Stream base class, objects like serial, I2C, ethernet, and even SD communication now have shared methods that make coding easier. It also makes maintaining these individual objects simpler. I'm all for the Propeller adopting more base classes (that are in the IDE) that other objects can be derived from.

All in all, I don't ask for much!

-- Gordon

ratronic · 2012-04-28 17:43

Gordon I have ordered a 32GB San Disk uSD card today for something else but I am going to give Kye's driver a shot using it on the PropBoe.

Mike G · 2012-04-28 18:12

Gordon, I agree writing to an interface is the way to go. I'm getting of subject here, but how do we as a community follow an interface standard? Who sets the standard?

GordonMcComb · 2012-04-28 20:21

Mike G wrote: »

but how do we as a community follow an interface standard? Who sets the standard?

Good question, and I don't have the answer. I'm just being an observer here, and comparing what appears to be working in other open source models.

I do think that if A creates a popular object and B wants to improve upon it, A's object should be enhanced rather than releasing a whole new (and possibly different working) object. That's the spirit of the open MIT license that nearly all of the objects are released under. If that's not practical -- it's a whole new idea -- I think it makes sense to try to follow A's lead, assuming A's object was decent to begin with. If it uses methods that have a reasonable naming structure, why not keep it. Why reinvent that wheel for each object?

I return to the varieties of serial objects, and the sometimes mystifying differences in method names and syntax. Which syntax is better I can't say, but I think having consistent method calls between them would benefit all users, especially newcomers. With that said, GCC offers a fresh chance, and I'll be interested to see how that develops. As I'm more of a C programmer, that's something I can finally contribute to.

-- Gordon

4x5n · 2012-04-28 23:03

GordonMcComb wrote: »

Good question, and I don't have the answer. I'm just being an observer here, and comparing what appears to be working in other open source models.

I do think that if A creates a popular object and B wants to improve upon it, A's object should be enhanced rather than releasing a whole new (and possibly different working) object. That's the spirit of the open MIT license that nearly all of the objects are released under. If that's not practical -- it's a whole new idea -- I think it makes sense to try to follow A's lead, assuming A's object was decent to begin with. If it uses methods that have a reasonable naming structure, why not keep it. Why reinvent that wheel for each object?

I return to the varieties of serial objects, and the sometimes mystifying differences in method names and syntax. Which syntax is better I can't say, but I think having consistent method calls between them would benefit all users, especially newcomers. With that said, GCC offers a fresh chance, and I'll be interested to see how that develops. As I'm more of a C programmer, that's something I can finally contribute to.

-- Gordon

I'm not sure who (person or group) would be the arbitrator but the internet uses the RFC process to generate standards. Maybe something like it could be adopted with the object exchange. My first thought would be that Parallax would take the role that the ietf has in the RFC process. I do know that they're looking to add more in the way of standards to the objects in the obex. Somethin like an RFC process would allow others working on a similar object or process to to offer comments about the directions they're going in order to utilize the best ideas of all involved.

On a side note all this talk about sd, sdhc cards as well as fat16 and fat32 has triggered my OCD and not long after I got home from my first trip to Microcenter with my 2gig microSD cards I went back and got a bunch ( 25 ) more. This is more then I will ever have any use for with any propeller I projects I'll ever need an microSD (not sdhc) with fat16 so now the world is safe and sdhc with fat32 will become mainstream with!!! :-)

smithdavidp · 2012-04-29 02:42

I am a beginner to the Micro Controller. My only experience was with Robots like Fanuc, Panasonic, Nachi, etc. The only thing I knew about them was inputed through a Teach Pendant. The software was the installing companies headaches. I am also from the old school of building PC's. Back when you had to go through DOS to install a hard drive giving the sectors, heads, and landing zones, of the hard drive, to make it usable within the PC (did I just give my age away?). I am pleasantly suprised to see the increasing number of "help request" in this, and other, venues. This means that more and more people are starting to get interested in the Micro Controller for various reasons. The thing that you folks, the experts, have to understand is that there are many "users" out there that come from a "plug and play" world. It's the same as if you brought someone from the early 1960's into todays day and age of television. They know what a TV is but they have never seen 3D TV let alone a color TV with such a vivid screen. Imagine their suprise finding out you have to have a little black box to turn the TV on and off. Some of you forget that people are just starting out with these neat little Robot Kits that have no previous background in electronic or programming. If I had no experience with the Boe - Bot at all I would not have known where to look to find the answer for the problem I had here. After I saw my problem, that I typed in, I could stand back and ask "what is this guys problem?". It finally came to me to look in the manual. We all have to agree that the manual, for the Prop BOE, is less than perfect because it is in the compilation stages. Another issue is that not all of the Propeller chips come on the same platform. A beginner reads what worked on a Prop Demo board and wonders why it isn't working for his/her Prop BOE. If I had instructions to make a SD work on my platform that were written for my platform, and the exact software (spin code) for my platform then this post would have never been created. Try this experiment. Go out there and grab one of your realitives (no micro experience), set them in front of a table with all the parts to build a Prop Boe-Bot. Then leave the room. How much progress do you think they will have made when you come back in two hours? I guess my point is that you Guys are the teachers and these Forums are the what to do if it does not work guidence. If not for the help from the "Experts" and the efforts Parallax is making to create a text book a lot of People would be wanting their money back simply because they don't understand what it is they purchased in the first place. My project is to build a Robot, for under $5,000.00, that will be useful to senior citizens and/or the handicapped. The robots I see that can do that today will run for 90 minutes max and cost well over $12,000.00 just for a basic model. And I am a beginner. If that doesn't make you shake your head then nothing will. I am grateful for the help and guidence that all of you provide.

smithdavidp · 2012-04-29 05:51

Duane, the demo ran fine. Here are my results:

GordonMcComb · 2012-04-29 08:16

4x5n wrote: »

all this talk about sd, sdhc cards as well as fat16 and fat32 has triggered my OCD

Haha! I'm the same way. Once I get a bug in my ear I go hog-wild.

Dave, Duane's demo looks like a great way to test the functionality of the SD services, while providing some helpful tips at the same time. Duane, can you put it in the OBEX so when folks have an SD problem we can point to a convenient download location?

-- Gordon

Don M · 2012-04-29 10:29

Just bought 10 2GB MicroSD cards from here:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250987330642#ht_4047wt_1141

smithdavidp · 2012-04-29 10:58

Maybe add Propeller BOE so there is no mistaking it? lol

Duane Degn · 2012-04-29 11:46

GordonMcComb wrote: »

Duane, can you put it in the OBEX so when folks have an SD problem we can point to a convenient download location?

@Gordon, I feel kind of silly putting a demo of someone else's object in the OBEX but if you think it would be a good idea, I'll do it.

The demo I posted does a few of the things with a SD card I've seen questions about here on the forum. It numbers the log files. It writes data as comma delimited ASCII characters that could be read by Excel or other speadsheet programs.

One thing the demo doesn't do that I'd want to add before putting it in the OBEX is to read the ASCII characters from the file and store the numbers to variables that could be manipulated mathematically by the Prop.

The demo does read the file it creates but it just outputs the ASCII characters to the terminal window.

My PropBOE-Bot code that can record the robot's movements does convert ASCII characters to numbers the Prop can use. I'll add this ability to the demo and post it to the OBEX.

@Dave, I agree there are a lot of things people who have been use uCs for a while take for granted. It's often hard for people to remember what it was like when they were first learning about microcontrollers. I hope you've felt welcome to ask questions here on the forum.

@Don, I hope you let us know how those uSD cards work. I've heard of generic cards using memory that doesn't hold up to multiple writes as well as name brand cards. Hopefully these cards work as well and last as long as name brand cards.

Prop BOE SD Card not working

Comments