RB0 + Internal Pullup + Interrupt

[mackrackit]

I do not see the TX or RX connected to anything??

But... using http://www.picbasic.co.uk/forum/show...24&postcount=4
PIC MULTICALC the setting should be

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 129 ' 9600 Baud @ 20MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

[Freman]

No, in that schematic they're not connected to anything - but in reality they're hooked up to tx and rx of a usb-serial adapter. The schematic I posted was more to illustrate the reason behind the pullups being turned on.

The serial values I'm using are ones I've used in another project that's working... but I'll give yours a try.

Edit.

Nope, no change...

I have noticed tho that when I send data over the usb/serial cable that the voltage does in deed dip (drops from 4.95 to 4.60v) which indicates that the signal is being transmitted (my multimeter isn't fast enough to measure the full weight of the dip)

I've also done some testing on the usb/serial cable and have found it goes to 3v when high (again probably more, my multimeter can't keep up)

[Freman]

Oh dear - I feel stupid now...

I souldered the tx wire to dtr...

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

[Freman]

Which has left me with another problem...

The pic isn't recieving my strings right...

d and u are what I'm sending, d consistently returns v... don't know what u returns...

v returns 7, 7 makes the screen work in place of d

[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