UART Performance issues with 2.0.2 version

[handmade0octopus]

Board

Not board specific

Device Description

Not board specific

Hardware Configuration

Not board specific

Version

v2.0.2

IDE Name

PlatformIO 4.2.0

Operating System

Windows 10

Flash frequency

80MHz

PSRAM enabled

no

Upload speed

921600

Description

I have been using Platformio 3.5.0 without any issues for very long time.

I tried to moving on to version 4.2.0 based off 2.0.2 but it seems it has lots of underlying problems or it requires me to rewrite most of my code.

I can't share all of it as its quite advanced, instead I will provide you with few insights and code that had dramatic performance issues. I run all code on mostly tasks with priority 4-8 and less important ones being on 3 and 2.

Top is version 3.5.0 of Platformio (I don't know exactly which Arduino version it's based off - sorry).
Bottom is version 4.2.0

Note - I left device to run for 5 minutes to make sure test is fair.

Displays are as follows (starting from left top corner):

• Log speed - is .CSV logging appending the file with ~30 parameters, speed is in rows/second - as you can see on 3.5.0 it was stable and flat and it's jittery on new version (but it does keep up.

• Max heap - I wouldn't worry about this one, but we can see change in max heap and it's much smaller than on previous version.

• RPS - it's "responses per second" - basically I use single wire serial connection (LIN type) to gather data from old typ ECU, here my performance is most important and as you can see it doesn't keep up with it. Maybe my code here is wrong as it's very complicated to provide great stability, but I have been using this one for few years and never has issues before.

It's worth mentioning I am using GPS at 5Hz data rate constantly sending data to my second Serial input.

• Free heap - here difference is huge and I can't believe it's only due to change from 3.5.0 to 4.2.0 - but I can't find any other culprit!

But the worst offender of all is the part of sketch below that I use to transfer data from/to SD card. Below is snippet of function I use to get those performance stats:

Before I managed to get constantly around 71 ms:

[E][Gauge.S.cpp:1536] handleCopyFile(): Time to read /displayConfig.json -     73 ms

But now it's not even funny:

[E][Gauge.S.cpp:1536] handleCopyFile(): Time to read /displayConfig.json -   1466 ms

I think SD card handling may have changed so some sort of guide of how to move to new type of handling files would be appreciated.

Sketch

#define SD_CS 15
#define SD_SCK 14
#define SD_MISO 27
#define SD_MOSI 13
SPIClass SDSPI(HSPI);

// In setup()
void setup() {
	SDSPI.begin(SD_SCK, SD_MISO, SD_MOSI, SD_CS);
	SD.begin(SD_CS, SDSPI, 80000000);
}

// Yes I could have written it better
// It basically transfers files from SD card to flash and vice versa with usage of temp.dat file in case of power failure.

#define COPY_BUFFER 512
#define TEMP_NAME "/temp.dat"
boolean handleCopyFile(const char* nameSource, const char* nameTarget, boolean overwrite = true, boolean toSDCard = false, boolean removeSource = false) {
	#ifdef DEBUG
		uint32_t fileWriteStamp = millis();
	#endif
	uint8_t bufFile[COPY_BUFFER];
	boolean sourceExist;
	boolean targetExist;
	if(toSDCard) {
		sourceExist = SPIFFS.exists(nameSource);
		targetExist = SD_USE.exists(nameTarget);
	} else {
		sourceExist = SD_USE.exists(nameSource);
		targetExist = SPIFFS.exists(nameTarget);
	}
	if(!overwrite) overwrite = !targetExist;
	if(sdReady && sourceExist && overwrite) {
		File sourceFile;
		if(toSDCard) sourceFile = SPIFFS.open(nameSource, "r");
		else sourceFile = SD_USE.open(nameSource, "r");
		if(!sourceFile) return false;
		boolean renamed = false;
		if(targetExist) {
			if(toSDCard) {
				// SD_USE.remove(nameTarget);
			} else {
				renamed = SPIFFS.rename(nameTarget, TEMP_NAME);
			}
		}
		
		File targetFile;
		if(toSDCard) targetFile = SD_USE.open(nameTarget, "w");
		else targetFile = SPIFFS.open(nameTarget, "w");
		if(!targetFile) {
			sourceFile.close();
			if(renamed) SPIFFS.rename(TEMP_NAME, nameTarget);
			return false;
		}
		
		size_t bytesRead = COPY_BUFFER;
		while(bytesRead = sourceFile.read(bufFile, COPY_BUFFER)) {
			targetFile.write(bufFile, bytesRead);
			#ifdef DEBUG
		//	Serial.write(bufFile, bytesRead);
			#endif
		}
		targetFile.flush();
		sourceFile.close();
		targetFile.close();

		if(renamed) SPIFFS.remove(TEMP_NAME);

		#ifdef DEBUG
		log_e("Time to read %s - %6d ms", nameSource, millis() - fileWriteStamp);
		#endif

		if(removeSource) {
			if(toSDCard) {
				SPIFFS.remove(nameSource);
			} else {
				SD_USE.remove(nameSource);
			}
		}
		delay(20);
		return true;
	} else if(targetExist) return true;
	return false;
}

Debug Message

