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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community