Hi all,, I have a ESP32 triggering interrupts on both High and Low incoming 70uS pulses which are being timed. (OBD) The interrupt routines are quick, so in a loop I am able to process the times, and Everything works great as long as I keep loop times quick too, before next interrupt... Now here is my problem: I was outputting my results with " serial.println(xxxx); " and I see everything fine on a pc serial monitor.. So I decided to use Bluetooth as opposed to serial cable... Now output can't keep up... The only difference is I print "serialBT.println(xxx); instead of "serial.println(xxxx);" So I'm looking for an educated guess as to where to start looking for the problem.. -PC- Bluetooth program I wrote, Bluetooth Speed in general, or Esp32 instruction cycles for prints... I can't publish codes, But any thoughts on where to look would certainly be appreciated... Ahhh
What's good with making a guess? If you are capable of fixing the problem(s) based on a guess, you would not be here.
It probably depends on how you are using Bluetooth with the ESP32, but since your not prepared to share the code, I would not be guessing.
Ok, since this is a guessing game... SerialBT is just slower than Serial. Probably why it now loses the race. If you are trying to print inside the interrupt.... Probably a bad idea. If you are just capturing and storing data in the interrupt and then processing that data outside the interrupt you might be ok. If you are doing that and still failing, you might try using Core 0 to print the data. Arduino code runs on Core 1 on the ESP32. You could push the SerialBT printing task off to Core 0. Take a look at how Main is written to run both Setup and Loop. I have successfully pushed some tasks to Core 0 to work in the background while other Arduino code is running on Core 1, like OTA updating and watchdog timing. Is this just for debugging or is the printed data part of your main purpose for the code. Be sure you don't collect it faster than you can dump it. I'm out of guesses and time I want to spend speculating. Good luck.
Well, Thank you guys,, wzaggle, no, not printing from interrupt... but because I only have a window of 60uS min to 128uS max to inturprit the pulse time as a 1 or 0, then make a byte out of 8 pulese then print that byte of data. I do have a window of 200uS (SOF)between next stream of pulses that I also use in the loop to get the job done, it's timing, I basically have 2 interrupt pins tied together, one triggers a timer on rising, the other triggers timer on falling this works good and with no clashes.. So now I process the high time during low trigger and low time during high trigger in a loop.. I simply add a 4050 cmos chip to buffer the input, of the interrupt pins to Vehicle OBD port. Now the timing of Highs and Lows gives a binary 1 or 0... 8 of them gives us a byte to print out, to those not familiar with vehicle OBD, a low or High is not 0 and 1, its how long a time of the pulse that determines 1 or 0... So If I print to a serial port everything works, I can even decode the header bytes to show source and Target destinations etc of OBD, as opposed to the hex bytes of obd.. But when I try to send same data over bluetooth it misses bytes that should have been printed.. I think you might have something with using both cores wzaggle, I will try that, but its a shame if I have to Reprogram, only to find bluetooth is just is not fast enough.. I could turn to math and try to figure that out but on paper that never works out in reality.. One other thing,, in Bluetooth mode, reading on PC with Putty, Realterm, and a terminal I wrote, all give different data...??? for same input... Thanks
To those wondering about the code,,, I have no problem with posting it, But in order to make sense of it you would need to be a electronics engineer as well as understand a vehicles OBD port, the program jumps around using micro Seconds to get the job done. And without other knowledge of why,, a programmer would have more questions than answers...