Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote:So your threaded code results in roughly the same byte rate as the real thing? Does it support a single rate or uses the UART baud registers?
It uses the baud registers and has a timer for Tx/Rx delay until next byte. I was having some trouble figuring out the perfect amount of cycles to use based on the register values. I made handlers for all writes to UCSR0x so TXEN/RXEN need to be set to make it work, it just calls function(that probably do end up inlined) from the class so there is barely any new code in avr8. Every time something is written to one of those registers there is a another function inside the class to recalculate baud rate delays(which is right now just 1000 cycles no matter what). Essentially I wanted to have anytime one of those registers gets written it determines the new wait time for bytes accurately, but also checks settings for 8-N-1, etc. If any bit isn't right for communicating with a real 8266, just set a generic "bad_baud" flag and every bit gets shifted,EORed, and generally screwed up, but not really in the exact way it would on real hardware.

I notice when I have the baud rate set wrong on real hardware, something like "OK\r\n" will come back as gibberish, but sometimes that gibberish is just a little different. That's why I want to abstract the whole thing as much as possible. Basically if trying to emulate analogue minute details, might as well calculate insertion loss on the pins and PCB trace capacitance at that point to get the framing errors just right :lol:

Does your real 8266 always start up at the last speed you set it to? I know I have at least 1 that does not(always 9600), I will try and double fact check myself on that though.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

Does your real 8266 always start up at the last speed you set it to? I know I have at least 1 that does not(always 9600), I will try and double fact check myself on that though.
Yes all the modules I have tested so far restart at the last set baud rate. Though I have a heap of them in all sizes and shapes and haven't tested 75% of them... :)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

Since that seems most common let's emulate that. I have a save file that stores the wifi credentials for joining a (fake) access point, and also the softAP hosted by the 8266, the IP address, the MAC address, etc. I will add the last baud rate in there as well when I get back to Uzebox stuff.

I read the documents but can't get it yet, do you have a good idea how to turn UART control register bit settings into a wait cycles value? That is the only thing that is missing from cycle perfect UART, since the Uzebox can always put/get a byte to/from the FIFO regardless of what the 8266 thread is doing. The real 8266 cannot instantly respond to AT commands either as it has to run some heavy code, but the amount of time is small, if anything the emulator should respond with something like "OK\r\n" faster and could be slowed down if necessary later.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

Worked out the spooky problems I was having with the background high score updating process. The basic problem was me recommending doing it in the Post Vsync Callback, er, don't do that. Instead, use a custom WaitVsync(). Every frame(assuming your game makes it every frame, otherwise anything you do is dangerous anyways) the main program spends all free cycles after game logic/etc simply checking the vsync flag to start processing a new frame. Instead we can use some of those wasted free cycles to do the updating. In very time tight games we could only do this update when the game logic wasn't too heavy that frame, but I don't have a need for that right now.

Code: Select all

inline void SWaitVsync(uint8_t frames){
	UpdatePad();
//	if(TCNT1 < 1000UL)
		UpdateUzenet();
	WaitVsync(frames);
}
That is all I am doing, and all the "impossible" things that were happening disappeared. This is much better since it should be able to fit into cycle tight games better now. I am again at the limits of the emulator, but it seems I have the Uzebox side of things close to done. The high score server unfortunately needs to be redesigned because I see a process that is easier for the Uzebox(which the overriding goal is to be easier on Uzebox side, even if harder on server). I do expect under normal network conditions that Solitaire will retrieve all current world records before the Uzebox logo at the start is even done. After that, it repeatedly checks the eeprom for new scores and sends any there, then retrieves the list again in case anything new has happened. I do expect a high score you just entered to get to the server and read back in the updated list before the high score screen displays world records a couple seconds later. To give you an idea of what should be pretty close to what you'd need to include:

Code: Select all

