Welp. Two hours in and the comments are shaping up as you'd expect on HN.
Is it really so hard to empathize with people who have different skill sets than yourself? Yes, C would be more efficient. Yes, this wouldn't be very cost effective used in a high volume product. Yes, it's a little funky to write a web page just to plonk your script tag in there.
But, if you spend all day doing front-end dev with jQuery and just want to prototype some blinky lights or a flood sensor in your basement, now you've already got all the skills you need. You're not producing a million units, you're not worried about power so much as it'll be plugged in. An evening with a soldering iron and your text editor and off you go.
Anyways. For prior art on this ecosystem, see janOS:
which is basically stripped down firefoxOS which runs your app only (none of the launcher crud and such) in god-mode. It's actually quite fun to go grab a $30 phone off of ebay, and have a nice programmable screen and sensor suite with wifi, gps, and cell connectivity. Indeed, I find it more compelling than this board they're releasing, because I like taking advantage of the cheapness of mass manufacturing. The only downside is it's difficult to impossible to break out any GPIO on phones.
I agree, and I come from an old-school C and embedded background. If you do it in C, you have the opposite problem: interacting with the hardware is easy, speaking to a web API becomes a huge pain.
There's an "impedance mismatch", which has to be overcome somewhere. And computing power is getting cheaper and cheaper. We're at the point where if you have a little board in a case with some I/O connectors, the CPU will be the least expensive part. Casework and connectors will make up a surprisingly large part of the cost, often costing whole dollars!
Edit: also, debugging your C microcontroller program can be quite a pain, even once you have a correctly configured in-circuit debugger.
Coming also from a hardware design & embedded background, it was quite a surprise when I began to notice this a few years ago. I was so accustomed to processors being expensive that it was a shock to notice that as their prices dropped close to zero, it was the connectors and switches in my design that were becoming the expensive bits.
OTOH, CPUs are now so cheap they have become replacements for fixed logic devices.
Sure cpu's are cheap, but the thinking in the embedded world is still - i'm making 20K of this(or maybe a lot more) , and if i save 50cents on the cpu - this is $10K so management will like this savings, even if it takes some work.
But actually , if you can replace the physical UI with a phone based UI using a cheap bluetooth mcu and some framework like blynk or simblee ,than you'll have a decent ram/flash and a cheaper product.
> interacting with the hardware is easy, speaking to a web API becomes a huge pain.
Particle (particle.io) does a pretty nice job of bridging this gap in my experience. You still write code in C-like Wiring, but they have built-in APIs for storing data in the cloud and calling webhooks. It's not as simple as interacting with web apis from JS, and the fact that it relies on their cloud service would make me hesitate to use it in a commercial product. But for my home play projects, it provides a really nice balance of using C for the hardware stuff without making the networking stuff a major pain.
If you know C, you will love Arduino. It's very easy to "to speak to a web API". They are usually low power 8-bit CPUs with 16 MHz, exactly right for small projects like blinking some lights that should run on battery for years.
JavaScript/Python/etc on RaspherryPi or this new Mozilla thingy are interesting too, though will drain your battery faster. You need an OS on a 32bit CPU. If it's connected to the web you should also update the software stack.
Isn't it the opposite? If you aren't comfortable with C, Arduino has a simple enough API and good enough tutorials+documentation that you can still make it work.
If you are comfortable with C, just about everything is better than arduino because you'll get debugger support and full control over all the goodies like clocks, charge pumps, DMA controllers, asynchronous ADC operation, pin multiplexers, USB/Ethernet controllers, etc.
I live in the middle. For quickie little projects like my NMEA protocol converter, the Arduino tools & IDE are fine, if barely adequate as the project has grown.
However, I have another project where Atmel Studio is a better choice. So I import all the Arduino libraries I need (there's a plugin that can do this automatically, but it's buggy), and then just build it as a regular C++ project but I get "free" use of the libraries without the crappy Arduino IDE.
The nice thing about Arduino is it's so popular that the economies of scale let me buy hardware cheaper than I could build it myself and pretty much all the libraries I need are already written. Although I have had to debug a few of them!! The bad thing is their terrible interface that's really made for tiny programs only.
It depends what you want/need. Initially I thought like you too, I coded embedded C stuff years ago. Though for quick prototyping and hobby things, it's a lot faster to write C code with macros (=Arduino), you can put together a nice prototype in hours. If you want to sell your product, you can always rewrite it later.
I thought Arduinos didn't come with Ethernet on the chip, and instead you have a Heath-Robinson addon board which you speak SPI to another microprocessor which has the TCP/IP stack, MAC and PHY on?
The only thing I've seen that seems to really be viable for remote battery operation is the ESP2866. I have a Pi in my cupboard reading the electricity meter.
I really ought to learn Arduino, simply because it's so popular.
There several Arduino models that have an ethernet port on board and there is the official Ethernet Shield for other models like UNO, Mega. The Arduino standard library supports the common solutions out of the box. So no, you don't have to bother with low level stuff (but optionslly, you can write very low level C and shift registers and speak SPI directly, if you want).
The biggest problem I can see here is how limited using a browser as an API is. It has USB ports but there doesn't seem to be a way to add new functions to speak to them in the browser API. Likewise, there's no UART API, so using this to control an Arduino for any sort of real-time needs is going to be much more difficult. There are no event hooks for hardware, which means you have to fall back to polling the device for data. There is no sort of server API, so anything this device does to connect to the outside world will require pushing to an intermediary.
While I understand your desire to use javascript to program it, the API presented thus far is slipshod and half-assed. This is barely a tech demo, and is going to need a lot more structure and development for it to be compelling as an IoT device that's more than just a toy.
Sure prototyping platforms are useful, but compared to prototyping/dev platforms availble for the IOT , some done by single guys , and with the expectations carried by the name Mozilla, this seems extremely underwhelming.
IMHO, this project is coming ahead of its time. I don't think it's going to gain traction due to the fact that the hardware requirements for the overhead imposed by the underlying web stack will make it too expensive.
SoC: RK3066
Memory: DDR3 1GB
NAND Flash: 1GB
microHDMI female
microUSB x 1 (OTG)
USB x 1
microUSB x 1 (UART debug)
GPIO > 1 (Configurable)
I2C 2
UART 2
SPI 2
Audio analog stereo IN x 1 / OUT x 1
PWM 1
Analog IN x 1
Note that everyone's missed - it has HDMI out. This is looking more at smart devices that display information and which you can interact with directly, rather than devices which you configure occasionally and which are hidden otherwise.
Additionally, this is likely a DIY/hobbyist board and a reference device - any major company doing their own thing will likely be building their own devices. Mozilla isn't in the B2B business.
Which is useful for early prototyping I guess, but does it have any way of interfacing to non-HDMI screens? You wouldn't want to use HDMI for a product, and even for DIY hobbyist stuff it's probably not ideal; small HDMI screens with touch are exotic, expensive, and not all that small.
Is there any reason they'll remain exotic, expensive and not that small? (I don't know what interface the typical high-dpi oled touch screens use, like the ones you find on a Galaxy Note 4 etc) -- but it seems that HDMI might make perfect sense for a tiny 4k screen (and it seems reasonable those will become more and more common)?
Devices don't use HDMI to talk to their built-in screens due to licensing fees, complexity, etc. Usually it's either LVDS or embedded DisplayPort these days, with newer/4K screens being more likely to use DisplayPort and older ones generally using LVDS.
The BeagleBone Black is $49.99[1] and has very similar specs.
You can interface with its hardware using JS, and it already ships with the web-based Cloud9 IDE.[2] The main differences are:
* BBB has 4GiB on-board storage vs Chirimen's 1GiB
* BBB has 512MiB RAM vs Chirimen's 1GiB
* BBB has no analog audio in/out, but
Chirimen has no on-board networking
* You can buy a BeagleBone board right now.
If you want to trade off the micro HDMI port for two additional 4-pin peripheral connectors (Grove[3]) and trade the 5V power adapter requirement for the ability to power the board with microUSB, then there's the BeagleBoard Green for $38.99.[4]
It remains to be seen whether this applies to all firmware on the device. Hopefully it does, but I've seen too many similar claims by hardware manufacturers that turn out to mean "only these specific firmware bits".
Mozilla does so many things. I am afraid they loose their focus on one thing they could have done best. Make the best open source browser of the world. Look how they abandoned firefox OS phones. They shouldn't hope to become Google by doing almost everything Google does. Google is way bigger and has better Engineers.
The thing is, making "the best open source browser of the world" has never been a priority for Mozilla. Their stated goal has always been "to promote openness, innovation & opportunity on the Web".
The first thing they made was a web-browser, because they had all the pieces and all the people right there, they had a good idea how to do it, and because the biggest threat to openness, innovation and opportunity on the Web at the time was the dominance of Internet Explorer.
These days, Mozilla must be less focussed because there's no single dominant threat to focus on. There's things like video patent codecs, DRM, promoting HTTPS, the ever-increasing complexity of the browser stack, the enticing power of native mobile apps, the lack of an awesome funding model for freely-distributed content, the return of walled-garden content platforms...
They could focus on making Firefox awesome and abandon all the rest of those issues, then we'd have a nice browser but we might have a much less interesting and useful Internet to browse with it. I do not envy Mozilla's leadership in the slightest right now, they're making a bunch of very tough decisions and nobody will know if they did the right thing for maybe five or ten years.
> These days, Mozilla must be less focussed because there's no single dominant threat to focus on.
I don't think this is the right way. Having two much on the plate can actually be negative and you might end up doing nothing really well. I don't think that Mozilla should only be working on Firefox, but rather select few more which manage to do properly. We need a focused Mozilla, not a scattered Mozilla which tend to do everything that's a FAD (For eg: IOT)
I don't think it's an assumption. Just look at the contributions of some of the senior staff engineers such as Brad Fitzpatrick for GO, Jeff dean to name a few on their projects. I don't see any parallel at Mozilla who could rival them. Well, for really ambitious software projects, you really need someone who has tonnes of experience and can write really good code. Not to say that Mozilla doesn't have any, but I think they are not in the same league.
I can't speak for Mozilla at large, but I've had the pleasure of witnessing both Mozilla's Rust and Servo teams at work and can assure you that they are at the top of their league. To pick just two examples, Alex Crichton is an unstoppable machine ricocheting around the compiler, standard libraries, package manager, various miscellaneous tooling, and dozens of libraries in the broader Rust ecosystem leaving patches in his wake (all while finding time to perform legendarily detailed code reviews); meanwhile, Patrick Walton is an awe-inspiring graphics programmer and browser engineer whom I am convinced is among the top five humans with back-to-front understandings of the CSS specification, and by now is likely the world's foremost expert on cross-browser CSS quirks and edge cases.
TL;DR: I'm a squeeing fanboy for a lot of the people in Mozilla Research.
Well, you have a point but you see, both Rust and Servo are at the nascent stage. We still have to see widespread adoption of Rust. Servo is definitely way behind any browser engine in terms of features and specs and rewriting from scratch might also introduce new bugs(happens with every software product of considerable size). To summarise, both of these are very nice and ambitious goals but I really hope they turn into something nice rather than just an ambitious project(Servo).
Both Go and Jeff Dean's projects are meant for server-side work, so it is unsurprising that Mozilla is not a rival in this space.
However, it turns out they are heavily innovating in the same space as Go with their stunning work on Rust. Additionally, they are building world-class next-gen products with their work on Servo and Daala. Not to mention fantastic tools such as http://rr-project.org/.
I believe your assessment of Mozilla's engineering talent is inaccurate.
Well, you could say Servo is world class, but on what basis? Rust looks very nice but hardly anyone outside Mozilla is actually using in production as compared to Golang which has a very good adaptation in the community.
Yes, I am familiar with them. The tooling has been really good of late. Android Studio has really improved and it is no longer as bad as it was with Eclipse.
I sympathise with your problem and I understand it must be pretty shitty. But Java is the main language for Android, C/C++ support is via NDK. Since a majority of devs write in Java, naturally more emphasis is given on the Java ecosystem and not the NDK, which is definitely sad. Also, what big Open Source project doesn't have issues? Could you name one?
>
Yet Microsoft and NVidia are able to provide a much better experience for NDK users, for a platform they don't own.
Yeah, it's stunning how impossible it is in 2016 to profile native code on Android with Google tools. Meanwhile, Apple has had arguably the best CPU profiler available anywhere on any platform (Instruments.app) for years and years.
NVIDIA has done an incredible job making this basic functionality work on their Android systems…yet, sadly, their work doesn't extend to all Android platforms.
Permission to explore and invent sounds nice and it is very educational. However, It is not a guarantee a good quality product. You need correct decisions and architecture to write any complex software and experience matters a lot in this space.
Every year as December 31st looms, I sit down and parcel out my end-of-year donations to organizations I care about. Wikipedia, EFF, and of course some non-tech-related charities.
Every year, I weigh whether I should throw some bucks to the Mozilla Foundation. I've been using their browsers, under one name or another, for over 20 years since the day I first discovered the web. It's been the most important piece of software in my life.
I appreciate what they (along with Apache and BSD) have done in providing an open source counterexample for the GPL, and opening the door for open source in corporate software development.
Moreover, I worry about their long-term financial viability. Yahoo is NOT going to be around in its current form forever. I'm not sure whether there's any other "anchor sponsor" on the horizon that would fund Mozilla at the same level as Google or Yahoo without forcing compromises in principles.
However, I still just haven't been able to make myself click the donate button.
The things that I ACTUALLY care about from Mozilla (i.e. Firefox and Thunderbird) are things that fell into their lap from Netscape back in 1998, and which they've incrementally tweaked or re-worked in the two decades since. I don't feel a sense that anyone in a leadership position at Mozilla really cares about those things. I think they see them as "legacy software", providing only a "brand" to be "leveraged" in squeezing a bunch of other junk onto their resumes.
They work on a lot of interesting technical things behind the scenes, but little of it appears to have traction or visibility. The things that ARE promoted by leadership and marketing are "day-late-and-dollar-short" imitations of whatever Google did a few years prior. I don't care if you create a "me too" copy of Android without any phone carriers to sell it. I don't care if you create a "me too" Raspberry Pi, that will be lost in a sea of other coming-soon hobby boards by the time it's actually released.
The Wikipedia article on Mozilla suggests that their annual budget has grown from $2 million initially, to over $300 million today. You know what? They were a better and more RELEVANT organization when they were closer to the $2 million mark. I don't want to donate money so that a band of Google-reject executives can pad their resumes with nonsense and shut down Thunderbird.
I almost kinda HOPE that their funding collapses in the wake of Yahoo's death, so that the leadership bails and they're forced to downsize into something sensible and focused on the flagships. I just hope that the perhaps-inevitable reformation can happen gracefully without being so jarring as to end Mozilla altogether.
This is a strange comment that starts in one place, and ends with your musings on the collapse of Mozilla.
First off, Mozilla didn't have FF "fall into their lap" from Netscape. Netscape spun it off and gave birth to Mozilla. They absolutely do not consider Firefox legacy software and you'll need to back that up somehow for me to believe it.
They may very well be a better company at $2M than they are at $300M, but the back half of your comment sounds bitter and angry at what appears to be Mozilla's recent announcement on Thunderbird.
Despite the "bitter and angry" connotations, GPs comment still rings true. Everything branded Firefox or Mozilla is dying a slow, withering death. At least, everything I used to like using.
> First off, Mozilla didn't have FF "fall into their lap" from Netscape. Netscape spun it off and gave birth to Mozilla.
Not that this is a critical point worth arguing about or getting bogged down with pendantics... but I don't see any meaningful distinction in what we're saying.
Mozilla was bootstrapped with Netscape IP. They maintained Navigator/Communicator for awhile, then split its browser and email features into separate slimmed-down applications. My point was that their flagship applications come from inherited IP, and none of their original IP developed since the Netscape split has been remotely as impactful.
> They absolutely do not consider Firefox legacy software and you'll need to back that up somehow for me to believe it.
I struggle to name any meaningful developments in Firefox over the past 7 years that are not direct imitations of something done by Chrome. The situation with Thunderbird during that same window of time, and Mozilla leadership's view of it going forward, has been discussed at length. All major new initiatives and public visibly is directed toward mobile OS or IoT hardware unrelated to their flagship applications.
In my view, that is legacy software. The definitions and wordsmithing of others may vary, but that's the rationale behind my use of the term.
> the back half of your comment sounds bitter and angry at what appears to be Mozilla's recent announcement on Thunderbird
It is challenging to communicate in an online written medium, without being able to use voice inflection and body language to convey cues and emphasis on certain words as you would in person.
So if I capitalize a few words, or use Markdown formatting on a couple of phrases, that doesn't necessarily denote "anger or bitterness". Italics isn't a microaggression.
For what it's worth, I switched my personal domain's email hosting to Google Apps, and haven't used a desktop email client in years. I'm not personally bitter over the decline of focus on Thunderbird.
I'm simply wholly uninspired by everything that Mozilla leadership is trying to inspire me with today. The declining usage of their flagship applications, along with failure to gain traction for new initiatives, indicates that I'm hardly a minority. They need a more focused vision and identity.
> I'm simply wholly uninspired by everything that Mozilla leadership is trying to inspire me with today. The declining usage of their flagship applications, along with failure to gain traction for new initiatives, indicates that I'm hardly a minority. They need a more focused vision and identity.
I miss being enthusiastic about Firefox. I've used it since it was Phoenix. It was an absolute joy to use until some time in the 2.x series, IIRC. These days? Chrome's snappier, I like its interface better, its extension ecosystem is nearly as good, and it's ~1/10 as likely to make my fan kick on. Safari's so much easier on my battery that it's like the others aren't even trying, so I end up using it most of the time even though it's my least-favorite of the three.
I'd like something that is to Firefox what Phoenix/Firebird/Firefox was to the Mozilla Suite.
I think it's just unfamiliarity with anything else, and unawareness of the staggering complexity this introduces. Also, this is Mozilla who have a large concentration of people familiar with browser technologies.
On the other hand, I think IoTs with web interfaces aren't a bad idea.
> I think IoTs with web interfaces aren't a bad idea.
I think it is. The internet-of-things does not need to suffer from massive power consumption and hard to implement on the micro-controller scale protocols.
It needs something much more along the lines of encrypted UDP than that it needs to use 'web technologies'. Imagining a stack made on 'web technologies' running off power harvested over a relatively long period of time is painful.
I had in mind more things like routers, home automation management consoles, etc. which have had web interfaces for a very long time, but it doesn't take all that much power to do it[1], unless you want to run a full Linux kernel and JS and all that other bloat which tiny IoTs don't need.
Indeed. Basic web technologies - client-side HTML, CSS and JavaScript (and I mean writing them directly, not via absurdly wasteful layers of JS frameworks) - are a great tools for adding UIs to connected devices. You don't need that much resources for a HTTP server if you already have TCP/IP connectivity, and you also don't need much resources to output some rudimentary HTML or to process POST requests.
It's also a pretty cool tool for adding UIs to software you code locally. Embedding a HTTP server is simple in most languages, and for some cases, a web interface will be much simpler than building an equivalent from "native" UI components.
--
Incidentally, one of the best demonstrations I saw of that was in the book Land of Lisp. The book teaches you Common Lisp by guiding you through writing a few games. At some point, you end up embedding in your game a very simple HTTP server - and suddenly, you get to have interactive graphics (via SVG) without the author having to teach you lots of stuff about some random UI library.
> this is Mozilla who have a large concentration of people familiar with browser technologies.
It does, but this is not the reason. Browsers have grown to contain a stellar collection of networking APIs (compared to the rest), and IoT devices depend on talking to each other. Indeed, the people at Mozilla working on this stuff know more about the nitty-gritty of the low-level than about standard Web development. The API is for the users.
Browsers allowed developers to bring new things to customers quickly, because it was the only decent way of developing application that could work with Windows. It was the only way good open source software could "breach" how microsoft was doing business and putting barriers to the internet.
The problem is that now, we should move on, and use something else than a browser. Maybe it involves inventing an alternative to html, or making all application networking p2p. Not talking only about bitcoin. Also, html is so much focused on TCP, and not on real time networking.
I'm not dismissing the web, but to me it seems that it's the only decent standard to do things, and there's really nothing else.
> It was the only way good open source software could "breach" how microsoft was doing business and putting barriers to the internet.
Maybe I'm missing out on a big chapter of the history of computing, but I don't recall Open Source done via webapps until very recently. Most of the things browsers did were things that mattered only to businesses - like easier software updates, and much more control over the customers and their data. And the latter reasons are why web technologies are popular today.
Weird code like this is what you get when you apply web technologies to hardware. But I guess I should wait until their docs come out, maybe the title tag will be used by something.
They properly have a better chance here than with FFOS, there are no carries to interface with and the audience is developers who know mozilla in advance.
I opened this on my phone, and just seen some links (MozOpenHand Links). I had no idea there was supposed to be more content here. The actual content is hidden for mobile UAs (I have no idea why, but it's very confusing).
I'd have expected more from a Mozilla project.
You can see what I'm talking about by spoofing a mobile UA in your browser.
I've developed a few things on my Espruino Pico[1] board, some Raspberry pi and also so arduino things. Just toys really.
One of the nice this I've found with the Pico is because of the JS vm, when I don't do anything in the code all the power in the chip goes to sleep state, and just wakes up for me as I've got scheduled. Yes Arduino has sleeps but i've also go to go learn that as another thing, yes the Pi can be configured so but that's even more tinkering.
JS seems like a really great "Just get it done" sort of phase to work in. After that you'd no doubt make a better job of the project with a myriad of other technologies.
Indeed, JS being event-driven probably makes it a better fit for such devices. Most devices don't need to be realtime, so the GC pauses likely don't cause much harm. Speed isn't an issue most of the time either. As Dart is similar, it is also trying to lodge itself in that niche: http://dart-lang.github.io/fletch/.
Most embedded applications consist of a tight loop of constant polling. People slow things down by using delays... But if you use the wrong sort of delay (read: the most popular one https://www.arduino.cc/en/Reference/Delay), you'll end up executing nops instead of powering down the processor
What would then be the right way to sleep? I've always wanted to do something like 'sleep until event <X> and do absolutely nothing till them', but end up using the delay every time.
From what I searched, it's dependant on your microcontroller, so there is no generic way to do this (since different Arduinos have different microcontrollers).
For a very low power project I had, I basically found a lib that did deep sleep correctly for my microcontroller (an ATTiny), then you sleep for a significative period of time each time (for example, 500ms), and check if the event happened when sleep ends. That results in a consumption under 10uA.
It is obviously very dependant of what you want to do, some applications can't afford to check only every X ms.
And be careful too, you need to put everything possible behind your microcontroller, to be able to disable things during sleep (otherwise, you are just powering the rest of your circuit for nothing).
Unfortunately there's no easy answer to the correct solution. One method is to setup interrupt service routines and put the mcu to sleep the rest of the time. There are a couple libraries that provide convenient interfaces to AVR's sleep lib e.g http://playground.arduino.cc/Code/Enerlib
The basic idea is that it is possible to put the chip into lower-power mode... but you need a way to wake it up after that. That could be an interrupt, watchdog timer... etc
Another thing to note is that for most applications the mcu's power consumption will be negligible with respect to the peripherals', so the average person shouldn't care much.
I have one application where the CPU literally does nothing other than process switch actions (it turns a double click into a single click), so it goes into deep sleep and pressing a pushbutton is the only thing that wakes it up.
not that I like javascript that much, nor I know how meaningful are the result you can get with js in iot-firefoxOS, but js is absolutely more approachable than C so there's that problem that can be solved (lowering the barriers to access hacking on some iot device).
What's interesting is it's compatible with Web rendering probably at a relative cheap price, and it runs an OS which has WebRTC and stuff, so it can be used as a cheap terminal but which is still able to render internet modernly, and connect through WebRTC to any browser. So it could be used as a server and rendering unit in a network of cheaper C-only integrated circuits which connect to it, I think. Personally, I'm not an expert, but I'm intrigued. We're biased by the monstrosity of the thing, but I like the idea, and surely it serves its function.
Seriously ? The only build/library ecosystem that I hate more than C++ is javascript/node - it has all the same problems (a bunch of competing and incompatible standards/tools/patterns that do the same thing) but lower quality because of so much noise from low barriers to entry (hey at least you need to get C++ to compile on one compiler - that's something).
In the context of IoT applications, the typical application is either a dashboard web page or a HTTP web service - hosted on the device in both cases - serving sensor information to whoever requests it.
Both cases are easily implemented using Javascript on Firefox OS [1].
In contrast, a C(++) application would let you read the GPIO states. But all the HTTP stuff still needs to be implemented. What's a good way to do that? I know C(++), Python and Java. I might select one of these. Can I use Node.js and interface with the C(C++) code? I don't really know.
I think such questions inhibit devs who have not done any/much backend programming from getting into the IoT field at all. Firefox OS solves that problem by exposing low level system interfaces via client-side JS.
As for the larger topic of javascript vs C(++) ecosystem, I can't say much because I'm not that familiar with server side javascript.
I agree, one issue with js on embedded is that while it is fun and easy to prototype compared to C, if it is intended to be mass produced the variable cost for each unit will be a lot higher due to js needing more powerful->more expensive microcontrollers. If you would substitute C for something in embedded I personally would go for Elixir/Erlang or something that would actually provide some great advantages over C in terms of abstractions and VM:s.
I am actually hoping for something like web assembly versioned modules with a p2p module registry to become popular for iot, blockchain, everything. Web assembly is actually a language-agnostic abstract syntax tree which can be JITd/compiled across architectures.
This is pretty cool, but imo raspberrypi is making micro-controllers obsolete. Why would you bother with such a limited environment when you can have a full linux environment + GPIO for like $10 more.
In many cases, sure, however there are definitely cases where microcontrollers still make sense, i.e. real-time control, low power applications.
I work in embedded systems, and a lot of the reason you would choose a microcontroller is all of the peripherals that are also part of the chip. For example, if you are doing a project where you need to control motors, you can get a micro with a lot of built in high resolution timers , built in hardware for motor commutation, decoding of encoder signals, high speed analog inputs for feedback, etc. You would also typically AVOID having a linux environment, and opt for either a hand coded loop, or an RTOS which gives predictable, deterministic performance.
In my particular industry (robotics), we definitely do like to use a more powerful computer with linux or some other high level OS on it for a lot of the high level intelligence, so a lot of what you end up seeing is almost a 'distributed system on a board', where you have a more powerful processor providing the intelligence, which then issues commands to the less powerful microcontrollers which do things like control motor torque, sample sensors, etc...
This doesn't even get into things like power consumption...simply put you can have microcontroller based systems run for months on a single coin cell battery, which is going to be a hell of a lot harder to pull off on a RasPi / linux based system.
All that said, for a lot of projects where you just want to monitor a few simple sensors, or do a basic home automation type of project, a RasPi can be a great choice! (Even if my inner engineer is screaming 'your over complicating it!') But there is definitely still a huge need and use for micro-controllers as well.
Thanks for the details. Yeah that makes a lot of sense. I was looking at it from a home automation perspective. I have both a photon particle and a raspi. The raspi just opens so many more doors for me, but power consumption is not an issue since I always have it plugged in.
More fail safe (like Arduino is). Just plug the power in, instantly booting up and no worry to damage something if you just cut the power without shutting things down. And more energy efficient. You can't compare this Chirimen board to a Raspberry Pi, nor can you compare it to a Arduino. They are different. Maybe you can compare it to a Espruino board (but not really). They all will have their niche.
I'm not 100% against Javascript for things like this. It does make it much easier for non-C coders to get involved (although, to be honest, beginning C isn't that hard, and if you're going down this path you should try and learn it anyways).
It's the pretense of putting it all in an HTML document. The point of HTML is not anywhere close to the use case here. Javascript is way beyond its browser origins, why would it still need to be coupled? I can't imagine tossing in an HTML parser simplifies anything either.
Oh the memory though... GC's on embedded devices scare the hell out of me.
Is it really so hard to empathize with people who have different skill sets than yourself? Yes, C would be more efficient. Yes, this wouldn't be very cost effective used in a high volume product. Yes, it's a little funky to write a web page just to plonk your script tag in there.
But, if you spend all day doing front-end dev with jQuery and just want to prototype some blinky lights or a flood sensor in your basement, now you've already got all the skills you need. You're not producing a million units, you're not worried about power so much as it'll be plugged in. An evening with a soldering iron and your text editor and off you go.
Anyways. For prior art on this ecosystem, see janOS:
http://janos.io/
which is basically stripped down firefoxOS which runs your app only (none of the launcher crud and such) in god-mode. It's actually quite fun to go grab a $30 phone off of ebay, and have a nice programmable screen and sensor suite with wifi, gps, and cell connectivity. Indeed, I find it more compelling than this board they're releasing, because I like taking advantage of the cheapness of mass manufacturing. The only downside is it's difficult to impossible to break out any GPIO on phones.