MCU with JavaScript - espruino

Has anyone here heard about the kickstarter espruino?
http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things/posts

Seems like a great idea. I have seen a lot of people struggle with the C programming, and wanted to know what do you think about JavaScript as programming language for the MCU.

They have reached their funding goals so the product will come out. I ordered one, just for playing with it.

I'd prefer if it used Ruby.

...R

molahs:
what do you think about JavaScript as programming language for the MCU.

It's a horrible idea.

Everybody and their brother seem to always want to make the "Arduino Killer" - or at least take the "next step" - but I think what is ultimately going to hold back any of these (at least until there is no choice at all?) is the "3.3 volt" limit. Why?

Personally, among many reasons, I think that is why the Arduino has been so successful - 5 volt TTL DIP parts are easy to find, low cost, and easy to prototype and breadboard with. Not only that, but the Arduino is based around the ATMega328 - which is also available in a DIP IC form factor. Most 3.3 volt parts don't come in any form of DIP; they are almost all surface mount components. This is a hindrance to beginners; heck, I've been playing with electronics for 20 years or so, and I am not too keen to want to mess around with surface mount stuff (but ultimately I someday will have to). Just to prototype with a part I would first need to solder it to something; and if fails to work properly, was it because of my soldering job, or something else?

If that is something that I am questioning - can you imagine a beginner? The number of questions we see on this forum alone for DIP parts should tell you something.

It's strange, but despite surface mount technology being around for so long, the options for prototyping using it (or having alternatives) don't seem to have kept pace. In the industry, I suspect (and can only suspect, not having worked in it) that everything is simulated (SPICE and otherwise) first, and that the simulation files are then used to create the actual schematics and PCB files, along with part lists and such, and then these (depending on part sizes) are either hand-assembled to test it in "the real world", or automatically "stuffed" as part of the prototype production process. Basically a form of rapid fabrication for electronics.

That's all fine and dandy for the industry - but where and how does a hobbyist manage to do the same? While a hobbyist can - to a certain extent - simulate a new design, then move forward to a PCB, which could then be sent to a board house - and even stuffed - each of those steps incur a greater economic cost to the hobbyist - especially the last two - which, if the hobbyist gets their boards back and finds a problem, a lot of money will have been wasted. While with a breadboard and some jumpers, if a mistake is made, most often it's just time that is lost; sometimes it's a part that costs pennies to a few dollars that is destroyed. But in the end, it isn't hundreds of dollars lost.

Also - in reality - the tools available to the hobbyist to simulate a design aren't really available with the integration needed to go from design to a stuffed PCB without ever building an actual prototype. Those that are available for the public are typically in the "call to speak to a sales representative" price range; the majority of hobbyists don't have the economic means to even begin to go down that route.

Unfortunately, that is where everything is headed; I fully expect to see 5V TTL devices go by the wayside and for 3.3V devices become the new "norm" - I just wonder if there are going to be any options for hobbyists to fully use them for prototyping. So far, that answer has seemed to "no". Level conversion can only take us so far (and even there, most of the level converters are SMT devices, not thru-hole DIP). When 5V TTL is fully phased out, what will happen to our hobby?

Cr0sh.. You got 'a lot of points' there =P but I'm the kind of hobbyist that loves SMD! I learned electronics back in high school.. After that I haven't touched or did anything with my education until 2.5 years ago when I discovered the AVR microcontrollers.. Well you can imagine, I went from soldering only through hole components to almost only surface mount.. To me, surface mounts are easier to work with (somehow).. They are smaller and makes your project look neat/cool.. It only took me 3-5 boards in-order to develop a technique for soldering these small things.. It's not hard.. And when I prototype and etch my boards at home, I try to put only SMD's on my boards.. That's because I don't have to drill the boards, which saves me a lot of time and money (smaller boards == cheaper).. Anyhow, that's my opinion! =)

Back to the topic: No, Javascript is a horrible idea.. What's the next step after Javascript??? Developing a robot that writes these javascripts for you?? I can only see a lot of bulkiness and dumm code generated from this..

//Basel

I would like to echo everything that Cr0sh has said, and add the following ...

I don't know how many programming languages there are (I could probably think of 20 or 30 and be only scratching the surface). In theory all of them could be used with microcontrollers. But what would that achieve? All it would do is fragment interest and advice and confuse beginners. And the end product, the working device, wouldn't be any better or appear any different to the user.

I would much prefer to program in Ruby rather than C or C++ but the nature of Ruby makes it unsuitable for a CPU with very limited memory and there is a huge amount of advice available for the Arduino so I will put up with C++. Given that I already have to know a little about these two languages there would have to be a big incentive to work with a third.