void UpdateUzenet(){

//SPrintNum(3,0,uzenet_step,1);
//SPrintNum(3,1,uzenet_wait_ticks,1);
//SPrintNum(6,3,TCNT1,1);
	if(uzenet_wait_ticks)
		if(--uzenet_wait_ticks)
			return;//still waiting for something, try again next tick

//SPrintNum(5,20,uzenet_step,0);
//SPrintNum(5,21,uzenet_wait_ticks,1);

	if(uzenet_step == 0){//RESET MODULE//////////////////////////////////////////////////////////////////////////////////////////////

		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);//need to turn this pin back on next frame

		InitUartTxBuffer();
		InitUartRxBuffer();

		uzenet_substate = 0;
		uzenet_wait_ticks = 1;
		uzenet_wait2 = 0;
		uzenet_iteration = 0;
		uzenet_step++;

	}else if(uzenet_step == 1){//TURN MODULE BACK ON(RESET PIN)//////////////////////////////////////////////////////////////////////
	
		PORTD |= (1<<PD3);
		uzenet_wait_ticks = 180;//give it a chance to spit out its bootup stuff
		uzenet_step++;
		uzenet_iteration = sizeof(BaudLookUpTable)+1;//counter for number of attempts(each at different baud)
	
	}else if(uzenet_step == 2){//FIND THE BAUD RATE//////////////////////////////////////////////////////////////////////////////////

uzenet_step++;return;//EMULATOR HACK////////////////////////////////////	

		if(uzenet_substate == 0){//attempt to reach ESP8266 on UART

			if(uzenet_wait2 >= uzenet_iteration)//tried every baud rate, something is wrong
				uzenet_step = 0;
			else{

				InitUartRxBuffer();//clear any garbage(from startup or bad baud rates comms)
				UBRR0L = pgm_read_byte(BaudLookUpTable[uzenet_wait2++]);//try a new baud rate
				uzenet_wait_ticks = 2;//make sure a response could be here in time(next tick)
				Uzenet_SendStringP(PSTR("AT\r\n"));//we might have sent garbage at the last baud rate, clear it(could get "ERROR\r\n")
				uzenet_substate++;//move on to next sub-step
			}

		}else if(uzenet_substate == 1){//CLEAR POSSIBLE BAD DATA ON MODULE SIDE(MAY HAVE SENT AT WRONG RATE BEFORE)/////////////////
		
			Uzenet_SendStringP(PSTR("AT\r\n"));
			uzenet_substate++;
			uzenet_wait_ticks = 8;
			uzenet_wait2 = 5;
			
		}else if(uzenet_substate == 2){//CHECK FOR "OK\r\n" TO VERIFY CORRECT BAUD//////////////////////////////////////////////////
			
			//we cleared our buffer last step, so if we don't get "OK\r\n" there was a comms problem
			if(UartUnreadCount() < 4 || UartReadChar() != 'O' || UartReadChar() != 'K'){//wrong baud or other comms problem, keep trying

				if(--uzenet_wait2 == 0)//took too long, start from the top
					uzenet_step = 0;
				else
					uzenet_wait_ticks = 1;
					
			}else{//WE FOUND THE BAUD RATE!!
				uzenet_step++;//uzenet_wait_ticks is 0 so will automatically run next step on the next frame
				uzenet_wait2 = 0;
				uzenet_iteration = 0;
			}
		}


	}else if(uzenet_step == 3){//turn off echo

		Uzenet_SendStringP("ATE0\r\n");
		uzenet_wait_ticks = 1;
		uzenet_step++;
	
	}else if(uzenet_step == 4){//CHANGE 8266 BAUD RATE TO THE ONE WE WANT////////////////////////////////////////////////////////////
		
		Uzenet_SendStringP(PSTR("AT+CIOBAUD=57600\r\n"));
		UBRR0L = 30;	//57600 bauds	5760 bytes/s	96 bytes/field
		uzenet_step++;//uzenet_wait_ticks is 0 so will automatically run next step on the next frame

	}else if(uzenet_step == 5){//VERIFY WIFI CONNECTION//////////////////////////////////////////////////////////////////////////////
		
			//the response from baud rate change should already be in Rx buffer
			InitUartRxBuffer();//we will ignore it and check errors later(should have worked though)
			Uzenet_SendStringP(PSTR("AT+CWJAP\r\n"));
			uzenet_wait2 = 255;
			uzenet_step++;
	
	}else if(uzenet_step == 6){//WAIT FOR WIFI CONNECTION OK MESSAGE/////////////////////////////////////////////////////////////////
		
		if(UartUnreadCount() > 1 && UartReadChar() == 'O' && UartReadChar() == 'K'){//connected
			uzenet_step++;
	//		uzenet_iteration = 0;	
		}else if(--uzenet_wait2 == 0)//timed out, reset and try from the top
			uzenet_step = 0;
		else
			uzenet_wait_ticks = 1;
	
	}else if(uzenet_step == 7){//SET SINGLE CONNECTION MODE//////////////////////////////////////////////////////////////////////////
		
		InitUartRxBuffer();//burn any bytes left from connecting to wifi
		Uzenet_SendStringP(PSTR("AT+CIPMUX=0\r\n"));//this should always work if we got this far
		uzenet_wait_ticks = 1;
		uzenet_step++;
		uzenet_iteration = 0;	

	}else if(uzenet_step == 8){//CONNECT TO UZENET///////////////////////////////////////////////////////////////////////////////////

		InitUartRxBuffer();//burn response from previous command(which should always work)	
		//Uzenet_SendStringP(PSTR("AT+CIPSTART=\"TCP\",\"uzebox.net\""));//we need to split this message to support Tx buffer sized as low as 8
		Uzenet_SendStringP(PSTR("AT+CIPSTART=0,\"TCP\",\"uzebox.net\",51697\r\n"));//EMULATOR HACK////////////////////////////////////	
		uzenet_wait_ticks = 2;//wait for '>'
		uzenet_wait2 = 255;//wait for response in next step
		uzenet_step++;

	}else if(uzenet_step == 9){//VERIFY CONNECTION IS GOOD(check response)///////////////////////////////////////////////////////////
		
		if(UartUnreadCount() > 1 && UartReadChar() == 'O' && UartReadChar() == 'K')//connection good, ready to send packets
			uzenet_step++;
		else if(--uzenet_wait2 == 0)//count down to try again
				uzenet_step = 0;//something went wrong, try again from the start

	}else if(uzenet_step == 10){//PREPARE PACKET SEND///////////////////////////////////////////////////////////////////////////////

			Uzenet_SendStringP("AT+CIPSEND=0,7,\r\n");//EMULATOR HACK////////////////////////////////////	
			uzenet_iteration = 0;
			uzenet_wait_ticks = 2;//give time to receive '>'
			uzenet_wait2 = 4;
			uzenet_substate = 0;
			uzenet_step++;

	}else if(uzenet_step == 11){//BUILD A REQUEST PACKET///////////////////////////////////////////////////////////////////////////
		
		Uzenet_SendByte(0xC7);//magic number
		Uzenet_SendByte(1);//set request params(so we can ask for things later with less bytes)
		Uzenet_SendByte(0x00);//flow control flags
		Uzenet_SendByte(SOLITAIRE_UZENET_ID>>8);//rom ID
		Uzenet_SendByte(SOLITAIRE_UZENET_ID&0xFF);
		Uzenet_SendStringP(PSTR("\r\n"));
		uzenet_wait_ticks = 2;


	}else if(uzenet_step == 12){
		
		//should already have got '>', otherwise we will detect problems later anyway(would be hardware problem)
		if(uzenet_substate == 0){//check if this score should be sent using wait2 as sub-state to save ram
		
			if(eeprom_data[uzenet_iteration*10] & 128){//already sent this score before
			
				if(++uzenet_iteration > 2){//we have cycled through all the entries
		
					uzenet_iteration = 0;
					uzenet_step++;//now retrieve updated high scores from the server
					uzenet_substate = 1;
					uzenet_wait_ticks = 2;
		
				}

			}else//move on to next sub-step
				uzenet_substate++;

		}else if(uzenet_substate == 1){

			Uzenet_SendStringP(PSTR("AT+CIPSEND=0,12\r\n"));//EMULATOR HACK////////////////////////////////////	
			uzenet_wait_ticks = 2;//wait for '>'
			uzenet_substate++;

		}else if(uzenet_substate == 2){//BUILD A REQUEST PACKET

			Uzenet_SendByte(0xC7);//magic number so server knows this isn't run away code
			Uzenet_SendByte(2);//write command
			
			Uzenet_SendByte(eeprom_data[(uzenet_iteration*10)+0]);//send score part including MSB
			Uzenet_SendByte(eeprom_data[(uzenet_iteration*10)+1]);//server sorts everything by MSB so names are irrelevent(older score precedence)
			uzenet_substate++;

		}else if(uzenet_substate == 3){

			for(uint8_t i=2;i<10;i++)//send name bytes(after score because server sorts everything by MSB)
				Uzenet_SendByte(eeprom_data[(uzenet_iteration*10)+i]&127);//don't send the MSB which is used as a flag for different things
			
			Uzenet_SendStringP(PSTR("\r\n"));
			uzenet_wait_ticks = 2;
			uzenet_wait2 = 250;
			uzenet_substate++;

		}else{//make sure the send worked
			if(UartUnreadCount() > 1 && UartReadChar() == 'O' && UartReadChar() == 'K'){//it worked

				uzenet_step++;
				uzenet_wait2 = 0;
				uzenet_iteration = 0;
				eeprom_data[uzenet_iteration*10] |= 128;//make sure we don't try to send this again

			}else if(--uzenet_wait2 == 0){//timed out start from the top

			}

		}

	}else if(uzenet_step == 13){//REQUEST UPDATED LIST
		
		if(uzenet_substate == 1){

			Uzenet_SendStringP(PSTR("AT+CIPSEND=7\r\n"));//EMULATOR HACK////////////////////////////////////	
			uzenet_wait_ticks = 2;//wait for '>'
			uzenet_substate++;			

		}else{

			Uzenet_SendByte(0xC7);//magic number
			Uzenet_SendByte(0x03);//read command
			Uzenet_SendByte(0);//start at top of list
			Uzenet_SendByte(10);//number of bytes we will be reading 2 score bytes + 8 name bytes
			Uzenet_SendByte(5);//5 entries total = 50 bytes
			Uzenet_SendStringP(PSTR("\r\n"));
			uzenet_wait2 = 255;
			uzenet_substate = 1;
			uzenet_step++;
		}

	}else if(uzenet_step == 14){//GET UPDATED LIST
		if(uzenet_iteration == 1){//eat "+IPD,X:"
			if(UartUnreadCount() && UartReadChar() == ':')
				uzenet_iteration++;
			else if(--uzenet_wait2 == 0)//timed out, try it all again from the top
				uzenet_step = 0;		
			
		}else if(uzenet_iteration == 2){
			if(UartUnreadCount() >= 25){
				uzenet_wait2 = 255;
				for(uint8_t i=(3*10);i<(3*10)+25;i++){
					eeprom_data[i] = UartReadChar();
				}
				uzenet_iteration++;
			}else if(--uzenet_wait2 == 0)//timed out
				uzenet_step = 0;

		}else if(uzenet_iteration == 3){

			if(UartUnreadCount() >= 25){
				uzenet_wait2 = 255;
				for(uint8_t i=(3*10)+25;i<(3*10)+25+25;i++)
					eeprom_data[i] = UartReadChar();
				uzenet_iteration++;
			}else if(--uzenet_wait2 == 0)//timed out
				uzenet_step = 0;

		}else{//got the full update, repeatedly attempt to send our scores and get updated list
			uzenet_got_records = 1;//make sure high screen shows this now
			uzenet_step = 12;//go back to send any updated data
			uzenet_iteration = 0;
			uzenet_wait_ticks = 1;
			uzenet_wait2 = 0;
		}

	}

}

