What are you using for "real" rs232?



  • I was really excited about the new rs232 Atom kit, but unfortunately it requires 12V to power it, which it converts to 5V to power the Atom. I can see how that could be cool if you had full serial and could use one of the control lines. But I only have the minimum 3: Tx, Rx, Gnd.

    So what are folks using to talk to "real" (full 12V) serial devices? I have some max232 chips laying around, but they're 5v, and the ESP32 spec sheet shows a max of 3.6 for pin input. I may have a level shifter somewhere, but that seems like overkill.
    I guess I could get a 3.3V max232, but I'm kind of surprised that there's no ENV or HAT for this.



  • I'm not patient. :) I broke down and bought this, although I don't know what I'll do with the other 4 units.



  • actually. you could use 5V to supply. connect the 5V to Grove Port or connect the usb cable.

    the 12V->5V purpose is to satisfy most industrial scenes. if you don't have 12v supply. you could just use 5V.



  • I guess I misunderstood what support said: "If you are connecting through 3.96 terminal, 12V DC is required" seemed to say that I needed 12V to use the serial pins.


  • Banned

    Most people simply called it a serial connection. At one time, it was the most used form of data transmission. You will probably recognize the standard 9 pin DB9 cable. Simply put, a RS232 connection transmits signals using a positive voltage for a binary 0 and a negative voltage for a binary 1.



  • I was able to get the serial output of a cisco switch using the M5 Atom rs232 kit, but for some reason it always crashes at the same point regardless of when I start the terminal session after turning on the switch. Still trying to debug this as I hope to make a video on it soon


  • Banned

    This post is deleted!


  • I got hand a Atom Lite with the R232 shield and got it working after applying some workarounds. Here are my observations/experiences:

    1. The shield Transmit line is labeled with a blue R, the shield Receive line is labeled with a green T. This is opposite to what I expected !
      I guess this Oriental logic: please connect the other device Receive line to this device R (transmit) line.

    2. Using Arduino 1.8.13 and the esp32 1.0.4 board library, the hardwareserial device would not receive anything on the Atom pin 22. The shield itself works fine with other devices (M5stack core), and other RS232 shields show the same problem when connected to the Atom Lite. The problem is present with both the 'ESP32 Pico' and the 'M5Stick-C' board type.
      Interesting, pin 23 works fine, so I only could the reception of data to work after patching the RS232 shield (connect pin 22 line to pin 23) and configuring the hardware serial with pins 23 and 19:
      Serial2.begin(38400,SERIAL_8N1,23,19);

    3. When the RS232 shield is powered through the 5V of the M5, it outputs 0V (low) to +12V (high) signals, which are kindly accepted by any other RS232 device that I tried. The RS232 specs say that the low signal must be below -3V, so you might run into equipment that does not accept the 0V low level. However, I guess that most modern devices are happy with 0-12V range.
      So the external 12V power is usually not required.

    4. When the RS232 shield powered by 12V, it outputs -12V (low) to +12V (high), according to the RS232 specs. The Atom is powered as well, so no USB power is required in this situation.

    I guess that the problem with pin 22 is an error in the ESP32 library, or in the ESP32 core. Any information on how to fix this is appreciated !



  • @keesjan With micropython, port 22 works fine, and as expected:

    CDS_PIN = 33
    TX = 19
    RX = 22

    As an aside, the idea that the labeling of the pins is "oriental logic" shows an unawareness of the history of rs232 and is a bit insulting. The question of what to label the pins depends on whether the manufacturer thinks of the device as DTE or DCE: StackExchange has a good explanation of the history.

    In particular:

    'some manufacturers try to "help" by effectively labelling their DTE equipment as if it was a piece of DCE. They mark their data input pin as Tx so that user just connects "Tx" from the external device (which, if it's DTE, will be the data output from there) to the pin marked "Tx" on their equipment (which they know is an input). Thereby allowing them to say "just connect Tx on your device to Tx on our equipment". They think they are trying to help, but such labelling often just adds to the confusion.'