Aasync SD card operations?

R

Ralf K.

Member
For a project we are using a Teensy 4.1 together with a custom PCB to replace the original PCB set in an old arcade game from 1981. As it is a vector based game the custom PCB contains 2 SPI DACs for x/y and a 4 bit resistor DAC for the intensity. A timer is used to ensure that these DACs are updated (FlexIO & GPIO) with a fixed 1.5MHz interval. There is although a PT8211 connected to SAI2. It uses a interrupt based updates with 125KHz. The isr emulates the two audio chips (AY3-8910) used on the original PCB. The main loop emulates two Z80 CPUs (3MHz & 1.5MHz) and the attached components synchronized to the 1.5MHz timer. This all works create and the game looks, sounds and play already like with the original PCB.

But there is one last issue. The original PCB has a 256x4Bit battery buffered RAM to store high scores and other statistic. The idea is to store these data on the SD card that already contains the settings and the ROM files. Unfortunately I noticed that saving the 256 nibbles take multiple milliseconds and it is a blocking operation. The time itself is not the problem as it would be enough to update the data on the card only from time to time. The issue is that during the safe the emulation stops. We like to avoid this. Based on the code for the SD card it spend most time just waiting for data transfers to be finished. This let me believe that it should be possible to rewrite the SD card code that it runs asyncron.*Have someone tried this before?

In our case it should be enough to just update the same sector every time we want to save an update. Updating the access time in the FAT is not that important. Neither*will the file every change it's size.
 
Yes, but as it updated quite often I am hesitate*to use it as it will wear down and cannot easily replaced. After some more thinking about it I might just move the CPU emulation from the main loop to another timer interrupt*with a lower priority. This way it will not matter if the file io blocks the main loop for a few milliseconds. The emulated CPUs will still run and the DAC updates can still interrupt them.
 
Have you considered using SPI FRAM for this purpose? It’s blazing fast (by Z80 standards), has no issues with wear, uses few pins (all but /CS can be shared with one of the DACs) and is non-volatile. DMA (async) should be straightforward. However, with such a small amount of data being accessed, quickly, you may find that to be unnecessary. Also, you can probably update between DAC writes.
FRAM is expensive for multi-megabit sized parts (~$5-10), but not bad at all for small ones like you’d need.
 
Agreed, FRAM is probably close to an ideal solution. Adding circuitry for reliable early detection of power loss might also allow ordinary RAM to be used and backed up before power goes down.

I have long wanted to put non-blocking write (and read) into the Arduino SD library. In recent times, we're using SdFat, where SD is just thin wrapper for SdFat. I've exchanged messages a few times with Bill Greiman (author of SdFat) about non-blocking APIs. His opinion is a RTOS is the only acceptable solution, where SdFat would still provide a blocking API which waits for the SD card write(s) to complete, but the RTOS would allow other tasks to run during that time. We've had this conversation several times over the years and it's 100% clear Bill will not ever implement or accept a non-blocking API for SdFat. If we ever move this direction, it's going to mean a major fork of SdFat.

But recently we've started a minor fork of SdFat. So far we've only diverged from Bill's code in fairly minor ways, like changing the default config, handling of partitions, performance improvements needed for MTP, and an API to reinitialize which we need for handling media change.

Bill has said he's working on a major redesign of SdFat for RTOS usage, and his most recent commit is titled "Restructure for RTOS use, getName mods, bug fixes".

Whether we merge back with Bill's new & upcoming RTOS-based work or continue on a diverging path is a difficult decision. Whether Bill's RTOS plans will (maybe partially) pave the way for non-blocking functions is unknown at this time.

I do know PJRC definitely does not have the dev time available right now for such a major software project.
 
You must log in or register to reply here.
Back
Top