Point of this change is to allow using these functions for
writing to the display, too, without duplicating all the code.
To reduce confusion, functions were renamed (they're no longer
'serial', after all:
serwrite_xxx() -> write_xxx()
sersendf_P() -> sendf_P()
To avoid changing all the existing code, a couple of macros
with the old names are provided. They might even be handy as
convenience macros.
Nicely, this addition costs no additional RAM. Not surprising, it
costs quite some binary size, 278 bytes. Sizes now:
Program: 24058 bytes 168% 79% 38% 19%
Data: 1525 bytes 149% 75% 38% 19%
EEPROM: 32 bytes 4% 2% 2% 1%
Regarding USB Serial: code was adjusted without testing on
hardware.
This is a pretty complex and, as system clock and baudrate are
known at compile time and never changed at runtime, unneccessary.
Replacing this calculation with fixed values makes the binary
a whopping 564 bytes smaller.
However, how to get these values? Well, we do kind of an
easter-egg. If parameters arenot known, we calculate them at
runtime anyways, and also report them to the user. So she can
insert them into the code and after doing so, whoops, serial
fast and binary small :-)
With known parameters:
SIZES ARM... lpc1114
FLASH : 1092 bytes 4%
RAM : 132 bytes 4%
EEPROM : 0 bytes 0%
Without (1428 bytes more):
SIZES ARM... lpc1114
FLASH : 2520 bytes 8%
RAM : 132 bytes 4%
EEPROM : 0 bytes 0%
On ARM we use only the 16 byte hardware buffer for sending and
receiving over the serial line, which is often too short for
debugging messages. This implementation works fine and still
neither blocks nor introduces delays for short messages.
Costs 72 bytes binary size, mostly because it's the first usage
of delay_us():
SIZES ARM... lpc1114
FLASH : 1656 bytes 6%
RAM : 136 bytes 4%
EEPROM : 0 bytes 0%
Pretty complex, this MBED system, it requires no less than
24 additional files. This will be fleshd out before too long.
SIZES ARM... lpc1114
FLASH : 5956 bytes 19%
RAM : 176 bytes 5%
EEPROM : 0 bytes 0%
Markus Hitter