Notifications
Clear all
Topic starter
2023-02-20 11:19 pm
Hi I have the following code to calculate the FPS on a 128x64 SH 1106 OLED display. When I first initialize, I get a FPS of 31 and it is pretty steady. However, if I unplug the usb from my board and plug back in, the FPS goes to 4. What the heck is that all about?
int FPS;
int fpsCounter;
void printScreen(){
u8g2.setCursor(110,64);
u8g2.print(FPS);
u8g2.sendBuffer();
// get FPS
if ((millis()-fpsTime)<=1000)
{ fpsCounter++;
}
else
{ fpsTime=millis();
FPS=fpsCounter;
fpsCounter=0;
}
}
void setup() {
Serial.begin(115200);
FPS=0;
fpsCounter = 0;
fpsTime=millis();
}
void loop() {
printScreen();
}
2023-02-21 1:03 am
@fishbone
Where's the rest of the sketch ?
You haven't defined or declared u8g2.
You haven't defined or declared fpsTime (has to be unsigned long).
When you unplug USB and plug it back in milliseconds() will restart from 0.
After unplugging, how long does it take to get back to a reasonable FPS ?
Anything seems possible when you don't know what you're talking about.
Topic starter
2023-02-21 2:40 pm
@will It is a pretty long sketch and I thought I would just include the "pertinent" sections. Through trial and error, I found the piece of offending code and it highlights a separate problem I have been having. I want to preface with the fact that I am new to this hobby, so bear with me.
I have been trying to investigate deep sleep and it's use on esp32-C3. One thing I noticed even before looking at this is the serial monitor on my setup seems problematic. I am using platformIO but haver verified the same issues occur on arduino IDE. One of the first issues I noticed was many pf the Serial.print statements in my setup() routine do not show up in the serial monitor. It is almost like by the time the serial monitor connects, the code is through the setup already. I do have the baud rate set to 115200 which is normal for esp32. I have also changed it to other values like 9600 but no good. A lot of my Serial.print statements are "missed" in the setup() (although occasionally it catches some of them). Now when I started to investigate deep sleep the problem got even worse. When my board goes into deep sleep, upon waking the serial monitor does not automatically re-establish. I have to manually close the terminal then open a new one. As you can guess, I miss a lot of data which is supposed to go to the serial port this way. This makes it frustrating since I have no way to know what the behavior of my code is during a wake-up because by the time I get a new terminal up, I am well into loop().
I have on-board JTAG debugging and that is also hampered since once the esp32 goes to sleep, the debugger gets lost and never re-connects.
So how does this relate to my original issues of the FPS? I did leave out a line of code in the loop() that was a Serial.println call which was the only other line of code in the loop. I didn't think this would make a difference with my FPS. However, because of my issues, once the code re-awakens, that Serial.println function somehow drags the code execution speed waaay down (if I comment out this line, FPS is 31 upon waking). I think it is related to the other issues with my seial monitor.
Anyway, still trying to figure it out.
Fish
2023-02-21 3:07 pm
@fishbone First let me say I see nothing unusual in your observations. Indeed the serial port 'misses' lots of data. I never questioned it or was surprised by that fact since day one since it is serial and therefore slow although modern serial devices like USB are quite speedy somehow. As far as startup, I and almost all examples I have seen have either a sleep delay of a few seconds after begin or loop on the status until good. I am not surprised that coming out of deep sleep is also a problem. I have never used that debugger and have done no serious work with PlatformIO (just too busy) since the projects I have done with Arduino etc are far too simple to warrant a debugger. Back in the day when I was debugging 10s, hundreds, even millions of lines of code, I would have loved a debugger but then that would have been too easy.
As far as your original problem, I have no idea how one time it gives one value and another time a different value.
My approach would be to print the involved variables on the serial monitor to see if any of them look other than expected. I am talking about millis, fpstime, FPS, fpscounter. Set the serial monitor to display it's timestamp on every message as well, then you can use those timestamps to calculate what your millis should produce etc etc etc.
Good luck
What happens if instead of unplugging, you just press the reset switch ion the board?
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-21 4:26 pm
@zander Ron:
I see this tutorial presented by a bunch of different people https://randomnerdtutorials.com/esp32-deep-sleep-arduino-ide-wake-up-sources/
Here you can see they run a subroutine print_wakeup_reason() fairly early in the setup. I have the same subroutine in my code, but I rarely ever see this printed (sometimes if I open a new terminal window at just the right time I can catch it). Come to think of it, in this video
the gentleman uses "log_W" instead of "Serial.println". He seems to be using a different terminal app all together or is that just the arduino IDE opened in a different window? At any rate, his monitor seems to be catching everything.
Hmmmm.....
2023-02-21 4:43 pm
@fishbone Ok, now I learned something. Set your Preferences to 'Compiler warnings ALL' as in pic below now change the serial output that wasn't showing up to be log_w(etc etc)
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
2023-02-21 4:58 pm
@fishbone I just ran the RandomNerds sketch from the link you posted above. Here is a sample of the output I get using an ESP-WROOM-32 but my selected board is a DOIT, see pic2. Do you see anything different when running this sketch?
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-21 5:08 pm
@zander Ron: Nice one...i'll try it when I get home tonight ... but that is a lot different to what I was getting.