It is an interesting idea to replace the battery buffered RAM with a µC.
I did not want to deal with a battery ever again, so could either load sram values via gpib at startup or put something in place of the sram. I really don't want to deal with gpib, and calculated an mcu could handle the sram duties.
The mcu sram replacement may be a moot point, as I intend to replaced the lcd/buttons as I indicated. I think the display/button mcu could do the duties of translating the lcd data (displayed value) with its own offset/gain data and output the corrected value. The main mcu would use the default offset/gain since there would be no sram, the display mcu would have its own custom calibration data and create whatever interface it wants to let a user customize that data, or change on the fly (usb,serial,whatever). With the display mcu having the display value, and will know the meter state as it will be doing the button presses, it could also send the data out externally in whatever format/method it wants. Maybe would not be as easy as I think, but also not at that point yet.
It looks like I can get the data pins set on a read about ~300ns before the rd rising edge so looks like its taking close to 20 cpu cycles to do the work.
I have only been running the mcu for a few days, so do not know if there are problems yet to discover. The CS pin is set to a falling edge irq, and the isr is in a loop looking for rd/wr pulses until the CS pin rises again. This allows the main loop to check for any need to update eeprom, and can be interrupted anytime without a problem (isr code only reads/write from ram).
So there is limited need for an extra constant.
I think I will scrap this idea then. Thanks.
Ideally this would be separate for the front and rear terminals
I'm also removing the front/back switch so will only have front terminals. I have no need for rear terminals, and also don't want to deal with that switch in the new front panel. No need to have those wires/switch hanging around inside if I'm not going to use it.