"runtime.hardware.path" now contains the path to the hardware folder
of the currently selected board and "runtime.platform.path" the path
to the specific platform.
This should fix#1176 and #1761.
Update FileIO::doBuffer() to check for TRANSFER_TIMEOUT and set buffered to 0, and optimize by incrementing readPos instead of moving all of the data one byte to the left in the buffer to skip the error code byte.
On later versions of avr-libc, prog_char is deprecated. In 0acebeeff4
the one occurence of prog_char was replaced by "char PROGMEM", which is
not entirely correct (PROGMEM is supposed to be an attribute on a
variable, not on a type, even though this is how things work in older
libc versions). However, in 1130fede3a a few new occurences of
prog_char are introduced, which break compilation on newer libc versions
again.
This commit changes all these pointer types to use the PGM_P macro from
<avr/pgmspace.h>. This macro is just "const char *" in newer libc
versions and "const prog_char *" in older versions, so it should always
work.
References #795
The new function just calls Print::write(const uint8_t *, size_t), but
this allows writing out a buffer of chars (without having to learn about
casts).
Previously, the row offsets were hardcoded to the ones used for 20x4
displays (which woudl also work for all 2-line displays). Now, the
number of columns given is used to calculate the offsets most likely to
apply.
For 2-line displays and 20x4 displays, the (used) offsets are completel
unchanged. With this change, common 16x4 displays and (if they even
exist) other 4-line and 3-line displays might also work (depending on
the hardware configuration used, of course).
See this page for some info on common LCD sizes and configurations
encountered in practice:
http://web.alfredstate.edu/weimandn/lcd/lcd_addressing/lcd_addressing_index.html
Before, the row value was maximized against _numlines already, but the
value from _numlines is not limited anywhere, so it could be longer than
the length of _row_offsets. This check makes sure the array bounds is
never exceeded.
Since these are memory addresses, there is no need to make them signed.
Furthermore, the HD44780 chip supports memory addresses up to 0x67, so
uint8_t shouldbe sufficient.
