This week has been a very productive week for me. I ordered a USB to RS485 converter, so I was able to fully test my communication protocol. I also started testing the dimming card firmware. I had to make a small change to the way a slave module talks because the RS485 transceiver chips I'm using have a transmit and receive enable pins, which requires an extra output on the microcontroller. The extra pin is set high to enable transmit and low to enable receive. This is the first issue I ran into. Originally my write function looked like this.

void writeUartData (uint8_t* data, uint8_t length) {
    TX_nRX = 1; //RS-485 chip transmit enable is high
    
    int i;
    for (i = 0; i < length; ++i) {
        TXREG = *data;
        ++data;
        while (!TXIF) //TXIF is set when the TXREG is empty
            continue;
    }
    
    TX_nRX = 0; //RS-485 chip receive enable is low
}

As the comment says the TXIF, transmit interrupt flag, is set when the TXREG is empty. My oversight was the the TXREG is moved into the transmit shift register before it is sent, so just because the TXREG is empty doesn't mean that the message has been sent. I was disabling the transmit of the transceiver chip before the last byte was sent. All I had to do to remedy that bug was after the for loop wait for the transmit shift register to be empty before setting the transmit/receive output pin low.

while (!TRMT) //wait for transmit shift register to be empty
    continue;

This issue was made harder to diagnosis because I was using a buggy version of MPLabX to debug the program. MPLabX V2.05 has an issue with loading the PICKit3PlatformTool module. That failed module would cause the Debugger to not halt the program on my breakpoints most of the time. That issue lead me down the wrong troubleshooting path and I subsequently spend a while chasing a red herring. I finally paid attention to the error and warning messages I was getting during the application launch and saw the warning about the PICKit3PlatformTool not working. After I uninstalled V2.05 and installed the latest, V3.05, the Debugger worked as it was supposed to, and I was able to properly diagnosis the problem.

The next bug I ran into was the way C# handles the size of structs.

public struct CommValueInt {
    public byte channel;
    public short value;
}

The above struct is apparently 4 bytes in size instead of what I think should be 3 bytes. C# pads a byte between channel and value, so when I was dissecting the message in the slave I was one byte off from the start of the value variable. I might have manual construct a byte array for each message so I have better control of the size of the message.

The last issue I had to overcome was the PWM filter. The output voltage was all over and sporadic. That just boiled down to a resister not being pushed all the way into breadboard.