RS485 Library for Windows and Atmel AVR 8-Bit
This project implements a half-duplex, master/slave communications protocol based on RS-485 bus hardware. A Windows PC acts as the bus-master, while several Atmel 8-bit AVRs function as bus-slaves. The Windows component is developed in C++, with the ninth data bit simulated by the parity bit, and the transceiver direction controlled by the RTS line. The AVR component is written in plain C and utilizes the multi-processor communication mode (MPCM). The protocol supports up to 128 participants. The code and makefile are designed for an ATmega8 but can be adapted for any other AVR with UART. A circuit is provided to convert a PC's standard serial interface (RS-232) to RS-485 for those without an existing RS-232 to RS-485 converter or RS-485 PCI card with appropriate Windows drivers. This passive converter does not require a microcontroller with two USARTs for translation. The +/-12V RS-232 signals are converted to 0V to +5V (TTL level) by a MAX232 (or similar), and the TTL signals are fed directly into a MAX485 (or compatible) RS-485 transceiver. The RTS line is also converted to TTL to control the direction of the RS-485 transceiver. This circuit provides a Windows PC with access to the RS-485 network. An extension of this circuit includes an ATmega8 for testing RS-485 communication between Windows and AVR. The library developed for this project implements a basic master/slave bus, where there is a single master and multiple slaves, each with a unique address. Communication is initiated by the master, and when the master sends a message to address 0, all slaves will read the message but none will respond, as this address serves as a broadcast address. The communication format is 9N1, meaning nine data bits, no parity, and one stop bit, with the ninth bit set during the address byte transmission. The baud rate is configurable in the makefile, with a default setting of 38,400 baud, which can be achieved by an AVR using an internal 8MHz oscillator with a minimal error rate of 0.2%. For a baud crystal (e.g., 14.7456 MHz), any baud rate can be selected with a 0% error rate. The MAX485 supports a maximum data rate of 2.5 Mbps, enabling the use of any baud rate that the ATmega8 can deliver. The library accommodates up to 128 participants, with the number of transceivers that can be connected to the bus depending on the specific transceiver model; for instance, the MAX485 allows for 32 transceivers, while the MAX487 allows for 128. The latest version of the library enables configuration of the port/pin controlling the RS-485 transceiver direction, with PD2 set as the default. Users can modify the port by adjusting the defined settings, ensuring that the data direction register and port register belong to the same port. In single UART AVRs, the library utilizes the only available UART, while in dual UART models, UART0 is the default. Users can set the define RS485_USE_UART to 1 to use UART1 instead. The library is designed to support all AVRs with one or two UARTs, although testing has been conducted with specific models: ATmega8, ATmega162, and ATmega1284P. Request messages are exclusively sent by the master (Windows PC), and slaves do not initiate requests.
The circuit design for the RS-485 communication system includes essential components such as the MAX232 and MAX485 transceivers. The MAX232 is responsible for converting the RS-232 signal levels to TTL compatible levels, which is critical for interfacing with the MAX485. The MAX485 serves as the RS-485 transceiver, facilitating communication over long distances and in noisy environments, which is a significant advantage of RS-485 over other communication protocols.
The physical connections in the circuit involve the TXD and RXD pins of the MAX232 connected to the corresponding RXD and TXD pins of the MAX485. The RTS line, necessary for controlling the direction of data flow in a half-duplex communication system, is also routed through the circuit. This RTS line must be properly configured to ensure that the MAX485 transceiver correctly switches between transmitting and receiving modes.
In terms of software, the implementation on the AVR side leverages the multi-processor communication mode, which allows multiple slaves to be addressed and managed effectively. The protocol's design ensures that the master can communicate with any slave by sending a specific address, while the broadcast capability enhances the system's flexibility.
The choice of baud rate can significantly impact the communication efficacy; therefore, careful consideration should be given to the selected rate to match the system's requirements. The library's support for various AVR models and configurations allows for extensive adaptability in different applications, making it suitable for a wide range of industrial and commercial communication tasks.This project implements a half-duplex, master/slave communications protocol based on RS-485 bus hardware. A Windows PC plays the role of bus-master and several Atmel 8-bit AVRs assume the role of bus-slaves.
The Windows part is written in C+, the ninth data bit is simulated by the parity bit, the transceiver direction is switched by the RTS line. The AVR part is written in plain C and features the multi-processor communication mode (MPCM). The protocol allows for up to 128 participants. Code and makefile are written for an ATmega8 but should be easily adaptable to any other AVR with UART. The following circuit can be used to convert a PC`s standard serial interface (RS-232) to RS-485 in case you do not have an RS-232 to RS-485 converter already or even an RS-485 PCI card with suitable Windows drivers.
The converter is passive in that it does not involve a microcontroller with two USARTs for translation. The +/-12V RS-232 signals are converted to 0V to +5V (TTL level) by a MAX232 (or similar). The TTL signals are directly feed into a MAX485 (or compatible) RS-485 transceiver. Not only the TXD/RXD lines are taken into account. The RTS line is also brought down to TTL in order to control the direction of the RS-485 transceiver.
The above circuit is a Windows PC`s ticket to the RS-485 world. Later we will see an extension of this circuit. It also contains an ATmega8 for testing RS-485 communication between Windows and AVR. I used this circuit for developing this library. The library implements a basic master/slave bus. There is a single master and multiple slaves. Each slave has its individual/unique address. (The master though has no address. ) All communication is initiated by the master. The slave which was addressed takes the data sent by the master and answers with a response message. If the master sends a message to address 0 then all slaves will read that message but none will respond. Address 0 is the broadcast address. Answering would not be a good idea because all the slaves would answer on the same bus at the same time which is not possible and results in communication error.
The communication happens in a 9N1 style, that is nine data bits, no parity and one stop bit. The ninth bit is set when an address byte is sent by the master. It is cleared in all other cases (master sends data bytes, slave returns response). The baud rate can be defined in the makefile. By default I use 38, 400 baud. This rate can be produced by an AVR driven by the internal 8MHz oscillator with a minimum error rate of 0. 2%. You are free to chose any baud rate with an error rate of 0% if you decide to use a baud crystal (say 14, 7456 MHz).
(A MAX485 has a maximum data rate of 2. 5 Mbps. That means that it is switching faster than your ATMega8. So any baud rate that the ATmega8 delivers can be used. ) The library supports up to 128 participants. How many transceivers can be actually connected to the bus depends on the transceivers. For example MAX485 allows 32 transceivers where MAX487 allows 128. The latest version allows for configuring the port/pin that controls direction of the RS-485 transceiver. PD2 is used as default. Should you want/need to use a different port then use the defines as shown in the following table. (Please be aware that data direction register and port register have to belong to the same port. Furthermore direction bit and pin bit need to designate the same pin. ) It goes without saying that, for single UART AVRs, this library uses the only UART available. For dual UART models UART0 is used by default. Set the define RS485_USE_UART to 1 if you want to use UART1 instead. Otherwise leave it undefined or set it to 0. In theory this library is supposed to support all AVRs with one/two UARTs. But it has been tested with these models only: ATmega8, ATmega162 and ATmega1284P. Request messages are only sent by the master (Windows PC). Slaves do not send requests. They 🔗 External reference
The circuit design for the RS-485 communication system includes essential components such as the MAX232 and MAX485 transceivers. The MAX232 is responsible for converting the RS-232 signal levels to TTL compatible levels, which is critical for interfacing with the MAX485. The MAX485 serves as the RS-485 transceiver, facilitating communication over long distances and in noisy environments, which is a significant advantage of RS-485 over other communication protocols.
The physical connections in the circuit involve the TXD and RXD pins of the MAX232 connected to the corresponding RXD and TXD pins of the MAX485. The RTS line, necessary for controlling the direction of data flow in a half-duplex communication system, is also routed through the circuit. This RTS line must be properly configured to ensure that the MAX485 transceiver correctly switches between transmitting and receiving modes.
In terms of software, the implementation on the AVR side leverages the multi-processor communication mode, which allows multiple slaves to be addressed and managed effectively. The protocol's design ensures that the master can communicate with any slave by sending a specific address, while the broadcast capability enhances the system's flexibility.
The choice of baud rate can significantly impact the communication efficacy; therefore, careful consideration should be given to the selected rate to match the system's requirements. The library's support for various AVR models and configurations allows for extensive adaptability in different applications, making it suitable for a wide range of industrial and commercial communication tasks.This project implements a half-duplex, master/slave communications protocol based on RS-485 bus hardware. A Windows PC plays the role of bus-master and several Atmel 8-bit AVRs assume the role of bus-slaves.
The Windows part is written in C+, the ninth data bit is simulated by the parity bit, the transceiver direction is switched by the RTS line. The AVR part is written in plain C and features the multi-processor communication mode (MPCM). The protocol allows for up to 128 participants. Code and makefile are written for an ATmega8 but should be easily adaptable to any other AVR with UART. The following circuit can be used to convert a PC`s standard serial interface (RS-232) to RS-485 in case you do not have an RS-232 to RS-485 converter already or even an RS-485 PCI card with suitable Windows drivers.
The converter is passive in that it does not involve a microcontroller with two USARTs for translation. The +/-12V RS-232 signals are converted to 0V to +5V (TTL level) by a MAX232 (or similar). The TTL signals are directly feed into a MAX485 (or compatible) RS-485 transceiver. Not only the TXD/RXD lines are taken into account. The RTS line is also brought down to TTL in order to control the direction of the RS-485 transceiver.
The above circuit is a Windows PC`s ticket to the RS-485 world. Later we will see an extension of this circuit. It also contains an ATmega8 for testing RS-485 communication between Windows and AVR. I used this circuit for developing this library. The library implements a basic master/slave bus. There is a single master and multiple slaves. Each slave has its individual/unique address. (The master though has no address. ) All communication is initiated by the master. The slave which was addressed takes the data sent by the master and answers with a response message. If the master sends a message to address 0 then all slaves will read that message but none will respond. Address 0 is the broadcast address. Answering would not be a good idea because all the slaves would answer on the same bus at the same time which is not possible and results in communication error.
The communication happens in a 9N1 style, that is nine data bits, no parity and one stop bit. The ninth bit is set when an address byte is sent by the master. It is cleared in all other cases (master sends data bytes, slave returns response). The baud rate can be defined in the makefile. By default I use 38, 400 baud. This rate can be produced by an AVR driven by the internal 8MHz oscillator with a minimum error rate of 0. 2%. You are free to chose any baud rate with an error rate of 0% if you decide to use a baud crystal (say 14, 7456 MHz).
(A MAX485 has a maximum data rate of 2. 5 Mbps. That means that it is switching faster than your ATMega8. So any baud rate that the ATmega8 delivers can be used. ) The library supports up to 128 participants. How many transceivers can be actually connected to the bus depends on the transceivers. For example MAX485 allows 32 transceivers where MAX487 allows 128. The latest version allows for configuring the port/pin that controls direction of the RS-485 transceiver. PD2 is used as default. Should you want/need to use a different port then use the defines as shown in the following table. (Please be aware that data direction register and port register have to belong to the same port. Furthermore direction bit and pin bit need to designate the same pin. ) It goes without saying that, for single UART AVRs, this library uses the only UART available. For dual UART models UART0 is used by default. Set the define RS485_USE_UART to 1 if you want to use UART1 instead. Otherwise leave it undefined or set it to 0. In theory this library is supposed to support all AVRs with one/two UARTs. But it has been tested with these models only: ATmega8, ATmega162 and ATmega1284P. Request messages are only sent by the master (Windows PC). Slaves do not send requests. They 🔗 External reference
Related Circuits
This document serves as a continuation of the previous work on PWM controllers utilizing 555 timers. The new design incorporates microcontrollers and MOSFETs in place of the 555 integrated circuits and transistors. Two versions have been developed: one equipped...
This circuit is designed to program AVR controllers, specifically the AT90S1200, using a parallel port. The circuit is very straightforward. IC1 serves as a buffer. The circuit operates by interfacing the parallel port of a computer with the AVR microcontroller....
It is now possible to program microcontrollers at home with a cost-effective AT89S51 series microcontroller burning IC kit. The AT89Sxx series ICs feature an inbuilt ISP (In-System Programming) module, allowing for easy programming of the microcontroller. This document presents...
The Ranco ETC-211000 utilizes an Atmega16L8 microcontroller. The chip comes with initial protection, necessitating an erasure before any code development can occur. The design has significant flaws, potentially ranking among the worst encountered during reverse engineering efforts, which span...
The intention is to utilize the sensor as a force sensor. It has been observed that the voltage output increases with the amount of pressure applied, although this output is only sustained for a brief period. This behavior is...
Nowadays, USB is the most popular connection between PCs and peripherals such as AVR programmers, printers, scanners, etc. For that reason, it was necessary to modify an old serial AVR In-System-Programmer (ISP) to work with a USB connection. One...