I'm trying to implement a simple communication between two LPC1765 devices using RS-485. I'm using this example added to my menu system (it's a basic example for LPC17xx):
http://www.codeforge.com/read/155431/rs485.c__html
http://www.codeforge.com/read/155431/rs485.h__html
http://www.codeforge.com/read/155431/rs485test.c__html
So, both devices are properly initialized using RS485Init(). When I send data using RS485Send using a slave address as the first byte, the result is:
(1) if the devices are disconnected, transmitter receives its own communication (the contents of UARTBuffer are updated
(2) if the devices are connected, nothing happens -- transmitted buffer is lost somewhere (UARTBuffer doesn't change)
Now hardware should be properly connected so I'll just list things for reference. There is a U59 SN65HVD1781D driver on RS485_TXD/RXD, there are RS485_OF, RS485_MASTER_PWR and RS485_MASTER_MFAS and a voltage regulator. There is a RS485 slave detect circuit and UP/DOWN connections. Each device is connected with four contacts and they are (I think) RS485_UP, RS485_A+, RS485_B- and RS485_DOWN. There is a 4-pin connector both on top and on the bottom to connect devices in a sequence, where the topmost device would, if everything works, assume the status of a master over all bottom devices.
I got RS485 to work.
Using LPC17xx user manual at http://www.nxp.com/documents/user_manual/UM10360.pdf
In rs485.c in function RS485Init, direction control bits were wrong with PINSEL1 instead of PINSEL4; according to manual page 110, this should be correct (well, you can write 0x800 in many ways, but this is just a quick fix):
if (DIR_CTRL == 1){
LPC_PINCON->PINSEL4 |= 0x800;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}else{
LPC_PINCON->PINSEL4 |= 0x8000;
LPC_UART1->RS485CTRL |= (RS485_DCTRL|RS485_SEL|RS485_OINV);
}
The second device has received my buffer.
Related
What I've been trying to do is send UART communications from an STM32 L152RE Nucleo board to an ESP32, however when I attempt to send these communications I get nothing on the ESP serial monitor. What I am able to see is the STM32 sending messages to its own serial monitor which is great but not what I want.
What I've read so far is that UART 2 is connected to ST-Link so that it can do specifically what I've been witnessing and it explains how this can be reconfigured to allow for the messages to be sent to a peripheral UART device but I'm not sure exactly how to do that.
So in the picture below it says to do this I need to "turn off" SB13 and SB14 and "turn on" SB62 and SB63. I don't really understand how to interpret that, other than to mean "remove resistors from SB13 and SB14 and Place them on SB62 and SB63", is this correct?
I know there are another set of UART pins on the board, can I use those instead somehow?
Your guess ist correct. "SB" means "Solder Bridge". It is just a pair of pads which can be connected with a solder ball, like a simple jumper. Setting SB13 to ON means to connect the pads with a solder ball, setting SB62 to OFF means to remove an existing solder ball connection.
Using a different USART is even easier. Have a look at the STM32L151xE Datasheet to find out that e.g. USART1 is available on pins PA9 (TX) and PA10 (RX). According to user manual of the NUCLEO-L152RE board these pins are available on the ST morpho connector CN10: PA9 at Pin 21 and PA10 at Pin 33.
I'm eventually trying to use transparent data transmission to pass messages between the mobile SDK and an onboard device using the A3 API/UART port.
Right now I used DJI assistant to output a timestamp to the API port at 1hz. When I connect a TTL>USB device, I see garbage data coming through. When I connect an oscilloscope with a protocol analyzer, I see one frame every second, but the frame is variable size. The ASCII representation of what does come through is nonsense.
I have double checked that baud is set correctly (and have tried other baud rates). I've made sure the grounding is proper. I've tried probing the pin on the actual A3 port (to remove possibility of EMI on the serial cable). It seems like I'm getting garbage data on the serial line, or I don't know how to decode it properly.
Hi，maybe you can refer to the open-protocol of M100 Link.I think it's difficult to decode the protocol of N3,unless DJI publishes that。
I'm developing an application with several serial ports. Each of these ports is handled by a different thread and has its own QSerialPort object. From a hardware point of view, they are connected hierarchicaly, meaning that there is one main device connected to the PC with a usb cable (1 COM port), to this main device there are several other devices connected, each of them having its own COM port. The main device can turn on/off the power supply to these child ports.
In the application, the ports are handled asynchronously. Each device object is running in its own loop. If its port is opened, it reads the incoming data. If the port is closed, it tries to open it in every loop until it succeeds. Each QSerialPort object handles errors on the errorOccurred signal. If it receives DeviceNotFoundError, PermissionError, ResourceError error, the port is closed (if it was opened) and the looping continues as described above.
The problem is that this serial communication part of the application is crashing (segmentation fault). I spent days finding the issue but with no results so far. To better understand what is going on, I wanted to ask here. Could it be a problem for QSerialPort if the main device turns off the power supply for the child ports while they're opened and are working? Or if the power supply is turned off while the child ports are being opened/closed or any other operation is being executed on them? (I don't want to include the specific executable code as it's a part of a bigger application and would be hard to make and executable from it. I'd like to discuss just the concepts described above if possible.)
Thanks for any help or ideas!
UPDATE
Creating of QSerialPort and putting it into a different thread:
QThread *t = new QThread(this)
SomeObject *o = new SomeObject(this);
o->moveToThread(t);
t->start();
Later in the SomeObject:
QSerialPort *port = new QSerialPort();
Try to destroy port object before power off, and recreate it after power on
QSerialPort *port = new QSerialPort();
//init and use
//....
delete port;
port = nullptr;
//turn the power off
//turn the power on
port = new QSerialPort();
I'm currently working on a project which involves dealing with a HW device tailor-made for this purpose.
The device will serve the purpose of sending certain data via serial port (COM1, for instance). The data it is supposed to send doesn't matter that much.
I already have some knowledge regarding Windows serial port communication. CreateFile, WriteFile, and so on... BUT...
There is one "engine" on the device, which will send me the data when I ask it to, and in order to do so, I need to send there a signal (10101010) the rate of which will indicate the clock rate of that device "engine".
Here comes the explanation of how this device work. It gets a signal to send data through one pin. I'm supposed to send there 0 for start, 1 for end. Then, after this, it will watch some other pin for signal, sample it, and based on the frequency of ones and zeroes I send to it, it will start sending data via the thrid pin.
My questions are:
How to access individual pins of COM port?
How to manage the frequency and any delays I will need by myself?
I think that maybe I will have to do on this in kernel more by use of device drivers which will have to be developed.
There is an easier way. The COM port will send out the signal of alternating 1s and 0s if you just send a 0xAA byte.
Is it possible to query serial port tx (send) pin status if it is active or not ?
For example when issuin break command (SetCommBreak) tx pin is set to active (low). I'd like to know when it is active or not. Thanks.
No. (at least not likely)
If you are using the "16550" family of UARTs, then I am confident that you can not query the serial port tx pin status. Of course, if you are using some new version or other UART family, maybe.
You can assume that the TX pin is in the SPACE state ('0', +Volts) whilst performing SetCommBreak(), but I suspect that is not enough for you.
If you are look to debug your code to know if a break occurred, you can short pins 2 & 3 on a 9-pin D-sub, thus loop backing the transmit to the receive. A paper clip will do. Your receive code would detect the incoming BREAK. Shorting to the incorrect pin does not cause a lasting problem with a conforming serial port, but be careful. Try this first with simple data, before testing BREAK condition.
If you have a "16550"-like UART.
You can put the UART into loop-back mode and see if you receiving you own outgoing BREAK signal. Its somewhat complicated in current PCs. Other UART type may support loop-back.