how to redefine putc?

slavka012 · Joined: 10 Feb 2012 Posts: 28

I'm using serial IO in some of projects, and I'm having problems with s/w RS232.

My chip is running @ 4MHz, and communication speed is set 38400. The ideal bit length is therefore 26uS, and 26 instruction cycles. Normally it works, but seemingly randomly CCS compiler would generate code with bit length equal to 24 instruction cycles.

The way it works is like this: I have a perfectly working serial comm. As I continue to work on my project, at some point my communication would stop working, at which time I have to switch requested baudrate from 38400 to say 36400. Then starts working again, and work for some time, until my further changes to the project would trigger CCS back into generating proper bit length.

This has become extremely annoying, and happens through multiple updates of the compiler. I mean I could live with that if it was consistent systemic error. But it switches back and forth.

Currently the affected project is running on PIC16LF1907. In case you are wondering, it is not due to the CPU speed being off from nominal.

If this can't be fixed, can I just provide my own implementation of PUTC that does not suffer from such nonsense? If I just define new one compiler complains it's being redefined.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

slavka012 · Joined: 10 Feb 2012 Posts: 28

I don't have interrupts, and I have DISABLE_INTS just in case in my RS232 parameters.

I think you misunderstood. It is not randomly happening during execution. If it compiled correctly, it executes 100% fine. But sometimes compiler generates me wrong baud rate putc.

Here. This is compiled with baudrate 41667. The bit time should be 24 instruction cycles. But in the generated code one bit takes 26 instructions.

This weird number I had to put here because if I put 38400 it would (or, rather, could) generate putc with 28 cycles per bit. And it changes from time to time when I modify unrelated portions of code. Sometimes it gets it right, sometimes not.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Somewhere, I have the feeling that CCS published a method to redefine
stdout. You could define your own versions of the output functions
using a mechanism provided by CCS. I just can't find it in the manual
right now (if it even still exists). I am too busy right now. Maybe later.

Ttelmah · Joined: 11 Mar 2010 Posts: 19563

I think you will find the problem appears if you have a RX/getc used.
I seem to remember testing a while ago, and somewhere around 26 instructions was the shortest that the supplied code would reliably generate for getc. It can go slightly faster if the code only handles putc. If it can't 'cope', it switches the timings on both directions.
I have to ask 'why' you want to redefine putc though. Just replace all calls of putc, with your own routine name (my_putc...). If you want to use printf, then just redirect this.

slavka012 · Joined: 10 Feb 2012 Posts: 28

I'm using a lot of printf's for debugging purpose. So just creating my own my_putc is not sufficient.

26 instructions is not the shortest they can make. You can see at line 1EF two consecutive "goto $+1" instructions. So at least 4 cycles could be shed. In my experience with requested baudrate 38400 it can generate putc with either 24,26, or 28 instructions. And it changes for no apparent reason.

temtronic · Posted: Mon Nov 17, 2014 3:15 pm

need some more info...
1) that PIC has a 16Mhz internal osc any reason why you're running at 4 mHz ?

2) it also has a real UART...is it commited to another serial device.

I seem to recall that running PICs over 9600 baud with a 4MHz xtal was 'marginal'.... though that won't explain the code created.

3) if you need 2 UARTS can you use a PIC with 2 hardware UARTS that's still pin compatible with your project? while it might cost a few pennies more it will be cost effective i the long run.

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19563

I don't see why having your own my_putc is any more difficult for having a lot of debug outputs. Just do a search and replace on all your putc's, and it is done. If you use printf, then just replace 'printf("', with 'printf(my_putc,"'. Less than ten seconds work.
In fact if this is for debug, then normally you'd have a single debug_printf define used for the debug, so you can disable this by just defining this as nothing, which makes the change even easier. One line of code.

slavka012 · Joined: 10 Feb 2012 Posts: 28

slavka012 · Joined: 10 Feb 2012 Posts: 28

temtronic · Posted: Mon Nov 17, 2014 4:24 pm

I only wanted to know more in case you _could_ use an alternative PIC for the project. I was 'stung' years ago with a PIC that failed to communicate when it got bitterly cold had to redo the PCBs with xtals and caps. One of those 'it worked fine in the shop...failed in the real world'.

Regulars here _know_ the pitfalls of a sw uart but if you know them, then a sw uart will function ok, that's why I asked about 'upgrading' to a pIC with two UARTs.

As for the 'bug', it might be related to the compiler version. Fixing one thing might have caused another thing to go wacky. As Mr. T pointed out there is a 'workaround'. Hopefully it'll do the job for you!!

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19563

slavka012 · Joined: 10 Feb 2012 Posts: 28

So this is what I'm talking about.

I'm still compiling the same code, but bit lengths is now 22 instructions:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I asked CCS support if there was a method to globally replace putc and
getc, and here is their reply:

You can do this: