Repurposing PIC16F877A 7 segment LED PCBs

Thank you sagor1. As the display will only change every minute, it won't hurt to introduce a small delay in the toggling.

Thanks for all your help! sagor1 was right about RC1. I now have the LEDs working, so moved on to getting the RS485 and UART side working. I wasted a lot of time trying to use USB to RS485 devices and just getting garbage, but finally got clean transmission using a USB to RS232 cable and an old serial to RS485 mini PCB. That is giving me the right data at pin 26 on the PIC. I send 4 digits, the MMSS from the PC clock plus #13 every 5 seconds, as in the attached trace.

Sometimes, the digits come through with extra bits on, like 93 instead of 33. I expect I will need to add validation code once the basics are working

My problem now is, if I plug values straight into portB I get say 4,5,6,7 displayed for ever more as I wold expect. When I try to read the 4 characters using an ISR routine, I get what appear to be random numbers appearing at different intervals. My guess is I'm doing implied character to int or vice versa in my code, which I've attached.

So if anyone can see the blindingly obvious that I can;t see, I would be grateful for pointing in the right direction. I see on my PicKit 3 that I'm just about to go over 200 reprogrammings for the PIC chip. Fortunately I have a few spares in case the legs fall off! The crystal on the PCB is AEXL009L and has 4.0000000 printed on it, which I make is 40MHz, although I'm not sure if the baud rate applies to receive side of the UART.

Are you still planning on using RS485? You mention a USB converter... Other than ask why (maybe distance or multi-chaining), I don't see why you don't use a USB to TTL level RS-232 converter. They are a dime a dozen on EBay. I use ones with the CP21xx chip in it, they seem to work fine. The PIC controller is TTL levels in the UART anyway.
Those older PICs run up to 20Mhz maximum, so your 4.0000 is indeed a 4.0Mhz crystal. You can;t change that without changing the baud rate of the UART In most cases, going to a 8.0Mhz usually works, making the baud rate double (but not always). A lot depends on how the UART clock is set up, with what registers...
Just some thoughts...

Hi,

yes, I have to use RS485, as that is what the PCB has installed. It uses a MAX3082 to convert the RS485 to TTL. I tried the USB dongles you mention, the CP2102 and the FTD ones, they both were giving framing errors all the time. Once I get the PCB working with the serial PCB, I'll try them again.

Switching the crystal to 4MHz (6 zeros instead of 7) has made the LEDs stay on 0000 much more. Before it was randomly changing the numbers. As I'm only poking 5 characters every 5 seconds, 9600 baud should be more than enough. The cabling will be about 50 metres when I remount them in our squash courts. It will use telephone grade twisted pairs.

If you are getting framing errors, it may be possible that the code has parity enabled (either odd or even), or it has enabled 9 bit data instead of 8 bit.
Just some options to check....

Hopefully, once I get it actually displaying the data I'm sending, I can go back to the USB converters. The serial board needs a 12v supply, which is a pain.

I was getting the framing errors on the output of the USB sticks.

Framing errors can sometimes be fixed by selecting two stop bits as this gives more time for the two ends to become synchronized again.

Also, in your ISR, the buffer can overrun and corrupt random memory. Maybe change it to,
The RCIE check is for if another interrupt is enabled at a later stage in development.

Mike.

Thanks Mike. I'll try that tomorrow.

One other thing, check the result of the calculated baudrate. Your baudrate variable if 16 bit and 9600*64 will overflow - not sure how MPLABX will handle this.

Mike.
Edit, check the baud rate tables in the datasheet. With BRGH=0 the closest baud rate is 8929 but with BRGH=1 it's 9615.

I've run into framing error problems if the PIC's baud rate is not an exact match to the USB/serial adapter. So, if the PIC's clock frequency only allows for a baud rate that is approximately equal to 9600 (for example), it may not work. The problem becomes worse as the baud rate increases. I was able to get around this with the FTDI chips because their drivers allow them to be set to virtually any baud rate, whether it is standard or not.

If BRGH=1 and SPBRG=25 then the rate is 9615 only 0.16% out. The software above seems to default to BRGH=0 and that gives an error of 7%.

Mike.