That's pretty awesome. I love Lua lately, for its simplicity both in design and implementation, and it's great to see that I can use it in an MCU! That said, it's pretty dumb that it has to have a JS transpiler in order to get popular.
It could be a really interesting tool for porting (some) javascript npm modules to luvit (a nodejs reimplementation with lua instead of js) as well :-)
Just seems like an interesting way to bolster the ecosystem :-)
My advice is the wrong tagline is up. If you want an embedded device running JS or higher level than C anyway, you toss in a raspi with much better hardware specs for much less money.
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.
I wonder how the timing on the micro-controller is. Is the JavaScript still async? While JavaScript +/-10ms is fine on a computer, when messing with signals that really limits you. Mind you this could be overcome by adding some flag before the code to specify it to be run synchronously...or something like that.
nothing in Javascript fundamentally forces IO libraries to be asynchronous, it's just that the domain in which JS is used (Node or Browsers) tend to have a lot of async IO due to networks.
> nothing in Javascript fundamentally forces IO libraries to be asynchronous
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?
It's not clear to me exactly how it came about that javascript is asynchronous. My suspicion is that in the earliest days, javascript was single-threaded simply because that made the implementation simpler.
It has WiFi, which requires FCC testing for the US market as well as compliance certificates for the European area. These certifications and checks are f...ing costly.
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).
You only need to undergo FCC testing if the module you use is not already certified. You can buy "FCC-approved" modules that are "ready to sell".
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.
Good point on the Wi-Fi. I guess that explains the cost, but it doesn't explain why you'd choose it over a Raspberry Pi. You can buy a Wi-Fi USB dongle for like 5 bucks on Amazon.
The base Arduino doesn't have networking. However, there are models, like the Yun, that do have wifi and/or ethernet and are less than the cost of the Tessel.
Tessel is marketed as a "micro-controller" while the PI as a "micro-computer".
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.
> it would be interesting to know if one can reproduce all Tessel capabilites with a Pi + extensions.
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.
It currently consists of a bunch of single purpose modules, some output (light switch and door lock via GPIO, music player, notification sender, etc.), some input (SMS via Twilio, Github webhooks, web interface, etc.), and a central broker. They're all communicating by sending JSON messages over ZeroMQ sockets. Each module connects to and registers with the broker, which keeps track of module health with heartbeats, and routes and schedules commands based on the modules' registered handlers.
It's less complicated than it might sound, I've got some (unorganized, undocumented) code up at https://github.com/spro/drsproboto if you want to take a peek.
Lower barrier of entry for people interested in playing around with hardware development. No breadboards and wires, only pluggable modules. Javascript instead of C.
I think for many people cost is the most important factor. People who bought the RPi did so because it was so cheap that it was practically an impulse purchase.
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.
Taking into account the value of one's time, maybe paying $50 for a pair of modules rather than taking the time to discover how to build them from scratch is a worthwhile spend? Enough hobbyists seem to think so, based on the success of these businesses.
The volume cost of parts that make smartphones, remote controls, wifi dongles, etc so darn cheap for the average consumer do not scale downward when you're only making 100 or 1000 of something.
It contains a grand total of three components, the only one costs anything is the SD slot. At 100 units, they're about 50c each. The other components cost nothing, relatively, you can buy a thousand resistors for a dollar. The board itself would cost under a dollar to make at anything above 10 units. Total cost is about $2 if we're stretching.
I ran a quote for an assembly house, and for 100 boards it would cost around $200 or $2 a board - so now it's $4. Standard markup is 3 times the build cost or about $12-15. Yet it costs $25. That doesn't include international shipping, by the way.
Economy of scale certainly works when you're making 100.
Even Seeed Studio do assembly nowadays, and you don't even need to carry the stock as the components are in their Open Part Library.
So...people who want to play around with hardware development without actually learning anything about hardware development? How is that helpful? Why not just learn what you need to learn and do it right the first time?
I assume you're using a computer you made yourself from materials you mined out of the Earth? Running software you programmed in hardware of your own design?
Higher level abstractions in computing are of obvious value. Many more people know Javascript than know HDL, an assembly variant or even C. It's pretty obvious why this would be helpful. If you know a little bit of Javascript you can get out of the browser and have physical stuff happen. Pretty neat hack if you ask me.
Yiur first paragraph is simply absurd, so I'll ignore it.
So what is one to do once they have designed a system using this platform? Do you want to turn it into a product? Great! Go redesign the entire thing from the ground up because what you made is a toy.
It can't be manufactured at a reasonable cost. The code will have to be completely rewritten. The hardware has to be completely re-specced. What a waste of time.
There are plenty of micro platforms our there these days that require relatively little knowledge of hardware,yet at least resemble something you may actually see in the real world. Use those.
That said, I could see myself being proven wrong here,which is fine. It would only take some enthusiastic person who already knows JavaScript and has some revolutionary idea to-do do so.
My opinion is that you don't need to sit on mountains of abstraction at all times. No abstraction I'd perfect and we already have enough people in this industry who don't really understand what the hell they're doing. Learning something new isn't a bad thing.
Probably, they don't want to turn it into a product. Probably, they just want to use it themselves. In this case it makes total sense to improve speed of development despite increasing unit cost.
Because hardware is hard. There's a learning curve that requires a time investment before you can do anything cool. Anything that starts to tear down that learning curve is a step in the right direction.
Do you honestly think that there is anyone out there who bought a Tessel instead of an Arduino/Raspberry/etc.? Every single person I know who ordered a Tessel is someone who wasn't interested in hardware originally AT ALL. The premise of the Tessel got them interested in playing around with hardware.
Edit: I answered this seriously because I assumed OP was a serious comment. After re-reading, I'm not certain, so I apologize if it wasn't.
It's absurdly expensive, even more so the modules. Looking at the BT module, the BLE112 can be purchased for $15 in quantities of 1. So you pay $35 for a small PCB, some pin headers and probably a wrapper around a UART.
As written above, everything related to radio has huge upfront costs in certifications. These costs are once-applicable, so if you're making a million-unit BT dongle, then the certification costs per device are fractions of cents. Here with thousand-unit series, the cost per device is massively higher.
In Europe, the one who imports the device must submit a certification document for the device... so even if you just stick already-approved products together you have to do a complete recertification. This, sadly, also includes selling a "Raspberry Pi computer" with you as distributor packing a Pi and a Wifi stick in a case. Only if you ship the individual components to the customer to self-assemble, you don't need certification...
As soon as you take anything and put it together, my lawyer has told me. Technically, even computer shops assembling computers from parts will need a full certification for every combination they sell... it's crazy.
Add the WEEE regulation (valuable resource recycling) to the mess and you're out a couple thousand bucks if you do everything by the books.
You can kind of achieve the same results with an Arduino board and https://github.com/rwaldron/johnny-five, but you do have to have a computer connected. I think you could probably hook up a raspberryPi with a usb network adapter and an Arduino for the for the same or less cost than the main unit.
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.
This is great. I have some small background in real time embedded systems, but I think that 99% of the "internet of things" need not be written in low-level C. I'll probably pick this up...
...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.
You don't have to write in low-level C. You can write in high level C++, which is vastly preferable to javascript! Or hell, why not write in Lua! It's what this apparently transpiles to, and is much nicer.
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?
> You can write in high level C++, which is vastly preferable to javascript!
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.
> First, C++ compilers are not available everywhere.
Neither is javascript. If both are available for this micro, then his statement is as valid as yours.
> Second, C++ compilers do not always implement all corners of the language on embedded systems.
I've done a good bit of embedded programming in C and I wouldn't need all of C++ to make life a lot easier.
> Third, C++ is better than Javascript? That's going to take some explanation.
To-may-to/to-mah-to. Whichever way you want to spin it (C++ > javascript or javascript > C++) is going to take some explanation.
> but Javascript isn't that bad
No. But its also not as that great in comparison to how popular it is. Its certainly improved a lot since the early days, but it still has some pretty significant warts. Most languages do, of course, so if this is an issue or not kinda depends on the "third" above.
> 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.
Indeed. I wonder how much overhead this has compared to running C on the same thing. I have nothing to back it up and certainly don't have time to benchmark, but I'm convinced I could write a forth interpreter running on a 60MHz PIC24E that would have competitive performance to this thing. Maybe I wouldn't beat it, but I reckon I could come close enough.
> Neither is javascript. If both are available for this micro, then his statement is as valid as yours.
Hrm, I stand corrected. I thought that at least some of the Javascript implementations were C-only, but it looks like they all require C++.
> I've done a good bit of embedded programming in C and I wouldn't need all of C++ to make life a lot easier.
Templates, exceptions, and memory allocation all interleave and you pretty much can't have one without all of them. And that's a huge amount of overhead on a truly small system (which this is not--my first Linux box wasn't 180MHz with 32MB or RAM). About the only thing you can have standalone is the original "C with classes" subset of C++. And I just don't find that very much more useful over straight C (and certainly not over the latest standard C11)
However, I'm much more interested in Rust on embedded systems than these dynamic languages.
I got one and I'm starting to experiment. I discovered that soldering can be a problem. First, I had to buy a solder. Second, physics is merciless and a mistake can toast your card (didn't happened to me yet) vs the run-fail-debug loop we're used to in sw development.
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.
As someone who does a bit of embedded stuff here and there (professionally), this.
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.