This is the current code I am testing, really not too many cycles per frame, and flash usage isn't that bad either at < 1.5k. There are some weird mixtures of single and multimode connection strings you might notice, I am using the old emulator version I put up a while ago since the current multithreaded version is broken still. I am procrastinating finally fixing that once and for all, it has really turned out to be difficult to get UART to work realistically with any sort of speed but doable.

I also plan on releasing the very low performance "script method" which takes less code space and can work with extremely meager ram costs for the buffers. It literally picks a baud rate, then runs all commands with max wait periods, and after the wait, assumes each step works out. It then picks another baud rate and runs the script again, indefintely. This way, if you have the module on there and it was setup correctly and your wifi is working...eventually it would accomplish the task. Should be possible to make it work with baud rates as low as 4800, but this will require "flow control" on the server to be implemented so it doesn't choke out a small receive buffer. Depending on how many iterations it takes to guess the 8266's baud rate, I would estimate it would take approximately 60 seconds to successfully upload a high score in the background and get a new list back(due to using long waits instead of checking responses). Could probably get away with 8 byte Tx buffer and 8 byte Rx buffer once the server supports flow control. That's just theory right now, but I do believe it is at least *possible* for essentially any game no matter what. I don't think implementing pad states networking system is any more complex than the code I posted.
User avatar
kivan117
Posts: 73
Joined: Sat Mar 14, 2015 5:43 am

