PROBLEMS with SOFTWARE USART ON PIC16F876! PLEASE HELP!

[tyro]

Hello. I have a problem sending and getting BYTES from PIC to Hyperterminal and otherwise with my own SOFTWARE SERIAL functions. With put_char() a byte is only sent right at 9600 bps. with get_char() nothing is incoming right at any speed. I need both functions at 115kbps! I´ve also tried a lot with the timing (delay_cycles(24) --> 1bit at 115k), but nothing works.

Can somebody help me?

Here is my code:

[ckielstra]

First of all, why are you not using the CCS supplied software serial functions?

As you already figured out at 11059200Hz a single bit takes 24 instruction cycles, not 24us. Replace delay_us() by delay_cycles().

The main problem in your functions is timing. Have a look at the generated assembly code for your functions in the generated *.lst file and you'll see there is some overhead to be compensated for. Count all the assembly instructions and make corrections for this in the delay_cycles() calls. Remember that jump instructions take two instruction cycles.

[tyro]

Oh sorry the

[rwyoung]

[tyro]

No, the problem is, i need 115kbps connection inverted on PIN_C6 and PIN_C7. Because the circuit board is already made. I have realized too late that i need inverted output to control the IR transceiver on this board.

[rwyoung]

[Ttelmah]

The problem here is that you cannot 'invert' the hardware UART.
You should still be able to use an inverted software UART, on the hardware UART pins, by using the 'FORCE_SW' command, and 'INVERT'.
This should work fine, but you need both commands in the #USE RS232, for it to work.

Best Wishes

[tyro]

No, no, no. This is not the problem. I must INVERT my output. Let me explain:

The old board I have, is only PIC16f876 communicating wired with Nokia. The software with hardware usart works fine at 115k without inverting.

Now I have a PIC16f876 on a new board with an TFDU4100 IR-transceiver, who should communicate with Nokia handy wireless.

But now with IR-transceiver I must invert the pic in-/output, because I noticed too late that the RX/TX must be inverted with this IR transceiver.

Therefore I´ve tried to put FORCE_SW and INVERT in #use rs232 and to use fputc() & fgetc() again. But it didn´t work.

This is the reason, why I wrote my own software serial functions.

I have tested my put_char() at 9600 bps with PIC <-MAX232-> Hyperterminal and it works fine. At faster speeds with the right delays it doesn´t work.

I only want these functions to work fine.

[Ttelmah]

I am very suprised the internal functions don't work for you, since they are generally reliable.
One thing that is very 'strange' about the code you post, is that it does _not_ properly invert the data. I am almost suspicious, that you misunderstand the polarity of serial communications. 'TTl' (well CMOS for the PIC) serial (as at the PIC), idles high. The 'stop' bit is a 5v level, while the 'start' bit is 0v. These levels are then increased in ampiltude, and 'inverted', when transmitted using RS232. As such the TTL levels agree with what you are trying to transmit.
'Inverted' TTL serial, idles at 0v, and starts with a 5v level.
Have you tried the internal routines, without using invert?...

That having been said, the problem on your code, is that with higher baud rates, getting the timing calculations 'right', involves including every instruction in the calculation. Basically in your transmit loop, you need to compile the function using 'delay_cycles(1)', look at the list file, and count the instructions involved in the loop. I'd expect that the 'for' itelf, will use about four instruction times, the test and jump, another three, and the shift, probably half a dozen instruction times. These then need to be subtracted from the delay value put into your loop. At 9600bps, a timing 'error' of perhaps 4uSec, won't be significant, but as the rate rises, you need to compensate for the overheads.

Best Wishes

[rwyoung]

RJ is right, trying to do your own software uart in C is going to come out wrong at high speeds.

Go back to the CCS software uart, use the INVERT command.

Use an oscilloscope to look at the signal on your IR module's Txd pin and also its IRED cathode pin. Do they make sense? Are the timings right?

You do have the limiting resistor selected properly, right? Can you detect anything coming out of the module (with either another module or by looking at the IRED cathode pin)?
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[tyro]

This MUST BE the right way of using start and stopbit. You can see here: www.winpicprog.co.uk/pic_tutorial7.htm

The reason i´m not using INVERT in the example above is, I wrote that code for hyperterminal usage, not for acting with the IR transceiver. Its only a put_char()-get_char() test.

This code leaves PIC and is inverted by the max232 and back in PC.

But on my board, transceiving with nokia phone, the pic inverts the signal and IR transceiver inverts back, so its sent absolutely right, like the pic is wired directly to the Nokia phone.

Thank you for the idea with the many instruction cycles, the pic needs in loops. i will check that in the listfile!!!! Thanks.
I will need fewer cycles.

[Ttelmah]

So you post an example, and in fact have sent code that differs from what you are trying. A great way to ask questions, and also a good way to generate errors.
If you want to do this with reversable bits, for future reference, use the #if ability of the compiler. So:

[tyro]

Oh thanks Ttelmah for your code. It looks good. I will try it tomorrow. I know not exactly what you mean with the receive code. Could you be so nice and put an example of an get_char function in here, like the put_char of you.

Thanks a lot

[ckielstra]

At least one more error in your code.

[Ttelmah]

Data is sent LSB first, so shift right is correct.

Best Wishes