1-Wire Limitations?

[exeng]

  There is some library issues going on here... My tests are invalid as I decided to look at the OneWire lib I was using. Don't know when it got installed (it's been awhile). But it's painfully obvious that I was mucking around in my copy as evidenced by the following code snippet.  The assertOakLED is a handy lib I wrote to put out LED patterns (like SOS, or a number prefixed by a lead in pattern) for debug.

Code: [Select]

OneWire::OneWire(uint8_t pin, bool pullup)
{
    if(pullup) {
        pinMode(pin, INPUT_PULLUP);
    } else {
        pinMode(pin, INPUT);
    }
//SJC There is something wrong with the following lines. If I pass pin 5 it doesn't translate to GPIO 4 as it should.
//    If I subtistute 4 for pin the DS18B20 responds and reset returns (1) but that's all the works and reset //    later fails returns (0) ????
gpiopin = esp8266_pinToGpio[pin];
bitmask = PIN_TO_BITMASK(gpiopin);

//assertOakLED(1, NUM, gpiopin);
//assertOakLED(1, NUM, pin);

// bitmask = PIN_TO_BITMASK(esp8266_pinToGpio[pin]);
baseReg = PIN_TO_BASEREG(esp8266_pinToGpio[pin]);
// bitmask = PIN_TO_BITMASK(pin);
// baseReg = PIN_TO_BASEREG(pin);
//assertOakLED(1, NUM, gpiopin);

#if ONEWIRE_SEARCH
reset_search();
#endif
}
I've lost track of what was original (I'll have to find the original source) but my comments suggest I was having issues with it and must have made changes to get it to work. You can see that there are pinToGpio translations handled in the code. So that's why I can use the digital pin and not concern myself with the gpio pin number.

Pete, I thought you were passing the digital pin numbers?

[PeterF]

I am. i.e. 2 = P2, 4 = P4, 6 = P6, 8 = P8. I am not doing any GPIO remapping.

What is happening is if you have installed a different OneWire library, it is overriding the copy that is provided as part of the Oak board package. That copy does NOT have a link which remaps the number you specify to the correct IO. Internally the Oak's onewire library remaps the pin you specify to the correct GPIO pin, whereas the stock ones doesn't. Because the stock ones doesn't remap, it thinks you mean the ESP8266 GPIO pin mapping.

@conspiracyx: Uninstalling the Arduino IDE won't change which libraries are installed, as the sketchbook folder (which is where 3rd party libraries not provided with the IDE are installed) isn't deleted. OneWire is not provided with the Arduino IDE by default. Hence, it should be located in your Documents\Sketchbook folder (check your Arduino File -> Preferences to check the location of yours). You'll need to delete the onewire folder whilst the Arduino IDE is closed so it can rescan the libraries when you re-open it.

The critical part to look for in the library manager is "Built-in" - if it doesn't say that, then you are using a version of library which you have installed yourself, rather than the one provided by the Oak core. It is because of issues like this that I have different sketchbook folders so I can also maintain different copies of libraries, as different architectures like the Oak, STM32 and Arduino Uno don't always work with the one version of a library :-/ You can see from the two library manager screenshots that one is using the Built-in copy of the library (provided by the Oak core), and the other is using the self-installed version from the library manager, which would give the same "incorrect" responses as you are getting if I were to use it.

[exeng]

Well, I'll have to look at which lib my sketch is actually using but I'm guessing I fixed a very early copy as shown before but I also have the Oak package version installed as shown by this snippet...

Code: [Select]

OneWire::OneWire(uint8_t pin, bool pullup)
{
    if(pullup) {
        pinMode(pin, INPUT_PULLUP);
    } else {
        pinMode(pin, INPUT);
    }
bitmask = PIN_TO_BITMASK(esp8266_pinToGpio[pin]);
baseReg = PIN_TO_BASEREG(esp8266_pinToGpio[pin]);
#if ONEWIRE_SEARCH
reset_search();
#endif
}

In either case the pin mapping to gpio is handled by the lib. I suspected that mapping to gpio was @conspiracyx problem and why I suggested the output of the gpio pin from the ds.gpioPin().

So the mystery may be solved and the tutorial is still valid (with the correct library). Perhaps a dependency note / reminder to ensure that the Oak package OneWire lib is warranted.

[conspiracyx]

D'oh. I checked before leaving home for the day and yes, "updating" the OneWire library in the Arduino UI caused the built-in to be overwritten by the Arduino distribution version. I did in fact delete the Arduino folder in my home directory (one that holds all the downloaded libraries) when I reinstalled the other day. After "updating," OneWire was the only library downloaded into the now "fresh" Arduino home directory. When I moved it out of there and re-ran the IDE, it went back to being listed as built-in per PeterF's screenshot.

That's probably the root of the problem, but I will verify tonight or tomorrow. Unless I find something else funky this matter is probably closed and I won't update this thread.

Thanks for walking me through it! Sometimes obvious things aren't that obvious.

[exeng]

@conspiracyx,

No worries as Pete would say. We all learn something from these little adventures.

[PeterF]

How well you know me

It's only obvious once you know what the heck is going on... 20/20 hindsight? 

@exeng, was the .gpioPin() function another helper one that you added? As it didn't work for me when I tried it.

[exeng]

No. It must be part of the library I'm using. Just compiled with it to check ds.gpioPin() so it seems I'm using the lib I mucked with but can remember the source of it.

The 1.0.6 repo OneWire lib doesn't seem to have it.

Code: [Select]

uint8_t OneWire::gpioPin(void)
{
    return(gpiopin);
}

where the gpiopin is set in the constructor when the pin to gpio translation is done.

UPDATE:
  Well maybe I did? I can't find any prior version that has it in it. Perhaps it was during my debug effort when I first started to play with the temp sensor. Sorry for assuming it was native to library. I just don't remember adding it. That's 2 embarrassing faces in one day. If I have to use another one today, I'll have to submit an apology.

[PeterF]

That made my day.... so it was worth it! 

I've seen that notation somewhere else, but it is probably from the espGPIOToOakPin remapping array thingy... Anyway... it looks like you were bashing heads with OneWire at some point... so there will be all sorts of diagnostic stuff in there that isn't normal from when you were trying to work out WTH was going on. No formal apology needed On another topic... did you see the DigiX post? Still after one?

[exeng]

On another topic... did you see the DigiX post? Still after one?

Yes I did see it. See my PM. I have so many micro variants now sitting idle, it's hard to justify adding another even though I miss my DigiX.