Uzenet

[D3thAdd3r]

Alec, I suppose a likely culprit is the overclocking here but I wonder if the same problem happens at 19200 baud. I found this thread and it seems much like what we are seeing. If it is the same issue a very simple low pass filter on the Rx pin could help.

[uze6666]

Funny how the thread goes back to this forum! Not sure if it's related to our problem but it looks like those constant video glitches I had on the 1284p when receiving MIDI in data (or was it the 644P?).

I have no idea why the low pass thing would work but we can always try. Thing is, I need a test that can generate the glitch more often since it happens so rarely. I only noticed one since the beginning.

[D3thAdd3r]

I've got quite a bit of functions tested out so far and I'm writing up a tutorial, seriously, it will not be difficult to add networking to games. That being said, for performance reasons it really is critical we get this fixed I see now. Checksums will do the trick, but it really kills the performance of packet receiving since we can't make assumptions that all bytes next frame will be correct, and of course you couldn't as easily process a packet bigger than the Rx buffer without yet another separate buffer and a reliability system for resends(since TCP doesn't care about the UART problems). Uzenet will still work out if we can't fix that, but I can already see this is a bigger problem causes more trouble than I thought. I will try to make a test program to trigger the problem, that plays a sound when it happens so we can see what could help here.

[uze6666]

That being said, for performance reasons it really is critical we get this fixed I see now. Checksums will do the trick, but it really kills the performance of packet receiving since we can't make assumptions that all bytes next frame will be correct

Are using UDP so far?

Also, yesterday I completed the TX buffer part. I had to rewrite the RX part and fuse it with the new TX code for simplicity. Only thing is a have an annoying bug where sometime it seems I loose a character! Except this time I'm pretty sure it's software. I suspect a race condition is screwing things. Perhaps the RX had the same bug? We'll see as I troubleshoot.

[uze6666]

Ok, fixed the TX bug, was a weird race condition. I rewrite it is another way to avoid the issue. Rewrote RX code also, so perhaps we won't the problem again. I did not notice any char lost so far on my side. Only remaining thing is that sometimes the module will return a "ERROR BAD SYNTAX" kind of error when sending lots of messages. Could it be due the the fact I concatenate the command with the message without waiting for the ">"? Dunno. I'll make more tests on that.

In the mean time, I have commited the changes and the updated uzenet project. Let me know if it compiles on your side.

[CunningFellow]

So bug was more involved than just _volatile ?

[D3thAdd3r]

Great work on the Tx buffer Alec, I am utterly swamped with non-fun tasks lately but I will try to compile it and report back. I'm interested in this race condition also, as when I hear race I think of multi-threading on some level. Was it something to do with UCSR0A reporting data is ready slightly earlier that it actually made it to UDR0? I'm glad you figured it out and since you suspected that on both maybe you killed 2 birds with one stone.

Only remaining thing is that sometimes the module will return a "ERROR BAD SYNTAX" kind of error when sending lots of messages.

It's weird if concatenating should matter but I'm waiting on some 644's before I'll have hardware running again so I can't really help. I wonder if all these problems go away at slower speeds? Also is there a possibility that the 8266 really isn't getting one of the bytes correctly when it says ERROR since the only one who would really know it was sent correctly was the 8266? I guess you could hook Uzebox up to a FTDI cable. I agree we need to find a method to reproduce these things, at least then a scope should show where it's going wrong.

BTW what happens if you "ATE1\r\n" then while(1){ "AT\r\n"}? An echo test seems the best way to see problems on either side.

[D3thAdd3r]

Are using UDP so far?

I've only done TCP on Uzebox. Documentation is conflicting on how to listen for UDP packets so I don't have it implemented in Uzem yet. Direct uzebox<->uzebox UDP would be the best performance, but I am going to get TCP through server done up in the API and documented down to a science first, since that will be more commonly used. I am reading about, possibly, some limitations that might not allow simultaneous UDP/TCP. Then you have to make your own reliable stream(if there is any one shot data that must be received)which is not trivial to do right, but can be better performance at the cost of using more bandwidth. Kind of like 16k of inline code in a way, except some of the instructions might never happen. I want to do Megatris TCP for an easier tutorial, but I might even change it to UDP afterwards for the UDP tutorial to compare. Megatris reliable UDP system is an easy case. Of course it will probably be 6 months before I really complete all the stuff I say is "easy"

(since TCP doesn't care about the UART problems)

If I didn't make sense there, and you probably know this, what I mean is if the TCP/IP network stack on the actual 8266 gets a packet, and it's good then, it moves on and doesn't look back. The network stack on the chip has no way to know that good packet data got corrupted over the UART, so with that UART glitch, TCP in practice was not a 100% reliable stream. Both TCP and UDP guarantee that any packet you actually do get to your program will be perfect(or else it would be silently discarded, and auto-resend for TCP case)

PS-Alec I can't see the Tx buffer code on SVN

[uze6666]

PS-Alec I can't see the Tx buffer code on SVN

An error happened during commit that I did not see. Try again, it's there now.

I guess you could hook Uzebox up to a FTDI cable.

Yes, I use that a lot to troubleshoot. I made myself a small board with the EXT connector, the FTDI connector and ESP8266 connector. So I can selectively intercept transmits for either the Uzebox or 8266 and send them to my PC terminal.

BTW what happens if you "ATE1\r\n" then while(1){ "AT\r\n"}? An echo test seems the best way to see problems on either side.

Will try this.

[uze6666]

So bug was more involved than just _volatile ?

Yes, some silly design of mine. For some reason I decided to add a "buffer depth" variable in the ring buffer. Naturally this variable has to be increased by the main program and decreased by the interrupt. Bad idea. Even though I could not nail it completely, I'm pretty sure the problem was due to a race condition of some sort on that buffer depth variable. Now it's implemented with just tail/head cursors and work fine.