Re: Uzenet

Post by kivan117 »

I read through the code you posted and it's almost spooky how similar it was to what I wrote a while back for Ghosty Ghost. Same exact general idea (simple script that runs at vsync) same step-substep methods, the breakdown of steps and their order was even about the same. The part that I got hung up on and frustrated with was knowing how long to wait and correctly identifying and parsing the messages from the 8266. At the end i just went with a series of maximum wait times and simplified it down to have/don't have an 8266 in order to decide whether or not to display the name entry and online high score menus. Your methods are a lot cleaner than what I was doing for the waiting and parsing strings, but otherwise it's almost scary how we independently came to the same design ideas. Great minds think alike huh? :lol:

Keep up the great work man. I think we'll be able to easily drag and drop this system into existing and future games which is exactly why I wanted to do it this way in my game originally. We're so close to online Uzebox gaming! :D
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

kivan117 wrote: Great minds think alike huh?
:) Oh, absolutely. It does seem a good sign for this methodology being independently reached by 2 sources. Really need to get Uzem UART section working like reality so we could actually develop game stuff and show people. That would sure help with motivation, I think real Uzenet modules are pretty rare right now.

Responses could be slightly different for some things on different firmwares. Basically any command that gets a response should contain "OK" somewhere in it, otherwise it's an error unless it's the "+IPD" or "CWLAP" stuff. Wifi is just a guess from what I've seen which could be adjusted if needed, if already setup it should automatically connect without intervention to the last wifi it was on, the actual CWJAP is just verifying it happened..my understanding.

