UART - software mode - Resolved

[DCW]

Hello --- so now I have a PIC16F688 running on internal clock at 8000000 Hz...
The hardware channel for the UART... is RC4 and RC5 ...
So when you connect a small circuit of RS232 chip and components to them and program a small program into the '688... you get a very good output..!!

However - when you decide to use the SOFTWARE UART, instead... at 9600 BAUD, and 8000000 Hz internal osc...say on RC2, and RC3.... NOTHING WORKS..!!!

WHAT IS WRONG PLEASE...BEN..???? AND DANIEL AND STEVE...????.. It should just work... should it not...????.. I mean you sposed to have checked this... NOT SO..???

WHAT IS THE SECRET..???? PLEASE..??? ... Can you guys tell me what I have to do... to make it work.... OR IS THIS A GENERAL BUG, that has to BE FIXED... for every single processor we select... by reporting it- then you fix it...????

I DUNNO..??? does anyone... else know...????

[Benj]

Hi Spencer,

8MHz is a bit slow for a software UART to generate reliable output at 9600 baud. Either increase the speed of the MCU or decrease the baud rate or both. Ideally 20MHz or faster.

With BoostC used in Flowcode v6 and previous the timings were very predictable and easy to generate software UART. With the newer XC8 compiler it is harder as the free version seems to do a partial de-optimise which is hard to predict. Don't get me wrong on this however, XC8 is a better overall compiler.

Ideally you should ALWAYS use a hardware UART where possible. Software UART is only there as a get out of jail and has very limited uses as many things can effect it. For example if you have interrupts firing in your program then this can corrupt the software UART data.

The chip you're using is now very old and there are pin compatible chips available which are much cheaper and packed full of new features e.g. more hardware UART channels and high speed built-in internal oscillators. Maybe you could consider moving to one of these?

I hope this makes sense.

I've been looking into assembler functions and generating the software UART code using assembler might allow us to work around some of the issues. I'll try and chase this up ASAP but I've a lot on my plate at the moment so I can't promise anything.

[Benj]

Hmm investigating further things do seem a bit broken regarding the software UART.

Increasing the clock speed is currently making the problem worse. In Pro XC8 anyway.

I'll spend some time on this today and see if I can improve things.

On inspection it looks like the micro second delay function in XC8 is a bit broken. In the Pro mode anyway, not confirmed in the standard mode yet.

A delay of 100us generates a baud of 4754bps
A delay of 99us generates a baud of 4289bps

which is totally wrong, the baud should go up with a smaller delay not down.

I'll keep investigating and see where I get to. It could be we have to re-work the us delay function or there are optimisations going on that are having a big impact on the timings. In which case assembler might be a good way to go.

Here's my test program.

FC_SW_Baud_Test.fcfx

(9.54 KiB) Downloaded 171 times

[medelec35]

Hi Ben,
Would using a selectable timer interrupt be the way to go?

[Benj]

Hi Martin,

Yes that might be a good way of doing it and would certainly be easier then assembler

Using assembler I've got much closer but the numbers are still somewhat bizarre. This is now working well at various clock rates but still needs work to build into the UART component. I think I need to think carefully about this as there may well be other issues with the assembler in larger programs.

Here's my test program, tested at 32MHz, 16MHz, 8MHz, 4Mhz at 9600 baud. Just tested transmitting, receiving is likely another kettle of fish

FC_SW_Baud_Test.fcfx

(12.07 KiB) Downloaded 167 times

I'll try this again tomorrow with the standard compiler and see what's happening there. Currently using the pro version.

Another option is to drop software UART support on 8-bit PICs, not ideal but may be the best option short term.

If there are any assembler guru's out there who want to have a look and try and optimise further then that would be great, my assembler is very rusty.

Spencer, you can probably export the tx macro from this program and import into your project and hopefully get much better transmission results.

[DCW]

Hello Ben.. and Martin... and others... GEE - thanks for this.
I will TRY ALL suggested, and see what happens.. maybe Martin ..( mnf).. could have a peek at this, and see .. I believe he is a real experimental GURU.
I am using the version 1.45 of the XC8 in PRO MODE.
If I have to upgrade, well then I have to upgrade.!! the XC8..
Thanks very much Ben for the loop you have given.. I will definitely try this tx loop, and see what happens.

Right - guys - back to work..!!

Kindest Regards
Spencer..

[DCW]

Hello guys.... yeah - just to report that I took the hardware option first..
I scratched around the PIC box... and found a "newer" PIC 16F1824... set it to 16000000 Hz... and just changed the options... and so now am very thankful to announce that... at 16000000 Hz... the SOFTWARE option - of the UART.. works pretty well - at 9600 BAUD...

Thank you BEN ... and will try further tests now...!! just to report back.. Thanks again...!!!

(So it seems that.. keep up the OSC frequency ... IT IS IMPORTANT.!!!).

Kindest Regards
Spencer..
DCW...