2

Well, I have no experience with ESP32 UART, tried it and failed. In brief: I need to implement a data exchange between ESP32 and external module via UART. And at some point I need to read the data from the external module, but have a garbage instead.

Details: I'm playing with KNX. I've made a simple setup with some devices. Also have made 2 completely identical devboards with NCN5120. NCN is configured to use UART 19200 8E1. One board is connected to the Rapsberry Pi, another to the ESP32 Wrover devkit (also tried bare Wrover with the same results). ESP32 UART is on the pins 21/22. On Pi I use java with NRSerial, and everything is working fine. The code is quite large, but MVE just inits the KNX transceiver, assigns address and reads frames (i. e. telegrams). Java init code:

int baudRate = 19200;
NRSerialPort serial = new NRSerialPort(portName, baudRate);
serial.setDataBits(8);
serial.setParity(SerialPort.PARITY_EVEN);
serial.setStopBits(SerialPort.STOPBITS_1);
serial.connect();

Then I init NCN, assign address and read frames. Everything is working fine, like, here's the readings when I read value from some of my KNX devices on the bus:

Using port /dev/ttyAMA0
Sent reset, got response 0x03
Sent address, got response 0x21
BC 11 07 00 06 E1 00 00 B2

But with ESP32 I have some garbage input from the NCN. Init and address assignement both are working correctly, but bus readings are completely different for the same frame:

SDK version 4.3.2
init written ok
init response read ok
Assign address written ok
Assign address response read ok

47 BC 11 07 00 46 F5 54 14 B2 57

I tried to swap my KNX boards, but each of them is working fine with Pi, and does not work with ESP32. Probably there's an error in my code. Please help. MVE for ESP32 follows:

{
    ets_printf("\nStarting\nSDK version %s\n", esp_get_idf_version());
uart_config_t uartConfig = {
    .baud_rate = 19200,
    .data_bits = UART_DATA_8_BITS,
    .parity = UART_PARITY_EVEN,
    .stop_bits = UART_STOP_BITS_1,
    .flow_ctrl = UART_HW_FLOWCTRL_DISABLE,
    .rx_flow_ctrl_thresh = 122,// Tried also 0
    .source_clk = UART_SCLK_APB // Tried also UART_SCLK_REF_TICK
                  };

int uartPortNumber = 1; // Tried also 2
int pinTx = 21;
int pinRx = 22;

uart_driver_install(uartPortNumber, 1024, 0, 0, NULL, 0);
uart_param_config(uartPortNumber, &uartConfig);
uart_set_pin(uartPortNumber, pinTx, pinRx, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);
uart_set_baudrate(uartPortNumber, KNX_UART_SPEED);
uart_set_word_length(uartPortNumber, UART_DATA_8_BITS);
uart_set_parity(uartPortNumber, UART_PARITY_EVEN);
uart_set_stop_bits(uartPortNumber, UART_STOP_BITS_1);
uart_set_hw_flow_ctrl(uartPortNumber, UART_HW_FLOWCTRL_DISABLE, 0);
uart_set_mode(uartPortNumber, UART_MODE_UART);

uint8_t byte;

byte = 1;
if (uart_write_bytes(uartPortNumber, &byte, 1) != 1)
{
    ets_printf("Init writte error\n");
}
else
{
    ets_printf("init written ok\n");
}
if (uart_read_bytes(uartPortNumber, &byte, 1, 10000 / portTICK_RATE_MS) != 1 || byte != 3)
{
    ets_printf("Init response read error\n");
}
else
{
    ets_printf("init response read ok\n");
}

uint8_t address[4] = {0xf1, 0x41, 0x02, 0x00};
if (uart_write_bytes(uartPortNumber, &address, 4) != 4)
{
    ets_printf("Assign address writte error\n");
}
else
{
    ets_printf("Assign address written ok\n");
}
if (uart_read_bytes(uartPortNumber, &byte, 1, 10000 / portTICK_RATE_MS) != 1 || byte != 0x21)
{
    ets_printf("Assign address response  read error\n");
}
else
{
    ets_printf("Assign address response read ok\n");
}

while (true)
{

    int res;
    res = uart_read_bytes(uartPortNumber, (void *)&byte, 1, 10000 / portTICK_RATE_MS);

    if (res == 1)
    {
        ets_printf("%2.2X ", byte);
    }
    else
    {
        ets_printf("\n");
    }

    vTaskDelay(1);
}

}

