Tessel: A microcontroller that runs JavaScript
tessel.ioActually, a microcontroller that runs Lua. They released the source for the JavaScript to Lua compiler today https://github.com/tessel/colony-compiler
I wonder if you can run code without going through the transpiler. Then you could program it in a sane language.
I wonder if this can be used for redis scripting. I bet a lot of people writing node.js apps would like to be able to write redis scripts in JS.
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.
Apparently you cannot run code without using the transpiler, but it is planned.
They also mention that the API will be awkward to use from Lua, but it's probably pretty easy to fix this.
Lua has actually had a microcontroller project for years see http://www.eluaproject.net/ but without the nice slick deployment that tessel has.
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.
Device looks to be based on an NXP LPC1830FET180 microcontroller which uses an ARM Cortex-M3 processor at 180MHz.
http://www.nxp.com/products/microcontrollers/cortex_m3/LPC18...
The product page seems to indicate it does a more than run JavaScript.
It doesn't run javascript (not natively). It runs just like every other ARM microcontroller (so assembly, C, etc).
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.
Relevant: https://xkcd.com/801
$100 for something vastly inferior to a Raspberry Pi, Beaglebone, etc. that cost 1/2 to 1/3 of that. What am I missing here?
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.
Yes, but the Electric Imp has wifi built in for $30.
Ironically it uses the Squirrel language to program it, which I think was a mistake - I found it very unproductive.
They were using Lua, but found some of the features of the language to be non-condusive to microcontroller use.
If you want something similar that can be programmed bare-metal, check out the spark core: https://www.spark.io/
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.
That sounds awesome, any details on what kind of setup you have on the Pi for home automation? Would love to try and setup something similar!
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.
Tessel is marketed as a "micro-controller" while the PI as a "micro-computer"
Its funny when a micro-controller is more expensive than a micro-computer... :(
Equally as ill-conceived and/or misdirected as other "language du jour"-specific chips of times past?
Jazelle still exists in newer ARMs; ARM shot its own foot off by keeping it closed, so its use is limited to a few corporates.
Not really, it has been replaced by ThumbEE https://en.wikipedia.org/wiki/Jazelle#Successor:_ThumbEE
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 really don't see how that homepage example is any simpler than Arduino.
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.
No Linux, which can be an advantage or a disadvantage depending on whom you talk to.
You don't have to run Linux (or any OS) on the pi either.
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.
Dude. You need to get some perspective on this.
People are not going to buy a Tessel to build a production-grade hardware project. It is for hobbyists.
Fine; it's the paint by numbers of the hardware world. Oh, and it's really expensive to boot. Raspberry Pi's and Arduinos are for hobbyists; this is a child's toy.
Seriously, who cares? Why is there a badge of pride on our industry being hard? Its not like using a Tessel is something grandmas can do. Why is it a requirement for someone to know how to wire up a LED without blowing it? Software has become huge specifically because you don't need to know Assembly or even C to build real things that people can use.
If anything, you would think that you'd be overjoyed. People would hypothetically try to create products with these "child's toys" and give people like you a more robust job market and salary prospects. Or they wouldn't and it doesn't affect you at all.
You seem to be repeatedly straw-manning EpicEng without replying to what he/she is actually saying. Maybe I'm just seeing that because I agree, but writing a useful embedded application in javascript seems about 100x harder than any of the standard ways, teaches you nothing useful, and would have to be rewritten from the ground up to go into production. It's a legitimate concern, not an "I'm so much smarter than you" brag.
I don't think you read me correctly.
I agree with the facts and premise he presents. A Tessel is a toy. It is not going to teach you C, Assembly, or any of the realities of hardware development.
I disagree with the premise that this is a bad thing. I disagree with the premise that people are buying Tessels with the intent to create production grade products. This is literally a toy for people who want to screw around with hardware. This is not a bad thing.
Would you give people shit for buying some Lego Mindstorms to do the same thing instead of a Tessel?
> Do you want to turn it into a product?
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.
You are right. We should design hardware in javascript.
So kids shouldn't play before they go to school?
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.
Isn't the BLE112 already certified? Or does integrating it into a product require you to get the entire product certified?
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...
Where is the "individual components" line drawn?
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.
Interesting. Are Adafruit (https://www.adafruit.com/category/112) and Sparkfun (https://www.sparkfun.com/categories/16) certifying each of their wireless module breakout boards, for example?
Adafruit is an US company, they can take advantage of simpler US regulations. As long as I import the modules for private usage, I don't need EU regulations (but in case my device causes RF interruptions, I still am liable!).
As soon as I start to selling them for money in the EU, I am the importer and thus need to provide CE certification, R&TTE inspection, WEEE trash register, etc pp.
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.
Do they not support templates? I'd be happy with "C with classes, templates and RAII". But point taken regardless.
I completely agree - I'm also much more interested in Rust for low level and embedded programming!
If you want to write C++, just compile it to javascript: http://kripken.github.io/mloc_emscripten_talk/gindex.html#/
Ridiculous?
> Third, C++ is better than Javascript? That's going to take some explanation.
It's statically typed, and the types you have to work with are a lot simpler.
.NETMF will run a C# Interpreter in 256KB of RAM and 1/2 a meg of code space.
Give it a bit more and you can get a full UI up and running with a WPF variant!
I didn't think NETMF was interpreted. That said, the last time I looked at NETMF I was put off by forum arguments over who owned what code samples.
For the same reasons you're writing in English.
Arguably should not be written in low level C, but something safer, lest it become the Internet of Unfixable Botnets.
Beaglebone is cheaper and already runs a version of node.js that has extensions to do digital/analog I/O
STM32 + espruino.
Lost my interest the first day. Couldnt manage to make it run.
I won a Tessel at JSConf this year and love it.
Are there ways to make our own module attachments? The $50 parts seem a bit steep.
Yes. The module ports are documented here: https://github.com/tessel/hardware/blob/master/tessel-hardwa... and the JS APIs for using them here: https://tessel.io/docs/hardwareAPI
When I think microcontroller, I think < $5. I'm not sure what this is supposed to be for - it's almost as expensive as a gumstix board.
Not enough jQuery!
How does this compare to http://www.espruino.com/?
Espruino is a similar device (without the cool plugins though, so expect to use a soldering iron). Much cheaper too.
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.
Yep, lots of good tutorials, and the creator of the board is quite helpful on email.
In their code snippet, it seems that position is not defined for the first loop and would throw a ReferenceError.
Really slick looking but way too expensive. Might buy it for $40, tops.
Yes, because we really, really need something else to run JS.
You win, please, just stop the pain.
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.
Javascript: the embedded parts.
Learn Javascript the Hardware Way