They also mention that the API will be awkward to use from Lua, but it's probably pretty easy to fix this.
Just seems like an interesting way to bolster the ecosystem :-)
The secret sauce appears to be (at a glance) great software support (edited to add, I'm talking about "high level bindings" like JS... there's plenty of C for arduino, not nearly as much non-C) for a bunch of off the shelf compatible debugged plugin hardware. Also deeply buried in the docs section it appears to draw a Lot less power than a pi when doin "stuff". Of course if you want to blink a LED I think a PIC 10F220 might just slightly have you beat by approximately six orders of magnitude (no kidding, well 4 to 7 depending on blah). Anyway that kind of stuff should be the primary advertising focus, or at least thats what I found interesting.
I'm fuzzy on the "how easy is getting started" part, at least only after five minutes. Not being clear means it must be as bad as gearing up for FPGA work (just kidding I'm sure its not that bad). If its good, this might be an additional secret sauce. Here's a 60 second video from opening box to blinking LED (or, whatever)
At least that was the first five minutes impression from a hardware guy who knows the market. And I've now spent more time typing and thinking than I spent looking.
Javascript inherently relies on highly non-deterministic heap allocation, deallocation, and garbage collection. None of these are conducive to real-time IO. You can not make strong guarantees about javascript execution time.
They probably partially get around this by having all the important IO stuff done in C, but then that's not really a javascript microcontroller, is it?
http://www.nxp.com/products/microcontrollers/cortex_m3/LPC18...
The product page seems to indicate it does a more than run JavaScript.
This device has a lua interpreter running as its firmware (coded in C, it looks like) and these guys wrote a javascript to lua compiler.
So it runs javascript by compiling it to lua bytecode and then intrepreting it in a C-based intrepreter.
RPi/Arduino in contrast only have wired or no networking, thus eliminating a huge part of the upfront costs (e.g. in Europe you then only need a CE certificate, which you can either issue without testing and be liable if your module doesn't meet the standards, or you get an ESD/EMR test for a couple thousand bucks).
I ran into something similar with BT4.0 modules - had to convince the client that a $3 module, while cheap up front, couldn't be sold without spending $$$ on certification. Eventually they went with a $7 one.
Ironically it uses the Squirrel language to program it, which I think was a mistake - I found it very unproductive.
Javascript marketing aside,it would be interesting to know if one can reproduce all Tessel capabilites with a Pi + extensions.
I dont think the "but it runs nodejs modules!" matter that much,if you're going to write for embedded devices,you need to go low level and seek optimizations like crazy.The stuff has like 32MB of ram,you cant do much in javascript+nodejs with that.AFAIK it doesnt even run a javascript engine,but translate the code to LUA.
You can, I've had a Node-on-Pi based home automation system running for a few months now. It looks like Tessel's main advantage is the plug & play nature of their modules.
Its funny when a micro-controller is more expensive than a micro-computer... :(
Disregarding the actual device price, the other issue here is the expensive module pricing. Let's face it, if you're buying this because you want to do things the simple way then you're going to be buying modules. Ambient light + MicroSD card? That'll be $50 please. Too many electronics outfits shaft consumers like this and too many electronics hobbyists put up with it.
Still interesting all the same, if they can get the cost down it would open the micro controller world up to a completely new group of people.
...however, I do hope that they can bring down the price for future models. $100 is a bit steep for a hobby project to control my AC. For now, I understand that the premuim is rewarding the software effort.
The only reason javascript became popular is because it was the only option on the web. Why does that mean we would want to use it when we have better options?
First, C++ compilers are not available everywhere. Second, C++ compilers do not always implement all corners of the language on embedded systems. Third, C++ is better than Javascript? That's going to take some explanation.
> Or hell, why not write in Lua!
Lua has it's own share of "Wat". 1-based indexing when a non-trivial amount of your stuff needs to interoperate with C is a big one. In addition, Lua is nicely configurable--read, "Every Lua implements a different set of modules."
> The only reason javascript became popular is because it was the only option on the web.
It's popular to hate on Javascript, but Javascript isn't that bad. Go back and take a look at Javascript in the Netscape 2.0 and Netscape 3.0 timeframe. It's a fairly straightforward, minimal language.
Now, all that having been said, this isn't exactly impressive. A 180MHz ARM with 32MB of flash and 32MB of RAM is not a small processor. With that level of power, there are lots of options.
If this were running on an 50MHz M0 with 256K flash and 16K RAM, it would be impressive.
Lost my interest the first day. Couldnt manage to make it run.
Are there ways to make our own module attachments? The $50 parts seem a bit steep.
Anyway, some hw modules have been tested with Espruino and the web site explains how to use them. My understanding is that you can plug almost anything into it, you just (!) have to know its specs and how to wire it to the board.
I cannot fathom why anyone would even poke this with a stick other than to appease the maker crowd who to be honest scare the shit out of me. And the price. Kill me now.
