Sweet! Thank you. So it seems I need the MCP1700-3302E/TO 3.3V regulator and two 1uf capacitors if I read that schematic correctly. I don't see a BOM for any of these anywhere, but I think I've got that right. Please let me know if I don't!Jubatian wrote: ↑Sun Aug 26, 2018 12:19 pm I believe you will need those. The SPI RAM, which is normally the other device on an Uzenet card, works fine without any extra parts. A bit of looking around revealed this: ESP8266 on the Wiki, they are responsible for the 3.3V the ESP8266 needs. So most likely in your current setup, the ESP8266 isn't even powered.
At least it isn't a bad solder then!
Uzenet
Re: Uzenet
Re: Uzenet
Definitely need the regulator and caps. Also keep in mind there are a ton of different firmware versions floating around. Off memory, the F ones that I have seen all come with an AI Thinker firmware that plug and play work with UzenetDemo..maybe. Different firmwares can have different default baud rates, response syntax, which might need changing. It can be a headache, and I believe the F revision is the best of several I tested.
I am trying to find the alpha version of "UzeNet Setup Utility" on one of these PCs which auto detects any baudrate then sets a known one and performs a WiFi list and setup. I am packed up for moving, so I may not be able to find it depending what PC it is actually on
I am just glad someone else is really interested in UzeNet, I am jumping back on it!
I am trying to find the alpha version of "UzeNet Setup Utility" on one of these PCs which auto detects any baudrate then sets a known one and performs a WiFi list and setup. I am packed up for moving, so I may not be able to find it depending what PC it is actually on
I am just glad someone else is really interested in UzeNet, I am jumping back on it!
Re: Uzenet
I got it working I scavanged the C16 and C20 capacitors from a broken uzebox I had along with the IC1 chip and put then in my newer, working uzebox. The uzenet demo works like a charm.D3thAdd3r wrote: ↑Sun Aug 26, 2018 5:26 pm Definitely need the regulator and caps. Also keep in mind there are a ton of different firmware versions floating around. Off memory, the F ones that I have seen all come with an AI Thinker firmware that plug and play work with UzenetDemo..maybe. Different firmwares can have different default baud rates, response syntax, which might need changing. It can be a headache, and I believe the F revision is the best of several I tested.
I am trying to find the alpha version of "UzeNet Setup Utility" on one of these PCs which auto detects any baudrate then sets a known one and performs a WiFi list and setup. I am packed up for moving, so I may not be able to find it depending what PC it is actually on
I am just glad someone else is really interested in UzeNet, I am jumping back on it!
The default baud rate of my module is set at 115200, but as you said, that can't be relied on. I've attempted to cycle through the available baud rates to see which one returns a 'ready' response so I can dynamically adapt the baud rates without making any assumptions about the firmware. I can't get that working though, and I'm wondering if my approach is wrong here. I paste the algorithm here:
Code: Select all
int initWifi(){
u8 bauds[5] = {185, 92, 46, 60, 30};
s8 i = 0;
int result;
UBRR0H=0;
UCSR0A=(1<<U2X0); // double speed mode
UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
DDRD|=(1<<PD3);
PORTD&=~(1<<PD3);
WaitVsync(1);
PORTD|=(1<<PD3);
do {
UBRR0L=bauds[i];
result = wifiWaitForStringP(PSTR("ready\r\n"),NULL, 2*60);
i++;
} while ((result != WIFI_OK) && (i < 5));
return result;
}
Re: Uzenet
Nice!
It has been a while and I can't find the code. My guess from my memory is it is possibly a timing issue, buffer overflow, or the ESP8266 interpreting commands differently than you want(due to ESP8266 timing). I think that firmware should show "ready\r\n" as the last thing it does after bootup, but if it was previously setup for WiFi it might say something like "WIFI CONNECTED\r\n" after a few seconds, potentially overflowing the "ready\r\n" in the Rx buffer before the next check. Originally I had done some different methods that were rather slow and unreliable for finding random baud settings, but I believe I finally settled on spamming "AT\r\n" and rapidly checking for "OK\r\n". So in the inner loop I think it is worth a try to just send out "AT\r\n" several times with a small delay. Due to timing, it might receive something like "T\r\nAT\r\n" a couple times if it is busy and spit out an error, and get confused, so with some very small delays and playing around, there is some perfect mixture that will find any baud setting in about .75 seconds. Ultimately I think that is the best way, then to set it to a known baud rate.
In my mind the best path would be to set a default rate of 9600 baud so that every Uzebox game knows to start there(since 9600 baud is plenty sufficient for many things, and it limits the precious ram cost of buffers). Defaulting to 115200 would potentially require a buffer some games couldn't afford even enough to get it set to 9600(missing rapid responses at 115200). I found that getting it to such a known state, there are a ton of assumptions you can then make in the logic with a bit of timing, and send out the stream of commands with a grand error check all at the end to make sure it worked. To check every possible thing gets slow due to longer than necessary delays, or otherwise has a bunch of very specific checks for amount of chars in the buffer, time elapsed, etc.
Re: Uzenet
Awesome, that strategy works perfectly I ended up adapting my local copy of the uzenet demo with the below algorithm that includes the AT spamming to determine baud rate, and then explicitly setting the baud rate to what I want to. (I also updated the send-and-wait commands to take timeout parameters)
Code: Select all
const u16 bauds[] PROGMEM = {246,184,92,60,44,30};
int initWifi(){
s8 i = 0;
int result;
UBRR0H=0;
UCSR0A=(1<<U2X0); // double speed mode
UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
do {
UBRR0L=pgm_read_byte(&(bauds[i % 6]));
WaitVsync(1);
result = wifiSendCommandAndWait(PSTR("AT\r\n"),PSTR("OK\r\n"), 30);
i++;
} while ((result != WIFI_OK) && (i < 12));
if (result == WIFI_OK) {
result = wifiSendCommandAndWait(PSTR("AT+UART_CUR=76800,8,1,0,0\r\n"),PSTR("OK\r\n"), 2*60);
if (result == WIFI_OK) {
UBRR0L=pgm_read_byte(&(bauds[4]));
WaitVsync(1);
}
}
return result;
}
Code: Select all
//initialize UART0
UBRR0H=0;
//http://wormfood.net/avrbaudcalc.php
//This is for single speed mode. Double the
//values for UART double speed mode.
//Baud UBRR0L Error%
//9600 185 0.2
//14400 123 0.2
//19200 92 0.2
//28800 61 0.2
//38400 46 0.8
//57600 30 0.2
//76800 22 1.3
//115200 15 3.0
EDIT: Yup, got my c addressing wrong as I suspected I was incrementing by two bytes instead of one to get the high byte from my array values. I needed to cast to an 8 bit pointer first. Fixed code is below with correct handling of high and low bytes and support for 9600 baud rate. Sorry for the long message!
Code: Select all
const u16 bauds[] PROGMEM = {370,246,184,92,60,44,30};
int initWifi(){
s8 i = 0;
int result;
UCSR0A=(1<<U2X0); // double speed mode
UCSR0C=(1<<UCSZ01)+(1<<UCSZ00)+(0<<USBS0); //8-bit frame, no parity, 1 stop bit
UCSR0B=(1<<RXEN0)+(1<<TXEN0); //Enable UART TX & RX
do {
UBRR0L=pgm_read_byte(((u8*) &(bauds[i % 7])));
UBRR0H=pgm_read_byte(((u8*) &(bauds[i % 7]))+1);
WaitVsync(1);
result = wifiSendCommandAndWait(PSTR("AT\r\n"),PSTR("OK\r\n"), 30);
i++;
} while ((result != WIFI_OK) && (i < 14));
if (result == WIFI_OK) {
result = wifiSendCommandAndWait(PSTR("AT+UART_CUR=9600,8,1,0,0\r\n"),PSTR("OK\r\n"), 2*60);
if (result == WIFI_OK) {
UBRR0L=pgm_read_byte(((u8*) &(bauds[0])));
UBRR0H=pgm_read_byte(((u8*) &(bauds[0]))+1);
WaitVsync(1);
}
}
return result;
}
Re: Uzenet
Sweet, you are armed to start networking then!
Re: Uzenet
I decided to bite the bullet and try updating the firmware directly via the UART port. I'm suprised that it was relatively easy in the end. You need a FTDI232 USB-to-serial cable and use their tool. So I installed the latest and greatest AT firmware (1.7.0) and god this thing improved since the last time I used it! There's a lot more functions and it overall feels much more responsive and polished. The things that most got my attention are:
Latest AT instruction set: https://www.espressif.com/sites/default ... et__EN.pdf
Here's all the latest docs (There's so many now!)
https://www.espressif.com/en/support/do ... d%5B%5D=14
And binaries
https://www.espressif.com/en/products/h ... /resources
I'll write up something on the wiki for the firmware update procedure.
- AT+CIPMODE: UART-Wi-Fi passthrough mode. Once enabled it directly sends the bytes you push on the TX line directly to a TCP/UDP adress:port (and receives the bytes the same way). Then send +++ to get back to normal mode. I have to make some tests for latency but that seems *the* thing for multiplayer games. So much simpler!
- AT+CIPRECVMODE: Set TCP Receive Mode. Finally a mode that the ESP8266 buffers what it receives and the client asks for arbitrarily sized chunks at its own pace!
Latest AT instruction set: https://www.espressif.com/sites/default ... et__EN.pdf
Here's all the latest docs (There's so many now!)
https://www.espressif.com/en/support/do ... d%5B%5D=14
And binaries
https://www.espressif.com/en/products/h ... /resources
I'll write up something on the wiki for the firmware update procedure.
Re: Uzenet
Interestingly, it looks like those two modes (passthrough and passive receive) can't be used at the same time according to the note in the AT docs for AT+CPIRECVMODE.uze6666 wrote: ↑Fri Sep 07, 2018 5:05 am
- AT+CIPMODE: UART-Wi-Fi passthrough mode. Once enabled it directly sends the bytes you push on the TX line directly to a TCP/UDP adress:port (and receives the bytes the same way). Then send +++ to get back to normal mode. I have to make some tests for latency but that seems *the* thing for multiplayer games. So much simpler!
- AT+CIPRECVMODE: Set TCP Receive Mode. Finally a mode that the ESP8266 buffers what it receives and the client asks for arbitrarily sized chunks at its own pace!
I'm still very much in the experimental phase and am yet to setup my second uzebox with an ESP-12f chip, but my plan is to enable local wifi networking by setting up one uzebox as a SoftAP, a second uzebox to connect to that SoftAP, and then sending data back and forth using UDP in the pass through mode. A game can then have two options. 'Host Local Wifi Game' or 'Join Local Wifi Game'. Hosting a game will setup an access point with an SSID with a game specific prefix and a subset of the ESP-12fs mac address. For example for Tank Fu, that might be 'TANKFU1afe3f'. The 'joining' game will look for access points with the 'TANKFU' prefix and choose a game to join. State will then be shared through UDP and passthrough.
That at least is the strategy I'm aiming to test.
EDIT: I suppose I don't even need to setup that second uzebox just yet. I can setup one with a softAP and then use a PC networking tool like 'netcat' to experiment with. Should make debugging a bit easier as well initially.
Re: Uzenet
Yes, but it doesn't really matter since I don't see them used together. In the first, it's implicit you will have control of the data flow since you must roll your own protocol and will insure only small amount of data is exchanged. I see the second one for things like service requests, web pages or even streaming where you don't know the size of what you will receive.Interestingly, it looks like those two modes (passthrough and passive receive) can't be used at the same time according to the note in the AT docs for AT+CPIRECVMODE
Re: Uzenet
That new esp8266 pass-thought mode really got on my mind and decided to hack my old uzenet demo. In no time I had a barebone telnet terminal. Was so easy and fun to code!
That monochrome 80 columns text opens the door to a world of telnet sites I never knew existed. Games, news, weather, chats, google search, wikipedia, you name it.
80 columns works ok on the Uzebox but even on my Commodore monitor, it get hard to read. I've looked at Jubatian mode 40 and its clearly the best thing for a Uzebox BBS/board/telnet site iHMO. So if you guys know of some active 40 columns telnet site for commodore machines or other ones, let me know. I'm totally working on a full Ansi color terminal for the uzebox.
Hopefully that will lead to my ultimate initial goal of making a retro computer with keyboard and all. Now with a relatively easy way to interact with the world, it makes it much more worthwhile. Now just think about that keyboard loaded with clickety Cherry-mx switches...
The best is, even with the current basic keyboard code included in the demo, I could exchange with the server with no efforts, just push the keyboard keys straight to the UART...so cool! That monochrome 80 columns text opens the door to a world of telnet sites I never knew existed. Games, news, weather, chats, google search, wikipedia, you name it.
80 columns works ok on the Uzebox but even on my Commodore monitor, it get hard to read. I've looked at Jubatian mode 40 and its clearly the best thing for a Uzebox BBS/board/telnet site iHMO. So if you guys know of some active 40 columns telnet site for commodore machines or other ones, let me know. I'm totally working on a full Ansi color terminal for the uzebox.
Hopefully that will lead to my ultimate initial goal of making a retro computer with keyboard and all. Now with a relatively easy way to interact with the world, it makes it much more worthwhile. Now just think about that keyboard loaded with clickety Cherry-mx switches...