Network time outs are an educated guess since you should get a round trip time of < 1200ms at worst(on satellite, which should actually be fine for some games) or nothing at all because it's lost. TCP can screw around not wanting to do a resend for perhaps 200ms in that event. Really ~2.5 seconds indicates 2 packets(including TCP window screw around+ 1 auto resend) got lost in a row on a very high latency connection. Re-point the dish and try again I guess, something is wrong :lol:
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I am back working on Uzenet and have a faster/better method for autobaud detection. I am currently working on the setup utility again that should be able to interface with any ESP8266 no matter what the firmware. From there I have it scanning for all available wifi APs and listing them, then giving the option to join one. Don't have that part done yet. I'm also working on a generic HTML 1.0 GET request to pull a file from uzebox.net that indicates the preferred firmware version and checks against the AT+GMR(get firmware version) string. As far as flashing new firmware to the device it's possible and I think it's a requirement to have everything on the same page. As I mentioned before there is working python code that just this(a SLIP format that sends commands/firmware over the UART). This unfortunately requires manual connection to pin with a wire since it's not broken out on the Uzenet module. This isn't too hard though.

So that is enough of a chunk for right now I want to get totally finalized so we can actually get these things off the ground. I did some UDP testing, and I must say it made me much more hopeful we will be able to get high performance out of these things for games. I certainly hope 60 packets per second is possible(or else we need custom firmware compiled). I don't remember where I mentioned it, but I did manage to get an Uzebox to access a shell on the uzebox.net server which can execute Lynx text based web browser...and I just so happened to have written this post in such!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzenet

Post by Artcfox »

D3thAdd3r wrote:I am back working on Uzenet and have a faster/better method for autobaud detection. I am currently working on the setup utility again that should be able to interface with any ESP8266 no matter what the firmware. From there I have it scanning for all available wifi APs and listing them, then giving the option to join one. Don't have that part done yet. I'm also working on a generic HTML 1.0 GET request to pull a file from uzebox.net that indicates the preferred firmware version and checks against the AT+GMR(get firmware version) string. As far as flashing new firmware to the device it's possible and I think it's a requirement to have everything on the same page. As I mentioned before there is working python code that just this(a SLIP format that sends commands/firmware over the UART). This unfortunately requires manual connection to pin with a wire since it's not broken out on the Uzenet module. This isn't too hard though.

So that is enough of a chunk for right now I want to get totally finalized so we can actually get these things off the ground. I did some UDP testing, and I must say it made me much more hopeful we will be able to get high performance out of these things for games. I certainly hope 60 packets per second is possible(or else we need custom firmware compiled). I don't remember where I mentioned it, but I did manage to get an Uzebox to access a shell on the uzebox.net server which can execute Lynx text based web browser...and I just so happened to have written this post in such!
I'm curious what version of the firmware you're using on the ESP8266. I started playing with one a while back, but I got so fed up with how unreliable the AT commands were that I gave up. I had one configured to be an AP, and another would connect to that AP and send sensor readings to the first device. It worked fine unless one of them got power cycled, and then when te first tried to reconnect after it came back up, it would just error out until I hard power cycled both devices. That's when I started looking into the nRFL2401+ for what I wanted to do. I wasted so much time with the ESP8266 chips, though I now have a nice little USART library that uses the Knuth-Morris-Pratt algorithm for string searching, so it's not a total loss.

