Problems with onInit in 1v79

[espruino-discuss2]

Posted at 2015-06-30 by mooniac

Not sure if I'm doing something wrong but code that previously worked when just applying power no longer works until I run the onInit manually (well it runs automatically on connect). Here is an example of code that used to work, meaning the onInit would be called and the code would operate properly:

A5.write(0); // GND
A7.write(1); // VCC

var g;

function onInit() {
  var spi = new SPI();
  spi.setup({ sck:B1, mosi:B10 });
  // Initialize the LCD
  g = require("PCD8544").connect(spi,B13,B14,B15);
}

onInit();

var sensor = require("HC-SR04").connect(A0,A1,function(dist) {
  g.clear();
  g.setFontVector(10);
  g.drawString("Distance (cm)", 0, 0);
  var distance = "0"+dist;
  var start = Math.max((distance.indexOf('.')-4), 1);
  var end = distance.indexOf('.')+2;
  var d = distance.substr(start, end);
  g.drawString(d, (g.getWidth()-g.stringWidth(d)-14)/2, 15);
  g.flip();
});

setInterval(function() {
  sensor.trigger();
}, 1000); 

Any help is appreciated. Thanks!

[espruino-discuss2]

Posted at 2015-06-30 by DrAzzy

espruino/Espruino#497

[gfwilliams]

Posted at 2015-06-30 by @gfwilliams

well it runs automatically on connect

Do you have the Pico? If that's the case then this has never worked - you always have to either run it from a USB power supply (so there's no actual USB connection) or you need to run a terminal program when you're connected to your PC.

I'm working on fixing it - there is a beta version with it fixed (see the USB HID post) but there are some massive changes to USB, so I want to make sure it works fine before I release it.

Also: there is a bit of a problem with your code. You can end up calling g.flip() before (or while) the LCD is initialising, which can stop it working. Either try:

var initialised = false;
function onInit() {
  var spi = new SPI();
  spi.setup({ sck:B1, mosi:B10 });
  // Initialize the LCD
  g = require("PCD8544").connect(spi,B13,B14,B­15, function() {
   initialised = true;
  });
}

// ...

setInterval(function() {
  if (!initialised) return;
  sensor.trigger();
}, 1000); 

Or actually call setInterval from the LCD's connect callback instead.

[espruino-discuss2]

Posted at 2015-06-30 by mooniac

Thanks for the help. I figured out why it used to work, I was using a USB cable that had a bad data line which I needed to swap out to do the firmware update. With the old cable it works fine.

[espruino-discuss2]

Posted at 2015-10-01 by chrigu

Hi
I'm running a Pico on 1v80 and I was wondering if this problem still exists.

I have the following code:

var ssid, password, url, timeout, apiString, ledInterval, wifiReady, http, wifi, testUrl;

//network & http stuff
ssid = "myssid";
password = "mypassword";
url = "http://www.myserver.com";
wifiReady = false;

//timestuff
timeout = 60*1000;

//setup
apiString = "";

function clearLed() {
    //clear RGB Pixel
}

function handleData(data) {
    //dosomething
}

function getForecast() {
    if (wifiReady) {
        http.get(url, function (res) {
            apiString = "";
            res.on('data', function (data) {
                apiString += data;
                console.log(data);
            });
            res.on('close', function () {
                handleData(apiString);
            });
        });
    }
}

function onInit() {
  
    http = require('http');

    digitalWrite(B9,1); // enable on Pico Shim V2

    //init serial for Wifi
    Serial2.setup(115200, {rx: A3, tx: A2});

    //init LED bus
    SPI2.setup({baud: 3200000, mosi: B15});
    SPI2.send4bit([0, 0, 0], 0b0001, 0b0011);

    wifi = require("ESP8266WiFi_0v25").connect(Serial2, function (err) {
        if (err) {
            clearLed();
        }
        console.log("Connecting to WiFi");
        wifi.connect(ssid, password, function (err) {
            if (err) {
                clearLed();
                throw err;
            }
            console.log("Connected");

            //add a delay just to make sure an IP address was obtained
            setTimeout(function () {
                wifi.getIP(function (err, ip) {
                    if (err) {
                        clearLed();
                        throw err;
                    }
                    //console.log(ip);
                    wifiReady = true;
                    getForecast();
                });
            }, 2000);
        });
    });
    
    setInterval(getForecast, timeout);

}

When I upload the code to the Pico via the IDE and type save() the code works as expected as long as the Pico is connected to the laptop. However, when I use a USB power supply to power the Pico the code does not work (I don't see any requests from the Pico on the server). So I wonder whether I got something wrong with the save() method or whether the problem still exists. Thanks!

[gfwilliams]

Posted at 2015-10-01 by @gfwilliams

Nope, to me that code looks absolutely fine.

It could be that your USB power supply doesn't supply enough peak power for the ESP8266?

I'd try:

• Use LED1 and LED2 to help you display information about what's happening (whether it's connected and so on).
• Get a USB-TTL converter (they're really cheap, but you could use another Pico if needed) and wire it up to B6(Pico TX) and B7(Pico RX). You can then connect with the Web IDE on your PC and see exactly what's happening, without the board being connected on USB. Actually having something listening on pin B6 won't affect the Pico at all, so it's probably the easiest way to debug.
• Solder a big (47uF or so) capacitor to the WiFi shim - it should help to even out the power consumption of the WiFi module, and might solve your issues (if power consumption is the problem)

[espruino-discuss2]

Posted at 2015-10-01 by chrigu

Thanks for the quick reply. I used a USB-TTL converter to see what was on the serial interface when using the same USB power supply.

First I powered on the Pico and connected the serial converter while it ran. I could send commands over the serial interface and the Pico would answer but I did not see any errors (as expected as the Wifi is setup on startup). When I powered on the Pico while the serial converter was connected, it worked without any errors.

So I moved all my onInit() code to a function called foo() and called this method with setTimeout(foo, 20000) from onInit(). My plan was to power on the Pico and then after that connect the serial converter so that I could see what was happening when it tries to connect to the Wifi. But this worked also.

So I just leave the setTimeout() call in onInit and so far it works fine....

[gfwilliams]

Posted at 2015-10-01 by @gfwilliams

Ahh, thanks for letting me know!

That's interesting. When the Pico first starts up it starts executing code right away (even before the oscillator has stabilised), and I think that might mean that some timeouts get shortened/lengthened.

I wonder if that's confusing the Wifi initialisation? Thing is I've got some code here that's almost exactly the same, and it seems to work fine. Maybe some boards just stabilise a bit faster than others.

I do have something in the works that I think would really help with that though, so in a future firmware update, your problems might be solved :)

