ESP8266 Community Forum

- Sat May 21, 2016 8:39 am #47764 I'm trying to understand the exchange of simple data over UDP. I'm running a UDP sender on my Android, and manually send random strings thru it.

On the ESP, I have this minimal code running:

Code: Select all udpbegin 1234

[init]
let x = udpread()
serialprintln x
if x == "x" then  goto [getMeOutOfHere]
goto [init]

[getMeOutOfHere]
wprint "<a href='/'>Menu</a>"
udpstop
end

Now, 2 inexplicable (to me) things happen.
1) The string that I transmit keeps repeating on serial the terminal, till I transmit a new one. At which point the new string keeps repeating.

2) 'x', which I was hoping to act like a terminator, does indeed exit the program. BUT, when I re-run the program, it immediately comes out of the loop having received an 'x', from somewhere. This behavior ceases only after a reset of the ESP. I wonder where it gets the last 'x' from?

I imagine its a matter of flushing variables, but I have no idea how, or where.

Any ideas, guys?

- Sat May 21, 2016 12:41 pm #47772 If you are trying to understand the udp data exchange, I think you will find things much easier if you forget about your random android sender and serial monitor, and just use cicciocb's udp debugger instead, which will leave you in total control and without any other variables to confuse matters.
https://github.com/cicciocb/UDP_tester/blob/63bf7f5500e27cc9a8509326ad41636ecfb99d5e/UDP_tester/bin/Debug/UDP_debugger.exe?raw=true

Once you've got that working ok - which is very straightforward - then you can expand things to include whatever else you like, but at least you will be starting from a known good base.
For similar reasons, start off by using port 5001, which his debugger is using by default, then change things later once you know what's what.

Your biggest problem is you don't even have a 'wait' instruction, so the branch on udp interrupt is not going to work. The key thing for you to get your head around is that all 'interrupty' type things need to 'wait' for an interrupt event else the event won't ever happen. So you shouldn't be looking for an incoming variable and then jumping back up to the top of the same routine to read the next one - you 'wait' at the bottom of the routine for the interrupt, which will then automatically re-read each new event as it happens, like this...

Code: Select alllet udpport = 5001
udpbegin udpport
udpbranch [udpmain]
wait

[udpmain]
let msg = udpread()
udpreply "Msg received=" & msg  'it will be obvious in the debugger receive window when a msg is received
if msg == "whatever" then gosub [wherever]
wait

[wherever]
'do something
wprint "done something <BR>"  'but you won't see this until you refresh your browser (F5)
return


Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat May 21, 2016 5:47 pm #47784 Thanks for that information. The UDP_tester looks like a great tool. Incidentally, there's another, newer version of that at https://github.com/cicciocb/UDP_tester/ ... OpO7D.dpuf

Also thanks for the example code.

Reagrds.