Before on 3.5.0:

[E][Gauge.S.cpp:1536] handleCopyFile(): Time to read /displayConfig.json -     73 ms

Now on 4.2.0:

[E][Gauge.S.cpp:1536] handleCopyFile(): Time to read /displayConfig.json -   1466 ms

### Other Steps to Reproduce

_No response_

### I have checked existing issues, online documentation and the Troubleshooting Guide

- [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[VojtechBartoska]

Hi, there were issues with SD card in 2.0.2.

Please retest this with 2.0.3 which was just released. SD performance issues are fixed there.

Thanks

In general, there are not any performance issue in other parts you mentioned above (as far as we know) and 2.0.2 is out for quite some time.

[handmade0octopus]

In general, there are not any performance issue in other parts you mentioned above (as far as we know) and 2.0.2 is out for quite some time.
Will do once they release on PlatformIO.

You haven't changed how Serial is handled for 2.0? Any other things I can look for for performance bottlenecks?

[SuGlider]

Main difference from Arduino Core 1.0.6 (used in PIO 3.x) to Core 2.0.2 (used in PIO 4.x) is that most Peripherals were refactored to use IDF instead of reading/writing registers directly.

Serial is based on IDF now, but I don't think it is a problem for performance.
Everything is IRQ driven and there may be a overhead of maybe 500 CPU cycles on it, if compared to 1.0.6.

[mrengineer7777]

PIO is still pointing to arduino-esp32 v1.0.6 (very old). Jumping to 2.0.2 is a huge leap, and yes there were issues with SD card that were solved in 2.0.3. Serial did change but no known issues. Try 2.0.3.

[SuGlider]

@handmade0octopus
I guess you use Serial to read a GPS, is it right?
We provide a new API HardwareSerial::onReceive(callbackFunction) that may help your application to get better performance.
It will callback a fuction as soon as data arrives to UART, like an ISR...

[handmade0octopus]

Thanks @SuGlider, any idea about increased heap usage? Do you know what sort of things changed in this regards? Does Arduino 2.0 uses any extra xTaskCreate for its internal use that I may stumble upon?

[SuGlider]

Regarding Heap, we have changed a few configurations for WiFi in sdkconfig file.
There was an issue with Heap left with WiFi when Arduino Core 2.0.0 was compared to 1.0.6.
Not sure if this is your case... Also not sure if PIO has those changes as well...

Look at #5474 (comment) to see a comparation:
PR #5791

Arduino v1.0.6 (v3.3.5-1-g85c43024c) ==> Free memory: 213,900 bytes || Binary Size 692,190 bytes
Arduino v2.0.0 (v4.4-dev-2313-gc69f0ec32 / sha.44c1198) ==> Free memory: 142,228 bytes || Binary Size 734,576 bytes
Arduino v2.0.1 (v4.4-dev-3401-gb86fe0c66c / sha.f459b10) ==>Free memory: 216,140 bytes || Binary Size 645,381 bytes

Comparing V2.0.0 with V2.0.1, this sketch has about 74K extra heap and takes about 90K less flash with the compiled binary.
The numbers are now likely better than it was before with 1.0.6.

[SuGlider]

Regarding UART onReceive() check this #6134 and #6364

[handmade0octopus]

@SuGlider I really try to port my code but its getting harder every second I look.

SD.remove() API has been changed and it requires new things now, I cant use my wifi portal (this may be due to SD card issues).

The heap problem was with the Wifi off (not initiated at all) with wifi on usage is similair fortunately but it doesn't work.

Is there a full list of functions that has been affected so I can go through and fit them? Even some things doesn't display right (one of my lcd.println(string) is affected - but only single one..).

Sorry for my frustration but it seems I am stuck with very old version as trying to find all bugs that update caused it's not feasible.

I understand you had to make some changes to make it easy to port to new IDF versions but it's so strange all the performance issues are worse (can't use 2.0.3 for now so I can't check).

Also I found the issue I had with large flash size - it was BluetoothSerial.h - once I commented it out flash size was exactly the same.

[VojtechBartoska]

@handmade0octopus Just go ahead with 2.0.3. And yes, all the changes are listed in particular releases.

Edit: What is the reason you cannot used 2.0.3? Or at least 2.0.2 with manually check out SD fixes?

[handmade0octopus]

@VojtechBartoska PlatformioIO doesn't support it yet.

Please don't make out of me chooser beggar, I understand how it sounds. I am more than thankful for all hard work you guys do. I am just trying to use it and it saddens me seeing I have to rewrite code I worked for over 2 years on.

SD card isn't the only problem I have, there are many, many more I listed above. I don't know if changing approach on Serial will cause my program to work better, I think those simple read() commands should work as fast as any other - especially that I guard them with Serial.available() everywhere - this just doesn't make any sense to me sorry.

[SuGlider]

I understand you had to make some changes to make it easy to port to new IDF versions but it's so strange all the performance issues are worse (can't use 2.0.3 for now so I can't check).

I'm not expert on PIO, but it seems that there may be a way to setup 2.0.3 in PIO.
It's necessary to change some PIO setup files (I have not tried it...).

Check these links:

#6647 (comment)
#6632 (comment)