Correct me if I'm wrong, but better disable the interrupts just in the message writing itself. I created the PR 29. Here is the diff:
Rafael
toggle quoted message
Show quoted text
On 5/2/23 19:36, Ashhar Farhan wrote:
Fabulous, I will roll this in. Or better?yet, can you send me a pull?
On Tue, May 2, 2023, 9:33 PM Steve Beckman <n3sb@...> wrote:
Hi Farhan;
Sorry - I was not very clear with my previous email. The potential
software bug is in the Arduino .ino code for the attiny85
microcontroller that's new to the sbitx V2 hardware.
The attiny85 Arduino code executes in a loop that reads the
forward and reflected power values from the two ADC channels, then
assigns those values to four bytes in the message[] variable
array, one byte at a time, like so:
? delay(100);
? fwd = analogRead(A2);
? ref = analogRead(A3);
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
This loop was executing every 100 mS, but github shows that you
just changed the delay call in that loop from delay(100) to
delay(2) so the loop is now repeating approximately every 2
milliseconds. That change increases the probability that the
attiny85 will be in the middle of assigning values to the
message[] array when it gets interrupted by an i2c request from
the pi,
Your arduino .ino code for the attiny85 also sets up an interrupt
with a statement in the setup() section:
?? Wire.onRequest(requestEvent); // register event
This code enables an interrupt that will occur when an i2c event
is received. The attiny85 will stop whatever it is doing and
branch to the requestEvent() interrupt service routine. This means
that the loop() code will be interrupted whenever an i2c event
occurs. That interrupt code services the i2c request and provides
the forward and reflected power readings back to the pi. The data
being sent back to the pi is contained in the message[] array.
If the attiny85 code execution point is in the middle of updating
any of the message[] variables when that i2c interrupt occurs, the
array will have some values from the latest adc() read function
call and some values from the previous adc() read function call
when those values are sent back to the sbitx app on the pi.
For example, if the previous ADC() reading was 0x01 0x00 and the
new reading was one count less 0x00 0xFF, and the i2c interrupt
occurred while the code was in the middle of updating these two
bytes, the LSB could get updated to 0xFF then before the MSB got
updated to 0x00, the interrupt would get called, and the bytes
that get passed back to the pi would be 0x01 0xFF, which would be
significantly wrong.
I think the simplest way to prevent this problem from occurring is
to change the attiny85 Arduino .ino code as shown below,
bracketing the array writes with noInterrupts() and interrupts():
? noInterrupts();
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
? interrupts();
73; Steve, N3SB
