Debugging Code Question

ilmenator · November 1, 2002, 4:31pm

Hi Thorsten,

I’m trying to do some debugging for my filter code (NRPN to CC and vice versa, see other topic). Now, I would need to feed the debugger some MIDI bytes to see where the program branches to and what the registers are.

Could you please tell me where to insert those MIDI bytes (say BF 63 23 BF 62 17 BF 06 03 BF 26 00 for a NRPN message) into the debugger? Which are the addresses/labels in the source code where the stimulus values are to be injected into the register? Which are the file register addresses/names where the values are to be injected?

Btw, do you use the MPLAB environment for your work?

Best regards, ilmenator

T.K · November 1, 2002, 11:01pm

Hi,

normaly I don’t use a debugger for my code. The MPLAB simulator is nice for verifying algorithms, but useless for checking a realtime system.

Here an extract of different debugging methods I’m using:

I print out some values on a LCD if I want to check the behaviour of my routines during runtime. This is only usefull if only a small number of values have to be displayed which don’t change too fast.
for fast changes I write the values into a seperate SFR region which acts as a ringbuffer and which is printed out by the LCD on every mainloop cycle. On this way the SFR region acts as “trace memory”.
When I have to observe a lot of value changes, I send them out as MIDI events and use MIDI-Ox to write them into a logfile
When I have to send stimuli to the core module, I use the SysEx editor of MIDI-Ox which allows to send any (also invalid!) MIDI data. (type “BF 63 23 BF 62 17” into the command window and press the send button). The SysEx editor can also be used to save the stimuli
I generate stimuli files with a short perl script, send them out with the SysEx editor, save the responses from the core module into a logfile and use a second perl script to filter out the data which is interesting for me
I use a MIDIbox as stimulus generator
I use a scope which is connected to the spare pin (J14) to monitor internal events in realtime. On this way I see how many times a particular routine is executed and how long it does get

Best Regards, Thorsten.

ilmenator · November 2, 2002, 12:33am

Hi,

thanks for your reply. I got around to modifying the relevant registers in the debugger and can now simulate an incoming MIDI message.

The problem seems to be within the following: I’m using the WGT and WLTEQ macros that you provide in macros.h to check a statement like value 1 > value 2 or value 1 =< value 2.

     ;; if JITTER_DELTA < DELTA2
      movf      DELTA2, W
      WLTEQ      JITTER_DELTA, goto Jit_Test_4 ; result true: JITTER_DELTA < DELTA2
      goto      Jit_Test_3            ; result not true: JITTER_DELTA >= DELTA2

The problem is that the results sometimes do not seem to be right. Still, this cannot be a fault of your macro, because even with this code I get the same strange behaviour:

     movf      DELTA2, W
      subwf      JITTER_DELTA, W      ; subtract DELTA2 from JITTER_DELTA, store result in W

      ;; is the result true ?
      btfss      W, C
      goto      Jit_Test_3            ; result not true: JITTER_DELTA >= DELTA2
      goto      Jit_Test_4            ; result true: JITTER_DELTA < DELTA2

I already exchanged the last two lines of code, which gives me a correct comparison in some cases - in other cases it is just the other way round.

Is there something I overlook? When compiling, I get two warnings like:

Command line: “C:\PROGRA~1\MPLAB\MPASMWIN.EXE /p16F877 /q C:\PROGRA~1\MPLAB\SM-CONV\MAIN.ASM”

Warning[202] C:\PROGRAMME\MPLAB\SM-CONV\MACROS.H 32 : Argument out of range. Least significant bits used.

Warning[202] C:\PROGRAMME\MPLAB\SM-CONV\MACROS.H 38 : Argument out of range. Least significant bits used.

I do not get these warnings without use of the macros, but the effect is still the same - sometimes the comparison works okay, sometimes the result is just utterly wrong, depending on the two input values… ???

Any hint is much appreciated… this topic might also be discussed in german language, if this is easier to anyone…

Sigh, ilmenator

T.K · November 2, 2002, 2:17am

To which address did you assign the DELTA registers? If you want to access them on the normal way, they should be in between 0x20 and 0x7f. Registers above this range are located in different banks, and you have to switch to the appr. bank to get the right values.

An oversight of available RAM registers for PIC16F877:

0x20-0x6f: Bank 0

0x70-0x7f: all Banks

0xa0-0xef: Bank 1

0xf0-0xff: all Banks

0x110-0x16e: Bank 2

0x170-0x17f: all Banks

0x1a0-0x1ef: Bank 3

0x1f0-0xff: all Banks

Microchip recomments the use of a special assember directive to switch between the banks. But this directive generates 2 instructions for each bankswitching, and so I’ve created some macros which helps me to reduce the code, it’s:

SWITCHBANK_0_1, 0_2, 0_3, 1_0, … 3_0

So, when your delta registers are located in Bank 1, write this:

SWITCHBANK_0_1

movf DELTA2, W

subwf JITTER_DELTA, W

SWITCHBANK_1_0

If JITTER_DELTA is a constant, write:

SWITCHBANK_0_1