Thank you!

Bence Kaulics
  • 7,783
  • 8
  • 41
  • 90
BUKTOP
  • 161
  • 4

2 Answers2

4

Sorry colleagues, I simply forgot to connect common ground. Found the unconnected wire, plugged it to the devboard and now everything is working.

Bence Kaulics
  • 7,783
  • 8
  • 41
  • 90
BUKTOP
  • 161
  • 4
0

Configuring a UART for 8 bits plus even parity is a red flag. This configuration has been obsolete for decades. A lot of current hardware doesn't actually support it. Set to 8-bit no parity.

CWallach
  • 101
  • Could you please elaborate it? How could configuration be obsolete? – BUKTOP Feb 11 '22 at 18:43
  • 1
    Obsolete as no longer in use by any standard protocol using UARTs. – CWallach Feb 11 '22 at 18:46
  • But I don't use any protocols, just bare uart. Really, don't understand. Could you share some links please? – BUKTOP Feb 11 '22 at 18:47
  • 1
    Parity is terrible for error detection as it misses 50% of the errors. Any protocol that needs error detection uses the more efficient and far superior CRC. Or even a checksum. – CWallach Feb 11 '22 at 18:52
  • 1
    Could you please elaborate, why do you think that some uart parameters sets are obsolete? Regarding protocols: 50% more errors detections is much better than 0. Like, 50% better. If you read my question carefully, you'd notice there's knx underneath. But I really would like to understand your point about obsolete configuration – BUKTOP Feb 11 '22 at 18:55
  • Do you use Morse code? No, because its obsolete. 8E is obsolete. It reduces thruput by 10% while missing 50% of errors. Look up CRC error detection and compare. – CWallach Feb 11 '22 at 18:59
  • Morse code is a completely different interface. Uart is pretty standard, so this comparison is not really correct. Ok, so is it just your opinion then? – BUKTOP Feb 11 '22 at 19:02
  • I've decades of experience with numerous UARTS. If your application needs error detection, a simple checksum detects 128 times more errors than parity. Thats just one reason 8E became obsolete. – CWallach Feb 11 '22 at 19:14
  • So, except of experience, no other explanations for such a strange statement? I really confused and would appreciate any explanations. Talking about experience, I'm working with uart since, like, 85 or something, but idea that some set of configuration parameters could be obsolete is quite new for me. As an engineer, I cannot even imagine how and why could it be implemented, either in hw or sw – BUKTOP Feb 11 '22 at 19:17
  • Other error detection algorithms detects 100s or 1000s more errors than parity and don't incur the loss of bandwidth. Implementing a checksum is easy. CRCs are more complicated, yet implemented in numerous hardware chips for Ethernet, WiFi, etc. Do you understand this? What is strange about it? – CWallach Feb 11 '22 at 19:27
  • let's leave alone other algorithms, I'm curious about uart layer and obsolesce of some configurations. – BUKTOP Feb 11 '22 at 19:30
  • Lets not ignore other algorithms. Other algorithms are why 8E is not longer used and thus, obsolete. – CWallach Feb 11 '22 at 19:38
  • So, no further info about why do you think some configurations are obsolete. Ok, got it. Really, have no time to discuss other trivial and generic topics not related to my question. – BUKTOP Feb 11 '22 at 19:39
  • I offered reasons that you willfully ignore. – CWallach Feb 11 '22 at 19:48
  • I see no reasons why configuration could be either supported or not. I didn't ask about architecture design, I know pretty well how is it working on any layer and so on. You wrote, some uart configurations ain't supported. Furthermore, your comments clearly shows you don't understand what was my question about. At all. Please, either provide some evidence for your statement 'This configuration has been obsolete for decades" or lets just stop this meaningless conversation. If your info is correct, I'd surely redesign my interface, although you're the only source I have such a strange info from – BUKTOP Feb 11 '22 at 19:54