At this point, the implementation of SdFat was completed, the remaining RAM1 was over 30k, and the efficiency of memory consumption was dramatically improved. The modifications made were from steps 1 to 5, which are described below, and at that stage it was not possible to read out the JPEG file.

Perhaps the communication speed of the microSD was too fast, but at the beginning, errors occurred frequently during read and write operations. We have inserted a delay(); element as part of our error countermeasures, but so far we have not observed any problems.

This time, I will rearrange the code by referring to ExampleCode of GFX for Arduino and JPEG image viewer example.

The steps to switch from SD.h to SdFat.h are as follows.

(1) First, include SdFat.h.　

include 〈SdFat.h〉.

(2) Next, declare the SdFat object and the SdFile object that handles files.

SdFat sd;
SdFile sdFile;

(3) Specify the microSD mount location.　

If Teensy4.1 is selected as the MCU, it is assumed that BUILTIN_SDCARD is specified. However, the SD.h file automatically recognizes it, but in SdFat, “10” must be specified.　　

(4) Also, the initialization described as if (!SD.begin(chipSelect)) { return; }

define SD_CONFIG SdioConfig(FIFO_SDIO) / if (!sd.begin(SD_CONFIG)) { return; }

The connection with SD_CONFIG guarantees a faster transfer rate than the single-line SD.h because the data lines are duplicated.

Note that if (!sd.begin(chipSelect, SPI_HALF_SPEED)) { return；} is written, the file is not read out for some reason.

5) Rewrite SD.open() to sd.open() to accommodate SdFat, which has a different command specification.

The above changes are made on main, but the next phase is to modify the file processing functions.

(6) Since SdFat uses a different API for file processing, the functions on JpegFunc.h,

jpegOpenFile, jpegCloseFile, jpegReadFile, jpegSeekFile

need to be changed to work with SdFile.

7) The error (‘JPEGDRAW’ was not declared in this scope) at this point indicates that the JPEGDRAW type is not recognized by the compiler, but this type is defined in the JPEGDEC library. As a remedy, include the JPEGDEC library.

(8) The next warning “FILE_READ and FILE_WRITE are redefined” can be solved by using the SdFat library definition consistently.　When using SdFat, the inclusion of the FS.h file present in the Teensy core must be avoided.　As a countermeasure, remove or comment out the inclusion of FS.h described on JPEGDEC.h.

Teensyduino has dedicated hardware-optimized libraries, but AI suggests that the corresponding parts are not replaced when the libraries are updated, and as a result, conflicts may occur from the libraries standing side by side.

‘SD’ was not declared in this scope is an error that occurs because the SD object is not defined in the sketch, and the cause is the jpegOpenFile function in JpegFunc.h.　I was able to address this by replacing the call to SD.open() with the SdFat specification.

We have been operating the system with the optimized firmware uploaded for about 8 hours and have not found any problems at this point.

Additional note:

When SD_CONFIG is specified, it is possible to exchange data with micorSDslot implemented in Teensy4.1 on 4 lines.

The code modification I made this time improved the consumption of RAM1 by almost 1K for some reason.

I was able to use the latest version of JPEGDEC.

GFX seems to have changed a lot since the last version, and compatibility is not ensured.

It seems that Teensyduino has a peculiar quirk that prevents direct external updates to the libraries included in the package.

It has been found that when SdFat is removed from the Library folder, ArduinoIDE no longer recognizes SdFat.

In fact, the original library optimized for Teensyduino was stored, and its version was 2.1.2.

In any case, the customized SdFat library should be prioritized, and it may be foolish to update it so easily.