61–70 of 92 posts
Actually, a microcontroller that runs Lua. They released the source for the JavaScript to Lua compiler today https://github.com/tessel/colony-compiler
Earlier quoted context omitted.
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?
Actually, a microcontroller that runs Lua. They released the source for the JavaScript to Lua compiler today https://github.com/tessel/colony-compiler
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.
They also mention that the API will be awkward to use from Lua, but it's probably pretty easy to fix this.
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.
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?
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.
Earlier quoted context omitted.
> 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 stu…
> 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…
Ridiculous?
Earlier quoted context omitted.
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 h…
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.…
People are not going to buy a Tessel to build a production-grade hardware project. It is for hobbyists.
Earlier quoted context omitted.
> 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 stu…
> 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…
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.