Hi All,

This link [http://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusFAT/index.html] says that

FreeRTOS+FAT is an open source, thread aware and scalable FAT12/FAT16/FAT32 DOS/Windows compatible embedded FAT file system which was recently acquired by Real Time Engineers ltd. for use with and without the RTOS.

On my Nucleo board, when I have tried to create RamDisk before calling vTaskStartScheduler(); then it doesnt create RamDisk.

But when I have tried to create inside thread after vTaskStartScheduler() starts then RamDisk created successfully..

1. Is there anything specific need to be done to create RamDisk without using vTaskStartScheduler inside thread ? 2. Is FreeRTOS+FAT soruce is tightly coupled with FreeRTOS source code, Can we make compatible with other os or non-os platform. 3. Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork?

Best regards, Sachin

The FAT library has to be ported to storage media, so the port layer is not really part of the FAT library itself, and I suspect the RAM disk (which works on any device with enough RAM) has a dependency on the RTOS - although I've not checked to see if that is true. It may also be the case that the 'without an RTOS' claim is no longer valid.

Hi Sachin, as far as I remember, the only dependency is ff_locking.c.

If you're a single user, you should make an empty version of each function:

~~~ BaseTypet FFHasSemaphore (void *pxSemaphore) { return 0; }

BaseTypet FFTrySemaphore( void pxSemaphore, uint32t ulTimems ) { return 1; } /-----------------------------------------------------------*/

void FF_PendSemaphore( void pxSemaphore ) { } /-----------------------------------------------------------*/

void FF_ReleaseSemaphore( void pxSemaphore ) { } /-----------------------------------------------------------*/

void FFSleep( uint32t ulTime_ms ) { } /-----------------------------------------------------------/

BaseTypet FFCreateEvents( FFIOManagert pxIOManager ) { return pdTRUE; } /-----------------------------------------------------------*/

void FFLockDirectory( FFIOManager_t pxIOManager ) { } /-----------------------------------------------------------*/

void FFUnlockDirectory( FFIOManager_t pxIOManager ) { } /-----------------------------------------------------------*/

int FFHasLock( FFIOManagert *pxIOManager, uint32_t aBits ) { return pdTRUE; }

void FFAssertLock( FFIOManagert *pxIOManager, uint32_t aBits ) { }

void FFLockFAT( FFIOManager_t pxIOManager ) { } /-----------------------------------------------------------*/

void FFUnlockFAT( FFIOManager_t pxIOManager ) { } /-----------------------------------------------------------*/

BaseTypet FFBufferWait( FFIOManagert pxIOManager, uint32_t xWaitMS ) { return pdTRUE; } /-----------------------------------------------------------*/

void FFBufferProceed( FFIOManager_t pxIOManager ) { } /-----------------------------------------------------------*/ ~~~

Regards.

Hi Hein,

1. You are suggesting that if its one user means only main thread then it will be possible to create RamDisk with above mentioned empty functions for semaphore.

2. Is FreeRTOS+FAT soruce is tightly coupled with FreeRTOS source code, Can we make compatible with other os or non-os platform. But it is multi threaded system then it is coupled with FreeRTOS scheduler, right.

3. Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork? ??

Hi Sachin,

The +FAT locking mechanism, as it has been implemented in ff_locking.c, is using FreeRTOS kernel API's, notably mutexes and Event Groups. These functions have been put together in a single module, so that all other modules remain independent from the kernel. At least, that was the intention. But, through time, through the years, the library has been ( new verb ) : freertos-ised.

Also, the project got a nice extension: a new layer called ff_stdio. That module makes use of an errno that is local to a task. Each task can have 1 or more pointers for local storage.

I'm trying to compile a +FAT project that uses a RAM-disk with the FreeRTOS header files excluded, that is any of these files:

~~~ //#include "FreeRTOS.h" //#include "task.h" //#include "semphr.h" //#include "portable.h" ~~~

Most modules do not miss a lot, mainly the following defines:

~~~ /* Get the standard types like 'int32_t'. */ #include

typedef long BaseType_t;
typedef unsigned long UBaseType_t;

#define pdFALSE          ( ( BaseType_t ) 0 )
#define pdTRUE           ( ( BaseType_t ) 1 )

#ifndef portINLINE
    #define portINLINE   __inline
#endif

#ifndef configNUM_THREAD_LOCAL_STORAGE_POINTERS
    #define configNUM_THREAD_LOCAL_STORAGE_POINTERS    3 /* FreeRTOS+FAT requires 2 pointers if a CWD is supported. */
#endif

~~~

That is not too much.

Today I found a few more dependencies, two of them are locking mechanisms:

ff_ioman.c is using :

~~~ taskENTERCRITICAL taskEXITCRITICAL ~~~

ff_sys.c is using :

~~~ vTaskSuspendAll xTaskResumeAll ~~~

ff_stdio.c is using :

~~~ vTaskSetThreadLocalStoragePointer pvTaskGetThreadLocalStoragePointer ~~~

Coming back to your questions:

You are suggesting that if its one user means only main thread then it will be possible to create RamDisk with above mentioned empty functions for semaphore.

Yes. Beside the locking mechanism there are 6 more functions that must be simulated, listed here above.

If FreeRTOS+FAT source is tightly coupled with FreeRTOS source code, can we make compatible with other os or non-os platform.

Yes you can.

But if it is multi threaded system then it is coupled with FreeRTOS scheduler, right.

It will equally work together with another scheduler.

Can FreeRTOS+FAT used with other RTOS like ThreadX or VxWork?

You can also use it with a different RTOS, provided that you implement the locking mechanisms with primitives from that RTOS. In case there is only a single user, things are a lot simpler.

Regards.

Thanks Hein for your valueable response which has research included in it.

In summary :- 1. Intention was not to create +FAT which is independant than FreeRTOS, if taking as it is then it is not compatible with other OS but if someone want he can make it with single user.

Sounds like a good summary, except that it is also possible to port +FAT to a different multi-tasking OS.

The FreeRTOS version of ff_locking.c is using both mutexes and event groups. If a different platform only has semaphores that is enough to create a reliable locking.

Regards