Unfortunately it seems to be an in-built human weakness always to favour the newest thing with the biggest numbers (often including the price number :)) and a new CPU that runs at Zillions of MHz may be very seductive even though one really only wants to blink a few leds at 50Hz. Perhaps the Arduino community needs to put a little more effort into marketing the Due - though it does suffer from the problem of 3.3v I/O that Cr0sh mentions. Perhaps if another version had built-in level shifting ......

...R

Thank you all for your input. It seems I don't know enough about this mcu world (yet).
From a programming point of view (coming from asp/php/scripting background) JavaScript seems like an obvious choice for my area of interest being home automation.
I struggled a few days with the rf24 library from maniac bug, and not understanding the workings on C, I failed to see the obvious solution.

I guess people tend to gravitate toward what they know.
Just for the hell of it, I ordered two espruino boards with the rf2401 modules. Looks like the project will go through, so once I've got it, I'll report back. Most of the sensors I will use are 3.3v in any event, so I don't see the 5v limitation as such.

Again, thanks for your feedback.

cr0sh:
Everybody and their brother seem to always want to make the "Arduino Killer" - or at least take the "next step" - but I think what is ultimately going to hold back any of these (at least until there is no choice at all?) is the "3.3 volt" limit. Why?

Simple: Because you can't drive an LED directly from a wimpy 3.3V pin.

I think 5V AVR chips and other devices will be around for a quite a while because they can happily run at 3.3V too.

A device that can run at both voltages has no downside so why stop producing it?

molahs:
I struggled a few days with the rf24 library from maniac bug, and not understanding the workings on C, I failed to see the obvious solution.

Switching to Javascript isn't going to solve that.

What's nice about Javascript is that it has dynamic variable typing and automatic garbage collection. These are features that, to my mind, are completely inappropriate for a device with very limited RAM.

Not having these features is what makes C, C++ a pita but also makes it suitable for microcontrollers.

...R

Robin2:
What's nice about Javascript is that it has dynamic variable typing

A fruitful source of bugs, SQL injection attacks, etc.

Robin2:
and automatic garbage collection.

Dynamic memory is rarely needed on a microcontroller.

Even if it were needed, C++ destructors work (tada!). I'm currently working on a 250,000 line C++ program and there's exactly 19 'delete' statements in it, mainly for custom container classes. All the rest is completely automatic - I can't remember the last time I did manual memory management in C++.

fungus:
Switching to Javascript isn't going to solve that.

True. But if one is comfortable with the code, it's easier to find what is going wrong.
For my programming style, which is web based, there are never memory limits, or issues with variable declarations. I know it has to change when working on a MCU, but that's just time.

In my particular situation I used an optional setting in order to improve reliability

// optionally, reduce the payload size. seems to
// improve reliability
radio.setPayloadSize( 8 );

Not understanding why my Strings aren't going correctly from one Uno to another.
It's my "learning curve" I guess. If I can avoid it and use a familiar surrounding like php/asp/JavaScript then it's easier to understand the language limitations and hence easier to identify problems.

Thanks for your input.

I know it has to change when working on a MCU, but that's just time.

I suspect that there is a fundamental disagreement between the people that think the major "hurdle" to MCU programming is learning a new programming language (C or C++), and the people who think that the major problem is the fundamental limitations of the MCU environment (memory, speed, etc) (completely independent of language.)

You think dealing with the performance/memory issues is "just a matter of time." I think that learning enough C to get by would also be "just a matter of time." (doesn't simple javascript end up looking a lot like simple C++ anyway?)

As for cr0sh's concerns about hobbyists... To a large extent, the hobbyist solution is board-level products like Arduino, Raspberry Pi, BeagleBone, Teensy, and so on. The first "hobbyist microcontroller" was probably the BASIC51 chip; an 8051 microcontroller with a basic interpreter in its ROM. You could "easily" connect it to some EPROM and RAM memory, and start programming it in interpreted BASIC over the serial port using your ADM3A or whatever, and burn programs into the EPROM for permanent storage, if you had an EPROM programmer. The bare chip cost about $30. Next came the Parallax Basic Stamp; $30 for a module that did everything (well, now you needed a PC to program it, instead of a "dumb" terminal.) Bare chips were also available starting for about $10. Now we have Arduino, where you can get a pretty complete board for about $10, or various other boards in various performance ranges still in that $50 price range that people used to be happy to pay JUST FOR CHIPS...

When 5V TTL is fully phased out, what will happen to our hobby?

WE WILL ADJUST... my wife really does not use that kitchen toaster oven nearly enough to justify the counter space it occupies XD

Ray