Library not working with Pro Mini with Atmega168

[lg007]

Hello,

Forgive me if I ask something that has been already asked before.

I am trying to make the library work with a Pro Mini board with an Atmega 168 controller, but it doesn't even respond to the master I connected it to. If I connect a genuine DS18B20 to the master, I am able to see the response from it on the logic analyzer I have connected. But if I use the Pro Mini, I don't get anything. I tried several types of Por Minis (with Atmega 168) but I get nothing.

Unfortunately I don't have any Pro Minis with Atmega328P, so I cannot check with that controller.

Do I miss something or the Atmega 168 is not supported yet?

[kutukvpavel]

Well, there should be no difference between 168 and 328, except memory volume. How much memory does your sketch occupy? If it's close to 80-90% then you might run into peculiar issues (depending on your exact code), which are not related to the lib itself. Can we see you sketch, at least partially? Also mini-devices sometimes are operated at low voltages, are you sure voltage levels are equal on both sides? To bring simple mistakes out of the question, show us you code and circuit. You can check the code on any simple board (uno, nano), not only pro mini-s, there is no difference. If it works on 328 and fits into 168 well too, then the problem is not the code, but hardware.

Edit: is your master polling the line continuously, or waiting for presence-pulse (you should be able to clearly distinguish it with logic analyzer)? Genuine slaves generate a presence pulse when are connected to the line to let master know. As I mentioned in my issue sometime ago, this lib does not generate such pulse.

[lg007]

Thanks for the reply. The sketch I am using is just the example of the library. Probably the issue is with the lack of the response to the presence pulse because I tried it with a Pro Mini 328P and I had still no success (the master I am using is generating a presence pulse). Sorry that I ask, but are you sure this library is not able to generate an answer pulse to the presence pulse? If the answer is no, which library would you recommend?

[kutukvpavel]

There's a bit of confusion: master generates reset pulses (~480uS) when starts communication. Slave generates presence (~150uS) pulses in response. Then master issues timeslots (60-80uS) for bits. (and then repeat) If you meant that your master generates reset pulses continuously (without any slave on the line, 480uS low pulses from time to time), then this lib should work perfectly fine, and if the lib does not - something is setup wrong. Since you have a logic analyzer, could you provide captures (1 - without any slave on the line, 2 - with OneWireHub connected and 3 - with a genuine ds18b20)?

[lg007]

Thanks for the clarification. The master is indeed generating reset pulses continuously. I am not able to continue with the project for a couple of days, but once I got hold on it, I will send the captures. Thanks again.

[lg007]

Here I attach a rudimentary capture (at home, I have only a Pickit2 to work as logic analyzer).

If the markers (cursors) are correct and I interpret them correctly, it seems that there are timing issues in this circuit. The master is generating 1ms long reset pulses instead of 480 uS. OneWireHub is generating presence pulses roughly 230us long, which still are OK ("When the DS18S20 detects this rising edge, it waits 15µs to 60µs and then transmits a presence pulse by pulling the 1-Wire bus low for 60µs to 240µs." as written in the Dallas datasheet). The original Dallas for sure knows what to do, so its timing is still somehow satisfying the requirements of this master.

If I connect both OneWireHub and the original DS18S20, I get the same capture as when I only connect the OneWireHub.

Since I can't change the master or its source code, the only thing I could do is to modify the library to suit the timing requirements. Any suggestions are welcome!

[lg007]

After looking at the captures, I tried modifying the following line in OneWireHub_config.h:

constexpr timeOW_t ONEWIRE_TIME_PRESENCE_MIN[2] = { 160_us, 8_us };

to constexpr timeOW_t ONEWIRE_TIME_PRESENCE_MIN[2] = { 125_us, 8_us };

or constexpr timeOW_t ONEWIRE_TIME_PRESENCE_MIN[2] = { 100_us, 8_us };

With those changes, the code worked perfectly for both the Pro Mini 328p and the Pro Mini 168.

@kutukvpavel thanks for your help!