[espruino-discuss2]

Posted at 2015-10-01 by chrigu

cool, I'm looking forward to that :)

[espruino-discuss2]

Posted at 2016-02-02 by Peter

Hi Gordon,
I'm running a Pico on 1v81.274 and my program works fine, when I'm using it with the terminal connected on USB. Same problems as mentioned above when the terminal is not connected with the pico. - The onInit() routine is not starting.

I was improving it as mentioned using the setTimeout statement - but without success.

function onInit() { setTimeout(startUp, 20000); // wait for 20 seconds }

Which pico version should be used? Do you know any further problems?

Any help is appreciated. Thank you very much in advance!

Note: I can't use the last pico 1.84 version because I have some problems with ESP8266 from the Kickstarter project ...

[gfwilliams]

Posted at 2016-02-03 by @gfwilliams

Are you sure this isn't just what is mentioned in the troubleshooting page? http://www.espruino.com/Troubleshooting

If you have a board connected to a computer via USB, Espruino will move its console to USB, but won't discard any data that gets printed, so will end up having to wait for the computer to read it when the buffer gets full, which will stop your code executing.

You'd know if this was the case if your board works when connected to a USB power supply, but not a PC.

Do you have print/console.log statements in your code that might be writing enough text to fill the ~128 character output buffer? If so, either remove them, or in onInit you can force the console to go to the Serial port on B6/B7 by adding Serial1.setConsole() as the first line.

Maybe you could start a new post about the issues you're having with 1v84 and the KickStarter WiFi module? It should work - although I know there was a glitch for a few days that meant that the Web IDE didn't load the module for it when it should have.

[espruino-discuss2]

Posted at 2016-02-04 by Peter

Hi,
all console.log statements are now removed - and now it works!
And the (old) WiFi module ESP8266 now works without any problems on 1v84.

Thank you for your help!

[espruino-discuss2]

Posted at 2016-02-09 by DrAzzy

@gordon - might it make sense to not retain console.log() output if the console is set to USB, it's plugged into a computer, but the computer isn't "connected" to the serial port, and the buffer is full? Or is there a use case in which the current behavior is desirable? I can't see any use cases where this is anything other than a trap for the user...

[gfwilliams]

Posted at 2016-02-10 by @gfwilliams

but the computer isn't "connected" to the serial port

This is the problem, and has been since the first Espruino. There's no way to tell, so you'd just have to have some kind of timeout.

The obvious one is throwing away the Espruino logo on startup, but let's assume nobody cares about that :)

So let's take a simple example - someone writes some script on the connected computer that does:

while (true) {
  while (!data_has_newline) data += get_serial_char;
  http_post(data);
  data = "";
}

I guess a sensible delay for throwing away data might be 1 second? But an HTTP post could easily block for that time sometimes, and now your reliable USB connection is actually throwing away data :(

Even if you don't care about that, your Espruino randomly halting for 1 second every so often would probably be really annoying, and difficult to track down (since it'd work when you plugged it in).

[espruino-discuss2]

Posted at 2016-02-10 by DrAzzy

Aaah... that's awkward...

What about catching the most common case? Once a character has been read from or written to the Espruino via USB, you could set a flag.
If that flag hasn't been set, then the computer hasn't sent anything to it or read anything from it - so we can assume that it's not "connected" to the USB serial, and thus we shouldn't block waiting for the buffer to empty.
If that flag has been set, we use the behavior we have now.
Maybe add a USB.disconnect() (or some other name) function to unset the flag - so the IDE could send that when you cleanly disconnect, so then it would not block waiting for the computer to read bytes from it until the computer again sent or read something from it?

[gfwilliams]

Posted at 2016-02-11 by @gfwilliams

It's all just a big hack though. What if someone's not using the Web IDE? It'll then break when they disconnect?

On Linux (and I think on some Macs as well), if you haven't set up udev rules the OS thinks you've connected a modem, opens the connection, sends some random AT commands, and then closes it. So then Espruinos connected to those computers would inexplicably stop working as well.

There's a huge discussion on this on GitHub somewhere.

But my feeling is: best keep it simple. It's much better if your code breaks reliably, and you can google it, see the notes in the troubleshooting page or other places and work around it.

If the underlying problem is still there but there are a few hacks to fix it in 90% of cases, we'll just end up with a bunch of Espruino-powered devices that just inexplicably stop working when plugged into certain computers.