i cannot figure this out by myself. What is the point of the RTS (direction) line in the RS485 ModBus communication?
There is no description about it on the internet, all the images in google only show the RX & TX lines but i know that RTS is also used.
Thanks
The only use of RTS in the context of RS485 based communications is so-called RS485 Transceiver Control (see for example the related Docklight RS485 setting). In Microsoft Windows API for serial communications, this mode is called RTS_CONTROL_TOGGLE:
Specifies that the RTS line will be high if bytes are available for transmission. After all buffered bytes have been sent, the RTS line will be low.
It has nothing to do with the 2-wire RS485 bus and the MODBUS application protocol used on such a bus. But some older RS232-to-RS485 (or USB-to-RS485) converters require the RTS signal to be set to high before transmitting any data, and reset it to low for receiving data.
Most standard RS485 interfaces and converters for PC can handle this switch between transmit and receive automatically, so they don't need the RTS at all. Just for example - For the popular MOXA brand this is called ADDC (Automatic Data Direction Control).
Related
I want to send data through USB between STM32 and Raspberry Pi. I don't want to use USB to Serial convertor, but instead have a actual USB Connection (maybe CDC class). I have to send data at high rate (Full speed). Please guide on how to achieve this?
A USB-serial connector is simply a microcontroller implementing a USB CDC/ACM virtual COM port and bridging to a UART which you would connect to a microcontroller's UART interface.
In your case you can simply implement the CDC/ACM directly on the STM32 using either of its USB device controller peripherals (USB support varies depending on the specific device https://www.st.com/resource/en/application_note/dm00296349-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf).
How you actually implement that will depend on what specific part, and what library or framework ecosystem you are using (e.g. SPL, CubeMX, Mbed). There are reference implementations, examples, drivers and libraries for all of these.
Your milage may vary, but I have measured ST's own USB library and example CDC/ACM virtual COM for STM32F1xx on a 72MHz MCU achieving 700kbits/s. Note that the performance is independent of the baud rate you might set on the host when you open the he VCP. Setting the baud rate simply sends a control packet to the device that can be used to set the baud rate of a UART in bridging applications. In your case such control packets can be ignored. There are similar packets for modem control signals such as DTR, RTS, CTS and RI, which you might choose to us for flow control or other signalling.
I want to send and receive data with two Lora module but I have only one STM32l4 nucleo board. Is it possible to connect both transmitter and receiver Lora module to this board and have a communication between them?
Yes it should be possible to have both a transmitter and receiver connected to a single MCU. It mostly depends on the availability of pins.
I don't know why you would want to do that as the transceivers are both transmit and receive capable. Such as the Semtech sx1276.
For a week I've played with cheap modbus RS485/Ethernet adapters like USR-TCP232-304. I was assuming they would "speak" modbus TCP on the ethernet side and modbus RTU over RS485. After countless experiments I've found what that these adapters are actually expecting is RTU over TCP on the ethernet side, so they're not repackaging the ADU/PDU but simply relay.
Is this a standardized way of doing modbus or do I simply misunderstand what's going on?
Looking at the datasheet for the USR-TCP232-304 I see no mention of Modbus support; it's a RS485 Serial to Ethernet Converter only. These units makes no attempt to understand the data flowing over the link (if they receive a byte via RS485 they send it via the TCP link and vice versa). They can be used to talk to pretty much any device that uses RS485 (there are a lot of other protocols that run over RS485).
Modbus RTU transmitted via this kind of unit is pretty common if not exactly standardised (it's not mentioned in the modbus spec to my knowledge). Often these devices include drivers that present themselves as a serial port so, from the applications perspective, there is no real difference between direct RS485 and going via one of these devices (other than timings).
It looks like the next model up includes a modbus gateway function that will act as a Modbus TCP server (and there are plenty of other options; they generally cost a bit more because of the additional processing required).
First and foremost I aware of a "similar" question/answer here: USB: low latency (< 1ms) with interrupt transfer and raw HID
In my case I'm at the start of my project and currently choosing the "right hardware" for the job. I want to transfer raw sensor data from an IMU to a host PC in roughly <1ms. So my Idea was to use a Teensy or Arduino uC to handle the interface between IMU and PC. The current priority is driving the input latency down as best as possible using (ideally) the USB protocol. I'm well aware that once on the PC I have to deal with a non real-time system.
Is there anything "hardware-wise" that I have to pay attention when choosing my Microcontroller?
I am trying to connect an analogue to digital converter to the raspberry pi. As far as I am able to understand, the RPi doesn't support Bi-directional SPI mode. The adc I am using says it is SPI compatible but only has the inputs SCLK, CNV and outputs CLKOUT+ and CLKOUT- and SD0+ and SD0-. This leads me to understand that it will only work with bi-directional SPI as there is only the serial data out. I am thinking of using a PWM for CNV (which I think CE), GPIO clock for SCLK and then an interrupt on the falling edge of the GPIO clock to just digitally read each bit from the adc. I don't understand SPI in detail but from what I've read quite often it requires sending data in order to receive it. Do you know if the setup I mentioned (without using SPI) will work? Or am I missing something about SPI and the adc will work with that while not in bi-directional mode?
We are using the Raspberry Pi 3 b
adc - http://cds.linear.com/docs/en/datasheet/232316fa.pdf
Thanks for any help you can provide.
Read the data sheet carefully, in particular pages 8 and 9. I suggest that you tie CMOS/LVDS pin to ground to enable CMOS mode. Then use only the "+"-pins. Use the SCK for SPI clock, SD01+ for SPI data input to the Rpi. Connect a GPIO pin to CNV.
Also observe that the RPi runs at 3.3V, and the ADC's max rating is also 3v3, that is running the IC right to the edge.