Preparing for new release of FC host tools

[Mychaela Falconia]

Hello FreeCalypso community,

Given that we do not seem to have any active users who run systems on
which the ASYNC_LOW_LATENCY patch makes any differences, I have decided
to revert this patch and not include it in the upcoming release.  The
upcoming release will have the same tried and trusted serial port
handling code which we've been using since the beginning of FreeCalypso,
including the Linux-specific high baud rate handling method introduced
in 2017, i.e., absolutely no change from what all of you have been
running so far.

The current code that will go into the upcoming release does however
include the new feature whereby fc-xram and each lengthy command in
fc-loadtool measure and report the time it takes to complete the
operation, and a new documentation article is included that explains
the underlying theory and gives the expected times for various
operations as observed on my current Slackware system and unchanged
since the beginning of FC back in 2013.  If someone other than Serg L
or his people (can be anyone anywhere in the world, just needs to be
someone other than that particular company) encounters a situation
where fc-loadtool flash programming or fc-xram loading operations take
longer than the reference times documented in the Loadtools-performance
article, THEN we can re-address the situation and possibly
reincorporate the ASYNC_LOW_LATENCY patch *if* this patch improves the
performance for the new non-Serg reporter - but only if and when we
get a non-Serg affected user, and not otherwise.

There is also one more large-ish change I am going to make to
fc-loadtool before cutting the new release: I plan on revamping the
implementation of flash program-m0 and program-srec commands.  Right
now the preferred way to program flash is via our flash program-bin
command, taking the bits to be programmed from a straight binary file.
We also have a flash program-m0 command that natively takes in *.m0
files produced in TI's environment (and a flash program-srec command
for the sake of completeness, differing only in byte order), but the
current implementation of these program-m0 and program-srec commands
is poor: they run much slower because they operate on one small
S-record at a time instead of 256 bytes at a time, the progress
indication is poorer, and there is no CRC-32 check at the end.  Hence
these flash program-m0 and program-srec commands as they currently
stand should be treated as "deprecated, don't use".

I was about to write a new documentation article explaining the subpar
and deprecated status of these SREC-based flash programming commands,
but then I decided that I would rather fix the implementation instead,
making this alternative method of flash programming as good as our
current flash program-bin.  The new approach I am thinking of is to
preparse the entire *.m0 or other SREC file before beginning any flash
operations, and build a map of discontiguous regions into which the
SREC image deposits bits - then program each of those regions in the
same way as our current program-bin implementation.  We'll see in the
next few days how this approach pans out.  The end objective here is
to have a flash programming mode that functionally matches the
agnosticism of TI's FLUID - a quality which we currently lack.

Hasta la Victoria, Siempre,
Mychaela aka The Mother