...
For MSX the duty-cycle was calculated instantaneously, this was improved in MSXI by using a time-averaged duty-cycle to reduce noise and improve accuracy. The duty-cycle was detected determined by using rising and falling edge detection, essentially this means that the Ichosen I/O pin we (s) is/are monitoring the signal on and alerts the software through an interrupt vector whenever the signal switches from low to high (rising) or high to low (falling). These vectors trigger This vector triggers code to read the internal clock time of the signal change to a pair of ring buffers one for rising and one falling. By computing the duration between two rising events we can determine the period of a cycle. By computing the duration between the first rising and next falling event the active time can be determined. Dividing the active time by the period we can determine the duty cycle. By averaging these results we can get a good idea of the average duty cycle for a short period, this is the then mapped to the current value using the manufacturer's function. In MSX these values were not averaged and as a result, the accuracy was lower.
...
The major difficulty experienced in implementing current sensing in MSXI was an internal timing issue. Specifically, the interrupt vectors to trigger the rising and falling behavior were not always interleaving as rising, falling, rising, falling. Instead one of the events would often skip leading to the two ring buffers falling out of sync yielding completely unexpected duty-cycles and by extension, current values. This issue plagued the initial implementation for weeks while we sought to understand the issue; it was particularly bad above 100 Hz and the sensor we were using operated at 125 Hz. It didn't help that the Timer A module we used in prototyping on the MSP430F5529 launchpad had different behavior than the Timer B module that was connected on the Plutus board. Going forward it would be ideal to use the same modules for both prototyping and real-boards, in . In this case, it was a hardware limitation of the launchpad and original design of Plutus.
A more specific, issue that would have helped with the conflicting interrupt vectors would have been to have had the rising and falling I/O pins in the same interrupt vector bank. The way Timer B was designed, pin 0 registered on a different vector than pins 1-7. The rising and falling pins assigned in hardware were pins 0 and 1 resulting in having to rely on multiple vectors to call on the same methods and the vector for pin 0 had priority over pin 1 likely causing most of the sync issues.
Another note to reflect on is the difficulty with doing mathematical division numeric division for the duty-cycle calculation without proper hardware support. The MSP430 series of micro-controllers microcontrollers did not have good support for floating point mathematics so integer math was needed which was less than ideal and resulted in using some weird units such as cA (centiamps) due to the native register/integer size of the MSP430 series controllers. Similarly, the interrupt vector speed issue could have been resolved with a faster CPU speed so upgrading the hardware is recommended.
Other suggested improvements include using an external clock crystal for the system to help with timing issues and to consider using a Hall Effect Sensor with a better pin interface (the solder joins joints often broke and were hard to repair on the model used in MSXI).