espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.01k stars 7.3k forks source link

HardwareSerial Flow Control #123

Closed forthlightning closed 7 years ago

forthlightning commented 7 years ago

Is this something that is currently or will be enabled?

Looking specifically at this usage in esp-idf example.

I had ben using the uart api here, but found it tricky to work with, so switched to the uart-hal functions here. but my sensor is lookin' to control the flow and I see no option to allow it to do its thing.

forthlightning commented 7 years ago

Additional question same topic:

What is the significance of these definitions in the uart-hal?

I see SERIAL_8N1 listed as a default in the HardwareSerial.h library here so that's what I used, not sure why. Are the others listed other configuration options?

me-no-dev commented 7 years ago

these definitions are for bits, stop bits and paring :) I have not written any hardware flow support in the driver mainly because Arduino has no such thing, so libraries would not expect it. Can you think of a test case that I can make to get this tested and added?

forthlightning commented 7 years ago

This is solved! For reference here is how I did it. I used a combination of GPIO api and arduino delaymicros. I'm sure there is an esp-idf handle for microsecond delays but arduinos work for now.

// flow control for MAX485 modbus to serial transceiver
gpio_set_level( GPIO_NUM_5, HIGH );
delayMicroseconds( 500 );  // trial and error setting for proper sensor response
sdm_serial.write( sdmarr, FRAMESIZE - 1 );
delayMicroseconds( 8300 ); // frame transmission length plus some wiggle room
gpio_set_level( GPIO_NUM_5, LOW );
sdm_serial.flush(); // don't continue until all serial data has been sent, for stability
forthlightning commented 7 years ago

for reference this is what i was looking for:

https://github.com/espressif/esp-idf/pull/667

mattncsu commented 5 years ago

I have not written any hardware flow support in the driver mainly because Arduino has no such thing, so libraries would not expect it. Can you think of a test case that I can make to get this tested and added?

Perhaps communicating with LTE modems at high speeds (up to 4Mbps for the SIM7000 (UART design note) might benefit from hardware flow control)

Flow control is very important during the transmission (large data) between the module (DCE) and the terminal device (DTE). When receiving buffer reaches its capacity, the receiving device should be capable of pause the sending device until it overflows. SIM7000 module is designed as no flow control by default, but users can enable this function by AT command.