Use of FatFS with modm's block device

[ludekcizinsky]

Hi,
I would like to integrate FatFS with modm's block device driver. I was searching through examples, but only found this one. Looking at the docs of FatFS, you need to implement the 'Media Access Interface' layer. I am wondering how to do this, for instance for disk_read function I would like to write something like:

DRESULT
disk_read(BYTE pdrv, BYTE *buff, LBA_t sector, UINT count)
{
    ....
    storageDevice.read(buff, address, size) // modm's driver
    ....
}

The problem, however, is that storageDevice.read is a resumable function and as such I would need to call it using PT_CALL according to the modm's docs. I have read in one of the dicussions, that the above mentioned driver was written in such a way that it could be integrated with the FatFs, so I would be grateful for an example showing for instance just how to integrate the read function since the rest will be similar.

Last but not the least, I have also seen in modm's todos to replace modm::fatfs with ufat. I wonder what is the reason for replacing FatFs with ufat? From the initial inspection of ufat, it seems like it is lighter as well as it is easier to integrate?

Thank you for your answers in advance :}

[salkinium]

You can use RF_CALL_BLOCKING in a non-resumable context.
You may be the first one to combine these two modules, so there may be some more issues to solve.
I wouldn't replace modm:fatfs, only add modm:ufat as an alternative, I've changed the wording.

[ludekcizinsky]

Thanks for the quick reply, really appreciate it! I will get back if there will be some new issues that I am not sure how to solve :)

[ludekcizinsky]

Hi, I have managed to make it working with the use of RF_CALL_BLOCKING, but could you think of a way where I can avoid doing this, i.e., I can use the PT_CALL?

To me, the only possibility seems like changing the FatFs which is of course more than suboptimal.... I will be grateful for some input on this :)

[salkinium]

You discovered the significant disadvantage of stackless, cooperative scheduling: the function signature must be changed for the entire call stack, which is an issue for third-party code that doesn't use this concept.
So, as you say, the FatFs code would have to be changed, which is a bad solution.

A better solution is to move the scheduling out-of-band, so that it is transparent to the call stack, which is what stackfull scheduling does.
We've implemented this as cooperative fibers in the modm:processing:fiber module, you must enable the module with the invisible modm:__fibers repo option, since it's not fully supported yet, especially missing backward compatible implementations of macros RF_* and PT_*.

I would recommend to add what you have now as an example to modm, so that we can use it when we implement the fibers completely.