Firmware UART

[Desperate Dave]

Does anyone know if it is possible to force the compiler to use a firmware UART when using the hardware UART pins? The PIC I/O has Schmitt thresholds when acting as UART Rx, but TTL thresholds when acting as general purpose I/O. I don't want to make a hardware change and need a TTL threshold. (I'm not lazy, I'm in the UK, the board is in China).

[Ttelmah]

FORCE_SW
However most modern chips have ST buffers on these pins, even when used as digital I/O. For example, if you look at the 18F2520, or 18F2550, though the pins are described in the pin table as 'DIG', in both cases, the 'entry' paragraph about PORTC, says that it has ST buffers throughout.
The same is true of most of the 18 family chips.
To make things 'worse', the position is very confused on some chips (like the 16F690), which shows a 'ST' buffer feeding the UART, but shows it connected after the TTL input multiplexor switch...
You would need to carefully check for 'real' the input threshold of the pins involved.
Consider just adding a pull up resistor...

Best Wishes

[Desperate Dave]

I now have a solution if anyone else ever needs to know.

Use the device editor (under Tools) to create a copy of the 16F88 device file and change the UART pin numbers to na. Save this as 16F88NoUart. Make a copy of 16F88.h called 16F88NoUart.h and change the #device 16F88 in this file to #device 16F88NoUart. In the main file Change #include 16F88.h to #include 16F88NoUart.h. The compiler will now think the 16F88 has no hardware UART and will implement a firmware UART instead.

[Desperate Dave]

Thanks Ttelmah,

That's a much, much better solution. Why isn't FORCE_SW in the manual?
I'm using a 16F88, not a modern chip. I don't know why Arizona Microchip have such high and low thresholds for the ST input. I would have thought the old 1/3 and 2/3 of supply would give ample noise immunity.

I trust the user to reflash the chip, but not to modify the hardware, that's why I wanted this solution. Safer this way.

[Guest]

The change of the device file seems like a lot of work and is not compatible with future compiler updates.
Why didn't you use the ' FORCE_SW' option in the #use rs232 directive as suggested by Ttelmah?

[Guest]

Sorry... I see you changed your post while I was typing my message and you are now using FORCE_SW.

[Ttelmah]

As a comment, 'FORCE_SW', _is_ in the manual. Fifth entry down in the table of options for #USE RS232. There even in the manual over 50 versions ago!...

Best Wishes

[Desperate Dave]

FORCE_SW is not in my manual which is July 2003. P 61 has the #USE RS232 entry and definitely no FORCE_SW. There is a FORCE_HW for #USE I2C on P 60. If it was in my manual I woudn't have posted the query would I?

I'm sure you'll be glad to know the change to firmware UART has solved the problem and my client's dodgy hardware is now talking to the PIC.

[Ttelmah]

Have a look in the 'readme.txt' file, in the compiler directory.
It sounds as if your compiler, was right on the start of this feature, and the readme, includes changes that have occurred since the last module. Always worth a look.
I only posted that it was in the manual, because you seemed to think that CCS hadn't documented this. The comment still applies if you are not including the readme, with your reading...

Best Wishes

[Desperate Dave]

Hi Ttelmah,

I think perhaps it was a new feature. The FORCE_HW was stated as a new feature for I2C in the readme file. No mention of FORCE_SW in #use RS232 though. Still thanks to you I now know about it.

I have an auxiliary question on differences between the software and hardware functions. I realise a putc returns almost immediately with hardware USART as you'd expect, whereas it returns at the end of the stop bit with the software function. But a getc seems to return halfway through the stop bit with software USART, which is no doubt where the software samples. I think the hardware function returns at the end of the stop bit. This matters if you try to send immediately after receiving and use the same line for input and output like 1-wire. Do you know if this is the case? If so perhaps it should be documented somewhere, or maybe it is now.

[libor]

[Ttelmah]

I'd have to disagree with 'using the newest' with CCS....

They seem to have improved a little recently, but historically, the 'latest compiler' from CCS, is at times not even up to 'alpha' status, and is rarely better than a 'beta'. Every new version introuces new bugs. The key with CCS, is to use the 'last known good'. 2003, puts the compiler version in the early 3.200 area. These had got significant bugs, but were capable of producing quite usable code (certainly better than the 4.000 to about 4.03x versions). The 'best' V3 compiler, is 3.249, at which point the bugs were fairly well known, and 99% of the compiler worked well.

So, though I agree a 2003 compiler is very old, and does not provide some quite useful features present in the latter versions, I'd definitely shy away from automatically grabbing the latest with CCS, unless you also keep the older versions as well.

The documentation on 'FORCE_SW', is quite unusual. The feature seemed to appear in 2003, but was not added to the readme, instead going straight into the 2004 manual. It is actually perhaps surprising that it did work in the 2003 compiler.

Best Wishes

[libor]

I think with the 4.05x - 4.07x versions of the compiler we have already passed the curve's bottom and we are in the more-bugs-fixed-than-made-with-each-new-version territory already.