Connecting the device to Arduino via the UART protocol

Question

The essence of the task

I have a task to connect an external device with my arduino and transfer data to each other via the UART protocol. The external device has 4 pins (Two for power supply and RS-485A and RS-485B), and I need to connect these 4 pins to the arduino nano pins (Either directly to the TX and RX pins, or, if possible, via usb on the arduino board)

I'm having problems with this, the data is not being transmitted. To transfer data, I need to send an array of bytes to it (for a request). In response, the external device sends it as a string for further processing for arduino.

To check the correctness of the data reading and parsing algorithm, I wrote an intermediate program on a PC that sends an array of bytes to an external device (To request a string of data) and sends the received string to arduino. On arduino, everything was read and parsed correctly from the PC. And I need them to be connected directly.

I would like to note that the external device has a CH340G chip.

I tried to connect via the MAX485, but it didn't work either. The connection was like this:

D4 -> DE
D4 -> RE
TX -> DI
RX -> RO
5V -> VCC
GND -> GND
A -> RS-485A (Device)
B -> RS-485B (Device)

I set D4 to HIGH before sending it, and set it to LOW after sending it.

Here is a piece of firmware on Arduino (The code itself is not complete, for example, there was a button poll above the loop)

 uint32_t flag = 0;
 uint8_t dataToSend[] = {
 0x23,
 0x08,
 0x00,
 0x46,
 0x00,
 0x0a,
 0xb8,
 0xa4,
 };
 void setup()
 {
 Serial.begin(115200);
 }
 void loop()
 {
 if (millis() - flag >= 250)
 {
 Serial.write(dataToSend, sizeof(dataToSend));
 uint32_t start_time = millis();
 while (millis() - start_time < 50)
 {
 if (Serial.available())
 {
 String response;
 response = Serial.readStringUntil('\r');
 
 // Data parsing
 break;
 }
 }
 flag = millis();
 }
 }

What is my mistake?

The data transfer rate is set the same with the device

• hcheung: "I set D4 to HIGH before sending it, and set it to LOW after sending it. there is nothing in your cod did that. There is not even in the code that you set D4 as OUTPUT with pinMode()? Please also provide the information(datasheet, link, library, etc.) of the "device" that you are communicating with. The dataToSend data object is suggesting a data structure similar to Modbus (but not exactly) with a 16-bit CRC checksum of 0xb8 and 0xa4 at the end of the payload, I seriously doubt that it will not return a similar data structure with crc, but an ASCII string terminated with \r.
• Michael: @hcheung Yes, I mistakenly cut the code with setting D4 to HIGH and LOW at the right moments, I left the redone code in the question (But this does not negate the fact that the code did not work for me, I also tried). Unfortunately, I don't have anything like that about the device description, except what I described in the question. It operates on RS-485 protocol, 115200 speed
• Rohit Gupta: Please read the help. You need to show us enough code so we can reproduce the problem.
• the busybee: Huh. Why are you changing the question so heavily? If you have a new issue, please post a new question, this site is not a forum. You can link back to the former question, if you think it is relevant.
• the busybee: I rolled back to the version with the initial issue. Please post another question about the issue of not receiving the expected reply.

Answer 1

What is my mistake?

You switch off the driver too early.

---

Serial transmission takes some time, in your case approximately 1 ms (8 bytes at 115200 baud). Since the write() method buffers the bytes to send, it returns quite soon and "long" before all bytes are sent.

Insert a delay before you switch off the driver, for example for 1 ms. You might want to calculate this more exactly and then use delayMicroseconds().

---

If the device reacts immediately, it would start its reply before the driver is disabled. Finding the exact delay is hard, and potentially not reproducible.

Then you would need some method to detect the end of the transmission. This would be your next step in development: do some research how to do this.