Closed forthlightning closed 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?
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
for reference this is what i was looking for:
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.
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.