btw, the rationale for this I just wrote - we don't want the I2C response to be delayed (IO is not the fast operation in the MCU... and we already have problems enough with bit-banging), but having a consistent read 1ms late (just exaggerating here) in the worst case is not a big issue.
I glue the diff here:
? delay(2);
? fwd = analogRead(A2);
? ref = analogRead(A3);
+? noInterrupts();
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
+? interrupts();
}
73
toggle quoted message
Show quoted text
On 5/2/23 20:11, Rafael Diniz wrote:
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
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
