Hello everyone,
I'm using an STM32L452RE-P, DS2482 module, DS28E17 module and SHT40 temperature sensor.
The STM32 is connected via I2C to the DS2482 module and this module is connected via 1-wire to the DS28E17.
I can communicate correctly with the DS2482. but I can't send commands to the DS28E17 and make sure I'm communicating correctly.
I use the arduino framework with the "Wire.h" library for the I2C connection.
Please show a schematic of your setup and a clear photograph of how everything is wired together. Please also share the code you're running on the STM32 and indicate how the behavior of this code is different from what you want/expect. In doing so, please build a minimum implementation that demonstrates the problem without extraneous devices or code that do not relate to the issue at hand.
You will therefore find attached a photo of the wiring schematic between the different components and some photos of the code.
When I say that I communicate correctly between the NUCLEO and the DS2482, this means that when for example I initialize channel oW0 and I come to do a reading I have the value 0xB8 which corresponds to the initialization of channel 0.
Then I would like to simply do something that ensures that I communicate with the DS28E17. So I first made the communication between NUCLEO and DS28E17 (with a GPIO) using the “OneWire.h” library. And I note the result of the "search": OneWire Device Found: 19:56:CA:4:0:0:0:3A
Then I try to go back to my project and do similar code to send the same commands but this time on the i2C bus. And when, I try to configure the transmission speed to 100khZ. The speed that I read next is "1A" which is inconsistent with the real value.
I hope this is a little clearer if you have any other questions I will answer them as soon as possible.
There's no power supply. There's also no pullup on the OneWire bus.
Please show the entire schematic.
Please also show a photo of the setup as this generally helps to spot hardware/wiring problems that aren't apparent in a schematic and sometimes help augment data otherwise missing (see e.g. power supply comment).
Please post the code as a single sketch in 'code' tags; it's now unclear what exactly you're running. Screenshots of text are not as useful as actual text. Code tags help with formatting and make everything easy to read.
I don't see anything in your present code that does this or would create this "1A" output.
I hope that you're now starting to recognize that providing complete and consistent information will be critical in enabling others to help you with this issue. It's a relatively specific situation and muddling the waters and holding back information will make things unnecessarily complicated.
Regarding the schematic, there is the power supply (3v3 line and GND).
For simplicity I use the 1-wire click and 1-wire I2C click I2C modules from MIKROE which use its components.
This is the entire outline of the project.
Indeed, on the 1wire click and 1wire I2C click I2C cards (which use the DS2817 and DS2482) already have pull-up resistors on the SDA and SCL lines but also a pull-up resistor on the 1-wire bus.
Indeed, I know that for my use (a few meters) it is not necessary to have both modules. However, I'm a little frustrated that I can't get them to work together because they're supposed to work together.
I will soon post a summary or the entirety of my code for the commands that I send between the different modules.
Usually it's best to just go with what works instead of wasting lots of time on something that nags at you, but doesn't contribute much to your project goals. In this case, I'd just settle for a OneWire sensor suite with no interfacing whatsoever. Much simpler and very effective. The total cost isn't necessarily any higher than the combined cost of the interface modules you're using now (especially if you're using the relatively expensive MikroE boards). If you factor in the cost in hours of getting this I2C-OneWire-I2C contraption to work, you'll be far cheaper off using just a slightly more expensive sensor that doesn't require any interfacing.
Frankly, I find it hard to figure out a reasonable use case, especially in your setup, for this approach. If you're bent on getting it to work, I'd start by hooking up a scope and a logic analyzer to the OneWire bus and monitor what's happening there. Start with the scope to see if the signal quality is decent. If so, proceed with the logic analyzer to work out what data is being sent over the bus. The OneWire protocol definition is open/accessible so you can read up on how a transfer is supposed to look.
In the past I've messed with OneWire, specifically to make a OneWire slave device (implemented as an ATTiny85) that would play nice with other off-the-shelf OneWire devices. Interesting project, spent a lot of time figuring it out, net useful result virtually zero (yes, I did get it to work - it just wasn't a very useful solution). We all learn the hard way sometimes.
I take note of everything you said.
I agree with you that using only the 1-wire module is the best option: better mastery of the software, simpler hardware, etc.
I posted this post in order to find someone who had already made this application because there is no application on the web that looks like mine.
We will talk about it internally about this project and make the right decision.
Thank you again for your help and wish you good luck.