Radiolink AT9 as a platform for Deviation?

nice. the main issue is that we read flash in the main code context but all protocol code executes in interrupt context.which means an interrupt can happen in the middle of an spi transfer (i think the transfer itself is atomic, but the setting of the chip-select is certainly not).
Possible options:
1) place all spi handling code in an interrupt that has higher priority than either the main code or protocol code
2) disable interrupts while executing spi code
3) use a queue (and probably DMA) to stage requests (along with the csn controls) to serialize requests

1 and 2 are almost the same thing when it comes down to it. The main question is what is the average length of a memory read, and will it affect protocol timing? Memory access is generally less critical than the protocol code. we could use byte-level memory reads when using the module (no high-speed transfers) and set/clear the csn for each byte. that would make the time spent in a critical section pretty low.

3 is a cool idea as it would allow a central code stream to handle all spi with minimal critical sections (just the command staging), but is a lot more complicated to setup.

Honestly, the easiest thing to do is to just disable interrupts when csn is low and re-enable them when it is high in the spi_flash code, and see what happens.

By the way, the at9 enabling has led me down a rabbit hole..After redoing the 320x240 menu system and rewriting the scroll handling, I'm now rewriting all the code to get rid of the listbox widget (replacing it with a scrollable, should be nearly transparent) because the listbox doesn't play well with the 4-button model. Hopefully that will be the last of the major gui changes, and i'll be able to start working on fixing the buttons and whatever else. This has been a lot more work than I expected, but the GUI code will be in a more supportable state in the end I hope. A lot of cruft has seeped in over time, and it is about time for a good spring cleaning. As mentioned in the 'post 5.0' thread, this also means it will take some time to shake out all the new bugs though.

I don't like the idea of a scheduler for this. It is a lot of complexity. I'm also really concerned with trying to guess when a protocol may need to do work. That can be difficult given the the protocols reschedule themselves.
i think a queue may actually work fine. the main question is: is the SPI transfer long enough that it affects the timing of the protocol. if we keep memory transfers short, I think the answer will be no.

I agree that the GUI work is beneficial. I could have hacked something that would work, but this revamp is long overdue and makes the code a lot easier to work on. It is also having the effect of freeing up quite a bit of space on the 7e/f7

Don't forget about receiving telemetry data! That inducates SPI traffic too, doesn't it? Furthermore it does it in a more unpredictable way according to timing...

you do not need to hold csn low while erasing pages (or writing them). the real question is how fast can the spi clock run (probably the slowest of the protocol chips) and what is the hold time for clearing and setting csn. There really shouldn't be a significant penalty to write a byte at a time (or maybe a small buffer at a time depending on delay). We could also switch the spi frequency on entering/leaving the interrupt so that we can run the spi at high frequencies for the flash.

The SST25VF032B can run at 80MHz with a 5ns setup/hold. That is plenty fast. We can ignore the setup/hold altgether with that chip. We'd probably want to have a transfer size of > 10bytes to minimize the overhead of setting the address, but otherwise, it should be fine to just disable interrupts during memory access. I don't recall which chip you were using, but I think it had similar specs.

OK, thanks for clarification!

why not use DIV/2? Is that too fast for the memory you're using?

It is fixed now. I also reworked the filesystem code so that it is possible to build the emulator to use the filesystem image (which makes it easier to debug filesystem related issues). This is disabled by default.

I just updated the chantest page. As far as I know all pages except the model layout are now fully accessible. I am thinking of remapping the 'mode' button so that if it is pressed, the scroll wheel acts as left/right rather than up/down. That would provide a solution for the model_layout page which I have otherwise not been able to figure out a solution to.

I fixed the channels as well I think, though my testing was limited.

I think we probably need an interrupt handler for the wheel. I haven't looked into it yet though.