-
Notifications
You must be signed in to change notification settings - Fork 1k
Support OneWire device (ex: DS1822) #412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, First point is solved thanks the move to LL for GPIO management, this is merge in master and will be available through board manger with 1.5.0. Here, the updated library which work with master of the core: Note the goal is not to merge that in OneWire library. Better approach would be to have a |
Hi @fpistm, I downloaded the library and replaced the official one. STM32 Nucleo F303K8 OneWire library example: "DS18x20_Temperature"
|
Which core you used? 1.4.0 or the repo one? |
Yes, the official STM32Core v1.4.0 |
Ok, that's why you have those issue, as said in my previous post:
1.4.0 does not have this. |
Just for information, do you know when v1.5.0 will be available? Thank you, Ezio |
I have to end USB stuff before releasing it. I hope in the coming weeks |
Ok, thank you for your help and your great job. Ezio |
Hi @fpistm, The new v.1.5.0 core with your above linked OneWire library seems working setting the serial port baudrate to 9600 but setting the baudrate to 115200 it read randomly wrong temperature datas. I do not understand the relation between the serial port and OneWire, perhaps it change some timings in the OneWire protocol. Using the official OneWire library with the new core the code still freeze. Thank you, Ezio |
Official library can't work due to interrupt disable for delay. |
So that means I can not use the Nucleo boards for my projects as I absolutely need to use OneWire sensors! Ezio |
That's means it requires some investigations ;) |
Ok, so I’m confident in your hands! 😉 Ezio |
I've also had problems getting the OneWire library to work on STM32 - great to hear that you're working on it! |
I'm glad to know that I'm not the only one in the world with this problem, I thought no one was using Dallas temperature sensors anymore. Normally I use a DS18B20 for each of my projects even just to know the temperature close to the board. Thank you @fpistm for working on it, Ezio |
Hi @eziologico, @eeeeeta, I've tested with Official STM32 core 1.5.0 and a Nucleo F303K8, it is now OK at 115200. If you can try and give your feedback. |
Hi @fpistm, at 2400bps (correct value)
at 9600bps (sporadic wrong value)
at 57600bps (more wrong value)
at 115200bps (wrong value)
at 250000bps (wrong value but different than before)
I tried different DS18B20 sensors and had the same result. I replaced the official OneWire library with yours, but I would like to install the official one for the genuine Arduino boards and yours only in the STM32Core environment, if it's possible. (Mac OSX) Thank you, Ezio |
Hey @fpistm - thanks a lot for looking into this! The updated OneWire library seems to work perfectly for me (with USART at 115200 baud), although as mentioned above, looks like it might still fail in some edge-cases (which I haven't got to test) - thanks so much for fixing it! :) |
@eziologico |
Hi @fpistm, Thank you, Ezio |
I don't think it is related to pin, it's mainly GPIO togglling. I'm using D10. |
Hi @fpistm, Any suggestion? Thank you, Ezio |
Well hard to tell. Anyway, it should be fine to test with #477 and with One wire without my fix about interrupts/noInterrupts usage |
Hi @fpistm, Please can you tell me how to test it with #477, I don’t know how to do it. Thank you, Ezio |
delayMicroseconds() should not rely to getCurrentMicros() and should only compute required ticks for the delay requested. This allow to use it even if interrupts are disabled. Example for OneWire library. Fixes stm32duino#412 Signed-off-by: Frederic Pillon <[email protected]>
delayMicroseconds() should not rely to getCurrentMicros() and should only compute required ticks for the delay requested. This allow to use it even if interrupts are disabled. Example for OneWire library. Fixes stm32duino#412 Signed-off-by: Frederic Pillon <[email protected]>
Support of STM32 series based on cortex-m0 (F0/L0/G0) will be available thanks #620 |
delayMicroseconds() should not rely to getCurrentMicros() and should only compute required ticks for the delay requested. This allow to use it even if interrupts are disabled. Example for OneWire library. Fixes stm32duino#412 Signed-off-by: Frederic Pillon <[email protected]>
delayMicroseconds() should not rely to getCurrentMicros() and should only compute required ticks for the delay requested. This allow to use it even if interrupts are disabled. Example for OneWire library. Fixes #412 Signed-off-by: Frederic Pillon <[email protected]>
This issue is still present when the board is running in low temperatures (sub -5°C). I suspect this is due to drop in accuracy of the internal clocks at low temperatures. #620 works well above -5°C but I've had to switch back to my manual implementation of microsecond delays via |
Hi @davidstoneham |
@fpistm I have an issue getting OneWire to work with a system clock other than default. I'm using L051C8T6 CPU, took a |
Timing issue. If you decrease the frequency gpio toggling time decrease too. That can explain. |
Strange, because there are a few |
Right it's stange. Long time I work on this hard to help. |
Maybe the delayMicroseconds precision is the issue. |
A bit hard to test it without logic analyzer/scope, will try replacing it with a dedicated timer. |
Replaced delayMicroseconds with a:
|
@fpistm with a home-made logic analyzer I was able to detect some timing issues and partially resolve them by trimming a redundant code. I'm wondering if all
|
OK. Looking at your proposal, DIRECT_MODE macro normally rely on pin configuration not setting a level. Let's see what the OneWire maintainer think. |
For STM32 it is replaced with a |
@tshcherban you can try OneWireNg library: https://github.com/pstolarz/OneWireNg It supports OD:
|
@uzi18 But it still switches GPIO mode from OD-output to input and vice versa? Or reads it while pin stays as an OpenDrain-output? My point was to eliminate those switches completely. On STM32 you do not need switch opendrain pin to input to read its state. |
@tshcherban please ask for support with STM32 OD mode @pstolarz it is possible for fast fix with your idea. |
Hello,
I'm trying to use a temperature sensor DS1822 with different genuine STM32 boards but the code freeze at the boot on all boards.
The same code and the same DS1822 Sensor run well on Arduino boards.
I'm trying the example code DS18x20_Temperature with the latest OneWire library v2.3.4 and STM23Core v1.4.0 but the problem is still present.
If I disconnect the Data Pin from sensor the code run and it print
"No more addresses."
on the serial port as the sensore doesn't answer.Thank you,
Ezio
The text was updated successfully, but these errors were encountered: