DS18S20 does not work with nodemcu_float_0.9.6-dev_20150704.bin

[fabianhu]

Hi, ... but it does with the INTERNAL://NODEMCU firmware out of the nodemcu-flasher.

I'm using this lua example

not working: nodemcu_float_0.9.6-dev_20150704.bin (NodeMCU 0.9.6 build 20150704) not working: my own "dev" build working: INTERNAL://NODEMCU, which reports itself as NodeMCU 0.9.5 build 20150318

what not working means is: The sensor identification runs well, but if the temperature value is being read, the result is 9 times 0xff.

If i only change the firmware, my hw-setup works. I tried parasitic and standard supply as well as different pull-up values.

Could please someone doublecheck this?

I diffed the versions in the meantime, but could not find any significant change in the onewire related code.

• Idea: Is it possible, that the delayMicroseconds are doing wrong timing, if the constant is fetched out of flash in the new version?

[jiegec]

I checked the ow files and nothing changed since then. Well, there is still a way to find the error commit: git bisect.

[vowstar]

This may timing problem. New build trade speed to get RAM, so it becomes wrong. We will use logic analyzer fix it.

[vowstar]

https://github.com/nodemcu/nodemcu-firmware/issues/535 May same problem.

[fabianhu]

after some bisect: just as expected and very likely not related to #535.

b0f9788a6d02609dc31a1a3360ad79210e3443e2 is the first bad commit commit b0f9788a6d02609dc31a1a3360ad79210e3443e2 Author: Johny Mattsson jmattsson@dius.com.au Date: Tue Jun 23 15:38:52 2015 +1000

Move constants to ROM. Frees up 16k+ of RAM.

Accessing 8bit and 16bit constants from ROM rather than RAM comes with a performance cost, as these loads go through the load/store exception vector. Any performance critical constants can be forced back into RAM as RAM_CONST_ATTR.

The entry point has changed from call_user_start() to user_start_trampoline() in order for the exception handler to be installed early enough.

btw: the referenced RAM_CONST_ATTR macro seems wrong, it references the .flash section, but it should reference some ram related section (don't know, which one to use)

[fabianhu]

@jmattsson i think your approach is really great and well crafted, but as I am no linker-script expert, do you know a way to do "old style" linking constants to RAM for the sdk .a files only? I tested with putting the constants for delayMicroseconds(xx) into variables, which I put into another memory section at the "old" position in RAM. This does not solve the problem. So I suspect some constants inside the precompiled objects to eat up some time. As we can not debug into the sdk, this gets complicated to fix. Or do I miss sth? (except a logic analyzer, which I really am missing)

[jmattsson]

@fabianhu It is possible to force the SDK .a file constants back into RAM, but doing so forgoes most of the benefit of getting them out of there in the first place. From memory the SDK was responsible for something like 2/3rds of the overall constant use.

It seems odd that the timing should have changed around delayMicroseconds() though, as that is just a #define for ets_delay_us, which takes a uint32_t which wouldn't require hitting the exception handler. If you (or someone) can pinpoint which SDK function is acting up timing wise, I can take a look at it and hopefully just pull the relevant constants back into .rodata via the linker script. Ideally of course, @vowstar manages to compensate in the ow module giving us the best of both worlds :)

PS. Thanks for spotting the section error in RAM_CONST_ATTR, I've raised a pull request to fix it.

[jmattsson]

I believe this issue is now resolved on the dev branch:

> dofile("onewire-ds18b20.lua")
40  21  186 137 4   0   0   136
Device is a DS18S20 family device.
P=1
139 1   75  70  127 255 5   16  58
CRC=58
Temperature= 24.6875.6875 Centigrade

Can you please verify and if everything is well, close this issue?

[TheoHarbers]

It is working well again in dev branch.

[positron96]

Hello. I suddenly started to experience this issue on integer build 20150704 (2 days were OK on ESP-03, then I flashed my ESP-01 into 20150704 and suddenly both modules stoped working with DS1820, giving exactly 0xFF symptoms) so is there a binary build with this patch included? A new dev version or a custom binary maybe? I have absolutely no competence in building nodemcu myself.

[marcelstoer]

I have absolutely no competence in building nodemcu myself.

You don't need to...

• http://frightanic.com/nodemcu-custom-build/index.php
• https://github.com/marcelstoer/docker-nodemcu-build

[positron96]

Woa, thanks, didn't even know this site exists! Is it dev branch I should build from or master?

[marcelstoer]

dev

[positron96]

Thank you again!