int_tbe problems

Guest · Posted: Fri Feb 22, 2008 4:06 pm

Im using a PIC16F688, and compiler v. 4.058.

Ive got a fairly large program, and Im trying to implement the hardware uart. I cant get it to work. Its definitely too much code to post. The problem is that the transmitter buffer interrupt never fires. I made a simple test program using the code wizard, and still no luck getting into int_tbe.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

It only works with the hardware UART. You must specify the hardware
UART pins in the #use rs232() statement. For the 16F688, these are
pins C4 and C5, for Tx and Rx.

The hardware UART module is disabled by default upon power-on reset.
Because you specified non-hardware UART pins, the code to enable it
will not be generated by the compiler. The UART will remain disabled,
and no TBE interrupt will ever occur.

Guest · Posted: Sat Feb 23, 2008 11:28 pm

So if I use the non-hardware uart pins, I have to use the software uart? If the software doesnt use interrupts, how does the receiver know when its receiving a character?

newguy · Joined: 24 Jun 2004 Posts: 1908

It doesn't. You have to continually monitor it.

meereck · Joined: 09 Nov 2006 Posts: 173

Ttelmah · Guest

You would actually want a H_TO_L event. The start bit in TTL asynchronous serial, is a _low_.

Best Wishes

Douglas Kennedy · Joined: 07 Sep 2003 Posts: 755 Location: Florida

Ttelmah wrote

Ttelmah · Guest

Big problem is speed.
The edge 'event' will occur on the falling edge of the data bit. Even if no other interrupt handlers are present, you are talking something over 30 instruction times to actually reach the handler code. If you want to avoid a 'lockup' condition (if a spike triggers an edge, when no real data is present), you will need to have a kbhit, test then the actual read code. Now this is therefore going to be starting something like 40 instruction times _after_ the start of the character. At 4Mhz, and 9600bps, the 'bit time', is only 104 instructions. The read routine, by default, delays for half a bit time, before starting to sample the data (52 instructions in this example), meaning that you are now _very_ late in the bit. Only a small timing error, is then needed to give data errors....
The latter compilers, have an option 'SAMPLE_EARLY' for the software UART, which is really best used in this situation.
With a faster clock, or a lower baud rate, the problem reduces/disappears.
Remember also, that if you want to use a software UART to transmit data at the same time, the data on this, _will_ be corrupted, as soon as a character is received.

Best Wishes

Douglas Kennedy · Joined: 07 Sep 2003 Posts: 755 Location: Florida

Thanks Ttelmah for an excellent description. I wish I had tried SAMPLE_EARLY. I'm going to go back and give it a try.
Inside the interrupt on change isr I plan to be doing something this
If ( KBhit()) circ_buff[received_index++]=getc();
I'm at 4mhz on the internal osc rs232 is 9600 baud.

muratmaman · Joined: 30 Jan 2010 Posts: 19