Adding FreeRTOS+FAT to existing FreeRTOS system?

I’m not sure, but I was wondering. If I have an embedded FreeRTOS system, and that FreeRTOS system already interacts as expected with the hardware, would it be possible to simply add the FreeRTOS FAT libraries on top of that system? If the flash is encrypted, would this also still work or does it only work with standard underlying DOS-type hardware?

Yes, you should be able to.

I guess it should work but you’ll need to handle encryption/decryption in your port layer. @htibosch is that correct?

1 Like

Many thanks!

I guess it should work but you’ll need to handle encryption/decryption in your port layer. @htibosch is that correct?

I’m still a student so some of the terms are a bit new to me. I’m not completely sure I understand what you mean, however, more concretely, the project I’m designing would use the following:

Base FreeRTOS system:

Infineon Github PSoC6 FreeRTOS

Evaluation board:

Infineon CY8CProto-064S1-SB

Which contains the following flash:

Infineon Semper Nor Flash Family

Does that help? Also, I am curious what you mean by ‘port layer’ in this context?

If you look at the code in the FreeRTOS-FAT repo, it can divided in 2 parts -

  1. Common Code - This code is applicable to all the hardware platforms. These are .c files in the top level directory (such as ff_fat.c, ff_file.c etc.).
  2. Portable Code - This is hardware specific code. It is in the portable directory. As you can see, there are several sub-directories for different hardware platforms.

You will need to write a portable layer for your hardware platform. You can use any of the existing ones as reference.

In FreeRTOS+FAT, the contents of files is always treated as binary. It doesn’t do CR/LF translations, neither will add a Control-Z ( or ^D ) at the end of a file.

The FAT file system itself is not encrypted. You can go through the directories and you will see file and directory names, they are not encrypted.

The contents of your files can have any encryption you like. +FAT doesn’t bother with the contents.

I often have multiple file systems in one name space. For instance:

/
/etc
/images
/part2
/part3
/ram
/Old Emails

where /ram is a special directory: it is a RAM disk. All other entries are located on the SD-card.
The directories /part2 and /part3 are pointing to the partitions 2 and 3 of the SD-card.

So that project has :

Instance of SD-card driver on partition 1 presented as /
Instance of SD-card driver on partition 2 presented as /part2
Instance of SD-card driver on partition 3 presented as /part3
RAM disk driver presented as /ram

You may want to have a look at this Xilinx/Zynq project

The SD-card is mounted here.

It is handy if you have a way of printing debug information. The library will use the macro FF_PRINTF() to print messages.

It is recommended to use the standard interface: ff_stdio.c. That looks like you’re used to on other systems: ff_fopen(), ff_fread(), ff_fwrite(), ff_fclose(), etc. There is even a kind of errno.

If you need the highest speed, try to exchange file data in blocks of a multiple of 512 bytes. If you read 4 KB, it will be read in a single operation.

I don’t know if there is a FreeRTOS+FAT driver for your Infinion. It is mentioned here.

At Infinion I found this project.

Maybe @Kugler can help us here? I see his signature in ff_sddisk.c, which is a FreeRTOS+FAT driver for MCU_PSOC6_M4!

Please keep us up to date. You can always ask more questions here.

1 Like

One more remark: you will find many versions/releases of FreeRTOS+FAT. Also in the project downloaded from Infinion you will find some old source code.

It is recommended to use the latest version on github.

I am curious what you mean by ‘port layer’ in this context?

FreeRTOS+FAT (and FreeRTOS+TCP) are libraries that can be used on many different platforms.
The ‘port layer’ consists of a set of function that are found between “the library” and “the hardware”. In the case of FreeRTOS+FAT, the port layer will give access to the physical memory (nor-flash) or SD-card.