gfwilliams

Hey everyone! I'm the creator of this. Glad to see a few of you have tried it and enjoyed it. Any questions, just let me know below and I'll do my best to answer.

Just to answer some of the stuff below:

Yes, you could write something faster and smaller in C. However chances are you'd spend a lot more time doing it, eg. https://github.com/classycodeoss/nrf52-ibeacon/blob/master/m... vs http://www.espruino.com/iBeacon

Most battery powered devices spend most of their time asleep. If your device spends 1ms awake every minute instead of 0.01ms then honestly in most cases that's not a big deal, because the power consumption of everything else in the system is 100x that.

Low.js/Moddable/Jerryscript/etc are bigger, faster more complete JS engines that provide a more Node.js-style experience, but generally for more powerful devices. With Espruino we're saying if you're willing to make a few small tweaks to the way you write code then you can use amazingly low power devices: 0.003mA sleep for nRF52 vs. 80-500mA for Raspberry Pi or 0.8mA for ESP32 (with RAM retention)

I think there were just a bunch of other features they wanted to give exposure (ML, speaker, etc), and the kid-friendly tools out there for it won't support Zigbee.

However I bet Nordic's examples for Zigbee on nRF52833 would work pretty much as-is (maybe just changing a few pin names) so you could get up and running pretty quickly.

Espruino (a JS interpreter for MCUs) runs really nicely on this too now - you get wireless programming and debug, and a full Bluetooth LE stack (you can run Web Bluetooth on the device and use to control other consumer electronics).

I'd like to see Apple implement Safari's missing functionality before they try and come up with a replacement for WebGL.

Where are getUserMedia, MediaRecorder, WebRTC, filesystem, vibration, screen orientation, Service Workers, Web Bluetooth ? What about WebGL 2? I'm sure there are a few more I missed too.

Those are things that are really holding the web browsing experience back on iOS/MacOS, not an extra 20% 3D performance and slightly shinier graphics.

Or why not lift the app store restrictions so that Google/Mozilla can actually ship non-crippled web browsers and implement it all for you?

Hi! Thanks, v7 looked great too. mJS looks like a good idea - IMO it'd be nice to standardise a sane, minimal subset of JS that can be easily implemented - it'd be a huge help for all the developers of embedded JS interpreters, and could potentially be targeted by transpilers too.

Espruino's had an FFI interface for the last 3 years! Nice to see they did their research :)

I get this too - thought it was just me/my family.

I never seem to actually 'dream' the answer, or know what it is ahead of time. It just seems obvious when I look at the code again later, and I totally rely on it now.

As others have said, actively thinking about the problem makes it less likely I'll solve it. Usually I just keep looking through my open issues, maybe writing a few lines, until I get that feeling I know how to do it.

Any other disciplines where this is 'a thing' - or is it just programming? I heard someone mention maths...

Oxfordshire countryside in England. I tried working from a small flat in London and I got totally burnt out. I like being able to look out the window and see trees, fields and a river - I've been working full-time for myself for 7 years now, I'm personally finding it's hugely important to be able to keep stress under control and get some perspective... and for me, being able to get outside really helps.

Ideally I'd move to Wales where it's cheaper and prettier, but realistically I need to be able to get to London and airports relatively quickly, as well as to not be too far from friends and family.

Thanks! Yeah, the phone apps that do it turn on the phone's flash and it works much better - but I can't find a way to do that from JS. It seems like one of those things that's in the pipeline but hasn't made it in just yet.

Thanks for submitting this! I'm the developer, so if you have any questions just let me know :)

I'm under NDA, but I believe we can talk about things that have already been disclosed.

If you do a google image search for large micro:bit images, you'll see there's a Nordic NRF51822 chip (Which is an ARM Cortex M0, with BLE), and a Kinetis ARM chip connected to USB. It's running an mbed-compatible bootloader that appears as a USB mass storage device. You just copy hex files onto it and it programs the NRF51822.

There is currently a version of Espruino for the Micro:bit too, so kids will have the ability to use JavaScript. You can even program/debug it over BLE as well :)

However there's been virtually no interest in it so I haven't spent as much time on it as I'd have liked. Hopefully that'll change when the boards start appearing though.

There is http://www.espruino.com - where the toolchain runs in the MCU - you can then just send the JS code you want to execute straight over to it :)

