RB0 + Internal Pullup + Interrupt

[mackrackit]

Never fear tho - I've had my eyesight checked, and the idiot that left me in charge has been taken out the back and flogged

I always blame my bifocals when something like that happens

Your other problem... I will assume the 232 chip or equivalent is working and the settings on the machine sending the data are correct? I do not know what would cause the problem...

[Archangel]

@     device pic16F628A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_on, cpd_off, pwrt_off, mclr_off

You really want 2 PWRT statements here ?
Shouldn't you clear RCIF in your int handler ?

[Freman]

@     device pic16F628A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_on, cpd_off, pwrt_off, mclr_off

You really want 2 PWRT statements here ?
Shouldn't you clear RCIF in your int handler ?

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

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

Your other problem... I will assume the 232 chip or equivalent is working and the settings on the machine sending the data are correct? I do not know what would cause the problem...

I'm using a pl2303 chip mounted on a basic board (get them on ebay from china for $6 a pop, strip them down, cheaper then buying the individual components and you get spare parts)

Don't honestly know if they work right, they pass a loop back test - I'd probably need to pay a visit to my local electronics store and grab a null modem or equiv cable (Don't have any female 9pin plugs...) to test them properly - don't have any other serial ports in the house to use...

I've done some more scientific testing then firing random characters at the thing and seeing what it gives me back...

   DEBUG: Initializing
        DEBUG: Creating lockfile for /dev/ttyUSB2
        DEBUG: Opening serial port /dev/ttyUSB2
      DEBUG: Setting port configuration
        DEBUG: Writing settings
   DEBUG: Initialized
 DEBUG: Screen up
   DEBUG: Transmitting
      DEBUG: Sending: 00000001
     DEBUG: Sent 1 bytes
   DEBUG: Receiving
     DEBUG: Waiting for 4 bytes
     DEBUG: Received 4 bytes
      DEBUG: Received: 00000000,01010101,01010101,01111111
   DEBUG: Receive OK
DEBUG: Transmit Failed

So what I've done here is written a script that sends 0x01 to the pic, the pic is supposed to send back 0x55, 0x55, 0x01 0x01

The 0x55, 0x55, 0x01 is hardcoded, the second 0x01 is what it's received from the wire. (the 0x55 was chosen because it represents alternating 0's and 1's helps detect squishing bitrates)

What I'm getting back is 0x00, 0x55, 0x55, 0x7f, and it's consistent...

If I ask my script to read more bytes it reads back a maximum number of 5 - 00000000,01010101,01010101,01111111,01000000

If I send something different say, 0x7F I get back 00000000,01010101,01010101,01111111,00000001

0x02 00000000,01010101,01010101,01111111,01100000
0x03 00000000,01010101,01010101,01111111,00100000
0x04 00000000,01010101,01010101,01111111,01110000

So here, I made it output 0x00 - 0xff, 0x01, 0x04 - which should be 258 bytes, but I got back 252. so there's at least 6 missing bytes, and it appears to be talking to me inverted off by a bit...

00000000,11111101,11111011,11111001,11110111,11110 101,11110011,11110001,11101111,11101101,11101011,1 1101001,11100111,11100101,11100011,11100001,110111 11,11011101,11011011,11011001,11010111,11010101,11 010011,11010001,11001111,11001101,11001011,1100100 1,11000111,11000101,11000011,11000001,10111111,101 11101,10111011,10111001,10110111,10110101,10110011 ,10110001,10101111,10101101,10101011,10101001,1010 0111,10100101,10100011,10100001,10011111,10011101, 10011011,10011001,10010111,10010101,10010011,10010 001,10001111,10001101,10001011,10001001,10000111,1 0000101,10000011,10000001,01111111,01111101,011110 11,01111001,01110111,01110101,01110011,01110001,01 101111,01101101,01101011,01101001,01100111,0110010 1,01100011,01100001,01011111,01011101,01011011,010 11001,01010111,01010101,01010011,01010001,01001111 ,01001101,01001011,01001001,01000111,01000101,0100 0011,01000001,00111111,00111101,00111011,00111001, 00110111,00110101,00110011,00110001,00101111,00101 101,00101011,00101001,00100111,00100101,00100011,0 0100001,00011111,00011101,00011011,00011001,000101 11,00010101,00010011,00010001,00001111,00001101,00 001011,00001001,00000111,00000101,00000011,0000000 1,11111111,00111111,10011111,11101110,11101010,111 00110,11100010,11011110,11011010,11010110,11010010 ,11001110,11001010,11000110,11000010,10111110,1011 1010,10110110,10110010,10101110,10101010,10100110, 10100010,10011110,10011010,10010110,10010010,10001 110,10001010,10000110,10000010,01111110,01111010,0 1110110,01110010,01101110,01101010,01100110,011000 10,01011110,01011010,01010110,01010010,01001110,01 001010,01000110,01000010,00111110,00111010,0011011 0,00110010,00101110,00101010,00100110,00100010,000 11110,00011010,00010110,00010010,00001110,00001010 ,00000110,00000010,11111110,00011111,10001111,1101 1100,11010100,11001100,11000100,10111100,10110100, 10101100,10100100,10011100,10010100,10001100,10000 100,01111100,01110100,01101100,01100100,01011100,0 1010100,01001100,01000100,00111100,00110100,001011 00,00100100,00011100,00010100,00001100,00000100,11 111100,00001111,10000111,10111000,10101000,1001100 0,10001000,01111000,01101000,01011000,01001000,001 11000,00101000,00011000,00001000,11111000,00000111 ,10000011,01110000,01010000,00110000,00010000,1111 0000,00000011,10000001,11100000,00000001,10000000, 01111111,01110000

[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.