Where do you see that?
The problem in the original code is that as soon as one byte arrives the code assumes that it can read 4 bytes. So it gets the one and then gets 255 three times.
here.
Serial.println("Got some serial data!");
// read the incoming bytes:
for(int i = 0; i<4; i++){
data[i] = myPort.read();
Serial.print("data[");
Serial.print(i);
Serial.print("] = ");
Serial.println(data[i]);
'data[x] = x (or xxx) \n'
that is between 11 & 13 bytes * 4 + 'Got some serial data'\n
so reception does take time, but for every 4 bytes you send 65 byes or so, filling up the TX buffer completely. Speed wise you will be on par input to output more or less, (given that 9600 * 12 = 115200) but the 16 byte header will cause the TX buffer to overflow if the data stream is continuous, after 4 iterations already..
Anyway it is all very unimportant.
that is so true.
Yes of course, and then all the work starts.
he (that is actually an assumption) will want his code to work using those pins, i should really just quickly check to see if it does on one of my ESp32's I have the facilities set up.
1 Like
That is just a test to see if the data is even coming. You'd never leave that in production code. Even if it does fail after a few transmissions, it would have served its purpose to confirm that data is coming and then be taken back out. Even so, it depends on how often he sends those four bytes. I was assuming that some time would elapse between. If there's no time for the rest of the code to run then the input buffer would be overflowing. Those print statements weren't in the suggested code. That was after he said that it was still not receiving and I wanted to see if it was even sending.
I got all that, but, so was i,... just making sure something should come out. I use the 'if (!Serial.available()) delay(1);' method a lot when dealing with data streams with an unknown (or variable) length. (basically, 'oh something has come in, let's wait and see the complete message. Like waiting next to the fax machine the moment it starts producing the message.)
Anyway on a different point. Pins 12 & 14 should do the trick just fine, i assigned Serial2 to them and have reception and transmission. So just assuming that the hardware is connected properly, what is being sent ?
I did not actually. I just understood that the Header bit from the sensor was supposed to be 0xFF (or 255, according to my hexa-to-decimal conversion lol).
I will try this tonight when i get back home.
This is a great idea, I will also try this if all else fails.
I really appreciate you going through the effort the verify this independently. I wish i could answer your question. I will update you when i have tested further, and in the meantime, any other ideas are very much appreciated.
Regarding the efficiency of the code (as discussed above), At this point all i'm aiming for is to get it working. However, any feedback for keeping the code robust and efficient is appreciated as it gives me pointers of good practice after the communication is established.
Thanks all
Just had another look at the datasheet, so just to make sure, you are powering the sensor with 3.3v, that would mean that there is no need to modify the logic level.
Now the TX & RX lines need to be crossed over. TX ESP -> RX sensor & TX sensor -> RX ESP
I personally have resorted to using lines with a 1K resistor in them for experimentation, which will prevent burning out a GPIO pin in case of wrong connection.
It really wasn't a lot of work, i had almost all of it done already since i have been working on a triple MIDI-merger with an ESP32.
Well, i swapped the tx and rx lines in my code, and results have changed. With the last implemented code change, i get a reading! but it does not change after the initial printout (as in, the values are about the same, regardless of how much room is in front of the sensor)
Actually it does, I've been using it for over a year
Except, Keep this in mind...
When using Arduino Dev Board You use the LIBRARY...
SoftwareSerial which is implemented by SoftwareSerial.h
However when using ESP32 you use the LIBRARY
EspSoftwareSerial By Dirk Kaar, Petar Lerup
it is implemented also by SoftwareSerial.h not EspSoftwareSerial.h
This tends to cause some confusion for obvious reasons
But... SoftwareSerial.h does work on ESP32
ESP32 Dev Module has three UART Ports:
UART0(3, 1) is engaged with Serial Monitor
UART1 is engaged with Flash Memory
UART2(16, 17) is available to the user
1 Like
It is not engaged with flash memory, but the default pin assignment is, but you can assign any pins you like to any of the UARTs.
With UART0 assigned to GPIO 3 & 1, the RX-pin is disturbed by the USB to TTL converter, so if you want to use it to connect it to something other than USB, you should also re-assign them.
#define FORMAT SERIAL_8N1
Serial.begin(BAUD, FORMAT, RX_PIN, TX_PIN)
If begin() is called without these extra parameters, the pin assignment reverts to the default pins. this can be problematic when using a library like MIDI.h which calls Serial.begin() as part of it's own begin() member function.
If I comprae the following two diagrams, I observe that UART1(9, 10) is engaged with Flash memory. However, PPin-28/29 of ESP32 can route five kinds of signal by selection.
Figure-1:
Figure-2:
It depends clearly what you mean by 'engaged'
if you call
Serial1.begin(115200, SERIAL_8N1, 5, 18);
Then pins 5(rx) & 18(tx) are connected to UART1.
I guess UART1 is engaged, but not married !
It is married as long ESP32 is concerned; bucause, the executeable program is loaded into flash memory from which it is taken into RAM memroy and then into the execution unit of the LX6 MPU. Espressif has warned not to play around with six GPIO lines (6 - 11, post #31).
Seriously ? it's not actually 'engaged' with flash memory at all !!
The GPIO pins are. The UART1 has no part in that other than it's default pins are also assigned to those same pins. There is no interaction between the UART1 & the Flash through those pins, in fact the UART1, if actually initiated with those pins will crash the MCU, Therefore, to use that UART, you should re-define the RX & TX pins, and then the UART is useable as normal.
UART1 & Flash are no more engaged than 2 couples sharing the same chapel to get married in. (and doing that at the same time doing a marriage which involves more than 2 people is still illegal pretty much everywhere)
1 Like
Let me clarify (with the help of the following diagram, Fig-1) what I have wanted to mean "UART1(9, 10) is engaged".
1. Fig-2 of post #31 says that signals from five modules (one at a time) can be routed to external devices via physical pin 28 and 29 of the ESP32 MCU. These two pins are found to have programming names: GPIO9 and GPIO10 or simply 9 and 10.
2. In the ESP32 MCU of the ESP32 Dev Module, SW5 is at closed condition and the common GPIO9/10 are connected with Flash Memory. All other switches (SW1 - SW5) are at open conditions.
3. Now, I understand that my wordings "UART1 is engaged with Flash Memory" are incorrect. I should say that "UART1 is not available" as the common sharing lines (GPIO9/10) are occupied by SPI Interface for communication with Flash Memory.
Sorry for the inconveniece caused and it is due to my language limitation!
Figure-1:
What are those number 5 and 18 in the above code? Do they refer to GPIO5 and GPIO18 of the ESP32 MCU?
They refer to them yes, but basically you can assign any available GPIO to be the RX_PIN & TX_PIN of any of the UARTs
Take a look at this example
void setup() {
Serial1.begin(115200, SERIAL_8N1, 3, 1);
delay(100);
Serial1.println("Hello frtom Serial1 !!");
}
void loop() {
delay(1000);
Serial1.println("and again ..");
}
Where GPIOs 3 & 1 are assigned to be the RX & TX pins of UART1. Since UART0 is not initiated, those pins are available, and they are connected to the USB to TTL converter. So opening the Serial monitor will actually show the output from Serial1.
Now i dispute that as well ! GPIO 9 & 10 are not available, but the UART is.
A small disclaimer, this works on the ESP32 dev board that i have, i do not have the possibility to test this on any other esp32 based board and S3 & C3 boards in particular seem to be rather different, still there is no reason for it not to work if those UARTs exist.
It took me quite a while to work out how to actually make use of all 3 UARTs at the same time, and since i wanted to use them as a midi-port each i had to do some more exploring, but i got it sorted.
Your post #36 contains interesting informatiom and is encouraging me to test them.
When you say "GPIO 9 & GPIO 10 are not available, but the UART is" -- I understand that "connections inside the ESP32" are fully programmable and any module's IO teriminals could be routed to any permissible physical pins of the ESP32.
Now, I would like to modify my conceptual diagram of Fig-1 of post #35 as follows (Fig-2). I will test the functionality of UART1(5, 18) Port and will let you know the results.
The scenerio looks logical and some meaningful result will come out. I have now opportunity to explore some hardware details of the ESP32 MCU, which are not readily available in the data sheets.
Figure-2:
1 Like
Ah yes i was wondering where you got that from, but you made that yourself.
Yes, that also goes for the SPI pins, mainly practical for HSPI, which default pins are also having issues for the same reason that the default UART1 pins are not working.
The use of them can be a bit more complex.
towards the end of this tutorial a method is described that works and is at least compatible with SD.h in passing the pointer of the SPI object to the SD object on contruction.
1 Like
I know it works, but i also would want to test it for myself.
The only thing that can not be modified is the actual hardware connections to the physical pins, that goes for the Flash, but also for the USB to TTL converter, which is connected to GPIO 3 & 1. Because of this, GPIO 3 &1 are not really usable for anything else, and using those pins for UART0 when you want to receive signals over the pins (not from USB) also doesn't work for me. Anyway, we are drifting off topic here a little.
By all means, it is an interestimg stuff which I could not even conceive before. This is the beauty of being in the Forum provided people can communicate in a understandable language.
All users including me, when looking into the following pinout diagram of 30-pin ESP32 Dev Module (Fig-1), find that there is only one free UART2. To meet the requirement of another UART Port, they incline to using Software UART Port and face many problems. Here is an opportunity to explore the posibilty of using the sleeping UART1 Port.
Figure-1:
1 Like