Search results for:

Is this still best practice for maximising memory efficiency?

So process.memory() does a garbage collection. Does garbage collection happen otherwise?

Asking because one of my programmes is running out of memory. The programme only has about 2500 bytes available following an initial save() so it is pretty tight.

It's just doing the same set of operations on a setInterval over and over again at long intervals, and in theory should use approx the same amount of memory each time as it is creating the same variables and not adding to what should be in memory. However after 5 iterations it runs out of memory. Use of process.memory() shows it gradually using more and more after each iteration.

For now I am simply replacing setInterval with a setTimeout which calls load() as I don't currently need state, however I will in due course.

I've reviewed the code and I am not obviously storing extra data each time, however i suspect my understanding of good memory management in JS may be weak, and the low memory and high async environment throws that sharply into relief of course.

For my 2p worth I was seeing c. 5% timeouts until I upped the timeout value. It is overkill given I can easily miss a few sensor readings, but I am retrying all failing ESP connects and as a final fallback hard resetting the chip by pulling RST low

I will report back on the battery part. By using deep sleep on the Pico and switching off every other device using one or more transistors, I am hopeful - based on a reporting interval of every hour - of getting to about 5 days per 1000mAh of battery - maybe more. However that's purely based on theoretical calculations.

Websockets is often a good choice for heavily firewalled environments where native sockets may be blocked. Also if you do not have complete control of your server environment, e.g. if you are using a cloud-hosting service with a web stack only.

I think they are considerably easy for less experienced developers too, just because HTTP is more familiar than socket programming.

A good deal of other stuff you typically need to implement in a command-and-control sceanrio such as authentication etc. can also be taken care of for you by your web-stack of choice which makes development faster.

The downside though is overhead of the HTTP stack, both in transmission sizes and processing speed if e.g. you are on a GPRS or low-fi radio network.

On a micro-controller if speed and performance were most important I would probably use net sockets. Example, I have in mind to build a voice-control system with a Pi running Google voice recognition as the central server and Picos as controllers. For that purpose, speed is probably pretty important - if I say "turn the lights on" I just want them to come on as quickly as possible.

On the other hand if I were already using HTTP comms to this central server in the project and it didn't need to be as close to realtime as possible, then web sockets would be a good choice.

The public server is a nice idea, but I'm not sure there's enough headroom in the client for an extra control layer to be attractive, nor enough shared purpose about what people may want to do with it. There're quite a lot of such command and control cloud-based services around which you can opt into if you want that. Perhaps an Espruino client for one or more of those would be a better approach.

Might be fun to run up a simple stats engine though which people could opt into and use it to drive a map and some numbers. I sort of doubt it would get much take-up though - although you could make it the default example on the http page which might help!

[edited] if you have problems with hooking up the WebIDE over TCP/IP, you could introduce a serial to TCP/IP proxy? There are some suggestions for doing this in the second section of http://blog.philippklaus.de/2011/08/make-rs232-serial-devices-accessible-via-ethernet/
Nice idea to remote program the Pico

So my wifi code is now solid when Pico and Adafruit Huzzah are running attached to the WebIDE.

However I am unable to connect to the ESP8266 following save() and disconnect from USB.

The two variables would seem to be power and possible changes to serial.

I am avoiding print and console when not on IDE, having read of problems this can introduce. However I wonder if something unhelpful is going down the serial1 line? I don't have a TTL cable to be able to monitor it.

I have an OLED display and was able to put in enough instrumentation to confirm that everything else is working fine as far as I can tell.

Sometimes when I return to USB it just starts working again. This led me to think it this was power as the symptom (steady blue light on ESp8266) is similar to what I had when I wasn't giving it enough juice. But I've ruled that out by having esp8266 on its own separate power circuit.

Powering off and on makes no odds, including whether I power off while connected to USB or afterwards.

In init I am re-initialising the serial line and also the ESP8266.

I've also tried pulsing the RST line on the ESP8266 to try to reset it before reconnecting - this seems to work as the lights flash, but no reconnection possible.

I'm doing a similar project. I prefer to have the sensors report to the cloud and collect the data there. More straightforward for sensors outside my home wifi environment and no need to worry about backing up the server. If necessary you could always have the server pull the data back again. I'm currently using IFTTT Maker but expect to use something more flexible in time.

If you do go for a central server, it depends what you need to do with the data server-side. personally I would prefer the extra oomph of having the pi. For passing sensor data to server, consider MQTT library instead of building your own transport.

The most annoying thing so far on the networking side with the cloud approach has been lack of SSL but totally understandable in a micro-controller.

I'm going to try the ESP8266-only approach too.

I think I fused the Pico...

While just connected to USB I get a plain red light, and get the same if I try to invoke the bootloader.

By connecting a breadboard power supply between GND and BAT_IN, I have been able to resurrect the Pico (saw this in another thread)