There's been info on doing this with Espruino for about a year now: http://www.espruino.com/Headphone. There's even an online-only version of the Web IDE that does two-way communications: http://espruino.github.io/EspruinoWebIDE

With 3.3v logic, it turns out you don't even need the transistor - just a capacitor and bias resistors.

As someone who's now shipped 2 hardware KickStarters on time (both of which were bigger than KoalaSafe), I find it a frustrating when people post up 'hardware KickStarters never ship'. It's just not true.

It's definitely 'buyer beware', and if you back a KickStarter that shows loads of renderings and no working finished product then you may hit trouble - but many people come to KickStarter with a working product, having already done their homework and made arrangements with a manufacturer. Those people will almost certainly ship, and it's a shame that other failed KickStarter projects make them look less legitimate.

But I totally agree with polar8 on this...

1. Design with the factory has been true for me. I did one KS in China, one in the UK - and the factories work totally differently. The time it takes to get things arranged is insane, and you absolutely need to not only have a manufacturer, but to have a design that they're happy with and can source parts for before you KickStart if you plan to ship on time (even if you plan on tweaking the design a bit later).

2. Sourcing - When you order 1000s of something, suddenly lead times matter. Generally you can't just go to Farnell and get things next-day, if they're not in stock, 13 week lead times are not uncommon - and a company can have 4000 items in stock one day, and they'll be gone the next (so checking stock levels is not enough!).

3. Features - definitely be sensible. Listen to your backers but be very careful about adding their suggestions. Changes really set you back, and the most vocal backers views are almost certainly not those of the majority. Adding features in software after the ship date is easy and people like it, but delaying the ship date for features would rarely be appreciated.

4. Margins. I think people feel bad about adding a big margin, but you've got to. There are loads of hidden costs, and most backers would prefer to pay a bit extra and have you still making and supporting devices 2 years from now.

Just to add: Overall open source has been great in my case. It's just that it's very easy for someone to make a comment on the internet - it doesn't mean they're particularly bothered about it or are prepared to do anything about it!

I actually had a lot of success with Open Sourcing. After a year of making virtually nothing out of selling Espruino as software (while being bombarded with sometimes abusive comments about the fact it wasn't Open), I decided to put it on KickStarter as Open Source hardware a year ago - and the result was very good. My second KickStarter is about to finish in 24 hours too.

It's a shame yours didn't work out - I think I was lucky I had something that could be crowdfunded more easily.

Having said that, none of the people that berated me for being Open Source have contributed anything back (others have been very helpful though). I've also had to cope with cheap clones, the possibility of competitors using my own software, and a huge support burden from users of other hardware.

As one of buro9's users, I have to say I was very happy to hear that the software was going to be Open Sourced, however I was dreading having to migrate it all to my server.

In the end I'm much happier that buro9 found a way to keep it ticking over. Given the choice of continued service vs. Open Source I definitely would have chosen continued service - but it's even better to have both!

Yes, it'd be really handy... Having said that, to be truly useful you'd need to be able to access whatever it was from some API that was common across platforms. Sadly I think it's very unlikely that any simple communications protocol will get exposed to webpages, because of potential security concerns.

Thanks! I'd seen your post when I googled to see if it could be done. It's just nice not to have to wire up so many components, or to need a battery!

There is a demonstration there of full loopback, without the 1 sec delay. The delay is purely so you can send a command using a totally normal audio API that only uses the sound card when needed.

I could probably get away with 1 stop bit... I didn't try. To be honest if the transfer speed matters so much, it might be better to use some other means of communications :)

They knew it was an issue. Did they know it was going to kill someone? I'm not sure.

I guess a lot of people here are software engineers...

If you have a button in your phone app that's a bit slow to make something happen, you might put off a fix for it in order to ship early.

What if someone's using their phone (maybe illegally) while driving, they're distracted by the 'faulty' button and then they hit and kill a cyclist.

Would you then responsible for that cyclists's death?

I'm just trying to think 'what if I were an automotive engineer?'. Thinking of all the things in a car you could blame for not being absolutely perfect, it seems like an impossible job.

It's not sarcasm, I'm just very surprised that everyone's opinion is so one-sided about this.

I think if you put yourself in the engineer's position, he probably didn't believe that having a switch that was a bit easier to turn would lead to anything more than mild inconvenience.

I think if GM honestly thought this would cause even one death they would have changed the lock barrels. Even if you ignore the human side, the potential costs damages from something like this would totally outweigh the cost of changing them.

I'll probably get flamed, but...

I'm shocked that everyone here is so against GM on this.

Given the complexity of a car and all the things that could go wrong, this is a very minor issue. The brakes still work (no ABS though), steering still works (it's just harder to turn), and lights still work. It basically turns into a car that's 20 years older, not a coffin on wheels.

The driver also knew there was a problem, wasn't happy with it, but still drove her car regardless and then wasn't able to cope when it happened again. She wasn't forced to drive it.

Maybe it's because I tend to drive older cars, but I'm all too aware that they're machines and they break. I've had all kinds of things fail when driving and I've had to try and cope with them safely. Luckily I have, but if I hadn't been so lucky I wouldn't blame the car manufacturer.

100 years ago you could get killed by all kinds of things and it was more or less just accepted - why are we now at the stage where a switch that's a bit too easy to turn is the cause of all this blame?

I'm the guy behind this - I just woke up so I'm a bit late to the party :)

It's really good to see a decent discussion here...

For me, it's about getting the right tool for the job. I'm mainly a C programmer, but if I want to manipulate a bunch of files I probably won't use C, I'll use Bash.

In the same way there are (a lot of) times when what you actually want to do with hardware is quite simple, but you'd end up writing a whole bunch of C code to accomplish it - and that's where Espruino will not only be faster, but a lot more fun :)

