ESP8266 Community Forum

- Mon Sep 12, 2016 8:39 am #54948 I have to receive chr$(0). I received hex characters one by one with Serial.read.chr () and is working but I have a problem, it is very slow. To receive 48 bytes the delay is 38 seconds. I have to receive 500 bytes.
The baud rate used is 115200
Is possible to improve this delay?

- Wed Sep 14, 2016 5:38 am #55083 If you could post the relevant part of your code up, perhaps someone may be able to suggest a faster way of doing things. I'm no expert but are you reading bytes to avoid a byte containing binary 0 being seen as a string terminator - in other words you need to be able to read raw data, rather than something that's been processed?

How do you decide when it's at an end- is it exactly 500 bytes, or do you have some sort of separator?

Without seeing it, in general terms once you know something has arrived a bit of a wait then grab a chunk is usually quicker than fetching individual bytes. 500 bytes of raw data at that speed should only take about a 20th of a second to arrive if loaded to the wire at transmission rate. Smartmeter? Do you need to capture cr/lf as raw data too?

- Sat Sep 17, 2016 6:51 pm #55305 Thank you for your response.

The code for test the device is:

cls
memclear
dim cmd(25)
baudrate 115200
serialflush

cmd(0)=hextoint("55")
cmd(1)=hextoint("AA")
cmd(2)=hextoint("24")
cmd(3)=hextoint("01")
cmd(4)=hextoint("02")
cmd(5)=hextoint("00")
cmd(6)=hextoint("01")

for j=7 to 21
cmd(j)=hextoint("00")
next j

cmd(22)=hextoint("27")
cmd(23)=hextoint("01")

for k=0 to 23
serialprint chr(cmd(k))
next k

delay 100
timeini = millis()
cant_car = 0

[serialin1]
timeini1 = millis()
cant_car = cant_car + 1
bla$ = Serial.read.chr()
dat = asc(bla$)
dat1$ = upper(hex(dat))
if len(dat1$) = 1 then dat1$ = "0" & dat1$
delayed = millis() - timeini1
wprint "Hex Code received: " & dat1$ & " - delay: " & str(delayed) & " msec"
print
if serial.available() <> 0 then goto [serialin1]
print
delayed = millis() - timeini
wprint str(cant_car) & " characters in " & str(delayed) & " msec"
end


The response from the device and delays are:

Hex Code received: AA - delay: 325 msec
Hex Code received: 55 - delay: 322 msec
Hex Code received: 24 - delay: 323 msec
Hex Code received: 01 - delay: 325 msec
Hex Code received: 04 - delay: 325 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 324 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 00 - delay: 328 msec
Hex Code received: 00 - delay: 325 msec
Hex Code received: 00 - delay: 326 msec
Hex Code received: 28 - delay: 324 msec
Hex Code received: 01 - delay: 125 msec
24 characters in 14051 msec
Done.

I sent 24 hexadecimal characters very quick but to receive 24 characters in 14051 msec is very slow.

Any idea how to reduce the delay?

Thank you

- Sun Sep 18, 2016 6:09 pm #55358 First question i'd ask is, are you sure the transmitting device isnt responsible for the delay? Have you tried sending a similar length byte sequence via a terminal emulator?

I suspect you're going to say you have, and it was the same...

Basic is actually doing quite a lot behind the scenes, and the chip uses about 20% of available processor to support wifi stuff.

To help narrow it down between execution times generally and serial specific, can i suggest you perhaps simulate the read and see how long your loop takes to execute?

Guioff and wifioff commands may reduce some of the overhead.
You might use the serial.available to see how many bytes are queueing.
Try taking out the print command if the number queing is low - it eliminates the possibility that data youre sending on the serial port is triggering receipt of next byte.

Remove all but the check for available and the char read. See how fast it runs then.

Try serial.read.int, if you havent already.
I have some thoughts i need to formulate, feel a feature request coming on...