Search results for:

So, sorry for the late answer.

I tested some issues.

I recommend you connect your WIZ550io's RDY pin to espruino's any GPIO pin and do ether.getIP() or ether.setIP() after its value turns to '1'

I check the RDY pin, but after the value was '1', nothing changed. DHCP is still not working. At the moment, i'm not able to set a static ip address at this place (university network), but i will test it at home again.

If it is, can you try connecting it to an LED instead and test it with digitalWrite(B2,1)? It's possible that your Espruino board has a bad connection.

I test the B2 pin with a LED and it works well. So the connection is definitively ok.

Well, i don't know how i get this module to getting work.

Any other suggestions? Test issues?

@all: thanks for your feedback... now, i'm back from italy and ready for further tests (fully recovered and relaxed) :-) I will give you feedback during this week. I hope the next tests are successfully.

Ok, i had not much time for a extensive test. I just set up all pins and connection from the scratch and retry the main features again.

(same network / router configuration like before)

• DHCP still fail
  
• eth.setIP({ "ip": "192.168.1.2", ... }) works after 2-3 function calls (very strange)
  
• first eth.getIP() call returns very strange ip settings (e.g. { "ip": "3.192.168.1", ... })
  
• ping from my Mac Book to the espruino works
  
• http server 'hello work' doesn't
  
• http request to my Mac Book apache doesn't work
  
  

The result was the same like my first documentation. At the moment, I don't know what I'm doing wrong. After my holidays i give that another with new network and router configuration. Additionally a friend of mine will take a look at my configuration.

I'll keep you up to date

@user47955: which revision do you have?

I'm suspicious of above result. In static IP mode, its IP address should be read correctly, but you couldn't do that.

I hope we're not talking past each other. DHCP connection doesn't work. A static ip definition with eth.setIP({....}); works well. I can ping to the defined ip address. But the server application doesn't work. No response after running a page request or setup a simple http server.

Well, i give this issue another try this weekend, but I guess I can not handle an oscilloscope :-) Nevertheless, I try my best to find a way for debugging.

Hi,

i guess the api has changed a little bit. You can see the change in the following commit:

https://github.com/espruino/EspruinoDocs/commit/e1b6dd998d6d3a6d6d5466dcdcc5d4a70b8ecc4f

Try: while (nrf.getDataPipe() !== undefined) {}

I've just fired off an e-mail to WIZnet and we'll see if they can think of anything.

@Gordon: do you have an update or feedback from wiznet?

Much more better! thumbs up :-)

Here a little example. I clean and reduce a little bit the code. Some var definitions are not needed.

/* Copyright (c) 2014 ToDo */
/*
Quick description ToDO
*/

var C = {
  ADDRESS : 0x48    // description
};

/**
 * Description
*/
function TMP102(_i2c) {
    this.i2c = _i2c;
}

/**
 * Description
*/
TMP102.prototype.getTemperature = function() {
    var d = this.i2c.readFrom(C.ADDRESS, 2);
    return (((d[0] << 8) | d[1]) >> 4)*0.0625; 
};

/**
 * export
*/
exports.connect = function (_i2c) {
    return new TMP102(_i2c);
};

It is really a good idea, to return an error message string instead of an error code? I guess thois could safe some memory and performance. What do you think?

I don't know if this is a big issue for other people, but for me it's a part of user experience. On most project pages you can find in the header of the page the current version or a little eyecatcher. From this view, i guess it would be an improvment, to present the release much more prominent.

And please, this issue has a low priority! Other things are much more important...

It would be also nice to see the last release version somewhere on the homepage. To have a short view, when a new version is released. At the moment i have to look in the binaries folder (it works, but not everyone know that).

Maybe the logo can include the last release version. So everyone can see it on every site.

SPI1 should be this.spi :-)

yeah, in the video, it's a professional laser cutter. I work with the little sister of this series (zing 6030). The accuracy of this machines is so awesome. Not comparable with home made stuff, but i'm interested in the result of your home made laser :-)

Just a little enhancement to reduce the code size: i guess its unnecessary to define the var fault. You stored the information in the object (see line 17.) why not use the object as default?

trtn.fault = (d.charCodeAt(3) & 7);
    switch (trtn.fault) { ... }

and you can combine these lines:

var trtn={};
trtn.temp=(d.charCodeAt(0)<<6 | d.charCodeAt(1)>>2)*0.25;
trtn.fault=0;
-------------------------
var trtn={
    temp: (d.charCodeAt(0)<<6 | d.charCodeAt(1)>>2)*0.25
    fault: 0
};

Sorry, to be a little bit niggling :-) Memory is a limited resource! (it's hard to say this in a time of 2014)

i suspect that too :-(

@Gordon: well, i'm fine with this solution. If i find something about this issue, i will inform you. I can't believe that other people doesn't have this problem neither.

No problem! Thanks for all the help and response. And i know, it's not easy for you to handle all these things. I will wait and hope for good news.

@DrAzzy: just a little code review question: why do you store this.spi / this.cs inside the constructor? And why not use this.spi / this.cs in the getTemp?

I would have expected this:

MAX31855.prototype.getTemp = function () {
    var d = this.spi.send("\0\0\0\0", this.cs);
    ...
}

Otherwise i don't understand the constructor.

BTW: thanks for all this response :-)

@DrAzzy: if i set the ip manually, i can ping this ip address. This works as describe above. Unfortunately, my home router (apple airport extreme) doesn't show the client connections or don't find it yet. But after set the ip manually, i can create a routing table and the device is listed:

Routing tables:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           12        1     en1
192.168.1.2        0:8:dc:1d:4f:18    UHLWI           0      115     en1   1181

So i test now another breadboard, same issue.

@DrAzzy: yes, the link lights works perfectly. They are flashing, if a ping occurs.
@Gordon: i have revision 1.1, should i be happy or not to have the common version? :-)

