Hi.

Been struggling for awhile with this code:

#include <stdio.h>
#include <htc.h>
#include <conio.h>
#include "usart.h"


#define _XTAL_FREQ 4000000
 
/* Configuration */ 
__CONFIG    (WDTDIS & PWRTEN & MCLREN & BOREN & LVPDIS &  UNPROTECT & INTIO);

void main(void)
{
    unsigned char input;

    INTCON=0;    // purpose of disabling the interrupts.

    init_comms();    // set up the USART - settings defined in usart.h

    // Output a message to prompt the user for a keypress    
    printf("\rPress a key and I will echo it back:\n\r");

while(1)
{
        input = getchar();    // read a response from the user
         printf("\n\rI detected [%c]",input);    // echo it back
} // end while
} // end main

I've used the attached schematic, and I found the code in the Hi Tech C sample directory.

It's connected to Hyperterminal, and when I push the reset button, I get a message on the screen saying:"Press a key and I will echo it back:".

When I press any key, it doesn't respond. When I press the reset button, it starts over.

I've tried with getchar, getch, getche, all found in the headerfiles, and no errors while compiling.

I've tested the cable, and it seems to work ok.

What could cause this?

I'm using MPLAB 8.63, Hi Tech C v9.80

 

If you get data from your PIC. You know at least that something are correct. Like the baud rate generator. And that at least the transmitter is enabled correct. Your MAX232 may also be good at least for the transmitter part. Have you done some debugging to see if the register concerning receiving are correct? Also remember the KISS rule. Instead of sending a message like detected.... using the printf function. Just put the received char into the transmitter at register level.
You can do this by polling the RCIF interrupt flag bit of the PIR1. The

PIR1 register is set whenever the EUSART receiver is enabled and there is an unread character in the receive FIFO. Then read the RCREG and put the content into the TXREG. If you type one char at the time in hyperterm this will work as simple test​

 

One thing come mind Rottetryne. Can you open the dissambly Listing. And post a cut out of the putch function

 

Can you open the dissambly Listing. And post a cut out of the putch function

Do you mean this:

1:                 #include <htc.h>
2:                 #include <stdio.h>
3:                 #include "usart.h"
4:                 
5:                 void 
6:                 putch(unsigned char byte) 
7:                 {
   7BF    00F0     MOVWF 0x70
8:                     /* output one byte */
9:                     while(!TXIF)    /* set when register is empty */
   7C0    1283     BCF 0x3, 0x5
   7C1    1E0C     BTFSS 0xc, 0x4
   7C2    2FC0     GOTO 0x7c0
10:                        continue;
11:                    TXREG = byte;
   7C3    0870     MOVF 0x70, W
   7C4    0099     MOVWF 0x19
12:                }
   7C5    0008     RETURN
13:                
14:                unsigned char 
15:                getch() {
16:                    /* retrieve one byte */
17:                    while(!RCIF)    /* set when register is not empty */
   7B5    1283     BCF 0x3, 0x5
   7B6    1E8C     BTFSS 0xc, 0x5
   7B7    2FB5     GOTO 0x7b5
18:                        continue;
19:                    return RCREG;    
   7B8    081A     MOVF 0x1a, W
20:                }
   7B9    0008     RETURN
21:                
22:                unsigned char
23:                getche(void)
24:                {
25:                    unsigned char c;
26:                    putch(c = getch());
   7BA    27B5     CALL 0x7b5
   7BB    00F1     MOVWF 0x71
   7BC    27BF     CALL 0x7bf
27:                    return c;
   7BD    0871     MOVF 0x71, W
28:                }
   7BE    0008     RETURN

One thing come mind Rottetryne.

Before I got new glasses, I was more like Harry Potter. LOL

 

As far as I can see you have the correct code for putch and getch. Then you use the printf function in HI-Tech C. You must provide your own putch function. And by so far it looks OK. Did you test a more simple version working directly on the register level. Do you have a scope. So you can test the output from max232 chip. It could be something wrong so you do not receive anything on the PIC side

 

If instead of connecting them to the PIC, you connect the wires going to RX and TX together, anything you type into hyperterminal should get echoed back. If not the problem is not the PIC.

 