Did the AT firmware suddenly get reliable, or is it still terribly buggy?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I'm using this for testing the setup utility:

Code: Select all

AT+GMR
AT version:0.21.0.0
SDK version:0.9.5
By "Ai-Thinker Technology Co. Ltd." which is old by now. I bought many different models and I recall some version from somewhere had this on it. It was a marked improvement over the terrible original firmware I had for the ESP02s, which would seemingly lock up at random with messages like "Busy now.." or my favorite "This no fun.". Back then I also recall I had some strange wifi stuff needing a restart(though I never tried 2 ESP coms without a wifi router in between, I think they can not really switch/route?), but these ones I can leave on for hours come back and give it a AT+CIPSTART=.. and know it will instantly work. I have newer versions wired up on a breadboard with recent firmware and they also work well, auto-update over the internet, some firmwares can run BASIC or LUA! IMHO, at this point it's quite reliable. Not everyone will find it fun to manually upgrade their firmware, so I do think something that near automatically handles all that is important for plug and play with any modules original firmware. Also, I eventually want to compile a custom version that has all the standard AT commands but can switch into a more efficient binary mode. At least, these things all have to present the exact same interface to the games.

Some of the disadvantages of the 8266 I think are mostly negated for our purposes. The UART is not used by anything else, where as the SPI for SD card and 128k ram is plenty busy. The serial speeds can be quite high(at least 57600 tested) and the kernel handles it perfectly and automatically at this point. Sucks to buffer it on the Uzebox instead of on the device, but it's not much ram. I do not like the AT command set concept, but it works at this point, and custom firmware is possible that could even buffer it on the device?. The biggest problem is the different AT dialects these things natively speak from the factory, some do AT+CIOBAUD, while others only accept AT+IPR, and older versions may not accept it at all, things like that. I think this worst characteristic is negated by a setup utility, since it can be a heavy program that knows all the different possibilities and quirks and can communicate enough to get all modules to a known state(firmware). Then games don't have to have all that bulk, and I think reliable enough to do little error checking at a few key points. I cannot get this version into an unreliable state no matter how badly I form manual AT commands, give too many bytes to a send, etc.

I wasn't faithful at all the the 8266 to begin with and I have a couple ethernet modules laying around next to a redpine wifi. I would like to explore(forget the models) the 2 cheap UART->Ethernet ones collecting dust. The nRFL2401+ I have looked at since it's as cheap or cheaper than the 8266. The issue is they do not have a wifi stack though I see someone got it to scan wifi/bluetooth networks somehow. That is a blessing for bandwidth/power/code efficient networking of robots and such, but then I think it requires a separate PC in the mix to act as a gateway/tunnel to the internet? If I'm wrong and the thing can be coaxed into doing wifi/bluetooth that would be crazy awesome(wiimotes).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzenet

Post by Artcfox »

Mine came with an AI Thinker firmware, but that did not support UDP, so I reflashed it with whatever was the latest official version at the time, but that version was so buggy that I regretted it. For example, it could only connect to WiFi access points that had exactly 10 characters in the name. Stuff like that made me lose all faith that they have any QE process at all.

The nRFL2401+ doesn't do WiFi, or Bluetooth, it can communicate with another nRFL2401+ which would need to have a bridge if we wanted to use that to talk to the Internet. I mentioned that because all I needed was point to point. I was thinking about it more for wireless controllers, rather than Ethernet, though an ATtiny85-based V- USB bridge would be a cheap way to interface it with a PC, though that is USB 1.0, so it might not be fast enough.

I see why everyone eventually ditches the AT command set though, but if we can guarantee everyone is on the same firmware, then that shouldn't be an issue. Even better would probably be to use the ESP8266 SDK to write a custom protocol that isn't AT commands, similar to the transparent serial firmware so it doesn't add any bloat at all to the Uzebox code. (You configure it once, and anything sent/received over the Tx/Rx goes to/from an IP:port). I wrote a simple ESP8266 library, and it wasn't as small as I had hoped.
Post Reply