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.
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.
Arduinos typically represent logical bits using 5 volts. When purchasing devices that work with Arduinos (such as sensors) manufacturers will develop those sensors to communicate using 5 volts as well. Raspberry PIs actually use 3.3v to represent bits, so you'll often see manufacturers develop both 5v and 3.3v versions of devices. Level-shifters are the equivalent of adapters - they sit between two devices that use separate voltage levels to exchange data and "shift" them to the correct voltage.
So, if Intel's boards use 1.8v, this makes it harder to use existing sensors and other devices made for PIs and Arduinos.
Isn't it also possible that they will be announcing and releasing a new product before December 31st?
It means that the GPIO is not
A GPIO is a general-purpose input/output
An input/output pin is
I give up. Go read stuff on MSNBC, reddit or somewhere else.
#DeleteFacebook
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.
This sums up my experience.
http://hackaday.com/2017/06/19...
Signature v3.0, now with 42% less memory usage.
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 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
Standard procedure for bad news is to post it to your press/corporate site on a Friday, but not actively tell anyone.
Standard procedure for good news (or new product news), is to hint, tease, and preannounce, then reveal early in the week with announcements on the press/corporate site, emails to journalists, branding and news "articles" on the main site, etc. Throw in some reviewers / tech "journalists" who are suckling at your teat and willing to sign NDAs and you'll have tons of coverage ready to go when you want it.
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."
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.