Nope, no scope.

When I measure with my digital voltmeter:

From PC, RX (pin 2) is -8.98v. When I press reset button, it jumps down to -7.99v. When I press a key in HyperTerminal, nothing.
From PC, TX (pin 3) is -11.25v. When I press reset, nothing. Nothing from HyperTerm.

From PIC, RB1 (pin 7) is 5.38v, nothing happens when I press reset or in HyperTerm.
From PIC, RB2 (pin 8) is 5.39v, when I press reset, it jumps down to 4.65v, nothing from HyperTerm.

 

If instead of connecting them to the PIC, you connect the wires going to RX and TX together, anything you type into hyperterminal should get echoed back. If not the problem is not the PIC.

That was a good one...

 

If instead of connecting them to the PIC, you connect the wires going to RX and TX together, anything you type into hyperterminal should get echoed back. If not the problem is not the PIC.

Do I dare connect them?

 

Nope, no scope.

When I measure with my digital voltmeter:

From PC, RX (pin 2) is -8.98v. When I press reset button, it jumps down to -7.99v. When I press a key in HyperTerminal, nothing.
From PC, TX (pin 3) is -11.25v. When I press reset, nothing. Nothing from HyperTerm.

From PIC, RB1 (pin 7) is 5.38v, nothing happens when I press reset or in HyperTerm.
From PIC, RB2 (pin 8) is 5.39v, when I press reset, it jumps down to 4.65v, nothing from HyperTerm.

A digital multimeter are way to slow to catch the RS232 signal changes. Have you turned off the flow controll in Hyper Term

 

I know its too slow, but it's what I have...

I thing I've tried nearly all settings in HyperTerminal.

 

Do I dare connect them?

You do have protective goggles I guess... Just joking. This will be safe it would be like connecting one output to an input not on the same gate on a logic circuit. On the Max232 you connect pin 12 and 11 together. But disconnect the pic first

 

Ok, I will try tomorrow.

Thanks.

 

Dunno if it's any use but this works fine on the 16F628A, it's in assembler. Probably best to ground pins 11 and 12 on the PIC so they aren't floating. Just type in numbers and see if anything changes.
http://www.marksphotos.info/fg/

 

Dunno if it's any use but this works fine on the 16F628A, it's in assembler. Probably best to ground pins 11 and 12 on the PIC so they aren't floating. Just type in numbers and see if anything changes.
http://www.marksphotos.info/fg/

I see you have:

movlw b'11110010'       ; RB7-RB4 and RB1(RX)=input, others output

in your code. I guess the important here is the RB1 pin...?

Could I be missing something like this...?

I can't check, 'cause I'm at work, but I think I remember something like

#define RX_PIN TRISB1
#define TX_PIN TRISB2

in the uart.h file. Perhaps the pin configuration for the RX_PIN is set the wrong way. Need to check later...

 

This can be somewhat confusing but the data sheet (16f628A) say

TRISB<1> and TRISB<2> should both be set to
‘1’ to configure the RB1/RX/DT and RB2/TX/CK
pins as inputs. Output drive, when required, is​

controlled by the peripheral circuitry.

 

OK. If I remember correct, both are set as 1 in the uart.h - file.

 

The datasheet must be inaccurate, because that code is working fine with RB2 as an output. Maybe it also works with it as an input, I haven't tried, I just copied some sample code from somewhere.

 

Lucky me, when it comes to computers, cards and laptop, I'm a bit of a hoarder...

I found a laptop with XP, startet HyperTerminal, and everything was working.

I guess this means that the com port is fired - Um that's fried, but fired works also...

Thanks for you effort.

 

Lucky me, when it comes to computers, cards and laptop, I'm a bit of a hoarder...
I found a laptop with XP, startet HyperTerminal, and everything was working.
I guess this means that the com port is fired - Um that's fried, but fired works also...
Thanks for you effort.

DoH! So that was the error. Anyway since you are so good at finding things. USB to RS232 dongles work OK in most cases. At least for simple work of the type you are doing now. It may take some googling if you do not have a driver