ATTiny2313 and Bad Baud Rate

Thread Starter

AgentSmithers

Joined Jan 14, 2011
77
Hi everyone. I have connected an ESP8266 to my ATTiny2313 via UART. It works great. However if my ESP8266 gets rebooted it ends up shooting out a bunch of garbage before loading Init.lua and correcting it baud rate with the following result.

> c_ÇRSöfJSúfJÃjêM†ÿËãÛÊÏoËSÆËÏInit Loading
listening, free: 18360
Setting up webserver
> !ESP8266_0a802d|PW: 12345678
!ESP8266_0a802d|PW: 12345678
!ESP8266_0a802d|PW: 12345678
!ESP8266_0a802d|PW: 12345678
!ESP8266_0a802d|PW: 12345678

The incomming data is at buad 115200. When the very first line is sent to the ATtiny2313 it appears to lock up the controller from continuing through its main loop. Is there any way to stop that UART from being rendered at all or do I need a watch dog to prevent my controller from being locked in the ISR? The next option I have unforunitly would be to recompile the ESP nodeemu binary to stay in that baud but that would take a chunk of work. I've tryed also asking the Attiny2313 to use ODD Parity and two stop bits but that 115200 is still trying the ISR for some reason?
Thanks everyone for the help!

void InitUART (unsigned char baudrate)
{
UBRRH = (uint8_t)(MYUBBR >> 8); //Set baud rate
UBRRL = (uint8_t)(MYUBBR); //Set baud rate
// Set
UCSRB = _BV(TXEN) | _BV(RXEN) | _BV(RXCIE);
UCSRC = (1<<USBS)|(3<<UCSZ0);//Set frame format
}

ISR(USART_RX_vect){
buffer[rx_read_pos]=UDR;

if (buffer[0] != '!')
{
return; //Start Char
}
}
 

JWHassler

Joined Sep 25, 2013
306
For some reason, the ESP8266's initial serial message is at 74400 baud. Thereafter, it switches to (default) 115200 or a value previously set by the user.
Without a hardware UART, (if that's your case) it's tough: you might have to delay a known-long-enough time after resetting the ESP8266
 

Thread Starter

AgentSmithers

Joined Jan 14, 2011
77
Hmmm after fiddeling around with it for two hours it appeared to be a buffer overflow issue. The issue is now resolved. I was reallocating the same var in a loop. I moved it to a Global Var and resolved it.
 

Thread Starter

AgentSmithers

Joined Jan 14, 2011
77
I did do that as well with CLI SEI and a sleep in the middle and with that I was able to discover that was indeed not the case, Red Harring.

However during this time I used the Custom Cloud build. I discovered that it swaps from
74880 and sends out a bunch of Debug of loading a rom.
Then it swaps to 115200 to output NodeEMU data then It swaps to 9600 to talk to my LUA script code.. I thought that was for sure the issue but thank goodness it was not.

What I did do is Hex Edit the Bin and add '\0' '\0\ to the start of the string saying something about "Custom NodeEMU blah blah blah" and it nurfed half the junk coming out during the load. The ROM I think works with RTOS? So I think it uses the PRINTF function to output the lower level data about loading the Rom. Only way to fix that is to recompile the code from scratch * Jumps Ship * well for now Im up and running. Thanks for the chime in!
 
Top