Uzem ESP8266 Support
Posted: Mon Feb 09, 2015 1:13 am
Ok I worked on this a couple solid days but I have been slacking for a week now. Showing what I have so far will force me to keep focused on this, as I already took a huge detour(Fairchild Channel F emulation,perfect+~fullspeed likely). I am not a hardware guy, and for me to focus on the assembly stuff is a waste of time since it could be done 10x faster/better by Alec/Andrew(Cunning), so what I can contribute is fueled by a strong interest in emulators and sockets programming.
This is very preliminary but it works, albeit very slowly in the current implementation. I implemented partial UART emulation in Uzem and I have a partial ESP8266 emulator core that is working enough to use the chat server. The build attached is very slow and the UART code is under serious surgery to make it faster. I think it should be possible for very fast processors to emulate it full speed when it is done, but I also suspect that it would be practical to run the entire thing in a different thread. I am changing the way the emulation works to be more abstract than the real way UART works on the console. I believe it's important for speed, and I believe we can have this and still function correctly since there are 2 very distinct send and receive pipelines that are not relying on eachother. Right now every time a new UART byte is sent the entire AT Command processor runs, checks if it's terminated and goes from there. What I did in this build just to be fast enough is artificially set the UART to an incredibly slow speed so we don't have to call a function every few machine cycles. I am already changing this over so that, all sent UART data is immediately put into the receive buffer of the 8266 core(respecting time before UART is ready for next char) but the ESP8266 AT core never runs unless a '\n' was just sent since all commands must end with this. The already "fully functional" internet part that receives data packets and puts them on UART could be called every machine cycle if you wanted true emulation of parallel processing(2 chips), or as rarely as you wish. I think it needs to be in another thread for emulation speed and responsiveness to internet data, but it should be very flexible and still work.
That's all I have to say for now, it is what it is, a preliminary implementation. The sockets stuff was pretty easy, the UART stuff getting fast and better/faster command parsing is the only real challenge to complete it. It is not practical or necessary to emulate the actual chip on the module that runs the AT parser+networking stack. Your operating system already handles all the networking stack, you can even "emulate" the module acting as a wireless access point since your computer looks just like a wifi router to the emulator.
To test it, use the very slow build of Uzem with buggy ESP8266, then run the listener.hex and wait for a while. You should see it gets connected to the chat server and names it self listener, if you wait you should see nothing else happen(unless someone else is online). Now, keep that listener running, and also run chatter.hex in another instance of Uzem. You should see there that data went from your home, to uzebox.net in New York, was processed, and sent back as a chat message both listener and chatter will see. Close Uzem and you should see a client disconnect, etc. Pretty cool if you ask me.
This is very preliminary but it works, albeit very slowly in the current implementation. I implemented partial UART emulation in Uzem and I have a partial ESP8266 emulator core that is working enough to use the chat server. The build attached is very slow and the UART code is under serious surgery to make it faster. I think it should be possible for very fast processors to emulate it full speed when it is done, but I also suspect that it would be practical to run the entire thing in a different thread. I am changing the way the emulation works to be more abstract than the real way UART works on the console. I believe it's important for speed, and I believe we can have this and still function correctly since there are 2 very distinct send and receive pipelines that are not relying on eachother. Right now every time a new UART byte is sent the entire AT Command processor runs, checks if it's terminated and goes from there. What I did in this build just to be fast enough is artificially set the UART to an incredibly slow speed so we don't have to call a function every few machine cycles. I am already changing this over so that, all sent UART data is immediately put into the receive buffer of the 8266 core(respecting time before UART is ready for next char) but the ESP8266 AT core never runs unless a '\n' was just sent since all commands must end with this. The already "fully functional" internet part that receives data packets and puts them on UART could be called every machine cycle if you wanted true emulation of parallel processing(2 chips), or as rarely as you wish. I think it needs to be in another thread for emulation speed and responsiveness to internet data, but it should be very flexible and still work.
That's all I have to say for now, it is what it is, a preliminary implementation. The sockets stuff was pretty easy, the UART stuff getting fast and better/faster command parsing is the only real challenge to complete it. It is not practical or necessary to emulate the actual chip on the module that runs the AT parser+networking stack. Your operating system already handles all the networking stack, you can even "emulate" the module acting as a wireless access point since your computer looks just like a wifi router to the emulator.
To test it, use the very slow build of Uzem with buggy ESP8266, then run the listener.hex and wait for a while. You should see it gets connected to the chat server and names it self listener, if you wait you should see nothing else happen(unless someone else is online). Now, keep that listener running, and also run chatter.hex in another instance of Uzem. You should see there that data went from your home, to uzebox.net in New York, was processed, and sent back as a chat message both listener and chatter will see. Close Uzem and you should see a client disconnect, etc. Pretty cool if you ask me.