Intel bungs PC on an SD: Tiny computer for Internet of Things and wearables Intel has put a PC into an SD card-sized casing. Dubbed Edison, the micro-microcomputer marks the chip giant’s first attempt to address the emerging wearable computing business; part of its strategy to cope with a world where punters buy far fewer traditional personal computers. Or, more specifically, where ARM and not Intel …
This post has been deleted by its author
There are products that are of a similar form factor, sd connector and solder down modules, that are cheaper than the Raspberry Pi and BBB. It's funny that you even mention the Arduino.. you could get an AVR on a piece of FR4 the size of a postage stamp and they are cheap as chips.
These wireless modules with some processing power are meant for "Internet of things" style devices and aren't really the same thing as the Raspberry Pi or BBB. You'd have to be mentally retarded to use something as buggy as the Pi in a commercial product anyhow.
The Amtel chips are efficient, but they're not powerful as ARM chips.
For instance a subtractive synthesizer module I use has a 20Mhz Amtel and is monophonic, mono-timbral. So one note in total.
An ARM one I built recently is about 6 note polyphonic per part, there are 4 parts and it is an FM synthesizer, so is more CPU intensive. 4x6 = 24 notes.
And top out at about 20MHz, but they also sell ARM Cortex based chips (32 bit, 80MHz+ clock). Take a look at the Arduino Due, based on the newer chip. The down side is that the newer chips run at 3.3V, so you can have problems connecting to older devices which run at 5V.
Its based on the Quark chip , which the Galileo product uses it supports Arduino headers .
http://www.xbitlabs.com/news/other/display/20140103230834_Intel_to_Showcase_Quark_Based_Wearable_Electronics_Next_Week.html
Interestingly its 64bit, so its going to be aimed at Linux and Android.
Scale is whats needed to bring the price down , Intel need to shift a lot of these to make it competitive, the advantage is that Intel has the manufacturing capability to do it. The more chips you can put on a wafer the cheaper it gets per chip. The question is for Intel can it drive enough volume to make it profitable.
Anonymous As I work there.
"Intel Quark SoC X1000 is a 32-bit, single core, single-thread, Pentium instruction set architecture (ISA)-compatible CPU with 16KB L1 cache, 512KB L2 cache, operating at speeds up to 400MHz. It features computing industry standard I/O interfaces, including ACPI, PCI Express, 10/100Mb Ethernet, SD, USB 2.0 device and EHCI/OHCI USB host ports, high-speed UART, RS-232 serial port, programmable 8MB NOR flash, and a JTAG port for easy debug."
Intel are going to get killed in this marketplace if that's all they have to offer. ARM v8 chips are already competitive with lower end Intel chips in the GHz range, and you can buy them tailored with whatever IO you need.
Its based on the Quark chip , which the Galileo product uses it supports Arduino headers .
I can make any processor or microcontroller support Arduino headers, as long as I put it on a board that has the right connectors in the right place. And if the processor/uC itself does not have the required I/O, I'll just stick support chips on that do, and add a HAL that hides this from the program running on it. Plus an emulator for the ATMEGA code, as appropriate. Which is exactly what Intel did with the Galileo. Problem is, it's way slower doing GPIO (about a factor of 1000) than a real ATMEGA, so why you (as someone building stuff based on Arduino) would want to go that route is beyond me.
And Intel itself describes the Quark as 32-bit, not 64-bit.
No way as it's just too bloated and stupidly resource hungry.
How much RAM does it have? Until recently I was running my Windows 7 mail/ftp/media server(*) on a Fit-PC2 which had a 1GHz single core Atom and 512MB of RAM. The UI was a bit klunky but as it was a server that didn't really matter. Admittedly for a reasonable desktop experience you'd want at least dual core and 1GB of RAM (what I upgraded to) but that's not what I'd call bloated requirements these days.
(*) VPOP3, FileZilla, TVersity, SqueezeServer
It'll probably have performance on par with smart phones. That means most likely Android and possibly Windows Phone. I bet Windows XP could be made to run on it although you probably wouldn't be able to do much with it.
From the sounds of it the limiting factor will most likely be the amount of RAM, not the processor speed.
*Maybe* Windows XP on a phone-class processor? Chrissakes, my phone could take on a dozen of the desktops that were around when XP launched and have enough left over to run Real Racing 3. We're talking about a time when desktops had, what, 128mb of RAM when XP launched? Phone CPUs may be slower than desktop procs per operation *now*, but I'm pretty sure if you compare one with the Athlon 600 I was running back in '99, it'll stomp it silly.
For that matter, my wife's netbook runs some 1.6ghz Atom; it runs Win7 just fine - though it barfs trying to play HD video in a web browser, who'd have thought? - with Aero no less. XP would be a doddle. And it's significantly behind modern phone processors at this point.
I think sometimes people forget how insanely f*cking powerful CPUs *are* now. Back in MY day, etc etc etc...
Bluetooth is still the connectivity medium that many devices that this chip is intended to work with use. You could say the same for wifi, a chip these days without these connectivity options is going to fail. Wearables at the moment is dominated by Bluetooth connectivity and this chip is aimed at that and other markets.
>We assume it does: there would be little point in adopting the SD card
>size and shape if developers couldn’t fit a low-cost SD card slot onto
>their project boards to take the Intel card.
This makes no sense. Mechanical interface and electrical interface are two different things..
They can use the SD card shape and connector without it being a true SD card. The imp mentioned below this paragraph is exactly that.. If you plug it into an SD card reader it would probably kill it.
> Mechanical interface and electrical interface are two different things
Spot on. Having an SD interface only makes sense (but given how flimsy & unreliable they are, not much sense) if the plan was to make these SoC's swapable, or interchangeable. With an embedded or wearable IoT there would be no reason or need to make the "brains" removable. It might need to be inserted into its gizmo once, during assembly but after that I foresee its closest neighbour being a large dob of hot melt glue.
My assumption is that the SD card format is merely used for the prototype to give journalists a sense of size and "ubiquity". I.e. to illustrate how it can be inserted anywhere (!) that an SD card would fit.
>Having an SD interface only makes sense (but given how flimsy & unreliable they are, not much sense)
The SD form factor of the dev imp is a bit of a pain in the ass.. if the mating isn't good you can go from working to trying to debug what the hell is wrong for a few hours until you probe pins. But it means you can get connectors to put on your prototypes almost anywhere. For both the Intel product and the imp I think it's a bit of "Hey, look! it fits in an SD card" and a bit of shipping something that connectors are readily available instead of some fancy connector that you can only get if you order 1000+. If intel are serious about this they will have a solder down module version coming out at the same time.
The SD format does make sense from a 'one-size-fits-all' perspective, insofar that manufacturers of appliances and devices that would require such a card to operate only need to build in the cheaper host electronics, with the main system being easily added in later. You COULD solder it all on at creation, but then it may very well be cheaper to buy the finished card units in bulk and simply insert them later on, after loading in your own custom firmware. Economies of scale and the like.
Plus, prototyping would be easier, knowing you can just add the brains to your creation later, as long as you have the relevant mechanical interface.
This makes no sense. Mechanical interface and electrical interface are two different things..
They can use the SD card shape and connector without it being a true SD card. The imp mentioned below this paragraph is exactly that.. If you plug it into an SD card reader it would probably kill it.
I don't see a reason to legitimately assert that. The SD card interface is a lot more flexible than you might expect. The full details are obscured by an NDA but the publicly available interface is plain vanilla SPI which allows for pretty much anything.
>The full details are obscured by an NDA but the publicly available interface is plain vanilla
> SPI which allows for pretty much anything.
Except maybe driving I2C etc.. which the imp does. Because something is SD card shaped doesn't mean it's an SD card. This is what the difference between mechanical (shape, size) and electrical (signal levels, signal types) is.. If it is an SD card it will require a host and that makes very little sense for the interwebs of things.
And the SD card protocol is no SPI. One mode is SPI but that isn't the SD standard.
> If it is an SD card it will require a host and that makes very little sense for the interwebs of things.
It makes a great deal of sense for development. Put the card in a reader on a PC and load up your programs to it, copy off the debug logs from a previous run, and such. Put it back in the device to run those programs.
It is also the reason that it doesn't have a 'hump' over the aerial - there is no need for the aerial when it is in a standard SD reader.
How hard is that ?
The production devices will use the soldered (non-SD) cards.
Except maybe driving I2C etc.. which the imp does. Because something is SD card shaped doesn't mean it's an SD card. This is what the difference between mechanical (shape, size) and electrical (signal levels, signal types) is.. If it is an SD card it will require a host and that makes very little sense for the interwebs of things.
I²C is perfectly possible over SPI. The voltages, signal timing, handshaking etc - the electrical specification in other words - are not an issue. The protocol level is slightly muddier but at its core the SD interface is still general purpose, it is only layered services on top that can suffer from a lack of standardisation.
Consider by analogy the USB host socket on one of my printers: it is there to allow you to plug in a flash drive and print documents from it directly. It doesn't make sense to plug a webcam in to the printer, so it has no support for that. That lack of support does not make USB webcams a theoretical impossibility, which is why you can buy them for £5 or so at ASDA.
The situation is the same with the SD card interface. The core protocol doesn't really care what data is being transferred or how it is organised. A device making use making use of the spec has an application case in mind - generally data storage for SD - so the higher level support for that is integrated. That doesn't preclude the possibility of another device using the same thing for something else, just as the use of IP for web browsing does not preclude another app using the same protocol for e.g. VoIP.
And the SD card protocol is no SPI. One mode is SPI but that isn't the SD standard.
Indeed, which is why I said as much in my original post. It's an SPI superset. In other words, it can do anything SPI can and more.
"a key aspect Edison lacks: a dedicated server infrastructure" - for me this is actually a selling point for the Intel device. The main reason I haven't bought an Imp yet is because it is tied into the servers of some company I don't really know who rent them from Amazon. If I made a product using Imp and Amazon have yet another cloud fart or Electric Imp go bust then I'm screwed.
A requirement to provide my own infrastructure is a feature for me!
Totally agree.
What put totally off the Electric Imp was its reliance on a Cloud server. I wouldnt have minded if you could have a private cloud or some open API that you could conform with. They will ultimately charge for the cloud service too confirmed from by a quote from Hugo:
"Yes, we will charge for the service when it's "ready", as you say the hardware doesn't pay for an ongoing service that we intend to run for a long, long time into the future. However, "developer edition" cards will continue to be free to use as a thank-you to the people who have taken the time to try them out at this early stage.
Service pricing will be published soon, but it's in the "small number of cents per month" bracket for M2M applications."
And yet, it's the 'gimmicky crap' that's the stuff that usually showcases the latest from the R&D boffins. While it may not be overly astounding to begin with, if enough interest is shown in these early designs, they'll get redeveloped, refined, and generally improved upon. This is, funnily enough, called progress.
And if no-one likes it? Well, that's fine, because not everything from an R&D department is going to be a solid gold winner. Designs don't perform as well as expected, aesthetics are not quite what people want, software can be buggy. It IS possible to make the mediocre better through PR (And that's my subtle reference to Apple for you, people) but if it doesn't prove popular, it'll vanish soon enough.
And it's surprising really, how much stuff from failed products gets reused in the next big development.
I seem to recall something about one of Intel's earliest chips - not sure if it was the 8008 or the 8080? - being classified as a failure during R&D, and only barely making it to market because they thought that, while it would surely lose money, it'd lose a little bit less if they spent the money to bring it to market and earned a little bit selling it rather than just canning the whole thing.
Obviously it turned out somewhat better...
Completely agree - beautiful new kit is featured as so slim and compact.
Oops - the publicity photos omit the power brick and cord, not to mention items such as an external mouse, hard wired ethernet connection, fully functional keyboard, external monitors...
Coat - yes, I am leaving...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