generally it's really hard with my espruino start :-) Two tries, two problems,.. buuuuuut JS > cpp :-)

Ok, i tried everything again. At first i flash the espruino with this the newest version

http://www.espruino.com/binaries/espruino_1v69_espruino_1r3_wiznet.bin

For information: my home network setup works with 192.168.1.x range. My Synology has normally the ip address 192.168.1.2, but i read your advice with the default chip address and change it to 192.168.1.5. I guess now, there are no collisions anymore.

Well, first step: this is the output for getIP()

eth.getIP();
={
      "ip":"0.0.0.0",
      "subnet":"0.0.0.0",
      "gateway":"0.0.127.0",
      "dns":"0.0.0.0",
      "mac":"0008dc1d4f18"
    }

so, i tried to connect the DHCP with eth.setIP(); after 5 minutes no response in the WEBIDE, just a blinking cursor after.

Next step: reset the espruino board and try to set a fix IP (192.168.1.2):

eth.setIP({
  "ip":"192.168.1.2",
  "subnet":"255.255.255.0",
  "gateway":"192.168.1.1",
  "dns":"8.8.8.8",
  "mac":"0008dc1d4f18"
});

This works, eth.getIP() returns a good looking json object. Now, it's possible to ping the ip from my terminal:

64 bytes from 192.168.1.2: icmp_seq=723 ttl=128 time=4.091 ms
64 bytes from 192.168.1.2: icmp_seq=724 ttl=128 time=3.910 ms
64 bytes from 192.168.1.2: icmp_seq=725 ttl=128 time=4.205 ms
64 bytes from 192.168.1.2: icmp_seq=726 ttl=128 time=4.107 ms

Fine, now a http.get(); request to my local webserver with default port 80

>require("http").get("http://192.168.1.51", function(res) {
:    res.on('data', function(data) { console.log(data);    });
:  });

Again no response after this comment. Just a blinking cursor on my WEBIDE.

Also to set the ip to 10.0.0.2 and eth.setIP(); doesn't work.

I'm out of idea's :-(

ps: i add also my wire configuration. the picture is little taken from the side, so it looks shifted, but the cables are set by B2-B5 on the espruino board.

Do I understand this right now, that only the CC3000 work's fine and the WIZ550io has actually problems? My first try today with the WIZnet library failed so far :-( DHCP dosen't work, http.get() doesn't work and http.createServer() neither. :-(

@Gordon: so now i have a comparison.

This is the output from the SparkCore which also use the DallasTemperature library (https://github.com/tomdeboer/SparkCoreDallasTemperature).

value 0 -> alarm off
value 1 -> alarm on
-----------------------------------------
Temp for Sensor A: 26.25  ->  1
Temp for Sensor A: 26.31  ->  1
Temp for Sensor A: 25.56  ->  1
Temp for Sensor A: 24.56  ->  0
Temp for Sensor A: 23.75  ->  0
Temp for Sensor A: 23.00  ->  0
Temp for Sensor A: 22.31  ->  0
Temp for Sensor A: 21.75  ->  0
Temp for Sensor A: 21.31  ->  0
Temp for Sensor A: 20.81  ->  1
Temp for Sensor A: 20.44  ->  1
Temp for Sensor A: 20.06  ->  1
Temp for Sensor A: 19.75  ->  1
Temp for Sensor A: 19.44  ->  1

I set the temperature range between 20° and 25°. So we have the same issue. I guess it's a bug or feature of the sensor :-) It seems that the alarm recognize only floor values.

Additionally i read the specification and found the definition:
(http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf -> page 4 at the last paragraph)

If the measured temperature is lower than or equal to TL or higher
than or equal to TH, an alarm condition exists and an alarm flag is
set inside the DS18B20

Hmmm, but what would be the right way now? Somehow, I am not happy with a subtraction of the minimal value, but that would be a simple and quick solution.

What do you think?

I guess, it's not the right way to subtract it :-) I can also handle it, in my script, that's not the problem.

I will try it on my SparkCore again, if there is the same issue. I had a working project with the same library and i also used the alerts. I remember, that the alarms works fine... but i'm not quite sure. I will report it as soon as possible.

@gordon: i have a small question. the alert system work's but there is one issue i did not expect.

Currently i use this small test code for the DS18B20 sensor:

var ow = new OneWire(B8);
var sensor = require("DS18B20").connect(ow);
sensor.setAlarm(25, 30);

setInterval(function() {
  console.log(sensor.getTemp(), sensor.searchAlarm());
}, 1000);

The alert for 30° works fine. If the value is more than 30°, the alert starts. But the low value is works strange. If the value is under 26°, the alert starts. I expected, if the value is lower than 25.

Here the debug output (i delete all redundant lines)

26.3125 []
26.25 []
26.1875 []
26.125 []
26.0625 []
26 []
25.9375 [
  "288728080600007a"
]

Do you have an idea?