By just changing the Stream = RS485 BAUD to 9600 I get my code to work exactly as I want, with the problem that now both the interfaces are at 9600.

H/W setup:
RS485 Stream is connected to PC and Stream MODBUS is connected to MODBUS device.
When data is received from Modbus device it is displayed on the PC. Debug data constantly is printed to PC via RS485 stream

I have tested the wave forms at the MODBUS Side via a scope and they change when I change the RS 485 Stream.

Tried with opt 0 and 9 - same results. Tried using setup_uart() no luck!

Note: If it was an error of simply swapping streams, then I wouldn't need to change the baud on the PC to get it to display correct ASCII data._________________There is no virtue in not knowing that which can be known

Ttelmah

Joined: 11 Mar 2010Posts: 13260

Posted: Thu Apr 28, 2016 12:01 pm

I'm surprised you get data correctly at all.
The internal oscillator is 16MHz+/- 2%, not '16.384MHz'. This means the baud rate values will be incorrectly set, giving about 2.4% error. This is 'borderline' for RS232 to be operational....

With the RS485 stream set slower than the Modbus stream, there needs to be interrupt driven TX buffering, and gaps in the data, otherwise the PC link is never going to keep up. Since the code will have to wait to transmit.....
If it is trying to send data at 4800bps, that is arriving at 9600bps, after only a couple of characters the UART will overflow, and (without ERRORS), become permanently hung. This is why you are not seeing the Modbus data.....

ezflyr

Joined: 25 Oct 2010Posts: 1005Location: Tewksbury, MA

Posted: Thu Apr 28, 2016 1:03 pm

Hi,

Yes, and then there is the fact that your compiler is quite ancient..... I don't think it would ever be worth my time to mess with such an old compiler! What are you really saving anyway??_________________John

The internal oscillator is 16MHz+/- 2%, not '16.384MHz'. This means the baud rate values will be incorrectly set, giving about 2.4% error. This is 'borderline' for RS232 to be operational....

You mean to say that 16.384MHz is not possible, since the max supported is 16MHz with an error of +/- 2%? So even though I've set 16.384 it will be 16MHz throwing the rest of the calc off. Correct?

Quote:

ERRORS should _always_ be used with a hardware UART, unless you are adding your own error handling code.

Pls confirm - with ERRORS the _uC_ automatically clears any errors prior to transmission? The RS232_ERRORS can be accessed a_variable = RS232_ERRORS; The CCS help is rather basic. Can you please direct me to some literature where I can get more info / understanding? Thanks.

My understanding is that after all the fuses the #use delay( internal = 16.384MHz ) decides what the frequency is. i.e if PLL is enabled it will use the PLL to generate the required frequency, if PLL is disabled it will generate the frequency w/o the PLL. Kindly point to a resource where I can read up on this.

TX Buffering
The MODBUS doesnt dump to RS485. The Modbus populates internal variables which are called on the RS485._________________There is no virtue in not knowing that which can be known

Ttelmah

Joined: 11 Mar 2010Posts: 13260

Posted: Sun May 01, 2016 11:33 am

ERRORS does nothing to the transmit code.
It adds basically the same code as your error handling, to the _getc_.
If an overrun triggers, the interrupt will be called. The error handling wants to be in the INT_RDA. If an error does occur, RCSTA is copied into RS232_ERRORS. So if you test the FERR bit in this, it will give you your error indication.
Your code won't work, unless you are disabling interrupts round the error handler. If RCIF is set, the interrupt will be called, so the whole thing goes astray....

Yes, all the timings will be off. The chip generates 16MHz. You can adjust the frequency a little, but this is not a 'set it to XXX' type adjustment, but a 'tweak up/down', that has to be done relative to the tweak applied from the ROM, that is programmed at the factory to give the nominal 16MHz. The compiler loads the factory programmed tweak factor.