The +FAT locking mechanism, as it has been implemented in
, 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
. That module makes use of an
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:
Most modules do not miss a lot, mainly the following defines:
/* Get the standard types like ‘int32_t’. */
typedef long BaseType_t;
typedef unsigned long UBaseType_t;
#define pdFALSE ( ( BaseType_t ) 0 )
#define pdTRUE ( ( BaseType_t ) 1 )
#define portINLINE __inline
#define configNUM_THREAD_LOCAL_STORAGE_POINTERS 3 /* FreeRTOS+FAT requires 2 pointers if a CWD is supported. */
That is not too much.
Today I found a few more dependencies, two of them are locking mechanisms:
ff_ioman.c is using :
ff_sys.c is using :
ff_stdio.c is using :
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.
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.