A RS-232 mystery

[melillo]

Hi everybody,

I'm trying to build a PIC based circuit to control a device (optical filter wheel) via a RS-232 connection. A description of the device can be found here: http://www.flicamera.com/pdf/HSFW_RevB_print.pdf. In short, if I want to select filter #1 I just send character "1", filter #1 character "2" and so on. If I connect the device to the computer and use the MikroElektronika Usart Terminal, I can control the device easily by sending the ascii values.

I have built a circuit identical to the one shown in the MikroC compiler help file in the Uart Library page, except for the PIC model - I use a PIC18F4620 (internal clock running at 8MHz) and a led connected to pin RA0. Here is the code:

Code: Select all

void main() {
     char uart_rd, i;

     OSCCON = 0b01110000;
     ADCON1 = 0x0F;        // PORTA digital
     CMCON = 0x07;         // disable comparators

     TRISA = 0x00;         // PORTA: output
     TRISB = 0xFF;         // PORTB: input
     TRISC = 0x00;
     TRISD = 0x00;

     // This loop is used just to make sure the PIC is ok (a led is on pin RA0)
     for ( i = 0; i < 5; i++ ){
          Delay_1sec();
          PORTA.F0 = 1;
          Delay_1sec();
          PORTA.F0 = 0;
     }

     UART1_Init(9600);

     Delay_ms(100);                  // Wait for UART module to stabilize

     for ( i = 0; i < 6; i++ ){
          UART1_Write(i + '0');
          UART1_Write(0x0D);
          Delay_1sec();
     }
}

If I connect my circuit to the computer, the ascii codes are transmitted perfectly. However, if I connect the circuit to the device, nothing happens. Yet, the ascii codes are identical to those I use when I connect the computer to the device.

Do you have any idea of the difference of the signal sent from the computer (using the mE usart terminal) and the one sent from my circuit? I noticed that when I compile the program, I get this warning: "Generated baud rate is 9615 bps (error=0.16 percent)". Could this be the problem?If you need further precisions, it will be a pleasure to inform you.

Thanks in advance and have a nice day,

Marc

[paulfjujo]

hello



Error of 0,6% must be acceptable..

Try to send CR LF instead of CR only..

Code: Select all

  
UART1_Write(0x0D);
UART1_Write(0x0A);

or the reverse

Code: Select all

  
UART1_Write(0x0A);
UART1_Write(0x0D);

[Sparky1039]

According to the manual sending the 0x0D carriage return character after the command byte(s) is correct. No need to send a "LF".
Interesting note: Nowhere in the manual does it state what the unit baud rate is. I assume it's 9600 by virtue of your successfully using it directly on a PC with the mE serial terminal program?

One thing I would do after configuring the PIC UART module is to wait at least 1/4 second (perhaps a bit longer) before sending any commands to the FLI. The manual states the units' serial timeout interval is 1/4 sec. During the PIC UART initialization process the TX line will typically "glitch" as it settles to the idle state (high). This could fool the FLI UART into thinking a command is coming in or sees it as a framing / overrun error. By waiting more than 1/4 second, it will allow the FLI to time out, reset it's UART buffer and accept new command byte(s).

[melillo]

Hi,

Thank you both for your help, but your suggestions didn't work.

paulfjujo: I tried all combinations of CR and LF, but none worked. In fact, with the mE Usart terminal, I don't need neither CR nor LF to work - the device ignores them.

Sparky: Yes, I use 9600 bps in mE Usart terminal. Your hypothesis about increasing the time between the initialization of the uart and the first command makes sense. So, instead of Delay_ms(100) after UART1_Init(9600), I put Delay_1sec(). Unfortunately, it didn't work.

Could the problem has something to do with hardware handshake lines (RTS, CTS, DTR, DSR) that I don't use (like in the mE help)?

Thanks again!
Marc

[Sparky1039]

Unfortunately the FLI documentation is quite sparse about it's UART hardware requirements so you are forced to experiment empirically.

Due to the tiny amounts of data exchanged it's unlikely any of the hardware handshaking is required by the FLI unit especially at 9600 baud.
As a suggestion try connecting only the TX, RX and ground lines of PIC/MAX232 and FLI to the DB-9 connectors, leave everything else unconnected, and see what happens.

Also, I would perform a loop back test of the MAX232 hardware with a PC just to validate this is indeed working correctly.

[android]

OSCCON = 0b01110000;

If you're using the Internal Oscillator I would have thought that OSCON needs to be:

Code: Select all

OSCCON = 0b01110010;

...to enable SCS1 (Select Clock Source to be INTOSC).
I'm not sure how your MCU is working at all unless you also set OSCTUNE to route your 8 MHz INTOSC through the PLL.

Are you seeing the LED flash at power up?

To be super sure, you could poll IOFS_bit (INTOSC frequency is stable) at power up.

[paulfjujo]

hello,

What is your PIC power supply 5V or 3,3V ?
did you check level voltage on MAX232 output ..

[melillo]

Hi folks,

Ok, I solved the problem this morning: I just swaped wires on pins 2 and 3 of the DB9 and it worked. A stupid mistake, I know!

Android: Yes, it works with OSCCON = 0b01110000. The 2 MSB are set to 0, which means that the Primary oscillator is used. In my configuration bits, FOSC3:FOSC0 are set to INTIO2, which set the primary oscillator as the internal one. That's why it works.

Anyway, a big thanks to all of you, I really appreciate.

Have a nice weekend,
Marc