Use this forum to chat about hardware specific topics for the ESP8266 (peripherals, memory, clocks, JTAG, programming)

User avatar
By eriksl
#16990 I am trying to get some more information about the built-in UART(s). Most project copy the ugly code from the example, but we won't learn how it works from it and won't let us use the full capability.

I am trying to get a datasheet, which probably is, like I already feared, proprietary and NDA. It can be downloaded from the cadence site, but you need to register first. I've done so, but I am not too sure whether I will get accepted ;-) No reaction so far.

Several sources on the internet suggest the UART's are actually 16550 compatible. That would make thing quite a bit easier. Can anyone confirm this?

Also does anyone know if it's obligatory to set the "UartDev" variable, which is linked from the sdk code? It doesn't seem to do anything useful. The example code sets it and then goes on setting the UART registers from this variable, so I guess you could avoid the variable altogether, or did I miss something here?
User avatar
By eriksl
#17063
eriksl wrote:Also does anyone know if it's obligatory to set the "UartDev" variable, which is linked from the sdk code? It doesn't seem to do anything useful. The example code sets it and then goes on setting the UART registers from this variable, so I guess you could avoid the variable altogether, or did I miss something here?


In the meantime I can confirm that this variable really needs to be setup, even if you don't use it yourself. If you don't, input of the uart will go haywire after each ~3 characters. It looks like the uart is (re-)setup every few milliseconds. Maybe an ISR or wake up from deep sleep where the uart needs to be reconfigured.

I didn't yet found out which fields of the structs are mandatory, that's the next step.
User avatar
By eriksl
#17064 Also neither the 16550 or 16552 documention "fits" the register layout of the UART according to uart-register.h, BUT the 16552 comes quite close and I found the documentation quite helpful. E.g. I learned that "TOUT" probably means "timeout"; i.e. an interrupt/threshold on one or more characters sitting in the receive queue and are not yet fetched after a few clocks.
User avatar
By eriksl
#17074 Also interesting: Setting the baud rate. Apparently you need to set a clock divisor as "uart clock" (which via three defines equals 80 Mhz = CPU clock) divided by the request baud rate. On ATmel uart's you need to set 16 * the baudrate as divisor because for every bit, 16 samples are taken and four of them of weighed which improves the influence of noise.

I am curious how esp8266 does that then, if it really one takes one sample per bit. If that's the case, the uart could be set to any baud rate you like, up to 80 Mhz, as long it's divisible by 1,2,3,4, etc., not just the standard rates. But somehow I doubt it works that way, I think the value is divided by 16 internally.

Also interesting is that the base cpu frequency can't match standard baud rates exactly (if internal division by 16 is assumed). for instance for 460800 baud, you will actually get 454545 baud, which is 1.3% off, which is just barely acceptable (according to ATmel guidelines).

This is especially interesting, because this means you don't need to bother using "exact" crystals on your connected microcontroller (like the 11.059.200 Hz ones, that can give you *exact* standard baud rates) and just use whatever you have lying around or even use the internal rc oscillator, which in my case, gives 8 MHz and can produce a baud rate of up to 1 Mhz ("double speed mode", 8 samples instead of 16), which the esp8266's uart can match *exactly*. For reliable operation it may be wise to switch to something lower though ;-) (1 MHz divided by 1,2,3,4,etc. which will match exactly on both sides).