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.
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.
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.
If you want something similar that can be programmed bare-metal, check out the spark core: https://www.spark.io/
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.
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.
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.
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.
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.
People are not going to buy a Tessel to build a production-grade hardware project. It is for hobbyists.
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.
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.
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.
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 completely agree - I'm also much more interested in Rust for low level and embedded programming!
Ridiculous?
It's statically typed, and the types you have to work with are a lot simpler.
Give it a bit more and you can get a full UI up and running with a WPF variant!
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.
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.
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?