mikroElektronika

Hi to all,

i a previous project, I used 16F648 to simulate an electronic device communicating via RS232 bus (sending different frames depending received data, baud rate 19200). No problem at all, software is Interrupt driven and all bytes are handled in an array of bytes for receive and send purposes. When simulator receive RxData_001 frame, it send TxData_001 frame. When it receive RxData_002 frame, it send TxData_002 frame, and so on.

Today, I have to make a simulator of a (slave) device communicating via RS485 bus (baud rate 19200). This simulator has to work in the same way that previous RS232 project (for each specific received frame, it has to send a specific frame). It is my first project with RS485 protocol and I think I have understand the main principles. I decided to use a MAX487 that is connected to Rx/Tx pin of the UC, with a third pin for direction control. OK for all this. But I have always some questions about the best method to use to get and send data's.

After analysing data transmission between the device to simulate and other devices of the RS485 bus (1 master and 4 slaves), I have "recorded" all bytes of all frames that interest me in several arrays of bytes. On Rx and Tx sides, some frames are 16 bytes length, other frames are 22 bytes lenght and other frames are 80 bytes lenght.

If I read RS485 routine help of MikroPascal, I can see that pin used to select Tx/Rx direction is handled by RS485Slave receive / send routines. But data buffer that I have to pass in RS485Slave_xxxx procedures seems to be limited to 20 bytes. As some of my frames are bigger than 20 bytes, I don't know if this is the good way to work.

So, my question is : do I have read / write frames byte by byte as I did for my previous project (but here with manual set / clear of the rx/tx direction pin), or do I have omitted some special technique to do all this in a "professional" manner ?

In advance, thanks for any help.
Remy

Hi Remy,

The RS485 standard defines the physical layer rather than any protocol. The RS485 library from mE, on the other hand, is based on a simple protocol allowing to transmit small (0-3 bytes) data packets over master/slave network.

From what I understood, you don't actually need any protocol to decipher or code messages, you just mimic communication of some devices without going into details of any message. In such case, all you have to do is to adapt your previous project for RS232 communication by adding direction control for half-duplex RS485 communication. One thing to take care of is the right moment of switching direction from transmitting to receiving. Depending on how you determine the end of transmission, it will be necessary to add at least a byte or stop bit delay.
Note also that some protocols (like MODBUS) employ strict timing that will have to be observed as well.

Hi Janni,

thanks a lot for your help.

I already worked with modbus in the past (in ASCII and RTU mode), but only between devices and computer (under Delphi) and on RS232 point to point link.

Well, I'll try with my "old" method, byte by byte. Sure it is simpler in my case as I have no work to do with CRC or other calculation.

Feedback will follow here in some days.

Thanks again,
Remy

Hello,

just a little feedback, as promised.

I did as I said (byte by byte Rx frame handling). Before working with real programmed PIC, I simulated elec part running Proteus and MP V3.8 on a computer associated to a RS232/RS485 converter. This 232/485 converter was connected to the real RS485 devices and direction (Tx/Rx) was driven by one of the control lines of RS232 port (Proteus integrate a RS232 port model). So, the computer acted as a RS485 slave, just as the final PIC do.

All work as expected, thanks again for your help

Thanks for the feedback, Remy. It may help others with similar projects to know the outcome and it's always nice to hear that something went well .