I am currently working on the design of a handheld instrument for a specific biomedical application (from which I cannot disclose much information due to IP-related issues, sadly). I have a working version on a custom PCB and I am in the middle of massive firmware and hardware improvements for the next revision.
The microcontroller I use is a Teensy 3.2 (clocked at 120 MHz) which is in charge of multiple tasks, including (amongst others):
- Measuring a specific frequency from an oscillator via Pin 13 (using the FreqCount library from PJRC),
- Reading the user's input from a couple of push buttons,
- Writing to an I2C OLED screen (using the u8g2 library),
- Reading values from an I2C sensor (perhaps more in following revisions),
- Controlling an analog multiplexer,
- Send formatted values in the form of an alphanumeric string through the serial port to a host PC.
It might me relevant to note that the I2C is clocked at 400 kHz, restricted by the slowest of the sensors.
During my initial evaluations noticed that writing to the OLED screen consumes considerable time (as expected, being an I2C device) which affects the overall performance of the instrument, mainly on the sample rate of my acquisitions from the MUX, frequency, and peripheral sensors. More importantly, I have noticed that when I disable all "writes" to the OLED, the multiplexing is also favorably affected, reducing the jitter on the output signal from the MUX and even the accuracy of the frequency measurements from Pin 13.
As part of my initial conclusions I realized that using an I2C OLED screen is NOT the best option and the new version will use an SPI module, however, I have considered the option of delegating the control of the OLED to a second microcontroller (say an ATMEGA328P) and establish a communication protocol between the Teensy and the OLED MCU via UART. This kind of approach is commonly used in some instruments like bench multimeters and similar ones, to reduce the load on the main controller unit.
This new proposal would look like this:
Any ideas? Would you overengineer the design this way?
I am totally aware that you might require more information regarding my project, however, I hope I have covered most of the important aspects of my current solution. I believe that my system has plenty of room for optimizations.