But is there anything I can do to get it back up and running without the PSU?

Just a follow-up question on deep sleep - if 3.3v pin and GPIO pins stay on during deep sleep, presumably I am better powering sensors from a controllable GPIO pin so as to minimise draw during deep sleep, something like the code below.

For larger stuff that needs more current than a controllable pin can supply, presumably I need a transistor connected to 3.3V, the controllable pin and common ground in order to switch them off during deep sleep?

// button will be wired from 3.3V pin to A8.
// other sensors will be wired with +ve to power pin B1 and their own ADC pin to read
var powerPin = B1, btnPin = A8;
var watch;

function doStuffAndSleep () {
  setDeepSleep(0);
  //power up sensors 
  digitalWrite(powerPin,1);
  //check sensors...
  //...check completed
 //shutdown power and go to sleep
  digitalWrite(powerPin,0);
  setupWatch();
  setDeepSleep(1);
}
function setupWatch () {
  setWatch(doStuffFromSleep, btnPin, { repeat:false });
}

doStuff();

I know quite a few people from JSoxford mostly the White October crowd - I've worked with Ben Foxall a few times. However only recently am I doing more JS myself at work. Good prompt about the IoT group, I've signed up for that and expect I'll see you there some time.

It was partly fringe involvement in the Oxford Flood Network (I offered to host a sensor and relay its data) that got me into this though my current project has nothing to do with that.

Really helpful answers and everything is really thought through on power. Now officially an Espruino fan-boy! Since I live in Oxford you'd better be careful I don't start stalking you :->

I'm new to battery-powering. A few questions I hope you can help me with

The docs say that the Pico will not enter deep sleep while on USB power. Will it wake from deep sleep when USB power arrives, or can it be configured to do so?

If I comnect both battery and USB I presume this is safe but will there be zero draw from the battery while USB is connected?

Next two questions are probably electronics ones which I am again new to:

When deep sleep is entered, sounds like 3.3V output on the Pico will be off. Therefore to create a "wake on push" button, I would plan to wire the button directly between battery and a pin I can monitor, but I am unsure how to wire this so that it won't interfere with the "normal" circuit.

Lastly, if I want to use both VBat and 3.3V outputs, can the circuits share the same ground? I would assume not, but maybe it is safe to ground through another pin set to 0v? And if I just set a pin to 1 using digitalWrite, I assume that is a 3.3 v output, and if so how does it differ from the main 3.3V output, other than that the latter is always on?

Saw the very helpful tip on another thread about measuring incoming battery voltage through E.getAnalogVRef in another thread - thanks Gordon.

Actually maybe NOT off-topic - I just saw this thread http://forum.espruino.com/conversations/266886/?offset=125#comment12565066 I'll definitely give Espruino on ESP8266 a go when I start work on those small sensors.

So it was that simple. Thanks for the steer. Connected now, although finding working AT firmware was a bit tricky as the Huzzah ships with nodeMCU. I couldn't get the latest Espressif builds to work. In case anyone else has the same problem, I determined that the ESP8266 in the Huzzah is an ES-12 or an ES12-E and the AI-thinker firmware linked to from Electrodragon here worked: http://www.electrodragon.com/w/ESP8266_AT-command_firmware

I am considering using a stand-alone Huzzah running nodeMCU for the least complex sensors in my network, but that's a bit OT for this forum...

Thanks. Using pinned while still at PoC stage. Will use unpinned in the long run when I'm ready to make some final units.

Wow be great if it was as simple as that - will try when I get home. I think I was running it off 3.3. I found the description at http://www.espruino.com/Pico in the Power section a bit confusing, mainly the table that is supposed to help clear things up!
When's the 1.4 revision out? If I get my PoC working I need to order at least another 4-5...

So I got a Pico and love the ease of use to get programming.

However I'm having trouble hooking it up to an ESP8266 (I'm using the Adafruit Huzzah breakout https://www.adafruit.com/product/2471 which has some nice convenience stuff). Essentially whenever I connect the ESP8266 to wifi (nodeMCU or AT firmware) it resets.

I'm not even connecting direct to the Pico yet. I've just been using the Pico for power

Looking around for people with similar problems seems to suggest it might be power that's the problem. Any other problems people can think of that could cause this behaviour?

in the long run I want if possible to power directly from the Pico to keep things nice and compact, since ultimately I want to run off a LiPo battery. Since the Pico can do 250mA and that's said to be the max draw from the Adafruit board in theory it's okay - or is it?

Should I be thinking about trying to power via the FET? Or do I definitely need to cater for external power ? Or should the Pico be OK?

I also wondered if the Adafruit maybe took more power than a naked ESP8266 - can people confirm a naked ESP8266 runs well and stably off Pico power with the shim, and anyone got a good recommendation/link for the ESP8266 mini board? I'm willing to go the extra mile with the shim if it means getting to my goal!