Search results for:

Do the IO ports have internal pull-up or pull-down resistors?

Yes, they have both - and they're switchable with software - simply use pinMode(pin, 'input_pullup') and connect the contact between GND and the pin, and you're done.

Am I right that I can use also my Espruino Pico to do the first tests

Yes, absolutely. Stuff like setWatch and pinMode are identical.

Are there any major differences between Pico and Puck

Not in terms of how you write the software. Just define the pins you're using as variables right at the top of your code (var REEDSW = A7;, etc) so you can swap the pins over, and you should be sorted.

Thanks! Sounds like a good plan - it's great to keep sharing what you're up to, and as you say there's no rush - if someone wants the code as-is they can just copy it. In fact they can even just require straight from the forum wirh require("https://espruino.microcosm.app/­api/v1/files/678070619d2612bcbdf8ff93714­63284cd5173e2.js")

Yeah, memory is tricky. You've got stuff like the Pico with 5000 16 byte variables, all the way to the micro:bit and Olimexino with 250 or less 12 byte vars :)

I'm not sure I'd name your stuff 1602A... it might just be confusing - after all, I have a bunch of 20x4 displays that I'm sure this would work on too. It's just thinking of something that implies it has more features than the standard version :)

By default, all the Pico's pins will be floating - so if you do use an FTDI cable there's no need to disconnect the ESP8266 from the Pico - just tack RX, TX and GND wires on top of the module.

It's annoying - I'm not really sure what could be causing the issue, as I've updated loads of ESP8266s this way... Unless there was some change to the uploader recently that broke things.

Sounds like a great idea!

The magnetometer on the Puck is handy, but it only outputs readings 80 times a second. I did a quick check and at 20 km/hr a typical wheel should be rotating 2.5 times a second, so it should work well enough.

However, when running at that speed it draws a bit of power (1mA, so only 200 hrs battery life), so you'd have to be careful to only turn it on for high speed readings when it thought the bike was moving.

In many ways just using a reed switch (especially if you used one off a cheap bike computer that's all set up for it) would be easier. You then don't have to worry about power consumption at all, as Puck.js will only wake up when it detects the input change state.

Yes, should be... as long as you're not charging the battery so it's below 4.1v.

As you say, diode choice is important as some won't drop enough voltage when you're drawing small amounts of power.

Nice, thanks! Would you be happy to submit this when you're happy with it? To be honest nothing apart from the angle+speed makes this specific to those steppers, so it might be worth making it a more general module name?

Does this ramp the speed up and down as well? Looks like it might... Some things that might be fun:

• Ability to move an amount in a fixed time period (it's handy if you have two steppers and want to draw a 'line' with them)
  
• Make sure you can set it going to a new location in the callback function and it doesn't 'stutter' - this caught me out when I did stuff :)
  
• stop function - sometimes you might have the stepper connected to something with a limit switch, and you want to move back until the switch is pressed, then stop it and zero the counter.
  

I don't think so... It sounds like it's a pretty standard Bluetooth beacon, albeit with RGB LEDs.

Minewtech and others have been knocking stuff like that out of years - Dot's real selling point appears to be their app (as it looks like there is nothing clever in the beacon itself).

They show it next to a light, but as far as I can tell that's a little misleading. The app on your phone will detect proximity to the beacon, and will then contact IFTTT (or something similar) which will then contact your expensive net-connected light-bulb and turn it on.

I'd have to wait until they're made, but my guess is the LED and proximity are exposed in totally standard ways - in which case you could make Puck.js pretend to be a dot and then use their app... Or maybe more interesting you could make it do things like pretend to be a dot, but only when a door is open.

It'll run off 1.7v to 3.6v, so LiFePo4 would be perfect (I had no idea the voltage was different on them).

Unfortunately that means it won't work out of the box with LiPo - which is annoying because you can buy LiPo CR2032 batteries. I've actually just finished tweaking the PCB for this though... I added a part outline for a diode. If you cut the trace and solder a diode in, that'll drop the voltage enough that you can use a LiPo.

Also, the absolute maximum rating is 3.9v, so if you were willing to push it, you could use a LiPo directly - just not when charging! And not when you turn the magnetometer on, as that really does only support 3.6v :)

IO is 10mA typically, 15mA max - so not as beefy as the Pico, but you'll struggle to draw a lot of power out of a CR2032 anyway.

You're probably best off looking at the chip specs for other info - the document is pretty good: http://infocenter.nordicsemi.com/pdf/nRF­52832_PS_v1.1.pdf

Did you change ESP_RAM_BLOCK and ESP_FLASH_BLOCK in esptool.py first? That could be one cause of problems...

If you've had the ESP8266 reporting version numbers then it looks like your wiring is absolutely fine, so it's just software that's the issue.

The RTC on Espruino will 'just work' - as in normal JavaScript you can do new Date() and you'll get the current date. And just use setInterval to call your code however often you want, and setWatch to wake Puck.js up when the button is pressed.

There's no 32kHz oscillator on Puck.js but the nRF52 does some fancy calibration stuff, so it manages better than 250ppm. That means that worst case over 1 year of operation it'll lose 2 hours... So if you checked it once a month and updated the time at that point, I guess that'd be good enough?

In terms of cases, the case will be open source, and hopefully some people will contribute some different sized cases (I may do as well). I'm hoping that the solid base will be easy enough to 3D print yourself if you have access to a printer (or it'll be ~£10 to send it off and get it printed) - and the existing silicone sleeve would still seal over the top of a new, larger case without any trouble.

