Slashdot Mirror
Intel Quietly Discontinues Galileo, Joule, and Edison Development Boards (intel.com)
Intel is discontinuing its Galileo, Joule, and Edison lineups of development boards. The chip-maker quietly made the announcement last week. From company's announcement: Intel Corporation will discontinue manufacturing and selling all skus of the Intel Galileo development board. Shipment of all Intel Galileo product skus ordered before the last order date will continue to be available from Intel until December 16, 2017. [...] Intel will discontinue manufacturing and selling all skus of the Intel Joule Compute Modules and Developer Kits (known as Intel 500 Series compute modules in People's Republic of China). Shipment of all Intel Joule products skus ordered before the last order date will continue to be available from Intel until December 16, 2017. Last time orders (LTO) for any Intel Joule products must be placed with Intel by September 16, 2017. [...] Intel will discontinue manufacturing and selling all skus of the Intel Edison compute modules and developer kits. Shipment of all Intel Edison product skus ordered before the last order date will continue to be available from Intel until December 16, 2017. Last time orders (LTO) for any Intel Edison products must be placed with Intel by September 16, 2017. All orders placed with Intel for Intel Edison products are non-cancelable and non-returnable after September 16, 2017. The company hasn't shared any explanation for why it is discontinuing the aforementioned development boards. Intel launched the Galileo, an Arduino-compatible mini computer in 2013, the Edison in 2014, and the Joule last year. The company touted the Joule as its "most powerful dev kit." You can find the announcement posts here.
Why is it we have these news announcements that assume everyone already knows what "obscure technology X" is? I've been around for a while, and I have no idea what these development boards are in the slightest.
Can someone please explain what these development boards are, and why this matters?
I'm not surprised Intel is doing this. When your competition for IoT devices includes widely available Arduino, Raspberry Pi and other simple, cheap boards with legions of followers? Embedded stuff is either going to COTS (Common Off The Shelf) stuff or very highly customized. At least that's my thought.
Never have a philosophy which supports a lack of courage
Exactly. Why buy into an ecosystem that's not as flexible as the others. Did they offer superior documentation and support? Superior integration? Anything at all aside the brand?
Guessing the bosses at the top want to retrench and focus on their server & consumer spaces now that AMD has shaken up the market once more. Despite this being a tiny space, I doubt it ever made enough money to justify the ongoing costs needed to crowd out all of the established open hardware.
Good to remember that not long ago, Intel PR touted the IoT as the Next Big Thing and the company followed suit, with entire groups and people dedicated to having these products out the fab.
These development platforms (the vehicle for having their IoT processors into product makers' hands) being now discontinued most likely means the sales were disappointing and that these groups probably are no more and there won't be any follow up.
Which is not that surprising, giving Intel is used to earn a living from high margin products, not cheap stuff that needs to sell millions to make a margin.
Seems like this market, like Mobile before it, will belong to ARM.
I mean, on paper the specs are great, but I've actually done projects with these things and they're seriously junk. They burn out if you look at them wrong. Additionally, they have a 1.8v gpio level, so there's basically zero chance that you can use any other peripheral without level shifting.
I've talked to a lot of other folks about them as well, they have a terrible reputation in the maker community.
And they're expensive.
So yeah, I'm not surprised. I abandoned them after a single project, like most other folks I know.
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
To bad. This mean less competition, less choices for the users.
I don't know anything; please explain the following:
Regarding poor quality of your products and pathetic support services. [ New ]
Options
06-17-2017 02:16 PM
Product Name: Hp Omni 10 5601w
Operating System: Microsoft Windows 10 (32-bit)
Dear Sir or Madam,
Subject . Regarding poor quality of your products and pathetic support services.
I regret to say that i had a bad experience purchasing your so called Hp Omni 10 5601w tablet. At first i was facing an issue with touchscreen fuctionality. It wasnt working at all. I had to restart the tablet several times to make it respond to touch atleast once. As i had 2 years of warranty i was able to get it repaired. The service team told me that it was fixed so i took it back and later i came to know that it wasnt fixed at all. Maybe they did a temporary fix. Later i gave it to them again and they did the same. It was working for somedays and again stopped working. Later i had to go abroad so i took it along with me so i clould get it repaired there. But what they told me was my warranty is expired even though i could show them online warranty is till there. They were asking for bill which i didnt carry with me. I tried every method to get it fixed but nothing worked at all. Now my warranty is expired. I feel cheated.
I came to know that many people were facing the same touch screen issue. I feel bad for them. If you knew eveyone faced the same issue you could have recalled or replaced the tablet. I was a loyal customer of hp. Previously i had 2 hp laptops which was amazing. Now i just came to know that hp is not a quality brand anymore. So no more hp laptops unless they find a solution to my problem.
I had to post it all again as i was told i would get a reply from hp support team but i didnt. Going with hp was the worst decision. Thats how i feel now.
Regards
Ajnaz
Ordered a Galileo when it was first released. Work at first, and it remained unused in my lab ever since. When I wanted to actually do something with it a year later, I discovered that it has been bricked. I tried flashing the firmware among a couple of other tricks I found online, but nothing brought it back to life.
Fortunately, Intel replaced it with a Galileo gen.2 for free. Again, I left that in the lab for a year and a half unused, since I didn't need it at the time. When I finally wanted to do something with it a year and a half later, I discovered that it, too, has become completely undetectable. It was opened, but NEVER BEEN USED! And it bricked! (Assuming intel did not send me a bricked board to begin with.)
Those boards seem to be extremely badly designed. I make longer-lasting prototypes at my home lab.
last few days the usual madison.ave..gov agenda overkill phuck & cover... nothing new... beware falling gargoyles...
Isn't it also possible that they will be announcing and releasing a new product before December 31st?
The chip-maker quietly made the announcement last week.
You can't "make an announcement" quietly. What were they supposed to do, accompany the announcement with a song & dance number? Take out a full-page add in the NY Times? Bribe some on-line "nerd" news site?
I may or may not work for the vendor of these products.
I may or may not have had a hand in designing the chips.
I purchased a Galileo to mess with. After all, I know the chips quite well.
It was utterly unusable. I couldn't even light the LED. The documentation was a walkthrough of how to light the LED, but it didn't work. Involved in this was a whole software layer to make the native hardware interfaces look like some other board at the API level, which was obviously daft if you are trying to get people to know and understand the chip, so they choose to design it into products. I failed to crack through this layer of obfuscation before I gave up and did something more productive.
Don't forget RISC-V, which is not only open, but elegant and designed for extensibility. There is already extensive industry support behind it, and the scent of inevitability. Available cores are already substantially more power and area efficient than similar ARM chips, and need not be licensed.
Offerings are fairly basic today, but in time features will grow in, and higher end cores will become available. I wouldn't be surprised if AMD shelved Seattle and adapted the effort for RISC-V instead.
This sums up my experience.
http://hackaday.com/2017/06/19...
Signature v3.0, now with 42% less memory usage.
Thank you, kind person.
What's so pathetic about this is that they basically pulled a Microsoft-and-mobile on this.
Arduino, BBB, and RPi had already been out for years before Intel finally figured out that there was a market there.
Then, when they finally got off their butts they came to the party with a stupidly overpriced offering that didn't fit with the existing ecosystem.
Why did they even try doing their own thing at all instead of helping to improve what already existed? For example, why not work with ODROID to put Intel chips on their boards instead of ARM?
This whole thing was stupid and ham-fisted on Intel's part-- whoever the exec was that made the decision should get a stern talking-to.
This also matches up with Intel's flailing in response to AMD's recent surge (sad as it was that AMD was on the ropes for so long).
The biggest reason discussed is NO DOCUMENTATION!
I would hope that the whole reason they are discontinuing these products is the realization on how they don't even compete with the arm products out there. Hell the ESP8266 showed that people will even tolerate a realistically unknown CPU instruction set, locked in firmware and a horrific manufacture SDK. It all doesn't matter if you just sell it cheap enough. So why, if Intel, wanted to compete, just slap on an atom and bare bones chips to make an IOT with a price that guarantees no one will use.
They NEED to make a RISC like chip using 3.3V using their fab plant tech and they can blow the lid off ARM. Hell, even just optimize the original Pentium core with some SIMD extensions would of been enough. If you keep in real mode, include a VGA compatible display core with drawing acceleration, you can be sure hackers will come out of the wood work do do all kinds of crazy stuff.
IoT might end up being in the hands of corporations, but it was the hobbyist that pushed it at the start.
PS As a side not, does anyone know the external component requirements for an Atom? Most arm chips, even A9's and the such require very little in the way of reset/clock circuits.
The pi uses binary blobs. It's intent was to be cheap for students, not an open source platform.
Only the State obtains its revenue by coercion. - Murray Rothbard
So where in your thought process dd you fail to think "Intel is probably one of the kings of COTS equipment"?
Cuz I got news for you, the 386 while discontinued is still a hot-shit selling item for embedded shit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I am a trifle surprised to see the Joule among the dead.
The others were hopeless: too cut down(in terms of 'IBM PC' stuff), for x86 compatibility to be of much use, notably lousy at GPIO twiddling compared to microcontrollers or devices like the TI ARM part in the Beaglebone; but at least they were expensive!
The 'Joule', though was a stock Atom part, plus some RAM, Flash, and a NIC in a little computer on module. Not based on some weirdo part; and allowed you to drop a more or less standard Atom based system into something without consuming much space. I'd be curious to know if it died because existing SoM vendors do it better, and Intel decided to stop flailing around and upsetting them; or because lack of interest in x86 for anything that doesn't either involve a small off the shelf motherboard(for onceoffs) or 10 zillion custom motherboards (for laptops and such) is just that dismal.
No one really cares how open a platform is. The winners of the IoT hobby world are not interested in "open". The Raspberry Pi famously runs an ARM core that is buried under NDAs and binary blobs.
The winners in this field are determined by ecosystems and communities. The Arduino platform is quite a poor performer and their libraries were famously crap, to say nothing of the god-aweful IDE compared to AVR studio, or the stupid design decision that lead to one set of pins being off centre locking out a whole lot of potential applications. Yet they are undeniably a ruler in the field, not because of their faults, but because of their ecosystem (a boatload of addonboards with that horrible pin spacing) and their community (almost an endless set of example libraries while inefficient none the less easy enough for a non-programmer to use.
The Edison was DOA without an incredibly wide range of off the shelf things to bolt onto it that any idiot could use.
To add onto your post,
When I was in college, I backed/bought a 3rd party board. It was faster than Arduino but pin compatible. It was before there were so many options but the experience is still applicable.
I bought it, and ran into problems. The hardware was fine but the SOFTWARE chain had problems crashing the IDE, and flashing/detecting the serial port. It was a pain in the ass. "Go online and search for a fix" doesn't actually work when: There's like 10 people at the company and
Another slap to the face? I realized I had bought a "Beta" board. They said it could have problems but it was tested and sound. The problem? They then produced the "official" board which wasn't pin or software compatible with the Beta board.
So I spent $60-80... on a paperweight that can't be programmed.
Additionally, there are zero 3rd party tutorials, almost zero forums with knowledge of the device. It's almost impossible to crowdsource a problem with it.
Another problem? Just like Intel here, what happens if the product is discontinued or no longer supported by the company?
I've learned the hard way that you're not buying a product, you're buying a PLATFORM. And the platform (documentation, official and third-party support, hardware, and more?) needs to be heavily entwined in your cost/benefit calculations. It can't just be "speed vs cost."
As I've looked for better Arduino and Raspberry Pi's, I've consistently applied that logic and found zero viable alternatives. Even if they could compete on cost, they can't compete on TIME investment. There are thousands of arduino/pi tutorials. Good official documentation. Thousands of active programmers to assist you and over a decade of toolchain support.
I've been learning the D language over the last year or two. I love it (except the garbage collector which adds an additional entire dimension to crash solving). Otherwise, it's pretty amazing (so much so the C++ committee adds features that D had for over a decade). They have one great forum and StackOverflow probably can solve it. But that's kind of it. There aren't dozens of _maintained_ D XML parsing libraries. Dozens of JSON libraries. Dozens of game programming libraries. Dozens of X/Y/Z libraries. In C and C++ you have your pick of the litter. Any possible question, no matter how niche, has a C/C++ library. Library for the reverse engineered Kinect2 sensor? Yep. But while D can interface cleanly with C, it doesn't support C++. And that's a huge flaw because it cuts you off from basically "Almost every library ever written" in the last three decades. Programming in D is a delight, but you HAVE to re-invent the wheel for things that come for free in C/C++. So I've been very hesitant to switch over completely to D. What happens if the community dies out? Do I really want to write a hobby game in a dead language? (There is a fork of LLVM based LDC, Calypso, which integrates Clang with LDC for C++ support. And it's a highly watched project. But it's even more niche. Do I hedge my game on an almost-niche language, with a niche fork of a compiler that is 300 commits behind the official LDC branch? What if I run into a bug that is solved in the new branch but not the fork? I'm relying on a lot of guys charity work in my build chain.)
So if I can distill all my points down to one: "For production, buy what's popular--not what's clever."
Nope, in fact Intel had the crappiest support and documentation available. Almost nobody used their stuff.
Do not look at laser with remaining good eye.
SKUs
I'm not heavily invested in this platform except over the past couple of years I've had a fetish for the Sparkfun blocks and "any day now" was going to open up some time to use it in a custom board for a side gig, or worst case, resume fodder. So I've got 5-6 of them laying around, the big breakout and the little breakout, and as I said, a bunch of red prototyping boards.
At this point I don't know how I'm going to justify experimenting with all the kit I've accumulated. For all the flaws in the product---mostly unit cost, and as everyone has said, support, documentation, and no ecosystem---I really like the little thing
So what's the alternative? My low-volume custom board needed to be portable (i.e., LiPo), low power, small, have USB connectivity, and while the Wifi wasn't required it simplifies at lot of the requirements. That Bluetooth is on there is not useful, but could be at some point. The closest competitor, the Pi Compute Module, has significant complications. It's not optimized for low power. Network has to be added externally. Battery-aware power management is roll-your-own, right down to how a soft power button gets handled. From what I see on the datasheet, it's up to you to supply VBAT, 3.3, and 1.8, and it's important the order and timing in which they come up. Lots of stuff to reinvent, whereas the biggest glue-logic issue with the Edison was level-shifting to 3.3V and 5V.
What else is this small, has Wifi/BT baked in, is easy to deploy on a battery, and runs Linux? It's a serious question
Kind right, kinda wrong.
I own every Intel device mentioned, and just about every other damn variant of IoT processing boards from complex devices with operating systems, down to the bare bones Atmel and PIC micro driven ones. The Intel boards are pretty damn wonderful. I never thought they'd be around for long though- the margins on those things just aren't what Intel is in the business for. The maker market is way too small for them.
That being said, the chips that power the said Intel maker boards sell in *droves* in commercial applications (Intel's IoT division has a multi-billion dollar revenue). If they did this to demo their chips to the guys who do this stuff for a living (this is how I get my hands on these things), I'd say they succeeded, because the Quark SOCs are nice as hell, and the Atom/Quark combo chips simply can't be competed against by most ARMs (With the exception of some TI parts like the Sitara with its PRUs)
Intel just isn't the right kind of company to succeed in the Maker market, but I will miss the availability of their processors on clean and cheap development boards.
Which might actually have been a dire warning for the people at Intel behind the Galileo and Edison devices: Both were x86; but violated enough legacy-PC expectations that the OS(es, did anyone aside from Intel's Linux branch get interested?) had to be ported; and any of the old 'basically uses DOS as an RTOS by ignoring it for time critical stuff' x86 applications were unlikely to work; plus reports on the quality of the documentation range from 'frustrating' to 'dire'.
386s, by contrast, are markedly slower; but are pretty exhaustively documented and supported at this point; and their behavior hasn't changed in ages, so your expensive legacy software and/or system design doesn't have to either.
These offerings were too novel to just inherit support by carefully copying a prior design(or at least its software facing behavior); didn't have a solid attempt to compensate for that with quality support and documentation; and once those factors dragged it down into the morass of eccentric SoCs with slightly shaky Linux BSPs, just being able to run x86 code in userspace applications wasn't enough of an advantage to offset the relatively high price and areas of mediocrity(reasonably high speed GPIO, in particular, was...not impressive).
They might have actually done better if they had offered a 'DOSbox SoC' or something that, from the software side, slavishly replicated the behavior of a Pentium Pro and whatever chipset was most popular in a single chip, just faster. Instead, they broke with the past far enough to require a fair amount of support; then didn't provide it; which doesn't exactly command a premium price among random application processor SoCs.
Galileo gave a 400mhz x86 with Arduino compatible I/O. It also had a solid FPU and true potential to be the ultimate core of 3d printers. If only they did Mega version, it would have been fantastic. And honestly, the FPU performance was something quite beautiful. Combined with an FPGA board, this device was a thing of absolutely beauty.
I know it's not allowed on Slashdot to say nice things about Intel or Microsoft, but to be honest, I like the x86/Visual Studio platform when it comes to development. I suppose that I should try an ARM based Arduino out, I don't expect there's any real difference between the ARM and the x86 platform for anything that matters when developing these projects and Visual Studio is the same.
I've learned the hard way that you're not buying a product, you're buying a PLATFORM.
This is one of the reasons that I've stuck with the mbed platform. From the time five-ish years ago that an NXP rep left behind an NXP-1768 MBED at my work (fuck the 1st gen LPCXpressos that he left too, their debug interfaces sucked, and not worth working around), I found a good paradigm of using C++ that I was able to apply to my own embedded coding at work. Best of all, it was system-agnostic (programmed via copying a binary to a USB filesystem), which meant it didn't require Windows, like so many micro-controller development systems did back then, and many still do, so I was able to use it with OS X at home.
Now I have a bunch of different boards that support it, with many different pinouts (some Arduino-compatible), including so-called "bluepill" boards that cost as little as $2 each from China, all running ARM Cortex M, not AVR. I ended up with a couple of boards with AVR/Arduino hardware, but I don't even have the Arduino IDE installed.
But I have to say that though you may be having fun with it, D sounds like a bit of a dead end. It's very hard for a new programming language to gain traction, if only because half its users may jump to the next shiny new language in a couple of years. It's even worse for micro-controllers, where C/C++ is king, with only a few crazy MicroPython users and PIC assembly die-hards skittering around the rafters .
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I read that this morning, and I'm going to have to agree.
- Documentation was too hard to get, even for people who knew Intel engineers. (apparently the specific example was trying to use DMA with SPI) China gets away with a lot of poor documentation because their stuff is so cheap.
- That damn connector may be amazingly compact, but that it also made it hard to work with. It had a limited selection of base boards unless you had a PCB engineer who could design a custom one, so you usually end up with more than you needed. And it wasn't designed for multiple connects/disconnects like you would want in a maker product. The usefulness of 0.1" pin headers can not be underestimated.
- Its main purpose seemed to be a bull-headed "x86 in everything because x86!" attitude, even in applications with no inherent need for an x86 architecture. Their domination of the consumer market made them over-confident.
- Making boards with all the bells and whistles, and then some, drove the price of entry way up. This cuts out the low-end community support beyond students who get free or heavily-discounted units. And in fact, that was exactly who I saw with Edison-based projects at maker faires. Before Arduino, it was common to cram demo boards with various other chips, but that brought the board cost up. The emergence of a standard "shield" pin-out let those other chips move to daughterboards. Intel was clearly still stuck in the old metaphor. Most micro-controller boards now are in the $10-$20 range, more if it runs Linux, less if you get generic Chinese stuff.
It's like a perfect study in how not to get the maker community interested in your product.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Intel just isn't the right kind of company to succeed in the Maker market, but I will miss the availability of their processors on clean and cheap development boards.
Sigh, yeah. I think the Atom/Quark combo on the Edison had tremendous potential. The Atom running Linux for the heavy lifting (yet has full access to the I/O), and the Quark for the 10% of the things that actually need to be real-time. Nice.
Sparkfun did a lot to overcome the prototyping problem introduced by that damned connector, but I think Intel lost the war in terms of perceptions. Any Maker-class guy takes one look at that connector and wonders how in the hell he's going to overcome that hurdle, and Intel's two solutions to that were way off base. The small breakout wasn't breadboard-friendly and still had to be level-shifted, good luck with that. The Arduino dev board is overwrought has no target audience that I can understand. Using an Edison to interface to Arduino-class hardware misses the point entirely. Anyone sufficiently unsophisticated to only be comfortable in the Arduino space is not going to get very far with Yocto, and loses the benefit of the Edison if they limit themselves to the Arduino emulation layer. Anyone sophisticated enough to appreciate the Edison's architecture probably doesn't care about being able to connect a shield to it.
Then there's the culture. Reading Intel's datasheets on these things drives home with a sledgehammer that this is a Big Iron company. There was probably no hope of bridging the divide between that and the Maker community. I liked the hardware enough to want that to somehow not be true, but alas.
I was really hoping something would gain traction. Solve the byzantine Yocto problem. Make the learning curve easier, either with more accessible docs, or mature out of the dysfunctional support into a more robust ecosystem. Drop the price point, even by $10. Something.
As you say, it's not cool on Slashdot to like anything Intel or Microsoft does, but I was excited about the potential of this board. It's both sad and maddening that they would walk away from it in only two years.
stay updates with scholarships alerts http://www.scholarshipsalerts.com
Not just that, there ain't any added value in having any of the modern CPUs, like Atom, for instance, in such a box. One does not need multiple cores, MMX or SSI instructions, and it helps that the 386 just has some 100+ pins as opposed to 400+ pins. 16 bit is probably inadequate for embedded systems, but 32-bit is perfect, and doesn't need to go 64-bit, which is what modern Intel CPU architectures are.
Incidentally, are all the 386 patents still active, or have they expired? If the latter, any fabless design house could design an SOC in an FPGA using a 386 core, and have something that would be very useful to the market. One thing I'd change though - enable it to support up to 2GB of RAM, and whatever the upper limit was for a 386 based PC. Such a thing, at the low end, could have 1MB of RAM and run FreeDOS, and at the high end, could do, say, a Windows 95 or 98. I won't go so far as to put any NT based OS on this. It could however have either Linux or Minix (is Linux still there in 32-bit? FreeBSD seems to have gone fully 64-bit, w/ no looking behind)
I think that SiS' old 486-to-pentium-ish designs are carrying on as Vortex86. If they aren't now; they were until comparatively recently.
On the FPGA side, there is ao486. Don't know much about it; but seems similar to what you have in mind.
RISC-V needs to branch a lot more than instruction sets with conditional instructions, and that would mess with pipelines and such.
While checking the discontinued product DB I saw reference to the Genuino 101. Just a hickup, seems its referring to a batch of boards only. I wonder if this is going to have any impact in the Curie processor.
The 101 & Curie module are really nice products and I am having good time using them with zephyr OS.
Sigh, yeah. I think the Atom/Quark combo on the Edison had tremendous potential. The Atom running Linux for the heavy lifting (yet has full access to the I/O), and the Quark for the 10% of the things that actually need to be real-time. Nice.
I really like "virtual memory mapping heavy lifting device paired with 1 or more coprocessors with predictable instruction timing and linear memory maps" model.
ARM licensees have played around with it since ye olden says (ARM9s paired with ARM7TDMIs) and TI has a part line (Sitara) that pairs a modern ARM with some proprietary coprocessors for running real-time process kernels without an OS.
Intel's Atom/Quark proc is really the best offering i've ever seen in that segment, though working with the Quark directly without signing an NDA is a complicated mess (though one can figure it out).
I am glad i bought several Edisons. Yocto may be a pile of shit, but better support will come in time, and it'll become more reasonable to roll your own OS for the Atom side, and people will figure out the Quarks, and you'll be able to do direct loads onto it without negotiating with some way-heavier-than-needed real-time OS kernel running on it.
Awesome part, but as you said- targeting it at Makers with funky Arduino adaption layers and such was pretty clueless.
Intel's Atom/Quark proc is really the best offering i've ever seen in that segment, though working with the Quark directly without signing an NDA is a complicated mess (though one can figure it out). I am glad i bought several Edisons. Yocto may be a pile of shit, but better support will come in time, and it'll become more reasonable to roll your own OS for the Atom side, and people will figure out the Quarks, and you'll be able to do direct loads onto it without negotiating with some way-heavier-than-needed real-time OS kernel running on it.
Unfortunately I've been around enough to see what happens when ecosystems dry up. The Linux will age and have more and more issues that the community cannot keep up with. The community will shrink by attrition, and no new blood will come in simply because you can't buy the hardware anymore. Dead end, as much as I hate to think about it.
Turns out I only have three Edisons, and I while I'd love to dive in and figure out the potential of this wonderful part, I just can't justify the extremely limited bandwidth I have. I'm fighting the temptation to buy another ten of them to have around when you can't get any more of them, vs selling my entire investment in the platform and just put the whole thing behind me. I've got an embarrassing number of Sparkfun blocks (easily a dozen or more) that I've never used. Nor am I likely to unless a miracle happens and Intel does an about-face on keeping the Edison in their portfolio.
Anyone want a bunch of barely-to-never-used Edison kit?
All that gloom and doom aside, I'm totally on the same page. Real-time is a lot like memory and performance optimization. It's tempting to code every line with those requirements in mind, whereas the reality is that at best only 10% of your code really needs the extra scrutiny. Such it is with real-time. Usually only 10% of the functionality really needs to be real-time, and that can then interface to queues that feed the non-real-time code which does the actual work. The Edison's architecture had that dynamic totally nailed.