logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO

max4elektroda 2115 86
ADVERTISEMENT
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #61 21610863
    divadiow
    Level 34  
    max4elektroda wrote:
    Thanks to @divadiow we tested all platforms with the result that it works as before. If it was working before, it still is.


    I liked testing this new full driver 🤓. Excellent work @max4elektroda 💯
  • ADVERTISEMENT
  • #62 21610880
    p.kaczmarek2
    Moderator Smart Home  
    I think this is acceptable. I forgot about PIN_IOR_NofChan.

    I saw rpv-toms delay code but I was under assumption that it breaks some drivers?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #63 21610899
    max4elektroda
    Level 20  
    This has to be checked in another PR, it worked good for me on Beken platforms with DS1820, but I didn't cross check with other code using HAL_Delay_us.
    Will try in another PR soon.

    So, if it's ok to discuss here: I would think it a good feature to check for duplicate channel assignments.
    This could be also used on pin_cfg page, but we would need to verify the number of channels per role in advance.
    Then I'd like to ask about the second part in used channels. If the channel type is != default it's regarded as used.
    Could you please explain, why is this? If I change type to a temperature, I will surely also connect it to a sensor.
    But I'm probably missing a simple point, since I usually don't really use the device with MQTT.

    I had a first PR for putting all role and channel related information together, it works as requested but since I introduced an extended array of information (http-name, number of channels, function of role[like DHT, temperature]), this structure increases size of image by up to 800 bytes, unacceptable.

    But I have another idea of keeping code as it is, only adding a textfile with all Information which generates the structures (enum, array of http-names..) so all information is kept in one place which makes it easier to handle and extend.
  • #64 21610912
    p.kaczmarek2
    Moderator Smart Home  
    max4elektroda wrote:

    Then I'd like to ask about the second part in used channels. If the channel type is != default it's regarded as used.
    Could you please explain, why is this? If I change type to a temperature, I will surely also connect it to a sensor.
    But I'm probably missing a simple point, since I usually don't really use the device with MQTT.

    This is because we have TuyaMCU driver which maps data to channel without roles, we have also many custom drivers that do not use pin roles at all. We also have scripting. So, the current approach is based on the observation that it would be very hard to figure out automatically if given channel is used or not, that's why it's just based on user choice - if user had chosen a specific channel type for given channel, then we treat it as used.

    This is also very useful for testing, so I can work on HA discovery just by setting channel types and checking what's published.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #65 21610945
    max4elektroda
    Level 20  
    I see, thanks!
    I wonder if it might be possible/useful to add some sort of registration when using a channel?
    That would save the need to "guess" if an assignment is (still) valid.
    On the other hand it's working right now...

    Especially for the pins with roles I miss a value for "no set" channel: actually it's 0 on default and we can't say if this is meant to be 0 or just not set.
    Since we use unsigned values, we can't simply use -1, but maybe we can agree on max value (iirc it's uint8_t so 255) to indicate an invalid/unset channel?

    I'm totally aware that this would be another step for "one relay, one button and one LED" setup, but to start with an empty channel there is no worse in my opinion, for it's better if it "works as expected" when set than it works like expected by "coincidence" - I hope you get what I mean.
  • #66 21613297
    max4elektroda
    Level 20  
    I opened PR#1727 for the changes to Beken timing for HAL_Delay_us.
    Since I only have BK7231N and BK7238, it needs more testing.
    I'm only aware of two drivers using HAL_Delay_us (DS1820 and DHT) and I tested to work it ok for both platforms (DHT was "only" tested DHT11).


    I'm especially unsure about BK7252 - the new approach didn't compile so I switched back to "old behaviour.
    I'm unsure, because I had to change that "old" code for BK7238, to to get it working.

    I tested delayed output with logic analyzer and it looks good for BK7231N and BK7238.

    BTW should (how?) powersave on BK7238 work? I probably simply missed some description, but it looks like device is "halted" and I didn't find a hint how to "wake up".
    Sorry for my ignorance.
  • ADVERTISEMENT
  • #67 21615192
    max4elektroda
    Level 20  
    Maybe @divadiow can do some testing on the Beken devices I don't have?!?
    Sorry for nagging
  • #68 21615246
    divadiow
    Level 34  
    sure. same tests as before but with new PR and untested Beken?

    Added after 36 [seconds]:

    and DST?
  • #69 21615378
    max4elektroda
    Level 20  
    Thanks, yes, the changes only have impact on Beken code, so it would be only BKxxxx to test.
    And if I didn't miss something, it's only DS1820 driver and DHT using it.
    For DHT the situation is a bit different, DS1820 has many "small" timings to work (some only few us) while DHT is using longer periods, smallest was 55us iirc.
    I'm especially curious, if timing now works on the platforms it didn't before...
  • #70 21615429
    divadiow
    Level 34  
    confirming current operation with normal release
    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO
    PR 1727 simple
    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO
    _ALT simple (doesn't have _ALT in build text but SDK 3.0.76 is seen at boot and chip temp is wrong/broken in _ALT)
    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO
    _Sensors FULL
    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO

    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO

    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO

    nice to see DHT22 come to life
  • #71 21615437
    max4elektroda
    Level 20  
    Oh, I didn't realize DHT22 didn't work on that platform before, too.
    Nice side effect ;-)
  • #72 21615465
    divadiow
    Level 34  
    SIMPLE
    Extending DS18(B)20 driver - multiple GPIOs and multiple sensors per GPIO
    FULL not in build

    Added after 10 [hours] 48 [minutes]:

    max4elektroda wrote:
    I'm especially unsure about BK7252 - the new approach didn't compile so I switched back to "old behaviour.

    = no need to test BK7252?
  • #73 21616088
    insmod
    Level 25  
    BK7252 doesn't support reading from timer.
    Only BK7231T/U/S/N, BK7238 and BK7252N support it.

    Or perhaps it does, but needed defines are disabled for it.
    BK7252 needs good old nop way.
  • #74 21616105
    max4elektroda
    Level 20  
    insmod wrote:
    BK7252 needs good old nop way.

    I tried with "usleep(x*r)" for BK7252 which works ok with BK7238 (didn't get timer working here).

    divadiow wrote:
    = no need to test BK7252?

    No, quite the opposite if you would like to spend the time.
    It compiled, but I have no clue about the result ...
  • #75 21616107
    insmod
    Level 25  
    >>21616105
    Do keep in mind that BK7252 requires slightly bigger value, than BK7238 (180mhz vs 160).
    Why BK7238 doesn't work though?
  • #76 21616128
    max4elektroda
    Level 20  
    See here, please:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1579#issuecomment-2798930858

    On BK7238 the "rpv-tomsk"-approach crashed the device (it would never return from getTicksCount() because this function doesn't use a timeout.
    If I added a timeout, it will return, but not in time...

    "your" approach also for me only worked with multiples of ~31us - much to much for DS1820.

    So I went back to "usleep".
  • #78 21616892
    max4elektroda
    Level 20  
    insmod wrote:
    Can a method from armino be adapted?

    Gave it a quick look, and I'm not sure how this might work:

    arch_delay.c

    has only this function:

    Code: text Expand Select all Copy to clipboard
    void arch_delay_us(uint32_t us)

    I wonder how this will work, the parameter "us" is never used in this function ?!?
    Maybe they mean "ms_count", which is used in the call to "delay()" ?!?

    I'll give it a try

    Added after 33 [minutes]:

    At least my straight-forward approach

    Code: text Expand Select all Copy to clipboard
    #elif (PLATFORM_BK7238) 
   // starting over again for BK7238
   // read factors between 5 and 6,7 - using 6 seems a good start
   // trying with 6.4 - higher values are off else

        uint32_t ret;
        uint32_t div;
        uint32_t clk = 0;
        uint32_t cell;
        SYS_CTRL_U param;

        ret = sddev_control(SCTRL_DEV_NAME, CMD_GET_SCTRL_CONTROL, ¶m);
        BK_ASSERT(SCTRL_SUCCESS == ret); /* ASSERT VERIFIED */

        div = param.bits.mclk_div;
        switch (param.bits.mclk_mux) {
        case MCLK_MODE_DCO:
        case MCLK_MODE_26M_XTAL:
                clk = 26000000;
                break;

        case MCLK_MODE_DPLL:
                clk = 480000000 / (2 << div);
                break;

        case MCLK_MODE_LPO:
                clk = 32000;
                break;

        default:
                break;
        }

        BK_ASSERT(clk); /* ASSERT VERIFIED */

        cell = 100 * clk / 26000;
   
   cell *= delay;
   volatile INT32 i, j;

   for (i = 0; i < cell; i ++) {
      for (j = 0; j < 100; j ++)
         ;
   }
   
#else

    didn't work:

    BK7238 simply "halts" and approx every minute, a "watchdog" message appears


    Spoiler:
    start_type:0
    Initializing TCP/IP stack
    bk_wlan_app_init finished
    rf_thread_init ok
    OpenBK7238, version _BKusnew_3615f905046c
    Entering initLog()...
    Commands registered!
    initLog() done!
    Info:MAIN:Main_Init_Before_Delay
    --write status reg:0,2--
    --write status reg:7c,2--
    --write status reg:0,2--
    --write status reg:7c,2--
    Info:CFG:####### Boot Count 57 #######
    --write status reg:0,2--
    --write status reg:7c,2--
    --write status reg:0,2--
    --write status reg:7c,2--
    --write status reg:0,2--
    --write status reg:7c,2--
    Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 30 changes count.
    Error:CMD:lfs is absent
    Info:GEN:PIN_SetupPins pins have been set up.
    Info:MAIN:Main_Init_Before_Delay done
    Main_Init_Before_Delay done
    Info:MAIN:Main_Init_Delay
    Main_Init_Delay

    delaying start
    #Startup delayed 0ms#
    #Startup delayed 10ms#
    #Startup delayed 20ms#
    #Startup delayed 30ms#
    #Startup delayed 40ms#
    #Startup delayed 50ms#
    #Startup delayed 60ms#
    #Startup delayed 70ms#
    #Startup delayed 80ms#
    #Startup delayed 90ms#

    starting....
    Info:MAIN:Main_Init_Delay done
    Main_Init_Delay done
    Info:MAIN:Main_Init_After_Delay
    Info:MAIN:Using SSID [UM_new]
    Info:MAIN:Using Pass [sarahsarah]
    Info:MQTT:MQTT_RegisterCallback called for bT obk8C011384/ subT obk8C011384/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT obks/ subT obks/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk8C011384/ subT cmnd/obk8C011384/+
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obks/ subT cmnd/obks/+
    Info:MQTT:MQTT_RegisterCallback called for bT obk8C011384/ subT obk8C011384/+/get
    Info:CMD:CMD_StartScript: started @startup at the beginning
    Error:CMD:LFS_ReadFile: lfs is absent
    Info:CMD:CMD_StartScript: failed to get file autoexec.bat
    Info:MAIN:Main_Init_After_Delay done
    Info:HTTP:TCP server listening
    Info:MAIN:Time 1, idle 262172/s, free 136744, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/24
    Info:MAIN:Time 2, idle 212258/s, free 136744, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/24
    task watchdog tiggered
    task watchdog tiggered
    task watchdog tiggered
    task watchdog tiggered
    task watchdog tiggered


    Added after 7 [minutes]:

    ... this was with DHT pin configured, so DHT driver starts automatically.
    Disabling DHT it boots normally, but crashes when I start DS1820 driver.

    So its surely the usleep which causes the crash,
  • #79 21620499
    divadiow
    Level 34  
    unless P23 is a bad choice, these are the results. single ds18b20
    Line graph displaying single DS18B20 sensor measurement results.

    Measurement results of a single DS18B20 sensor shown on a chart.

    Chart showing measurement results from a single DS18B20 sensor.
  • #80 21620564
    max4elektroda
    Level 20  
    Thanks for trying.
    If you ever feel you don't know what to do: it would be great to check the output on the pin with a logic analyzer.

    If it's even more time to waste:
    After starting DS1820 driver there is also a new test command with the maybe strange name testus:
    Code: text Expand Select all Copy to clipboard
    
testus <pin> <delay in us between tests> <testvalue 1> <testvalue 2> <testvalue 3> ... <testvalue 10>

    This will make it possible to test the timing for given delays...
  • #81 21620597
    divadiow
    Level 34  
    max4elektroda wrote:
    If you ever feel you don't know what to do: it would be great to check the output on the pin with a logic analyzer.

    could give it a go. I do have an LA but never got round to engaging with it.

    analysing pin as-is, without driver running, or with driver? with sensor connected too?

    Added after 9 [minutes]:

    max4elektroda wrote:
    testus <pin> <delay in us between tests> <testvalue 1> <testvalue 2> <testvalue 3> ... <testvalue 10>

    what's a reasonable starting point for this?

    don't I want a few seconds in between tests so I can tell if each timing makes a difference?

    Code: Text
    Log in, to see the code

    and
    Code: Text
    Log in, to see the code
    🤣
  • #82 21620611
    max4elektroda
    Level 20  
    Easy way is just connect one channel to the pin and start the driver, maybe DS1820 with argument 5 so sensor is receiving commands at least every 5 seconds.
    Just set sampling rate to 1MHz or so and larger number of samples, you can stop the run after you see the first "spikes" on the channel and can then zoom in to see the width of the pulses.

    Added after 2 [minutes]:

    divadiow wrote:
    testus 23 5000000 12 13 14 15 16 17 18 19 20

    I usually use something like

    testus 23 5 2 4 6 10 20 50 100 200 500

    Added after 4 [minutes]:

    If you can't distinguish the tests, there's something completely broken...

    I chek from the higher end, 500us should be visible, just measure the length in e.g. pulse view
    Usually the first timing is unusable, probably when code is loaded, after that it would be the best if there is a constant failure, like it's 3 times to fast or slow...
  • Helpful post
    #83 21620622
    divadiow
    Level 34  
    ah i see. i see. testus with LA :D

    OK, so here's with just driver running. no testus cmd

    Terminal window displaying performance test results of the operating system.

    Added after 6 [minutes]:

    sr file better or do you want screenshots?

    Code: Text
    Log in, to see the code
    Attachments:
  • #85 21620707
    max4elektroda
    Level 20  
    Sorry, can't check now, will report back tomorrow.

    First screenshot (138us) looks like it's way too short (reset should be >= 480us iirc.
  • #87 21620883
    max4elektroda
    Level 20  
    That's much better and it seems DHT11 is very lax about timing. IIRC it used 55us, and in your data I see 14us "real" for requested 50.

    The factor is falling from higher to lower values:
    Over 4 for 500us (read 118us)
    to 1.33 for 4us (read 3us - but it also reads 3us for 6us)
    I'll try to increase the factor to 2.5 * actual one (resulting in 4.25 since we started with 1.7).

    PR is updated (latest one, first I synched to main) - builds are running.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

The discussion centers on extending the DS18(B)20 temperature sensor driver in the OpenBeken IoT firmware to support multiple GPIOs and multiple sensors per GPIO. The original OneWire protocol timing was stable, so the focus shifted to refactoring the driver by separating basic OneWire functions into a shared file for reuse between simple and extended drivers. Key challenges include managing flash memory size, maintaining backward compatibility, and deciding whether to maintain two separate drivers (simple and full) or merge them with conditional compilation. The extended driver increases memory footprint due to more general and debug-capable code. Flash size impact varies by platform, with Beken-N showing no visible change and others like W800 and BL602 increasing by about 130-150 bytes. The multiline command feature requires enabling OBK scripting and is currently limited to Beken platforms but may be extended. User interface considerations include possibly using a Web App for configuration. Issues with sensor behavior on certain channels (notably channel 1) were noted, linked to external commands referencing channels (e.g., Tasmota commands). The discussion also touched on DST offset parsing improvements for timezone commands, balancing user-friendliness and code size. Overall, the consensus leans toward merging the extended driver with careful size optimization and backward compatibility, while keeping the option for a simpler driver for users with minimal sensor needs.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT