Sanity Check: RS485 Communications - rs485

Alright so I am new to RS485 communications I am putting together a document for client to wire up a Atlas Copco Mark V gateway device (Protocol Converter from CAN to Modbus RTU) to a Red Lion Protocol Converter (Modbus RTU to Modbus TCP), I know its a weird setup but its the best option we had. The Modbus RTU connection between the AC Mark V and the Red Lion is over RS485. With little experience in this field and very confusing online resources I want to make sure I have this pinout correct. Alright so here is the
AC Mark V Pinout and here is the Red Lion Pinout. How I currently have it set up is Pin 3 on the Mark V (TxD/RxD+) goes to pin 7 on the Red Lion (TxB) and Pin 8 on the Mark V (TxD/RxD-) goes to Pin 8 (TxA) on the Red Lion.
Something isn't working in our communications system and I believe this is where the issue lies. We can communicate between the two systems but data isn't going through like it should be. If anyone can help confirm/deny what I did that would be very helpful. Thank you for your time.

Related

How to setup UART on STM32 Nucleo board for a peripheral UART device?

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.

Using Pin 26 for ADC?

Using pin 26 for ADC seems to be discouraged in Toit.
From what I can see on https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html pin 26 should have an ADC converter, so what is the reason for that?
The ESP32 is limited around ADC2:
Since the ADC2 module is also used by the Wi-Fi, only one of them could get the preemption when using together, which means the adc2_get_raw() may get blocked until Wi-Fi stops, and vice versa.
Therefore I suggest using ADC1-pins if WiFi is used for connectivity.
Since All ADC2 Pins Can't be used while using WIFI, You can use ADC1
GPIO32 ADC1_CH04
GPIO33 ADC1_CH05
GPIO34 ADC1_CH06
GPIO35 ADC1_CH07
GPIO36 ADC1_CH0
GPIO39 ADC1_CH03
Check this video to learn more about esp32 pins and assigned pirepherals:
https://www.youtube.com/watch?v=LY-1DHTxRAk&t=546s

M600/A3 uart problems

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。

JavaME odd and confusing documentation

Oracles Forum about JavaME is dead! I'm sorry to say, but questions never get an answer.
The javaME-GettingstartedGuide.pdf from Oracle tells me: The GPIO pins are preconfigured! Does this mean I must take it as it is and JavaME does not allow any configuration? Further, the document tells me Device ID 1, named GPIO4 is input only and mapped to pin 4! But the Pi documentation tells me Pin 4 is connected to +5V! Where can I find valid information?
The problem relies in the two kind of numbering. A Raspberry style (Broadcom pin number) and raspberry physical style! You can find both in the JavaME-GettingStartedGuid, but not side by side. A problem in a GettingStartedGuid. Not being prepared you get confused! See Raspberry Pi Pinout
The question w.r.t. Pin reconfiguration in JavaME however ist still open.

GPIO pins will not toggle (high/low) on beagleboard xm

I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!

Resources