Three spaces possibly being added at the end of a returned 8.3 file name from an SD card driver
JRetSapDoog
Posts: 954
in Propeller 1
Greetings. I'm using (or likely abusing) Kye's useful and much-appreciated SD-MMC_FATEngine, Versions 1.9 & 2.0 (It was chosen due to directory support and the built-in ability to launch a binary). When I issue sdErrMsg := sdc.openFile(string("/DIR1/FILE1.TXT"), "R"), the return string on successfully opening appears to have three extraneous spaces appended after the 8.3 name. I'm not sure why and am wondering if it's just me. I noticed the three spaces when I displayed the returned file name in reverse video in a debug message (without using reverse video or some delimiters, those spaces could easily be missed).
What got me into this was that I was looking for a way to catch if the SD card had been ejected after the driver was started and the file system mounted. I think there is a card detect function (which might use an additional/5th pin, not sure), but I haven't used that yet. I was just trying to trap an error occurring on openFile to present a warning and prevent further file system calls. But I don't think any error number gets set with an openFile error (please correct me if I'm wrong). Rather, a pointer is returned to the error message string. And if no error occurs, then the successfully opened file name (all UPPERCASE) is returned.
So, to try to handle an error on openFile, I tried doing a strcomp on the returned file name (or error message) with my file name. However, I couldn't get them to match, as they should have when openFile was successful (I guess that's the only way to check after the call). Initially, I was using a mixed-case file name, but the driver (and FAT, I guess) works with uppercase letters. But after I adjusted for that, the two strcomp string names still weren't the same. And as described above, the culprit was the three apparently appended spaces at the end of the 8.3 filename being returned (I presume, sorry) from the openFile call. I don't think anything I was doing was adding the three spaces (just making a call) and my debug message display seemed okay. So, I added the three spaces to my filename in the strcomp call (but not the actual openFile call) and the comparison came out true (the returned file name with possible extra spaces and my hard-coded file name with three extra spaces matched). I'm currently still scratching my tired head. I confess that I haven't poured through the FAT engine to see if it added the spaces (I generally suspect my own code first), other than noticing that the driver apparently reserves 12- and 13-byte variables for file names (just enough for 8.3 (12 bytes) and 8.3 + 0 (13 bytes) file names). I'm just wondering if anyone has seen anything similar or has an idea what I've overlooked. Thanks. I'll go back and look again after resting as maybe I've missed something obvious (and my apologies if I have). --Jim
What got me into this was that I was looking for a way to catch if the SD card had been ejected after the driver was started and the file system mounted. I think there is a card detect function (which might use an additional/5th pin, not sure), but I haven't used that yet. I was just trying to trap an error occurring on openFile to present a warning and prevent further file system calls. But I don't think any error number gets set with an openFile error (please correct me if I'm wrong). Rather, a pointer is returned to the error message string. And if no error occurs, then the successfully opened file name (all UPPERCASE) is returned.
So, to try to handle an error on openFile, I tried doing a strcomp on the returned file name (or error message) with my file name. However, I couldn't get them to match, as they should have when openFile was successful (I guess that's the only way to check after the call). Initially, I was using a mixed-case file name, but the driver (and FAT, I guess) works with uppercase letters. But after I adjusted for that, the two strcomp string names still weren't the same. And as described above, the culprit was the three apparently appended spaces at the end of the 8.3 filename being returned (I presume, sorry) from the openFile call. I don't think anything I was doing was adding the three spaces (just making a call) and my debug message display seemed okay. So, I added the three spaces to my filename in the strcomp call (but not the actual openFile call) and the comparison came out true (the returned file name with possible extra spaces and my hard-coded file name with three extra spaces matched). I'm currently still scratching my tired head. I confess that I haven't poured through the FAT engine to see if it added the spaces (I generally suspect my own code first), other than noticing that the driver apparently reserves 12- and 13-byte variables for file names (just enough for 8.3 (12 bytes) and 8.3 + 0 (13 bytes) file names). I'm just wondering if anyone has seen anything similar or has an idea what I've overlooked. Thanks. I'll go back and look again after resting as maybe I've missed something obvious (and my apologies if I have). --Jim
Comments
We sure get a lot of support from down under on this forum. In another thread (perhaps about the P2), I saw a reference to Aussies and Kiwis. I didn't know what a kiwi was (other than the fruit) and had to look it up. Found out that it's a flightless bird and a way of referring to New Zealanders (apparently the kiwi is NZ's national bird). And just now, I discovered that "down under" can also refer to New Zealand and people therefrom, which makes sense. As PBS says, "The more you know...." Anyway, thanks again, Inspector Cluso, even if you're currently not down under (I forget if you're still in So. Korea).
Yes, I am here for another 1 1/2 weeks. Been here 3 weeks now.
Off to Seoul Wednesday to go to the Yongsan Electronics Market to see what I can pick up. Particularly looking for an SSD SATA drive for my laptop, although I wouldn't mind building a fast NUC so I can use a large screen.
Not only is my laptop slow and old, but compiling FPGA code is frustratingly slow too.
Have a good visit in Seoul this coming week. That sounds like a famous electronics shopping area, like the ones in Tokyo or Shenzhen, for example. I hope to go to the one(s) in Shenzhen someday (in person, not just via video), but I'd probably be overwhelmed by all the electrical components (chips and so on) that they stock. And maybe I could buy a microscope or something (though I think a company in Cali has good pricing already).
Hope your find a SATA SSD at a good price, and, most importantly, a reliable one (it often pays to pay more). Fortunately, SSD drives are beyond first- or second-generation at this point. Wonder if you want the NUC for its small size, among other things. Maybe it can be VESA attached to the back of a monitor, though that might not be the most convenient was to locate it.
I haven't taken the FPGA plunge like you folks on the bleeding edge. And when I say "bleeding," it does sound painful with the long initial download, the configurations, and the compile times. But one good thing comes from the long compile times: it gives Chip a chance to touch base with us without having to feel guilty about doing development, since it's understandable to resume development after he gets results after compiling. So I guess we should thank the tool makers for that.
Anyway, I look forward to seeing what you guys come up with. Perhaps you'll be working off of solar power on your boat with your NUC and a not-too-power-hungry monitor.
Thanks again for your help (we've still got a great forum here).