Search results for:

Has anyone tried connecting to an ssh server using espruino?

Nice to hear that this extension is useful 😀

If you have a bug, can you create an issue on github? It's a bit easier to track then: https://github.com/mariusGundersen/Espru­inoVSCode/issues

I don't know why it's not showing the name of the Bluetooth device, I'm just using the path and description returned by the espruino nodejs code, so not to point fingers, but the issue might be there. What happens if you look for devices using the espruino npm cli?

I haven't really tested tcp connection, so it might not disconnect properly, no.

Hmm, connecting to a gpio was a good idea, didn't think of that. And about that small capacitor, by small you mean something around 1uF? Or 1nF?

I made a quick hack to measure the battery for a project where I'm using the Espruino Pico running off of 3 AA batteries. It's an e-paper display that updates once a day, so it will run off of the batteries for a very long time, but I had no idea how long. It turns out measuring the battery charge isn't too difficult. Here is how I implemented it.

I can't connect the battery directly to the ADC, since the three AA batteries start off at about 4.5 volts, much higher than the 3.3v that is the maximum the ADC can measure. The ADC will report 1.0 for 3.3v and 0.0 for 0v, with 12 bits of resolution, so I needed to move the battery voltage into that range. A voltage divider is a simple circuit that can do that. The simplest voltage divider is just two equally large resistors in series, where the point between them will be half the voltage across both of them. 4.5 / 2 = 2.25 which the ADC will report as 2.25 / 3.3 = 0.6818 is the highest battery measurement, while 0.5 is the lowest (3.3 / 2 / 3.3 = 0.5). This gives a range of 0.1818, which is about 8 bits of ADC resolution. But instead of using two identical resistors I used one of 560k and one of 270k:

 o BAT_IN
 |
[ ] 270k
 |
 o------ ADC (pin A5)
 |
[ ] 560k
 |
 o GND

This puts the ADC at roughly 2/3 the battery voltage. Given that the max the ADC can measure is 3.3v then the maximum battery voltage that can be measured is 4.95v, but it's unlikely to go that high. I measured a fresh battery at 1.6v, so it might go as high as 4.8v, but that was under no load. 4.5v will give an ADC measurement of 0.9090 and 3.3v will give 0.666, so we have a range of 0.2424, a bit more than before but still about 8 bits of ADC resolution.

This setup drains about 6uA, so it does affect the battery life quite a bit given that the sleeping Espruino pulls 25uA. Higher resistor values could reduce the current drain.

The code for measuring the battery is very simple and not at all accurate. It assumes a linear discharge curve between 1.65v and 1.1v, which isn't correct for AA batteries. I'm planning to log the recorded values and plot them to produce a more accurate discharge curve, then I can make a better estimation function from that. But since this is a project that is designed to run for as long as possible on battery power it will take a few months to log this data.

// returns a number between 0 and 100
function getBattery(){
  let avg = 0;
  for(let i=0; i<10; i++){
    avg += analogRead(A5)*30 - 20;
  }
  return Math.round(avg);
}

The code above makes 10 measurements and takes the average of them. I multiply out the value right away to delay a bit between measurements. This code does not clamp the values, so it might return values higher than 100% and if no battery is connected it will return -200.

Just a quick follow up to note that now things are working very well, almost too good. When the espruino pico is in deep sleep and I remove the battery it doesn't reset, it continues to run for a short while, probably purely on the charge left in the capacitors! This unfortunately makes it hard to reset the device, which I sometimes have to do. I haven't checked how long it can run without batteries, but at least a few seconds.

Can you try updating to v0.4.1? I made some changes to how it's built

It might be an optional dependency that doesn't get included. I'll have a look at it tomorrow

I think vscode uses it's own version of node, built into electron. You can check process.version in devtools to verify.

I get that too, I don't think it's anything to worry about https://github.com/sidequestlegend/node-­blob/issues/5

What logs do you get when you try to connect?

