RB0 + Internal Pullup + Interrupt

[Archangel]

Umm, well... I don't understand the header... I sort of found one that worked and stuck with it

That's a honest answer!

Doesn't reading from RCIF clear it?
Doesn't a while statement read it?

Here is My honest answer, probably does, I do not know for sure if it does, or not, that is why I said it as a question

[Freman]

That's a honest answer!

Here is My honest answer, probably does, I do not know for sure if it does, or not, that is why I said it as a question

I've had a look at the datasheet for the pic, and it states

"Flag bit RCIF is a read-only bit, which is cleared by the hardware. It is cleared when the RCREG register has been read and is empty."

So the WHILE isn't actually resetting it, reading RCREG is.

I also found the datasheet for the PL-2303, it rx's at TTL (5v levels) and tx's at 3.3v - so that's some concrete information, but doesn't really help with what seems like inversion...

[Freman]

I've just finished testing the USB-Serial cable, and it appears to be working.

I've hooked it up TX-RX, RX-TX, GND-GND to a PC serial port (Real hardware kind) and I can send and recieve data to and from the device without any form of corruption.

Which brings me back to my original query... are the pullup's in the PIC breaking my serial communications?

If so, can anyone come up with a simple way to re-do the input detection of the buttons? (I have spare pins on the pic if that helps )

Edit:

Actually I think I found the answer to my problem "The HW USART output is inverted as it is designed to work with an RS232 driver." that means I must have built my FT232 circuit to use the inverted output/input (the FT232 chip is very smart, I just don't remember doing that...) I haven't been using a max232 chip on this project because the voltages were within tolerance, and I just don't have the room... maybe I'll have to build an external serial adapter...

[Archangel]

I've just finished testing the USB-Serial cable, and it appears to be working.

I've hooked it up TX-RX, RX-TX, GND-GND to a PC serial port (Real hardware kind) and I can send and recieve data to and from the device without any form of corruption.

Which brings me back to my original query... are the pullup's in the PIC breaking my serial communications?

If so, can anyone come up with a simple way to re-do the input detection of the buttons? (I have spare pins on the pic if that helps )

Edit:

Actually I think I found the answer to my problem "The HW USART output is inverted as it is designed to work with an RS232 driver." that means I must have built my FT232 circuit to use the inverted output/input (the FT232 chip is very smart, I just don't remember doing that...) I haven't been using a max232 chip on this project because the voltages were within tolerance, and I just don't have the room... maybe I'll have to build an external serial adapter...

Hi Freman,
I have never used HSEROUT . HSERIN requires you to send data to it TRUE, and idles in the HIGH state. This from the data sheet . . . <b>
"The USART’s transmitter and receiver are functionally
independent but use the same data format and baud rate." </b>
and this:
<b> "Clearing enable bit TXEN during a transmission will cause the
transmission to be aborted and will Reset the
transmitter. As a result the RB2/TX/CK pin will revert to
hi-impedance."</b>
This suggests to me it transmits TRUE too. Fact is I do not know, but the evidence suggests it.

[mackrackit]

I haven't been using a max232 chip on this project because the voltages were within tolerance, and I just don't have the room... maybe I'll have to build an external serial adapter...

I think that solves it. Look at the PBP manual.
Install an inverter as the manual states when using hardware serial or change your code to software, SERIN2/SEROUT2, and get back with us.

[Freman]

*sigh* Just another one of the things that leave me asking WTF were they thinking when they designed these chips... oh well..

[mackrackit]

*sigh* Just another one of the things that leave me asking WTF were they thinking when they designed these chips... oh well..

I bet they had a good reason.... Who knows what it was. Might be that a 232 type chip can bring the levels up to true RS232 levels that a micro can not because of the voltage they run at.

Most times the software solution will work and you then have the benifit of using most any pin. About the only time I use hardware (HSERIN/OUT) is if I need it running in the background as in an interrupt. Of course if something else triggers the interrupt then you can have the software routine in that interrupt.

All kinds of possibilities.