Unless the display is changed by one of the other tasks there is no
reason to update the display. It's not like you are preventing the
other tasks from running while you automatically update the display on
a regular basis. The speed of sending display updates via I2C really
isn't that much slower than doing it direct. In essence, the I2C
backpack on the display is just another co-processor that offloads
controlling the display from the main processor.
I can't argue with the fact that multiple processors provide more
computing power. However, as you point out, all those processors have to
communicate with at least the main processor which, in turn, slows down
the main control processor while it is communicating.
You might cast an ADC unit that communicates with the main processor
over I2C on an as-requested basis as a co-processor. The main processor
isn't required to actually process the voltage on an analog pin, the
ADC does that. The main processor just gets the result of the read of
the analog value, it doesn't have to actually read the analog value
first before it processes it.
tim ab0wr
On Thu, 19 Apr 2018 21:36:27 -0700
"NNicholas via Groups.Io" <NNicholas@...> wrote:
No, it's not a big difference in speed, that is until you consider
that the display in this radio isn't the Arduinos only task. I
haven't started on this all just yet, but from previous projects.? In
the past ,? ive found cop-rocessing with multiple prcoessors on an
I2C bus to not only offer greatly improved speed up of operations,
over all; it makes dividing up the project a bit easier too. The only
challenge, that I ever found in multiple processors , is at start up,
where you want to make sure that all the processors are talking
before entering into each of their program loops . It's not that hard
to code and you can find plenty of examples on how to do this.