@MaBe, do you see any output in the VSCode Developer Tools (Cmd + P > Developer: Toggle Developer Tools? You should see which serial devices it finds during initialization (use Cmd+P > Reload Window to restart). When it starts scanning it will show something like the second screenshot:

Give it a few seconds, it might not be there right away, but it keeps scanning while you have the selectbox open (as indicated by the progress indicator moving).

I have developed this on Windows, so that's the only place I've been able to test it. What system are you on? You could try to open the vscode developer tools (Toggle Developer Tools from the command palette) and see if there is anything there.

I think I use node 18.

It just constantly scans in a loop, it seems. Any reason not to have it like that? What's the advantage of a timeout?

I've published a few bug fixes and improvements. Let me know if there is anything not working or a feature you really want.

Can you try v0.0.7? Click on connect and it will show tcp/ip as an option

Ok, I'll have a look at how it works and try to implement something. I don't have any network device to connect to for testing, so not sure I'll be able to verify if it works.

This is just a wrapper around EspruinoTools, so it can do what the npm espruino cli tool can do. I don't think it supports tcp/ip connection, but I haven't tried yet either.

I've started working on a VS Code extension for espruino. The initial working version has been published, but it's a very early version. It supports BLE and serial port communication (tested on windows) and shows a terminal that can be used to communicate with the espruino device. It will also show you the files in storage on the device and let you run code on the device and send a file there. For now there is no config, so the file sent won't be saved to flash, that's the next thing to implement. Anyways, it would be great if people could test it and let me know if it works on various systems. You can find it here: https://marketplace.visualstudio.com/ite­ms?itemName=MariusGundersen.espruinovsco­de

@MaBe, how do you make requests through a proxy server from espruino?

I doubt many others will need this, but hopefully they will find this thread and figure it out.

Yup, removing the pull up resistor from the esp01s helped! I unsoldered the resistor circled in the attached image, and now the device deep sleeps with a current of 30uA!

So I've been trying this again, and I have a plausible explanation. Apparently the ESP01s had pull-up resistors on three pins, including the ch_pd. This is a 12k resistor, which means that when I connect to ch_pd to ground it draws 3.3v / 12kohm = 0.275mA! The ESP01 (without the s) does not have this pull-up resistor, it's only there is the newer s version. I'll try to de solder it and see how that affects it.

(yes, I bought a new more advanced multimeter)

I tried with this program:

setDeepSleep(true);
B9.reset();
//B9.mode("input");

It draws a steady 312uA. When I change the commented line so that B9 is input it draws 89mA, so it seems like the wifi chip is enabled then. Probably there is some charge left that isn't drained, leaving it on (my guess here). This is with the e-ink display disconnected.

I tried a few different things but couldn't get it below 300uA. Unfortunately I managed to short my cheap multimeter, so now it's not saying anything at all...

I have a Pico connected to a wifi module through a shim and an e-ink display, and it's all powered by 3 AA batteries. This setup wakes up every hour to fetch data and refresh the e-ink display. The code is here. Unfortunately the batteries only last about two weeks, which is a lot shorter than I expected. I've measured the power draw using a cheap multimeter, and it draws about 90mA when the wifi is active, 20mA when refreshing the e-ink display, and 0.9mA when idle. I've set it to deep sleep, I disable the wifi and power down the e-ink display, but that is still too much power consumed, IMO.

I'm wondering if the serial connection could possibly consume some power, through pull up/down resistors? Or maybe it's the voltage regulator? Any other tips to limit power consumption?

This spring I got the idea to use a framed edp (e-ink paper-ish display) with a wifi connection to show the hourly electricity price and consumption. The electricity prices here in Europe have gone up quite a bit, so it's nice to pay attention to when during the day they are the lowest.

So it's using a display from waveshare that can show red, white and black. I've written some code to dither other colors down to those three. There was no library for espruino, but there was some python code that I could easily convert to javascript. The hardest part about getting it to work was finding that reset needed to be toggled for only a few milliseconds, not several seconds. Weird.

The next step was connecting to the wifi. I've used the esp8266 wifi module soldered to an espruino pico using the shim. Getting it to connect was really easy, it worked on the first attempt. But then getting it to connect again an hour later didn't work. After a lot of work I ended up rewriting the wifi module so that it doesn't connect to wifi as part of the setup call. I also changed some parts to use promises.

The final problem was getting the deep sleep to work. I want this to run on batteries for as long as possible so it should deep sleep between refreshes (every hour). It should also disable the wifi and the e-paper controller.

That's a short summary of where I am now. The problem I have is that the battery is drained very quickly, IMO. Three AA batteries in series are drained in about 12 days. It fetches the image to show every hour, so about 300 times before it dies.

The batteries are not completely drained, the combined voltage is way above 3.3v, so I suspect there is too much peak current being drawn. Any tips on how to improve this?

Given the new pi Pico W and the wait for the espruino wifi, I'm getting interested in this port :)

https://t.co/2leMu87zwC