The elapsed time will be relative to when the logging mode is entered so the numbers don't keep changing. Storing this much data limits the logging history to probably 32 commands. That doesn't sound like much, but it will take a fair number of button presses to scroll through. Leaving off the elapsed time could expand the history to 40 commands.

Yes, I'm working on the XTBM Pro code. My working registers have overflowed the PIC page 0 RAM, so I'm now dealing with having to switch back and forth between memory banks just to access workspace RAM.

This is the major difference between the “consumer” PICs and the Motorola/Freescale microcontrollers I used for most of my career. Those devices have a flat memory map, with the entire ROM, RAM, and I/O in the same address space. The PIC segmented memory is a major pain to deal with. The PICs also force us back into the BASIC era, with GOTO instructions all over the place. It works, but the convoluted assembly code is ugly.

It's ironic, since I've been using the 16LF1825. To get a larger amount of uninterrupted linear memory, you would have to go with at least the 18 series. Have you looked at those? The lowest pin count package is 28-pin. Probably more I/O than you need, but who cares? They're less than a dollar more than the 16F1825.

It had to be pin-compatible with the 16F684 used in the XTBM. The 182X series was supposed to be, but a restriction on the comparator configuration forced a change to the PCB so it could accept both devices. The I/O is sufficient on the 14-pin device, and the 1K RAM is more than adequate. Unfortunately, it is broken up into 80-byte segments, so I've been partitioning the workspace between the first two 2 banks. The remainder will be used as the logging buffer, but that can be accessed indirectly as contiguous memory.

That might seem so. But just simply going through adding a banksel to every variable access would add hundreds of superfluous instructions. So I’ve been going through all the variables deciding which should stay in Bank0, which could cleanly move to Bank1, and which should be global. Unfortunately, that has been a time-consuming tedious process.

Some of you may be wondering why it is taking so long for the XTBM Pro to be released.

I have been working on the firmware in the little snippets of free time I have. The task has been much more complex than originally envisioned because all the display code had to be grouped into independent subroutines, selected by the operating mode. Previously the display was updated throughout the cycle as calculations were completed. Reorganizing that code has been a nontrivial effort, and I'm still chasing bugs that were introduced in that process.

With tax time looming only a few months away, I may not get this completed before next summer.

I finally completed debugging the repartitioned code, and all the XTBM basic functions are operational again. The mode selection code is operational, and I will be working on the enhancements in the coming weeks.

Several modifications will be ported over to the standard XTBM firmware in the next release early next year. Some are obscure bug fixes, and one allows it to display the firmware version on the LCD.