littlefs with async SPI

[bragma]

Hi,
I am considering to use littlefs with an SPI flash, but my SPI driver implementation is totally async. After setting buffers and lengths, I get an event on a callback when the operation is completed. I have no way to implement some "wait for event" to make operations appear as synchronous aside from busy waiting which I prefer to avoid (will not work with other timing constraints, also I have having IRQs and wasting them by having the CPU to poll).
I am new to littlefs, can it work with an async implementation (i.e. start_op -> op_completed_callback) of the required read, prog, erase functions?
Thanks!

[FreddieChopin]

Use an RTOS and then it will be easy to turn your asynchronous code into a synchronous one.

[bragma]

Use an RTOS and then it will be easy to turn your asynchronous code into a synchronous one.

I'd really like, but I can't do it.

[geky]

Short answer is no, sorry. littlefs is synchronous and adding support for async requires basically rewriting the entire implementation. There's other work littlefs needs that is higher priority.

Though if anyone writes an async implementation, let me know or create a PR :). It would very interesting to compare a sync vs async filesystem implementation.

If you don't want to go full in on an RTOS, you can try using a delimited coroutine library. This would give you the "thread_start" and "thread_yield" functions without preemption. I've heard of several for C (looks like a good list here), though I haven't had a chance to use one yet. They will require porting effort to your MCU though.

Another option I've used before with a lot of success: use low priority interrupts to run a separate async "thread". Then you can run blocking logic on the main thread, with system logic running on the async thread.

[bragma]

Ok thanks, I'll give a try with protothreads.

[geky]

Hey @bragma, out of curiosity which library are you using? I found this guy, but if I understand protothreads correctly, that won't work for you.

littlefs stores state on the stack, so the threading library you find will need to be able to allocate/save stacks. AFAIK this always requires hardware specific support (for SP).

[bragma]

At the moment I am working on a barebone firmware for Nordic nrf52832. There are a few options available, but to summarize the firmware is just using the main context and interrupts. The problem with this setup is that all peripheral accesses are async, with a pattern like this:

init_driver(event_handler) -> setup the driver to call the operation completed handler

start_device_operation() -> operation is started and function returns
...
event_handler() is called via IRQs

One trivial way to make this behave as an sync operation is to set/clear a flag before starting and at completion of an operation, and in the main thread busy wait on it. But the problem is that busy waiting wastes battery power. The busy wait cycle should instead put the device on sleep, but I've found it is not trivial to do when also handling radio and other events...

There is a basic scheduler to use from IRQs to move back to the main thread, but it uses a queue and an event handler which basically moves the async problem to another level.

[geky]

Do you have the __WFI() intrinsic in your compiler? That will tell the processor it can sleep until it recieves an interrupt. I may be misunderstanding the issue.

[bragma]

You have not misunderstood, there is also __WFE() but it is not enough when using SoftDevice for radio due to some critical timing constraints. Normally sd_app_evt_wait() is used and things become more tricky due to its internals.

[geky]

I couldn't find a coroutine library that did exactly what I wanted (easy to port, MCU support), so I wrote my own: https://github.com/geky/coru

I realized this old, but if you're still needing an async API, coru may be useful. There's a littlefs example in the readme. : )

[Inviz]

Is there an understanding of how much stack memory littlefs requires? I wonder if initial setup of FS requires more memory too?

Update: #417 Looks like ~ 1300b