The clock module actually just passes arguments on to Date, so you can pass in whatever Date can take. Probably easiest is:

new Clock((new Date(date)).getTime() + 60*60*1000)

getTime is the standard compliant way of getting the milliseconds :)

Yeah, very true. There's probably not too much you want to carry over - and as long as you have an arbitrary script box for Espruino you could work around anything anyway.

Once you've parsed the date into a Date object, it's got a ms field. You just add/subtract the number of milliseconds you need - 60*60*1000 is one hour.

Thanks to @user66772, there's now a KiCad part for the Espruino Pico, available on the Espruino GitHub page

Wire your multimeter in line with your battery early on, and assume nothing.

Yeah, I can try and get Espruino's sleep power down, but so much other stuff draws a lot of power (especially the breakout boards that tend to have high power voltage regulators)

Xbee

Well, it might be 'old' but it's used in enough stuff that I doubt XBee is going anywhere any time soon. It's just a shame the price is so high.

Nordic dev day

I did one in the UK... If it's anything like that, there's loads of nRF52-based info, and you might even get a free dev board. It may not deal with programming languages, but if it does, it'll all be C though.

It'll give you a good idea what the chip is capable of. It's actually really clever inside - you can wire peripherals together without getting the CPU involved.

You just have to promise not to come back here and ask why Puck.js doesn't use feature X - or if you do want it you'll have to implement it :)

For the SHA functions the library has to be "required". If this is a problem please let me know.

No, it's no problem at all - to be honest you should kind of need it for most of them.

It's a thought actually - Espruino supports TLS over sockets. You could actually write a JS Socket library (like is done for ESP8266/SIM900) that sends data over your given transport layer (if you were using some custom radio) and then you could use the built-in TLS support.

I wonder whether in cases where there is no RW pin (I can imagine many may not have it wired or want to wire it), we could just insert a short delay after clear? I know this has been an issue on and off for a while - originally it was fine, and then I boosted the interpreter speed and on some boards it stopped working... Then at some point it started again, and it looks like it's stopped again now :)

I'm also aware of a few people using this on boards like the Olimexino, where memory is really scarce and there's no Graphics lib (and folks complain about the library even as it is). It looks to me like this could probably be designed as an extra library (HD44780_full?) that requires the original and adds the extra functionality? I could be wrong, but it seems like it'd work and be relatively efficient (and you could legitimately ignore the I2C version if you wanted to :)

(also, I wonder whether IO over I2C is slow enough that the 'busy' flag isn't actually a problem on I2C?)

That's a thought... I imagine that any BLE beacon with an LED on it that's controllable via BLE would be usable - then you can just wire on to the LED. Espruino doesn't need much power to wake it up.

Might the HC-05 have a 'connected' LED you could use for Wakeup? Although unless you tweak the settings on it a lot, the HC-05 tends to use quite a lot of power.

The other option is something like an Adafruit Bluetooth LE module. These have a UART mode on them. I'm not sure about RTS/CTS, but it might be possible to get those out of it and then you can use them to control deep sleep.

So you could then ditch the standard Bluetooth module and could do everything (including Wakeup) through Bluetooth LE.

On the Pico there's also the Crypto library that should do AES encryption - you could use that with the code that you already have for key exchange?

Ahh, yeah :) I guess an assert_with_var would be cool, and then it could trace the offending variable if the assert failed.

Wow, that's awesome. Thanks!

It's quite fun to provide an insecure way to access secure-only things :)

If only you could register htt.ps you could have http://htt.ps/api.github.com/users/MrTim­cakes

How do I read the actual available space out of that command?

You just need process.memory().free. On Espruino boards each var is 16 bytes, so just multiply the value by 16 to get bytes.

And .usage is your actual program size

Is it actually as simple as:

function myClass() {
    this.nextPresident = "Bozo the clown";
}
myClass.prototype.add = function(a,b) { return a+b; };
myClass.prototype.getNextPresident = function() { return this.nextPresident; };
exports myClass; // <------- Not valid JS?

You actually want exports = myClass?

Hmm... that's a bit odd. What happens when you look at it with the web browser's 'inspector'? Is there a script tag there?

Just to add - yes, analogWrite uses the hardware by default, and the CPU isn't involved at all. Having said that, it uses the high speed oscillator, so it'll still end up using a bit of power (even if the CPU is totally free to do something else).

You can use {soft:true} to force software PWM though - it's occasionally useful if you want more PWM pins (for example on the LEDs), or if you can't get the combination of PWM frequencies you want.