UART Communication problems at 921600

ESP_Faye
Posts: 20
Joined: Thu Dec 10, 2015 6:47 am

Re: UART Communication problems at 921600

Postby ESP_Faye » Wed Nov 13, 2019 7:00 am

Crypth wrote:
Mon Nov 11, 2019 5:23 pm
Is there any chance the AT library will end up open to the public?


Sorry that AT lib is not open source, and maybe it will not change to open source in the future. Sorry for the inconvenience.

ESP_houwenxiang
Posts: 98
Joined: Tue Jun 26, 2018 3:09 am

Re: UART Communication problems at 921600

Postby ESP_houwenxiang » Thu Nov 14, 2019 7:40 am

LukeSkyWire wrote:
Wed Jun 20, 2018 11:05 am
What I have noticed however is if I send 1400 bytes the uart_read_bytes returns a value in the range of 1390.
If I send 600 bytes I get a len of approx 596.
Hi, LukeSkyWire

Have you enabled hardware flow control? At 1M baud, the CPU can read out the data in fifo in time. But At 2M baud-rate, the CPU cannot read out the data in fifo in time, resulting in data loss. When enable the flow control, the baud-rate can reach 5M.

thanks !!
wookooho

Crypth
Posts: 2
Joined: Tue Oct 29, 2019 12:24 pm

Re: UART Communication problems at 921600

Postby Crypth » Thu Nov 14, 2019 5:06 pm

ESP_Faye wrote:
Wed Nov 13, 2019 7:00 am
Crypth wrote:
Mon Nov 11, 2019 5:23 pm
Is there any chance the AT library will end up open to the public?


Sorry that AT lib is not open source, and maybe it will not change to open source in the future. Sorry for the inconvenience.
That's all right with me if we could get it working without errors in the uart communication.

I'm in the process of setting up HW control.
When compiling IDF and AT with 8,0,1,3, it doesn't seem to change anything at all. It chatters like it's not set after a reset.
When we send the UART_CUR command with HW control, the behavior changes radically.
Are we supposed to change the HW control on the host side after we send the UART_CUR changes to HW control, not from start?
IoT hacking all night long.

Who is online

Users browsing this forum: Google [Bot] and 19 guests