cancel
Showing results for 
Search instead for 
Did you mean: 

How to implement 1-wire communication on STM32MP13 MPU?

mmichala
Associate III

What method should be used to implement 1-wire communication (master) on STM32MP13x board? After doing the research I've found that:

  • for RPI, kernel module w1-gpio can be used to achive 1-wire communication. It's done on kernel level so those critical 1-wire timings can be met. But this module is not natively availabe for STM32MP1, there is no DT overlay ready (like for RPI)
  • dedicated IC like DS2482-800 can be use as a 1-wire master in-the-middle, from which STM32MP1 can later read out the data using I2C
  • no M-core co-processor is available for STM32MP13x series

Maybe there is a chance to port the w1-gpio to STM32MP1. But when using it, or the dedicated IC like DS2492-800 1-wire to I2C, I can only communicate with slaves that perfectly follow all 1-wire slave requirements (reset-present signals, timings, commands etc.). For my usage I need to have more control, because some of the 1-wire slaves I would like to communicate with do not follow those rules (they use custom function codes)

The most obvious way might be to implement it in userland, simply using the GPIOs, but I'm afraid that this way I will never meet the critical 1-wire timings.

4 REPLIES 4
PatrickF
ST Employee

Hi @mmichala 

don't know if it helps, but I was successful to read DS18B20 using UART (RX and TX shorted, no additional external HW), with STM32MP1.

Using PyDigiTemp python module like this abstract:

from digitemp.master import UART_Adapter
from digitemp.device import TemperatureSensor

    sensor = TemperatureSensor(UART_Adapter('/dev/ttySTM1'))
    temperature = sensor.get_temperature()

 Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
mmichala
Associate III

It seems that UART implementation will be only way. And modifying PyDigiTemp to support my non-standard 1wire slaves

After time spent on this, I want to share my findings. Maybe those will be useful.
Enabling w1-gpio on STM32MP1 board

I was able to run w1-gpio kernel module on STM32MP135F-DK board, by using this simple patch to device tree:

 

#########################################################################
# Enable w1-gpio kernel module on PF10 GPIO
#########################################################################
diff --git a/stm32mp135f-dk.dts.original b/stm32mp135f-dk.dts
index 0ff8a08..d1ee9ba 100644
--- a/arch/arm/boot/dts/st/stm32mp135f-dk.dts
+++ b/arch/arm/boot/dts/st/stm32mp135f-dk.dts
@@ -152,6 +152,12 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <&mcp23017 11 GPIO_ACTIVE_LOW>;
};
+
+ onewire: onewire@0 {
+ compatible = "w1-gpio";
+ gpios = <&gpiof 10 GPIO_OPEN_DRAIN>; // PF10
+ status = "okay";
+ };
};

&adc_1 {


When using Yocto and meta-st-stm32 layer, to apply the patch, simply add it to SRC_URI in linux-stm32mp_%.bbappend file.

Enabling certain kernel modules is also required, I have done that by creating w1.config file:

CONFIG_W1=m # 1-Wire core
CONFIG_W1_MASTER_GPIO=m # GPIO-based master
CONFIG_W1_SLAVE_THERM=m # Support for DS18B20
CONFIG_W1_SLAVE_DS28E17=m


In linux-stm32mp_%.bbappend this w1.config should be add as:

KERNEL_CONFIG_FRAGMENTS:append = "${WORKDIR}/w1.config"

 

This should be enough to run w1-gpio, and read temp. from DS18B20 sensor.

Later on I was able to modify w1-gpio module to support my custom slaves. I add those slaves manually (via sysfs), all under non-standard family code. When w1 core has some slave with family code that is not supported with any dedicated library, then one can use sysfs file called rw to read/write to that slave. It works with my slaves, although there are lot of problems with stability. I use a C program to read/write to that rw file, but nearly half of read operations fail, because master looses timing for some microseconds. I think it's due to some CPU interrupts coming in.
I am thinking about using kernel connector instead of rw sysfs file, like described  here 


@mmichala wrote:

It seems that UART implementation will be only way. 


Not the only way:

You could take a similar approach on SPI

https://community.st.com/t5/others-stm32-mcus-related/background-function/m-p/761089/highlight/true#M5966

Or,  use a hardware bridge - such as DS2480: https://www.analog.com/en/products/ds2480b.html 

 

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.