"

Reading from SD Card at Runtime

Hello,

I'm using EMSK and I'm trying to build and application there requires data from an external file (.txt for example). Is there any way where I can access my SD card for that file during runtime? FYI, I'm already using my SD card to bootload my application.

Thanks for helping!

Eugene

Comments

  • Hi Eugene,
    The files under \embARC\middleware\ntshell\cmds\cmds_fs include a bunch of commands that are related with filesystem that could help you access files on the SD card. You could build your application with this middleware and invoke the relevant API functions/commands.
    Please take a look at these files and let me know if you need more info, thanks.
    -Elliot
  • Hello Elliot,

    I need help on using the cmds given.
    I've tried the following:
    Adding "ntshell fatfs" to MID_SEL and removed "static" from the functions in .c files of the functions that I want work on.
    Results:
    Application starts with ntshell's booting procedure and enters the loop meant for ntshell application.

    Is there any step that I've mistaken above?

    Thank you!

    -Eugene
  • Hi Eugene,
    If you've added that middleware by default embARC will go into this ntshell part and wait for your command input, so that's expected behavior. I point you to this to help you take a look at how middleware is linked in/usesd. What you need is the fatfs file system to help you analyze the path/command for a file, and the SD card driver to carry out actual read/write operations to SD card. Fatfs is a middleware ported to EMSK under directory \embARC\middleware\fatfs. It includes source code/APIs that you could use directly. And SD card driver is under \embARC\board\emsk\drivers\sdcard, it has the basic SD card operations.
    So to access SD card, both file system(fatfs) and SD card driver are needed. See attahced picturee of how this is used with ntshell commands.
    sdcard.JPG
    879 x 146 - 33K
  • Hi Elliot,

    Thanks for the info, I manage to get it working!
    The command that I referred to was "ls" and it was working as expecting in my application.
    But I came across difficulties when I'm trying to "read" "write" or "create" a file.
    I've troubleshoot a few FLAGs using f_open function provided by FatFS.

    For creating a new file I tried:
    res = f_open(&file, pathname, FA_CREATE_NEW);
    and it hangs there. (I assume that it has something to do with the FA_CREATE_NEW flag)

    For read and write I tried:
    res = f_open(&file, pathname, FA_OPEN_EXISTING | FA_READ);
    res = f_open(&file, pathname, FA_OPEN_EXISTING | FA_WRITE);

    I'm not sure if it's correct since I can't get through the first step of creating a file.

    p.s. The pathname here is "test.txt"

    Thanks for helping!

    -Eugene
  • Update: reading works as expected but writing isn't working :(
  • could you run the example and see if it's correct? Then try to follow up the routine. What do yo mean by "writing" not working? Do you fail to write to the file or the file creation is not unsuccessful?
  • edited March 2017
    eugenelet said:

    Update: reading works as expected but writing isn't working :(

    hi, I had a short conversation with our engineers, ordinarily we don't write to SD card from the applicaton code but do that on PC and read the files fromSD card. Could you tell if you have any specific reason to update the SD card contents?
    Also I confirm that you could have "touch" and "cp" command to create new files, these should work without problem. And "res = f_open(&file, pathname, FA_OPEN_EXISTING | FA_WRITE);" should work, please take a look at the spirw command as a reference.
    Writing some contents to a file is not supported by far, say if you touch a new file and want to update contents of that file, this is not supported with current release.
  • edited March 2017
    Hi Elliot,

    I need to do that because there's a constraint on the limited RAM usage, thus writing and reading from a file seems to be the only viable option. (or there's a better way on dealing with this matter?)

    Yeah, I tried to "reverse-engineer" "touch" and "cp" function and came across the "res = f_open(&file, pathname, FA_CREATE_NEW| FA_WRITE);" function where I tried applying it in my application. The problem is my application always hangs when it reaches that line. I've tried "res = f_open(&file, pathname, FA_CREATE_NEW);" as well and my application still hangs there.

    "res = f_open(&file, pathname, FA_OPEN_EXISTING | FA_READ);" works as expected.
    My guess is there're initialization that has to be done beforehand.
    I think I've to dig deeper into the examples for those initialization.

    Edit: I tried using "cp" given by ntshell example, it seems that it's not working as well.

    Thanks!

    Eugene
  • Hi Eugene,
    Seems you want to store some temp data to SD card and read it back for later use? You could take a look at the spirw program: it's reading a file from spiflash and write it to SD card. And SD card initialization is done automatically is it's inserted before board power up. (or you need to execute the "disk -i 0" command to initialize the fatfs system).
    While you look into the spirw example code, please also take a look at the fatfs API, it might help you understand the process.
    http://elm-chan.org/fsw/ff/en/appnote.html
    http://elm-chan.org/fsw/ff/00index_e.html
    Thanks.
    -Elliot
  • edited March 2017
    Hi Elliot,

    Yeap, that's what I'm trying to work on.
    I've troubleshooted the problem and came to some findings:
    "touch" and "cp" for ntshell isn't working for the latest example code release, but it's working for the previous version.
    I guess there's something wrong with the middleware?
    Seems that I've to find the root of the problem now. :(

    Thanks!

    Eugene
  • Hi Elliot,

    A little update:
    I tried building my application using the previous version of embARC examples, my applications works perfectly (fatfs, bluetooth, display, etc), but there's one drawback: the update is too slow. I'm not sure what's causing this problem, maybe the timer/interrupt's running? As the following functions are found in the old example but not the new:

    cpu_lock(); /* lock cpu to do initializations */
    board_init(); /* board level init */
    cpu_unlock(); /* unlock cpu to let interrupt work */

    There're 2 things that can be done to solve my problem now:
    1. Fix fatfs in the new software version by referring to the old version.
    2. Fix the slow runtime issue on the old software version

    Thanks!

    Eugene
  • edited March 2017
    Hi Elliot,

    I've found the root of the problem, it has to do with "dw = get_fattime();" under "f_open(...)". The "get_fattime()" of the old version just returns 0 but the latest version gets the actual time and I think something went wrong with that.

    About the previous version, is there any reason that the runtime speed is far slower than the latest version? (is my assumption correct?)

    My problem is solved for now, thanks for your help Elliot! :)

    Update: And I realized that everything that is either "printed" or stored as "strings" get written into the opened file. I'm sure that I closed the file using f_close($file). :(

    Eugene

  • Hi Eugene,
    If you've closed the file pointer that should have been closed:) Anyway, the project needs some patience, and I suggest you to test with embARC2016.05 release.
    cpu_lock(); /* lock cpu to do initializations */
    board_init(); /* board level init */
    cpu_unlock(); /* unlock cpu to let interrupt work */
    These three functions are not needed in the new release. And the OLED refreshing rate is higher than previous version.
    -Elliot
  • Hi Elliot,

    Yeah, I've done the whole procedure using the latest and the previous version. I don't seem to find the root of the problem where all strings that were either print or stored as char* is stored into the newly opened file. This problem seems to occur on the latest version only and works perfectly on the previous version. Still trying to find the difference between both version that causes this problem.

    And for the OLED refreshing rate, any idea on which file is that parameter set?
    Thanks!

    Eugene
  • hi, this speed enhancement is due to a new driver, we have not defined such a parameter.
  • edited March 2017
    Edit: My bad, the concatenation of later strings happens on both version. I think it's my problem. Sorry!
    Update: I got it fixed, seems that there's a memory leak when I pass a pointer to f_write.

    Everything's good now Thank you!

    Thank Elliot!

    Eugene
Sign In or Register to comment.