-
Thanks a lot for the complete code.
Unfortunately I am not yet able to read the correct temperature (see below):_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate > =undefined Temp is -0.0625°C Temp is -0.0625°C Temp is -0.0625°C Temp is -0.0625°C Temp is -0.0625°C Temp is -0.0625°C Temp is -0.0625°C
The device returns a negative temp value that seems compatible with a scratchpad reading like FF ... FF.
Also changing the value of the pull up resistor between data and 3.3V (e.g. 3.3K or 2K) the result does not change (note: the "native code" also works fine without pull-up connected!)
At this point, I try to focus on the low level differences between the two implementations (the one that works and Espruino).
I see so far slight differences in the low-level commutation timings (e.g. in reset pulse, write bit "0" or "1"), though both implementations seem compatible with device sampling / response times.
Maybe these differences combined with the fact that I'm using a sensor with only a 1m cable can determine the different behavior.
Obviously to go deep I have to recover an oscilloscope that can help me in the analysis of the low level signals between the two cases (not immediately unfortunately).
Any other suggestion from you is welcome! -
Hi @Gordon,
maybe there is a misunderstanding because I did not explain it well.
This is your code that ignores the CRC in recovering \ convert the temperature from the device.
What is not 100% clear to me is what piece of "my code" should be merged with this one kindly suggested by you.
Until now, I have used the "hello world" example that is shown in the DS18B20 sensor page (http://www.espruino.com/DS18B20)
Alternatively, I have tried the OneWire code example to send raw commands to the device (retrieved from the relevant page: http://www.espruino.com/OneWire)Could you please clarify which of the two "pieces" should I use?
Thanks in advance for your feedback...
-
Hello all,
many thanks for the tips!
@Gordon: I have not yet tried the code that ignores the CRC verification. But I'm going to try...
Could you please clarify which "piece of code" I need to merge with the code you suggested?@Wilberforce: the DS18B20 sensor I'm using is cabled with 1 m cable.
Since I don't want to leave anything not attempted, I will try the resistor values you suggest if the test suggested by Gordon is not OK ... -
Hello all,
unfortunately, the suggested procedure does not seem to give clues for now.
I tried the configuration and the piece of code suggested by using different values of the resistors in my possession (200R, 470R, 680R, 1K, 4.7K, 10K) without triggering the "watch fired" message (the message appears iteratively, as expected, only by removing the resistor leaving the pin floating).
The "sentinel pin" (A1) mode has been configured as:- input
- input_pulldown
Note that also the "native application" continues to work properly, even when connecting the resistor between the sensor power pin and 3.3V power line supplied by the module, except when the connected resistor is 10K.
In this latter case, the converted temperature values are clearly incorrect (but return good immediately after the resistor is removed or replaced with a smaller one among those listed).
This type of resistor values seems to undermine the sensor acquisition and conversion capability... - input
-
Thank you very much for your suggestion!
For me it is correct to investigate in this direction (in the past I have never experienced any issue related to "poverty" of the power supply contacts).
For information, using the "native" implementation and the same board \ connections, the temperature sensor also works at 5V without problems (even with Arduino the 5V is OK).
With Espruino instead I get the same failure unfortunately:Temp is null°C Temp is null°C Temp is null°C
I hope to give the first results as soon as possible ...
Stay tuned!Regards
-
Hi Gordon, allObjects,
many thanks again for the feedabck, as usual you are a "wealth of information".
I try to start from the last suggestion (which gives me many cues for action) making the following simple experiment.The fairly simple connections are made through a breadboard; explicitly removing the cable on the power line connected with 3.3V pin on the Nucleo board I can still read the serial number via Espruino (this is for me quite surprising since I had the same idea of @allObjects concerning power supply management)
Same behaviour for the other "native" implementation where I get the serial number correctly but, subsequently, the sensor always read 85 ° C from the scratchpad memory which, according to the device user manual, represents the value of the scratchpad at "power up state"
No subsequent temperature variation is measured \ perceived by the sensor in this configuration.
Reconnecting the power supply pin (even "on the fly") all goes back to working properly...
Regards -
Unfortunately I do not have another sensor (of the same type), nor the oscilloscope for electric measurements (sigh!).
Anyway, I will try to get the latter because I don't want to leave the question open!However, I agree with your hypothesis, it may be a tolerance problem of the device \ sensor respect to the low-level timings applied by Espruino (if I understand well).
This leads me to ask a question (for purely cognitive purposes) about how low level operations are organized in Espruino (e.g. for the oneWire interface).
For example, how does a reset pulse is sent on the OneWire interface?
Sorry if it's a trivial question maybe, but it's just for better know some details that could explain some difference with the working implementation on the same board...The OneWire Class and the DS18B20 sensor module correctly hide these "electrical" aspects and only expose functions to send and receive bytes, initialize the line, get the temperature value etc, etc, ...
Thanks in advance for the feedback!Regards
-
Hi,
please find here the results for my Nucleo F401RE C0-2;1) Clock accuracy:
_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate > =undefined >displayResults() 31.64555874999 10.21179736904 41.81299369047 10.16743494047 51.65689622619 9.84390253571 61.63007591666 9.97317969047 71.57576703571 9.94569111904 81.62324639285 10.04747935714 91.60931855952 9.98607216666 101.71581107142 10.10649251190 111.63114655952 9.91533548809 121.65549364285 10.02434708333 average of 11 x-second measurements: 0.91130428030 =undefined >
The average value of measurements is close to 10 s (the clock\Timer accuracy seems OK)
2) DS18B20 "cabled sensor" issue
Unfortunately I have the same result of previous board (please see below)..._____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate > =undefined Temp is null°C Temp is null°C Temp is null°C Temp is null°C
Regards
-
Hi Gordon,
many thanks for the support.
The Nucleo board I'm using for this experiment is a C-03 board (from the discussion you have linked, it seems to be a "last generation" one)
Here is the result of the same test described in the post you reported.
The steps are:
1) press the USER button and start stopwatch measure (60 sec)
2) press the button again (when about 60 seconds are passed as indicated by the stopwatch)_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate >setWatch(function(e) { console.log(getTime()); :console.log(e.time - e.lastTime); }, BTN, { repeat:true, edge:'falling', debounce:10}); =1 1656.09075108333 // step 1) NaN 1716.41545185714 // step 2) 60.15261686904 >
The difference between the two presses of the USER button is about 60 sec confirming a good accuracy of the internal timer / oscillator of the board.
Let me know if the test is OK for you .Something strange happens when I pass from the device search (which returns the correct sensor serial) to the device selection on the 1-Wire line...
Do you have any other suggestions?Thanks in advance.
PS: I also have a Nucleo F401RE Board C0-2 (still working), I try to repeat the experiments with the latter (to see if there are differences)
-
Hello allObjects,
thanks a lot for your feedback.
Before trying the example code with Espruino and the DS18B20 module, I tested the very same configuration (e.g. Nucleo Board + 4.7K Resistor + Sensor) using another "native" program and I get the correct temperature.Moreover, the same sensor was also tested using an Arduino board and a sample sketch that use the oneWire protocol commands; I get (and convert) the temperature without problems and read the same serial number of the device as returned by Espruino.
Based on these results I can not say that the sensor itself is damaged or not working...
Unfortunately, using Espruino and Nucleo Board I can only read the sensor 64-bit serial code through the function OneWire.search() API.
According to the DS18B20 device user manual, the retrieved code is correct since the last CRC byte (0x20) is properly calculated.
The possibility to read such number is for me a clue that, "electrically" the OneWire interface links are fine, but any subsequent attempt to read the device memory (scratchpad) or start a temperature conersion\reading cycle through protocol commands is unsuccessful (see below):_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate >var ow = new OneWire(A0); =OneWire { "pin": A0 } >device = ow.search()[0]; // search returns an array of device IDs ="28ff050b85160520" >ow.reset(); =true >ow.select(device); =undefined >ow.write(0xBE); // Read Scratchpad [BEh] =undefined >var result = ow.read(9); =new Uint8Array([255, 255, 255, 255, 255, 255, 255, 255, 255]) >
Definitely I think I'm losing something when, after I get the device serial number (address), I try to pick the device, but, frankly I don't know what the problem is.
Even leaving the DS18B20 module working, the situation is not better.It would be nice to know and deepen the root cause of the problem (otherwise, even by replacing the device, I would remain locked on the first sensor selection)
Meanwhile I continue with the experiments ...Regards
-
Hello all,
I'm continuing my trip in the Espruino world and I'm experiencing a problem with the DS18B20 temperature sensor and my ST NUCLEO-F401RE board on which I uploaded the latest version of Espruino (1v93).
Using the first example shown on the DS18B20 sensor page (http://www.espruino.com/DS18B20) precisely:var ow = new OneWire(A0); var sensor = require("DS18B20").connect(ow); setInterval(function() { sensor.getTemp(function (temp) { console.log("Temp is "+temp+"°C"); }); }, 1000);
I get the following result (instead of temperature value):
_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate > =undefined Temp is null°C Temp is null°C Temp is null°C Temp is null°C
The DS18B20 "cabled sensor" type is that identified on the Espruino web page as "Sensor type 1" connected as follows:
Black wire -> GND
Red wire -> 3.3V
Yellow wire -> Data pin (A0)I'm also using the 4.7k resistor between data and the 3.3v line as suggested.
Browsing in the forum before posting the question I noticed the following post:
http://forum.espruino.com/conversations/254655/#comment11813806in which Gordon suggested to skip the DS18B20 module and search for the sensor through the OneWire protocol.
In the same configuration (board+sensor), described above, I get the following result:>var ow = new OneWire(A0); =OneWire { "pin": A0 } >ow.search(); // should return an array of devices =[ "28ff050b85160520" ] >
It seems to recognize the serial number of the DS18B20 device...
Could you please help me to solve this issue?
Thanks in advance for your support.
Kind regards -
-
Hi Gordon, all,
thank you for your support.
At the end, I found I2C address management in Espruino more smart than in other contexts...
Now that I have two working displays, I can start more intense tests to turn some projects developed with other (native) platforms into Espruino.
In case of problems I will try to ask for your support again...By the way, I find JavaScript an interesting and powerful language (although I am not much "in the matter" for the time being).
I have read, for example, that it can be adapted to different programming paradigms...
Could you suggest some tutorials (or other material) to understand this language deeply?
Thanks in advance...
Regards, -
-
-
Hi,
many thanks for the suggestion, however, I'm pretty sure I'm addressing the correct pins (scl:B6, sda:B7) as I did a test leaving the configuration board \ display \ pull up unchanged.
Then first loading a sample code written in C++, the result = OK (e.g. Hello world displayed), and after using Espruino interpreter + IDE and "Hello world" example (the result = FAIL unfortunately).Regards
-
Hi Gordon,
I also suspect a problem with the I2C address.
For the simple (and working) C++ program I'm using, the address is the following:#define SLAVEADDRESS 0x7E
I have read that the address of the PCF8574 adapter can also be 0x4E or 0x7E.
I replaced that address in the connectI2C () method, offered by the module for the HD44780 controller, that allows the connection by specifying a different I2C device address but the result has not changed.
Perhaps we also need to modify the HD44780 module file?Thanks in advance
-
Hi Gordon,
for now I'm just using the "Hello Word" example contained in the Espruino web page for the LCD Display (http://www.espruino.com/HD44780).I2C1.setup({scl:B6, sda:B7});
var lcd = require("HD44780").connectI2C(I2C1);
lcd.print("Hello World!");The HD44780 module is downloaded locally.
Any suggestion from you is welcome!Regards
-
Hi,
this is exactly the configuration I'm using (mounted on a breadboard, not soldered).
Also testing different pull up values (e.g. 3.3K and 10K) the result does not change (OK with C-based "Hello Word" program, FAIL with Espruino "Hello Word" example).
Moreover, when using such type of HD44780 LCD display and the same Nucleo board (or even an Arduino board) I have never had to connect any pull up resitor (always direct connection between the board and the LCD display).
I think this is due also to the fact that also the I2C PCF8574T adapter mounted behind the display has its weak internal pull up resitors "aboard"... -
Hello,
for now I still have problems including pull up resistors (4.7K) between SDA and SCL and VCC, although the error is now slightly different (I2C Write BUSY instead of Time out).Interrogating the getPinMode() function, the B7 and B6 pins are configured as Analog input,
but also changing pin state\mode through pinMode() function before calling connectI2C() does not change the negative result.Do you have another value of pull up resistor to suggest?
| |_ ___ ___ _ ||___ ___
| |_ -| . | _| | | | | . |
||| || |_|||_|_||_| http://espruino.com
1v93 Copyright 2016 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/DonateUncaught InternalError: Timeout on I2C Write BUSY
at line 1 col 121
...|4,c|4,c,c,d,d,d|4,d|4,d,d]);^
in function "a" called from line 1 col 7
a(51,1),a(50,1),a(40,1),a(12,1),a(6,1),a(1,1),{write:a,clear...^
in function "HD44780" called from line 1 col 150
...c|4,c,c,d,d,d|4,d|4,d,d]);});^
in function "connectI2C" called from line 1 col 51
var lcd = require("HD44780").connectI2C(I2C1, 0x7E);^
Uncaught Error: Field or method "print" does not already exist, and can't create it on undefined
at line 1 col 4
lcd.print("Hello World!");
^
=undefined -
Hi Gordon,
many thanks for your support.
The configuration I'm trying to use is with no pull up resistors.
By loading a simple "hello word" program, generated through another platform, I have verified the I2C interface works, with the same Nucleo board, the same display and same I2C pins of your "Hello world" example, as it is (perhaps with the internal weak pull-ups?).Generally I have never used additional pull up resistors with this kind of display and the NUCLEO-F401RE board.
Is it possible that the FW\ interpreter has configured the internal device peripheral registers differently (e.g. with internal weak pull-up and pull-down resistors disabled)?
Thanks in advance
-
Hello,
I'm trying to use the LCD Display Module HD44780 (with I2C adapter PCF8574T) with
an ST NUCLEO-F401RE and the Espruino Web IDE.
Running the sample code on the "HD44780 Character LCD" web page I get the following behavior \ error:_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://espruino.com 1v93 Copyright 2016 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate >Uncaught InternalError: Timeout on I2C Write Transmit Mode 2 at line 1 col 121 ...|4,c|4,c,c,d,d,d|4,d|4,d,d]); ^ in function "a" called from line 1 col 7 a(51,1),a(50,1),a(40,1),a(12,1),a(6,1),a(1,1),{write:a,clear... ^ in function "HD44780" called from line 1 col 150 ...c|4,c,c,d,d,d|4,d|4,d,d]);}); ^ in function "connectI2C" called from line 1 col 45 var lcd = require("HD44780").connectI2C(I2C1); ^ >Uncaught Error: Field or method "print" does not already exist, and can't create it on undefined at line 1 col 4 lcd.print("Hello World!"); ^ =undefined
I have verified that the I2C interface is working on the same Nucleo board, the same LCD display, and the same SDA, SCL pin
used in your example.
The problem also arises with the previous Espruino version (1v92) in the same way
Could you please help me to solve the issue?
Thanks in advance for your support.Regards
The
that is also the beauty of using a device with limited resources ...
Thanks so much !