Alfredo Saetta

Hi Evan, I have now completed the tests on the actual hardware and I think I can explain the situation more clearly. I kept the original V1.0 program structure and applied the changes you suggested: removed #define TIMER1 = TMR1L.Word; changed T1CON from 0b10000111 to 0b10000101; added #option explicit; replaced Str32 with LongToString; updated String.h to the latest version; replaced TEMP_OV = OVERFLOWS * 65536 with your ROTATE implementation; I also combined the 10a/10b/10c corrections into a single...

I followed your instructions: I removed #define TIMER1 = TMR1L.Word and corrected T1CON to T1CON = 0b10000101, but it still throws an error. The only thing left is to use ROTATE instead of TEMP_OV = OVERFLOWS * 65536, but I don't understand how to do that. Could you show me the exact GCBASIC syntax you mean for replacing TEMP_OV = OVERFLOWS * 65536 with ROTATE?

TIMER1 is simply an alias for the 16-bit Timer1 value (TMR1H:TMR1L). I use #define TIMER1 = TMR1L.Word so that FREQUENZA = TIMER1 reads the complete 16-bit Timer1 counter value in one operation.

Yes, I agree; the problem isn't the STR32 function. The input signal is sinusoidal and is taken from the radio's mixer. Essentially, there is a VFO—which Drake calls a PTO—that generates a frequency; depending on the band switch position, this frequency is either added to or subtracted from the intermediate frequency (IF) value of 9,000,000 Hz. The PTO frequency ranges from 4,900,000 to 5,500,000 Hz. When the band switch is set to 80m, an optocoupler activates and pulls PIN_FOTO to logic low (zero);...

I can see that your test uses a changing FREQUENCY value, but it is not generated by the MISURA_FREQUENZA calculation. In my case, the problematic value is produced at runtime by the Timer1 measurement routine on RB6/T1CKI. FREQUENZA is built from TIMER1 and OVERFLOWS, then multiplied/divided before entering CORREGGI_CALCOLA. A directly assigned or otherwise externally changing FREQUENCY does not reproduce the fault on my PIC16F1847.

I tried to reduce the program to a minimal test case, but the problem cannot be reproduced in the reduced version. Even with the simulated frequency calculation, the complete correction routines and the gestione_IF routine, LongToString() works correctly. The problem only appears in the full application.

I replaced string.h with the updated version you provided and recompiled the complete project. The code size decreased from about 41,9 % to 37,7%, so the new Str32()/LongToString() implementation is definitely being used. However, on the real 16F1847 target I still get exactly the same incorrect result.

Follow-up test results I also tried LongToString(FREQUENZA) as you suggested, but unfortunately it produces exactly the same incorrect result as Str32(FREQUENZA). I then performed some additional tests to try to isolate the problem. FREQUENZA is correct when it comes out of the MISURA_FREQUENZA routine, and it is not altered by Str32() or by LongToString() at that point. IF_REALE is also correct, and both Print IF_REALE and Str32(IF_REALE) work correctly. The problem appears when FREQUENZA is processed...