Hi @Delta_G,
Thanks for the detailed analysis and insight into UNO R4 WiFi Serial. I also found the following your posts are very interesting.
- The R4 Serial Problem
- How about DMA Serial?
By the way, let me ask a very basic question here.
I tested the following code, which is similar to the code in post 1 about Minima's Serial and Serial1.
(I corrected the spelling gimbel to gimble 
)
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
bool t = !Serial;
while (!Serial);
#ifdef ARDUINO_UNOR4_WIFI
delay(1000); // It requires at least 600 ms to complete Serial initialization.
#endif
Serial.println("\n** Serial Speed Test **");
Serial.println("!Serial = " + String(t));
uint32_t start = micros();
Serial.print("Twas brillig and the slithy toves did gyre and gimble in the wabe.\n");
uint32_t finish = micros();
Serial.println("Total Time : " + String(finish - start));
}
void loop() {}
The results in microseconds were:
Those were similar your results:
My understanding is that both Serial1 in Minima and Serial in WiFi use UART class. And also Serial in WiFi is connected ESP32-S3 which bridges between usb and serial. It means Serial in WiFi go through the level translation IC:
So the first question is: My understanding is right?
On the other hand, in the following schematics, WiFi would be able to connect directly to USB by setting P408 to HIGH.
Second the question is: Did you find any code that sets P408 ?
I think the relation between RA4M1 and ESP32-S3 causes some issues that are found at Firmware update fails if Serial Monitor/Plotter is open #2060 and Display output from Arduino Firmware Uploader #2220.
Thanks in advance.
Yes, I just started reading the long thread.
Thanks for sharing those links.
Hi @Delta_G ,
I tested your code at post #8 (except adding delay(1000) before Serial.println("\n\n *** " __FILE__ " ***\n\n");) and I've got different results from yours. i.e. No letters are missing.
Here's Serial:
And Serial1:
What is the difference between mine and yours? The UNO R4 WiFi board? The firmware on ESP32-S3 (0.4.1)? The PC (mine is a Mac)? The IDE (ver. 2.3.2) ? Or the USB cables?
In fact, I have experienced the phenomenon where the last character of consecutive Serial output characters is missing with my UNO R4 WiFi. However, I am not able to reproduce it at the moment.
I copied & pasted your code at post #16 . No letters are missing.
Here's result of Serial1:
I haven't done any modifications or compiling, just using the official IDE out of the box.
I attach Serial.cpp at /Users/myname/Library/Arduino15/packages/arduino/hardware/renesas_uno/1.2.0/cores/arduino in my MacOS.
Serial.cpp (11.2 KB)
I also tested the same code post #16 with my Minima. And the result was same as post #17.
Your modified version looks just like the PR on GitHub Modify UART Class to Make Use of the txBuffer #304.
You already let me know! So you have to debug your PR.
I think your suggestion using DMA is so great, but the Arduino team doesn't seem to like it very much, right?. I also expect your PR #304, but will it be difficult to resolve some sort of conflict race condition?
I agree with you. I personaly prefer DMA rather than FIFO. Using new MCU technology is necessary for the healthy development of Arduino.
However, the problem is that the Arduino development team doesn't want to touch FSP. This is because I think it will be difficult to maintain FSP when it is upgraded.
On the other hand, if FSP adopts FIFO or DMA, they will have no choice but to adopt it.
Just my opinion, but how about discussing about this on the Renesas forum?
Edit:
This is just my idea, so please don't take it too seriously. There is a feeling that Arduino is looked down upon in the Renesas forum, so I think it will not work unless you discuss it carefully.
Is there any way to improve PR #304 instead?
I'm sorry but my understanding can't keep you up.
In my experience, sending 512 bytes of data is sufficient when sending binary data, and 1K bytes of data is sufficient when sending escape sequences for screen control.
Considering the size of the SRAM, I don't think we can send that much data.
Maybe it's off-focus, however for example, I want to make sure that Serial.availableForWrite() and Serial.flush() work correctly depending on the secondary buffering behavior.