movf DELTA2, W

sublw JITTER_DELTA

SWITCHBANK_1_0

Note: sometimes it’s easier to access the registers indirectly.

Btw.: here the jitter elimination code of MIDIbox MF. IRQFADER_SNAP contains the target position, IRQFADER_VALUE the current position:

      ;; --- check distance between current and target position
        ;; --- if fader is in between "deadband", don't move it
        ;; addlw 255 - Hi
        ;; addlw (Hi - Lo) + 1
        ;; Carry is set if W is in range Lo - Hi
        movf    IRQFADER_SNAP, W
        addlw   1
        skpnc
        movlw   0xff
        sublw   0xff
        movwf   IRQ_TMP1

        movf    IRQFADER_VALUE, W       ; get last sampled value
        addwf   IRQ_TMP1, W             ; compare it with snapped value
        addlw   2+1
        bnc     MOTOR_Move              ; carry is set if value is in between range
        bz      MOTOR_Move              ; special case if fader == 0xff and target == 0x00

MOTOR_DontMove
        ;; --- Dont Move Fader -> Standby
        call    MOTOR_StandBy

Best Regards, Thorsten.

ilmenator · November 2, 2002, 2:33am

Hi Thorsten,

this could be the problem, the delta registers are like this:

FMPV1            EQU      0x1f1
FMPV2            EQU      0x1f2
DELTA1            EQU      0x1f3            ; Jitter Eater Delta 1
DELTA2            EQU      0x1f4            ; Jitter Eater Delta 2
JITTER_DELTA      EQU      0x1f5            ; max. Jitter Delta

Still, it seems to be working when modifying the code like this, means testing with “skpnc” instead of “btfss”:

Jit_Test_2
      ;; Jit_Test_1 was true (bit=1): JITTER_DELTA < DELTA1

      ;; if JITTER_DELTA < DELTA2
      movf      DELTA2, W
      subwf      JITTER_DELTA, W      ; subtract DELTA2 from JITTER_DELTA, store result in W

      ;; is the result true ?
      skpnc
      goto      Jit_Test_3            ; result not true: JITTER_DELTA >= DELTA2
      goto      Jit_Test_4            ; result true: JITTER_DELTA < DELTA2

The two Deltas are StudioMix specific, Wayne Legro describes two kinds of jitter: one is the normal jittering around one value, the other is jitter around two different values, one like e.g. around 10, the other around 80 (out of NRPN value total).

I’ll take a look at your code examples tomorrow - have to go to bed now…

Good night, ilmenator

T.K · November 2, 2002, 3:24am

In fact this is one kind of jitter when you combine the High- and Low byte to a 14-bit value.

Since you want to send out a 7-bit value, the simplest way is to work internally with 8-bit values - the NRPN can be converted on this way:

       clrc
        rlf     NRPN_HI, W         ; shift left NRPN High byte
        IFSET   NRPN_LO, 6, iorlw 0x01   ; copy MSB of NRPN low Byte (7-bit) to Bit 0  
        movwf   FADER_VALUE    ; save result in FADER_VALUE

Best Regards, Thorsten.

P.S.: your registers do partly overlap the RINGBUFFER0 address area at 0x70-0x7b. Suggestion: move the ringbuffer to Bank1 and locate the registers in between 0x30 and 0x7b.

;; 0xa0-0xef: SUART IN Ringbuffer

RINGBUFFER0 EQU 0xa0

RINGBUFFER0_END EQU 0xef

The Ringbuffer could also be located in Bank 2 or 3, but for this some additional changes are required

ilmenator · November 3, 2002, 8:36pm

Now, I changed the ringbuffer’s location as you suggested, everything’s running smooth now.

The problem with your 8-bit jitter-detection is, that the Studiomix’s faders do not reach the upmost and downmost positions. This means that if I pull the fader down, I get a min. value of say 01 3F (High-Byte, Low-Byte), if I pull it up, it ends at say 7D 22. Now, if I convert the 14-bit values to 8 bit values, there is fewer than 1 bit left for jitter correction. This can clearly be seen in MIDI-Ox, where depending on JITTER_DELTA the values change in steps of 2 or 3 (= jumps in the fader movement), but not smoothly any more.

The way I see it, it should be done this way: leave the values 14 bit, do some jitter correction, then scale the values down to 7 bit in such a way that 00 is the smallest value and 7F the highest value that is sent.

I would be happy if there was an easier way, though!

T.K · November 4, 2002, 3:21am

Ok, under this circumstances I would do it on the same way.

Hm

No, I would replace the StudioMix fader logic by the MIDIbox MF driver ;D

(Just kidding ;-))

Best Regards, Thorsten.

ilmenator · November 4, 2002, 7:19pm

I have actually been thinking about this. But you know, the unit is new, I loose my guarantee, and I’m not sure it is going to work the way I expect it… Maybe I could extract the logic circuits and just use the hardware (motor faders, buttons and incremental knobs). But then again, it might be easier to build a fader box from scratch…

Well, I’ll keep you informed. Thanks anyway,

ilmenator