I convert TM Library to Hal . www.stm32f4-discovery.net
I hope use it and enjoy.
I use Stm32f103vc and Keil Compiler and Stm32CubeMX wizard.
Please Do This ...
1) Enable FreeRTOS
2) Config a Gpio and a timer on CubeMX . 1us per tick example 72 MHz cpu >>> Prescaler=(72-1) counter period=0xFFFF
3) Select "General peripheral Initalizion as a pair of '.c/.h' file per peripheral" on project settings.
4) Config your ds18b20Config.h file.
5) call Ds18b20_Init(osPriorityNormal) on your app.
6) You can see result on debug . watch : ds18b20.
Hi! i had download, setup and start this code at mine prj. no freertos.
TIM2 (no nvic int). 72mhz/ 72 -1 prescaler, 0xffff counter period. no interrupts
pin GPIOB 12
one ds18b20 (later will be two)
Ds18b20_Init return true in main begin before for(;;)
Ds18b20_ManualConvert calls every 20 secs and return true always
but, no temperature and no dataisvalid
i can see ds18b20 adress only.
Hi,
I am using your code with STM32F411 (disco board) and some chinese probe based on DS18B20.
I am using CubeIDE but I've modified a few places in code to let is find all definitions and I've got the code running.
However, the temperature read from DS18B20 is extremely unstable and unreliable, making the sensor totally unusable.
The task is called as it should be, the DS18B20 address is detected correctly (I can see the address in the debug), usually the temperature is read correctly once and then the data is not read (isValid=0) for dozen seconds (sometimes minutes). After this time the data is read once again and then is invalid again.
Sometimes the situation is even worse - I don't even get the address of the DS18B20.
I lowered the update interval timeout to 1000ms but this doesn't seem to cause the issue because I have the same problems when the timeout is set to 10000ms or even 20000ms.
Is there something I am missing which causes these problems? Can this be made more reliable some way?
EDIT - after some debugging I see that the issue is the CRC which is invalid (crc is not equal to data[8]). There are values within data[] are partially just series of 1s like this:
The DS18X20 B7 chip die (found in the DS18B20, DS1820S, and DS1822 products) can experience EEPROM data corruption failures during power on reset.
Since the EEPROM holds internal trim values (in addition to the user data in the TH and TL registers) that control the conversion process of the DS18X20 this may show up as inaccuracy of temperature readings. And can cause temperature measurement errors of up to ±60°C.
Hey. I tried your example and everything works fine!
However, if you try to repeat it with the same settings in the STM32CubeIDE environment (https://www.st.com/en/development-tools/stm32cubeide.html) or another similar IDE Clion everything stops working. Just can't find a device according to the debug. Tell me what is wrong with the library and why it is so sensitive to changing the IDE. For an example of an error attached the project in STM32CubeIDE with identical settings.
Hey,
I've used the library with same clock configuration and it was working great.
Now i'm using it with a low frequency configuration (32Mhz , no external clock) and i've problems reading from sensor ,it's always at Zero.
I've tried to change the timer counts (PRS) from 71 to 31 to stay aligned with the 1us delay but no success.
Since it's supporting FreeRTOS , could we just use the osDelay() instead of a hardware timer ?
Any solutions for my problem ?
Regards