HardwareSerial without software buffer and interrupts

[igrr]

Based on changes proposed by @me-no-dev in #1485.
Implemented missing peek function.
Also did some cleanup and separated uart_ functions into a separate file.

The only hardware-dependant thing in HardwareSerial.h is the following line in available() method:

optimistic_yield(USD(_uart_nr) / 128);

This can be rewritten via uart_get_baudrate, but that would incur an integer division, which is costly on the ESP8266. Another option is to add a getter in UART HAL, which would return the value of USD. However i have no idea how to call that method (i.e. uart_get_WHAT(uart_t*)?).

I have also taken liberty to reformat both affected files with astyle --style=otbs. Going further, this is the style I want to enforce for all source files, so please adjust your editors :)

[me-no-dev]

what does "astyle --style=otbs" mean?

[igrr]

astyle is a widely-used program for source code formatting. Look up "One True Brace Style" here.

[me-no-dev]

so basically races on new line for function and then braces on each branch on the same line?

void someMethod()
{
  int something;
  if(whatever){
    //nothing to do
  } else {
    //we do in braces even if one line
  }
}

[me-no-dev]

USD(num) / 128 = 625000 / baud;
if you know the baudrate in HardwareSerial, then you can calculate the optimistic_yield with the formula above. Though I'm not sure how correct is to use the result (how long will optimistic_yield(5) not yield for);
for 112500 baud, the time between bytes is 73us roughly

[igrr]

Yeah, i thought about that at first, but as I mentioned

This can be rewritten via uart_get_baudrate, but that would incur an integer division, which is costly on the ESP8266

I.e. i don't want to do integer division on each call to available. Maybe I'll calculate it once and cache this timeout somewhere...

[igrr]

Also optimistic_yield(arg) doesn't yield for arg, it yields once in arg microseconds.

[me-no-dev]

you can have it calculate on begin :)
I know how optimistic yield works, just was not sure of the meaning of the number. Clock cycles or micro seconds :)

[me-no-dev]

I think it should not yield before another byte can come. so if the argument that optimistic_yield takes is microseconds, the number should be at least 80.

[igrr]

Yep, 80 microseconds is not enough for a context switch anyway. So probably this may be changed to optimistic_yield(10000); to let SDK do it's job at least every 10ms, for all those while (!Serial.available()); loops out there.

[me-no-dev]

I have been using 10000 as a reference value actually whenever I have needed optimistic_yield and it has worked OK so far :) so 10000 is OK imo