Someone also mentioned power consumption/events and I thought I'd give you some figures. When Espruino sleeps between events (which is does automatically) it draws ~50uA. Even with explicit power management calls, pretty much all Arduino boards draw at least 5mA (so 100 times more), and without explicit calls it'll be 20-30mA. Raspberry Pi is anywhere from 100-500mA, so over 2000 times more power.

It's not strictly NodeJS based - According to their site it runs on top of Lua...

There's also another JavaScript microcontroller crowdfunding at the moment: http://www.kickstarter.com/projects/48651611/espruino-javasc...

Sorry for the late reply....

At the moment I've got the KickStarter board down to 4mA when idle (as it can sleep) - when executing code I think it's around 40mA. Hopefully by release time I'll have sorted out a few glitches and got it down to under 1mA idle (in the range zokier noted).

Note that with something like 'setInterval(doStuff, 1000)' the processor will be idle for 99% of the time.

Running off a li-ion battery from an old Nokia phone (700mAh) you could then expect Espruino to run for almost a month. Using the battery out of my Galaxy S3 (2100mAh) it'd run for almost 3 months.

There's Beaglebone, Raspberry Pi, and also now Tessel that do that. The previous two have had node.js support for ages but I think have been lacking any kind of real advertising because they're more general purpose.

All of those appear to be fully-fledged computers though, and Espruino's not really aiming to compete with them.

Instead, you get to use JavaScript on a very small, low-power microcontroller than will sensibly run off a small battery for days on end.

Some people will want one thing, some will want another - and hopefully they can both coexist. If we get it right they'll both help each other and we can end up with a large library of JavaScript code for embedded devices :)

Thanks! As I understand it, Tessel uses a version of node.js (and probably Linux underneath) so it needs around 32mb of RAM (and quite a lot of Flash too).

I've worked pretty hard to get Espruino running in 8kb (with space for variables) so that it can run on a single cheap IC (without external RAM).

I think they probably serve quite different markets. I figure Tessel are aiming to provide more of an ecosystem? If I'm honest I think they've got a bit of a fight on their hands against Raspberry Pi/Beaglebone with node.js installed, so I'd guess they're going for some kind of added value.

On the other hand, Espruino's aiming more where the Arduino is. Low power, where you want to play with LEDs or automate a project you've made, and you want the instant gratification of using an interpreter.

Espruino does use reference counting, and currently falls back to proper Garbage Collection if available memory gets filled with cyclic datastructures.

Responding to IO is handled and timestamped using interrupts, so if you write your code such that you use the timestamp, you can actually do some very accurate timing.

One other good point is (strangely) power usage. As there's an interpreter, it can very easily detect when it isn't doing anything and can go into low power sleep modes - it's something that you can do with another MCU and a lot of effort, but that you get for free with Espruino.

There are things it's good for and things it isn't - but for the majority of projects people do with Arduino I think it really does provide value.