back to article The other end of the telescope: Intel’s Galileo developer board

Any notions that the Arduino platform is completely wedded to the Atmel ATmega family of microcontrollers have been shattered. The ARM-equipped Arduino Tre, which is based on Texas Instruments’ Sitara chip, is coming in the spring. And here, now is Intel’s Galileo, an Arduino board based on one of Chipzilla’s x86 processors, the …

COMMENTS

This topic is closed for new posts.
  1. Troy Peterson

    Cool! Looks like a nice alternative to the BeagleBone. I'll have to pick one up to play with.

  2. phy445

    Review or plug for intel?

    The article begins with the word "Review", but there is precious little evidence of this. Did the reviewer actually try to use this board or has all the information been extracted from sales literature and online articles?

    The Arduino platform is about doing things. I'd like to know how this board measures up when it comes to interfacing with the real world before I part with this amount of cash. I can get a lot of Arduino Uno clones for the cost of this board.

    1. Toxteth O'Gravy

      Re: Review or plug for intel?

      What would you like? 'We hooked it up to some LEDs and sensors and it worked.'? I'm sure they did that. 'We hooked it up to something really esoteric 99.9% of you will never use'? I'm sure they didn't do that, an there probably would not be much point if they did.

      1. Tony Smith, Editor, Reg Hardware (Written by Reg staff)

        Re: Re: Review or plug for intel?

        I can confirm that the Galileo has been hooked up to various switches, resistors, LEDs, jumpers and even an 8x8 matrix LED. In fact it's sitting here nicely pulsing some bulbs using PCM.

        1. phy445

          Re: Review or plug for intel?

          That's good to hear–thanks for the update.

        2. Charles Manning

          "I can confirm...pulsing.."

          Yes, yes.... but you didn't deny that it was a shill piece for Intel.

          Can you confirm/deny that pease?

          1. Frankee Llonnygog

            Re: "I can confirm...pulsing.."

            Why bother to shill this for Intel? Do you honestly think it will boost their profits significantly or harm the world of Arduino in any way? The conclusion of the review seems to be a fairly even-handed one: a bit pricy but may be worth it if you need the features. If that's shilling, it's a pretty half-hearted attempt.

  3. Andus McCoatover

    On first squint

    ..seems like a strange beast. OK, somewhat more welly than the Pi, but I can't really see it making many inroads against the BeagleBone Black (Judging from specifications and writeups, not experience. I do have a Pi, however, in daily, 'dole-destroying boredom fix').

    Maybe too late? I'd get a BBB, or maybe a "Teensy 3.1" first, although I'm more likely to just get a brace more Pi's shortly.

    (Happy to find the sticker hiding "Designed in ---land" obscured Ireland)

  4. Pete 2 Silver badge

    Get out the stuffing

    ... we have a new turkey.

    Seriously, an Arduino contender? A rival to the Pi?

    Maybe in the minds of the marketing people, but in real-life situations it's seriously lacking in either camp.

    It's far too big for use in most Arduino applications. It's power consumption is massive and it's far too complex (if you need all those peripherals: ethernet, micro-SD and what looks like an extremely dodgy sheild interface) then you really shouldn't be trying to do it with an Arduino. Even worse: put having a Linux layer underneath, the board can't even be applied to real-time applications: where you *know* to the microsecond how long a loop will take to execute - and that your I/O will take place now rather than at some point within the next 2mSec.

    And compared to a $4 Atmega328, it's not even talking the same language.

    As an O/S based solution for grown-up problems, well it has shortcomings there, too. Even the price is above what people expect to pay for a Pi or the more capable BeagleBone - or a $30 Olimex Lime. All of which have more than enough non-volatile memory and maybe even a SATA connector to a SSD for all but the most bloated applications.

    If this had come out 5 years ago, it would have taken the embedded world by storm rain-shower. However, the leading edge is moving apace and in 2014 it looks overpriced, under-spec'd, lacking in features and without the "killer-apps" of a widespread user base of code, libraries and contributed examples to get stuff developed quickly.

    1. Dave 126

      Re: Get out the stuffing

      >(if you need all those peripherals: ethernet, micro-SD and what looks like an extremely dodgy sheild interface) then you really shouldn't be trying to do it with an Arduino

      I'm a complete novice at Arduino and the like. My only experience is the custom Arduino board that runs my RepRap Ormerod 3D printer - I note that it has ethernet and a microSD slot, though.

      EDIT: Link added. It's one of these:

      http://blog.think3dprint3d.com/2013/12/Duet-Arduino-Due-compatible-3DPrinter-controller.html

  5. KjetilS

    I don't see what "problem" this product is supposed to "solve".

    If you need small and embedded, you choose one of the proper Arduinos, and get microscopic power usage and direct control over the hardware.

    If you need power and programmability, you can get a Pi, and still get something that can be battery powered in a pinch.

    1. Yet Another Anonymous coward Silver badge

      re: I don't see what "problem" this product is supposed to "solve".

      The problem of a generation believing that Computer and Intel aren't synonymous.

      Executive1: This low power embedded stuff is catching on - we need a product

      Executive2: And it should be 64bit and multi-core and have every peripheral we make and run windows server

      Executive3: We don't want to harm sales of Xeons, and it's about time we gave Microsoft a warning shot - stick Linux on it.

    2. the spectacularly refined chap

      I don't see what "problem" this product is supposed to "solve".

      If you need small and embedded, you choose one of the proper Arduinos, and get microscopic power usage and direct control over the hardware.

      If you need power and programmability, you can get a Pi, and still get something that can be battery powered in a pinch.

      I work in precisely this sort of market and have come to precisely the opposite conclusion. The smaller Arduinos are hobbyist devices, nothing more. It doesn't matter what you use, you're going to have to program it, so the smaller boards are up against bare e.g. PIC or AVRs. For simple stuff with bare chips you can sketch out a schematic in five minutes, calculates its values in another ten, and lay out a PCB in another fifteen - no, those figures are not an exaggeration. The resulting circuit may cost under £1 in parts and might consume one square inch of board space. That is what the smaller boards are up against commercially - they can't compete even in very limited volumes. Sure, a more complex circuit might involve more resources, but in that instance you will be designing that complexity as add-on boards for the Arduino, so even then you're not gaining anything.

      It's only going up the performance scale where modules start coming into their own, once you start needing high speed board layouts that are trickier to design and manufacture. RasPi superficially looks attractive for commercial use, but there are a number of issues with it that tend to make you very reluctant to consider it. The stated design aim was for something easily embeddable into other devices, and yet the first production versions left out something as fundamental as mounting holes. I mean, really, you call that a contender? Even now there are issues. USB ports for power are a dubious decision even from an electrical standpoint given that the Pi can draw more than 500mA, but there are more prosaic issues to consider. USB plugs are always moulded - they have to be, the spec demands it. How then are you supposed to connect it up to your wiring harness given you can't get a plug to fit it? Yes, these are little things to be sure, but there are any number of them. Each one simply adds to that gut feeling of "This board isn't really for me".

      This board might not have the same toy value for the hobbyist buying them in ones and twos but it seems to have a lot more practical refinement for the integrators buying them by the 20 or 50.

      1. Charles Manning

        re: "I work in precisely this sort of market "

        Me too. For 30 years.

        I agree that the RPi is not enough to make a proper product. You will typically have to do a lot of board design and shagging about with the kernel and software to make something that looks like a real product.

        But the same holds for the Intel thing. It is no closer to being a real product than the RPi.

        If I was to use these boards in some sort of products (eg. test jigs) I would go with the Pi over this thing because they are available from multiple vendors and I know I can still buy RPis in a year or two, and there are thousands of people that have dabbled with the RPi and ironed out its issues. This thing you're on your own.

        If I was up against the task of designing a board + software to bake into a product I would pick an ARM over the Intel any day. Heres why:

        * The ARMs are a known quantity. They have the same debug tools etc. One debugger toolchain works on all of them. There are near infinite sources of information. Almost everything you learn with one ARM device is immediately transferable to other devices from other manufacturers.Intel: none of those.

        * Intel has a very long track record of killing off their devices, a major reason why embedded people avoid them like the pox. If I design a board with an Intel on it, it becomes very unlikely I will be able to source those parts two or three years from now. That screws me over and I need to then re-design the board. I'd do better to just go with a vendor that has shown a willingness to commit to the embedded market.

        There is absolutely nothing compelling in this part or this board.

        1. Nigel 11

          Re: re: "I work in precisely this sort of market "

          Just for completeness, one should perhaps add that it is possible to obtain a full PC for not a huge amount more. I recently purchased a Gigabye GA-C1037UN-EU ITX board. Add a Pico-PSU, DDR3 RAM, a disk device (a USB stick will boot for embedded) and you're away. The board is fanless (17 watt TDP), and to my surprise even comes with two COM ports (one with D9 on the back-panel), two Gbit Ethernets, a PCI slot and an LPT header. Also 3 x SATA (one of which 6Gb for SSD) and e-SATA on the back panel. Cost around £120 (for board, pico-PSU and RAM).

          Agreed, it's rather more power-hungry and expensive than boards being discussed here. But it's also a LOT more powerful. I wanted mine for a silent always-on home server cum internet browser, but I immediately thought that if I wanted a computer to run off 12V in an automobile or boat, it would be a perfect starting point.

          And I've discovered that I'm no longer using my core-i5 desktop for anything except gaming these days. This little beast is always on so no boot-up wait, and feels plenty fast enough for everything else.

      2. Stoneshop

        Sorry, wrong market.

        For simple stuff with bare chips you can sketch out a schematic in five minutes, calculates its values in another ten, and lay out a PCB in another fifteen -

        You can, because you have the experience in doing so. I could, in maybe double that time. And yes, you can make the electrical and mechanical design exactly like you need it, and way cheaper than the readily available stuff. But a lot of people who want to dabble with embedded just to build a cat flap controller or something can't, because they lack the skills in hardware and/or PCB design. That's the market targeted by Arduino, and which Intel is now trying to enter with Galileo.

      3. Anonymous Coward
        Anonymous Coward

        AGREED!

        I completely agree here, putting RaspberryPi into the same category or demographic as almost any other development board (Launchpad, Arduino, Beagleboard, Olimex) is a mistake. Look at what the projects original intent was ("We want to see it being used by kids all over the world to learn programming."). It was not intended for the "maker" community hence the extremely limited GPIO. There is a place for the RaspberryPi, but it does not belong along-side ACTUAL hardware development platforms, it was intended to be an extremely cheap and easily adoptable software development platform. The appealing thing about this Arduino board is the IO component you expect from any microcontroller-based hardware dev platform is paired with hardware capable of running an embedded OS independently. Imagine an IDE that resides on the board itself.

    3. Charles Manning

      The problem being "solved"

      is not a technical one, it is a business one and a shareholder one.

      Intel is getting their lunch eaten by ARM in every space except servers, and ARMs are threatening there too.

      Intel is trying to find some new markets. If they don't then they will slowly atrophy.

      These threats must be making stockholder meetings uncomfortable. Intel was once a Blue Chip stock with guaranteed healthy returns. Now they look like they are heading for a rock. They need some comforting stories to quell the riots.

      Unfortunately for Intel, they very much understand high margin business that pretty much goes like this:

      1. Spend lots on development.

      2. Take a tablespoon of sand. Bake a chip and sell it for $100 or more. Repeat.

      3. Big profit.

      The business model they need to develop is low-margin. We're talking sub-$10 gross margin per chip, and far less for the real bottom end.

      Playing with a few development boards is the easy bit. Getting there is going to require a complete corporate re-jigging: development, marketing, sales,.... It is unclear that is possible with a company with 100,000 employees and development sites scattered around the globe.

    4. NullReference Exception

      And if you need power, programmability, and the time of day, you get a Galileo.

      Seriously, am I the only one in the world excited that someone is FINALLY making a low-cost Linux dev board with a battery-backed hardware clock?

    5. itzman
      Linux

      Re: I don't see what "problem" this product is supposed to "solve".

      Hmm. it is qualitatively different from many other boards, and this exites me. I've been looking for something with plenty of RAM and a decent basic kernel and analog I/O plus audio A<->D to do audio processing with.

      This might fit the bill actually. Arduinos lack the RAM and code space and general interfacing Pi doesn't have the right I/O mix.

      Hard to tell from the review that isn't a review - more a product announcement.

  6. Steve Todd
    WTF?

    All the Arduino IO is connected by a single I2C port

    Seriously, who's idea was that? Throttle all of your IO to 800Kbits/sec? If you want to run a full OS and add Arduino compatability (and seriously, the whole point of a Microcontroller like the Arduino is to control hardware as quickly as possible, not having to wait for the next time slice) then there are a number of other options like the UDOO (which is a hybrid between a RaspPi and a full Arduino Due).

    A total fail from Intel as far as I can see.

    1. the spectacularly refined chap

      Re: All the Arduino IO is connected by a single I2C port

      I²C has been operating at 3.4MHz for the last 15 years: you start getting much faster (especially for interconnects) and you need careful impedance control and high-speed boards. If you're going that way is the PCIe fast enough for you?

      No, not a total fail from Intel. A physics fail from a commentard.

      1. Steve Todd

        Re: All the Arduino IO is connected by a single I2C port

        A minimum of 24 I2C clock cycles to access a port on the expander they use and you think that 3.4MHz is good? The same task on an AVR processor is 1 clock cycle @16MHz

        1. CliveM

          Re: All the Arduino IO is connected by a single I2C port

          I2C runs at a maximum of 3.4MHz, well there is a 5MHz standard as I recall but that's new and I haven't seen any actual parts. If we believed your figures since it would run the bus at 320MHz - it's a serial bus and the minimum transaction is 16 bits.

          Do you think you have missed the point slightly, and perhaps are not comparing like with like?

      2. WaveSynthBeep

        Re: All the Arduino IO is connected by a single I2C port

        I/O timing is here:

        https://communities.intel.com/message/207904

        Essentially, I/O mediated via I2C can go at 230Hz (not KHz or MHz) maximum. The 2 pins that don't go via I2C can go just under 3MHz (it's unclear the jitter on this).

        SPI and PCIe are all very well, but the whole point of the Arduino footprint is access to raw GPIOs to wire to things. PCIe is very awkward to deal with unless you can build a gigahertz PCB (not straightforward) and an FPGA to receive it. SPI is potentially useful but needs extra chips to break out into GPIOs. All of these have increased latency over a simple GPIO.

        1. the spectacularly refined chap
          FAIL

          Re: All the Arduino IO is connected by a single I2C port

          I/O timing is here:

          https://communities.intel.com/message/207904

          Essentially, I/O mediated via I2C can go at 230Hz (not KHz or MHz) maximum. The 2 pins that don't go via I2C can go just under 3MHz (it's unclear the jitter on this).

          A ha! So that's where people are getting these silly numbers from. We were discussing the speed of the I²C bus, not the output speed of a GPIO module attached to that bus. It is akin to me noting that I have a serial card in one of my machines whose top speed is 115200 baud, and from that extrapolating that all the PCIe interface is capable of. Of course, it's nonsense, you are referring to the limitations of a peripheral and not the bus it is connected to.

          1. Steve Todd

            Re: All the Arduino IO is connected by a single I2C port

            Silly numbers? I like I2C but I understand its limitations. If you are going to use a serial interconnect then it needs to clock at least 10 times faster than a parallel link in order to get the same throughput. It's simple math. Add to that the 16 bit protocol overhead before you even START to deal with the data and anyone with half an ounce of engineering sense can see that it is a serious bottleneck in this kind of application.

            Let's go back to the WS2811 example for a moment. One bit every 1/800,000 of a second, but the protocol is one wire, starting high it goes low at a different point during that 1/800,000 depending if the bit is a 1 or a 0 (I forget the precise timings). The I2C port expander can't hope to get close to the speed and timing accuracy, but a cheap ATTINY can handle the task.

          2. WaveSynthBeep

            Re: All the Arduino IO is connected by a single I2C port

            You might have been discussing the speed of generic I2C in an ideal world, but the rest of us were discussing the speed of the GPIO that's provided on the Arduino headers on this board. As far as Arduino-land is concerned it's just GPIO, it shouldn't matter how it's wired internally. Except a flat-out rate of 230Hz (that's 2ms per transition) rules out a lot of things where you need to drive any kind of protocol via the GPIO as it's way too slow. (In my case I'd want to use it for being a JTAG master, which wants KHz or MHz and has no hardware acceleration in common microcontrollers).

            1. Steve Todd

              Re: All the Arduino IO is connected by a single I2C port

              I think you've got that the wrong way around. *I* was saying that controlling the Arduino ports via an I2C port expander seriously limits the speed at which you can use those ports, they're just not fast enough for many control applications. You can hit the GPIO ports directly via assembler code, via pseudo-variables or as pin IO on the Arduino. ALL of these methods are faster than the port-expander allows.

            2. CliveM

              Re: All the Arduino IO is connected by a single I2C port

              You might have been discussing the speed of generic I2C in an ideal world, but the rest of us were discussing the speed of the GPIO that's provided on the Arduino headers on this board.

              No. You start talking about the speed of the I2C it's reasonable to assume you are talking about the speed of the I2C, not connected devices. This isn't "ideal world" stuff but real world stuff - bit banging protocols is generally bad practice, especially for devices such as this with vanilla operating systems. GPIO is generally intended for simple stuff - indicators, switches, switch-like sensors etc. Running something higher speed on a bus not intended for it is a recipe for all kinds of headaches. Sure, I've bit banged all sorts of protocols in the past where the circumstances demand it, but on on devices of this class. What is regarded as acceptable changes between the £1 devices described by the refined chap and what you would do on a device into £100 territory.

  7. Erik N.

    "Any notions that the Arduino platform is completely wedded to the Atmel ATmega family of microcontrollers have been shattered"

    /me looks at Arduino Due currently hooked up to laptop, looks at article, looks at due. *facepalm*

    The AtMega family is perfect for realtime, embedded, and low power. The Due and Tre step it up with a Sitara ARM processor for when you need more power (faster, finer grained sampling, etc).

    The Tre isn't here yet, but the Galileo struck me as a strange beast when it was announced. Rather expensive and power hungry. The I2C communication isn't a no go for me. When you consider the speed of an AVR processor, I2C isn't terribly slow. Plus the Quark processor can do other things while waiting for responses.

    The Due isn't compatible with many shields built for the Uno since they will use 5V signaling and the Due is limited to 3.3V (which is why I have a bunch of 74LVC245 level shifters here also). This is the step up that the Galileo definitely has.

    I've still got Amazon gift cards and $60 for the Galileo is tempting. But, when you read the product page for the Tre...... I think I'll wait. Hopefully the price point is friendly, but that does look like a sexy beast.

    *edit* - Is that a header for an XBee? Oh, my it is. Super nice!

    1. Steve Todd

      I2C is fast enough?

      I'd guess you've never controlled modules that need I2C or SPI of their own then (nRF24L01's are cheap and fun to start with), or WS2811 based LED strip (which uses a 1 bit protocol at 800Kbits/sec and needs timing down to a fraction of that). There are all sorts of devices that an Arduino can drive, are cheap and easy to find but are beyond this Intel board to drive.

  8. Timbo

    connecting power BEFORE any other connection?

    "“You must use the power supply or you will damage the board,” the firm warns, adding: “Always connect the 5V power before any other connection.” (Intel’s emphasis). "

    BEFORE any connection ? I always thought it was wiser to connect everything you need, (esp Shields) before powering up - else you risk damaging components when they see the power line is already "on".

    1. Stoneshop

      Re: connecting power BEFORE any other connection?

      What it is trying to say: "Thou shalt not Apply Power to any hooked-up Device or Shield before you Apply Power to Galileo itself, lest you Fry it. Powering All from a single Supply is Fine and Dandy and Totally Okay though"

      Sticking a shield on with the Arduino, Galileo or whatever is under power is not the nicest thing to do; there's a reason why devices actually designed for hot-plugging have connectors that make sure ground is connected first, then power, then everything else when plugging in.

  9. Anonymous Coward
    Anonymous Coward

    Overpriced power-hungry piece of cr@p....

    That's what it is !

    I'd rather have one of these :

    http://www.86duino.com/

    It's cheaper, supports MMX instructions, uses less juice,

    it has hardware PWM outputs AND it's I/O isnt crippled by I2C...

    // I'd love to see The Register do a review of one of these !

    1. Frank Rysanek

      Yes yes yes! Vortex86 rules!

      Mind the EduCake thing at 86duino.com - it's a "shield" in the form of a breadboard.

      You get a Vortex-based 86duino (= the Arduino IDE applies) with a breadboard strapped on its back.

      I'm still waiting for some Docs from DMP about the Vortex86EX's "motion controller" features. It should contain at least a rotary "encoder" = quadrature counter input for 2-phase 90degree shifted signals, not sure if it's capable of hardware-based pulse+dir, or "just" PWM.

      The Vortex SoC's tend to have 40 or more GPIO pins straight from the SoC, capable of ISA(bus)-level speed. Plus an almost complete legacy PC integrated inside. All of that in about 5W of board-level consumption (3W without a VGA). The number of GPIO pins is obviously limited by a particular board design, and some GPIO pins are shared with configurable peripherials (LPT, UART and many others) - but generally on Vortex-based embedded motherboards you get dedicated 16 GPIO pins on a dual-row 2mm header, on more modern SoC versions these are capable of individual per-pin PWM.

      I seem to have heard that the 86duino is using DOS (FreeDOS?), rather than Linux, as its OS on the inside. Which might be interesting for real-time work, if you're only interested in the Arduino-level API and don't need the "modern OS goodies". While Intel tends to stuff ACPI and UEFI everywhere they can (ohh the joys of stuff done in SMI, that hampers your real-time response), the Vortex from DMP is principally a trusty old 486, where you still know what you can expect from the busses and peripherials.

      But other than that, you can run Linux on any generic Vortex-based embedded PC motherboard, or a number of other traditional RTOS brands. I agree that when shopping for hardware for your favourite RToS, the x86 PC baggage may not appeal to you :-)

      As for Linux on the Vortex, I believe Debian is still compiled for a 386 (well maybe 486 nowadays) - definitely Debian 6 Squeeze. You can install Debian Squeeze straight away on Vortex86DX and above. On a Vortex86SX (to save a few cents), you need a kernel with FPU emulation enabled (the user space stays the same). All the other major distroes rely on i686 hardware, so you cannot use them on Vortex without a recompilation from source.

      To me, the only possible reason to use the 86duino (rather than a more generic Vortex-based board) is cost. The 86duino is cheaper. And then there's the breadboard :-) Other than that, the full-blown Vortex-based boards are better equipped with ready-to-use computer peripherials, such as RS232 or RS485 on DB9 sockets, USB ports, disk drive connectors and such. It really feels like lego blocks - an impression supported by the colourful sockets used by ICOP on their boards :-)

      1. Frank Rysanek

        Re: Yes yes yes! Vortex86 rules!

        Speaking of chip-level and board-level product lifetime, the boards by ICOP with Vortex chips by DMP have a lifetime of quite a few years. I believe I've read 12 years somewhere, but I don't think the Vortex86DX is *that* old :-) During the 6 years or so that I've been watching ICOP, hardly any motherboard has vanished (except maybe 3rd-party peripherial boards), new products are being added to the portfolio, there have been maybe 2 minor updates (revisions) across the portfolio to reflect some bugfixes / general improvements - while the form factors and feature sets were kept intact.

        In terms of chip-level datasheets and source code, ICOP and DMP are somewhat secretive about selected marginal corner areas (the I2C controller comes to mind). Some chip-level documentation seems to be seeping from board-level 3rd-party manufacturers... But overall the state of support for the key features is pretty good - docs, drivers for key OS'es (including open-source drivers in vanilla Linux). Board-level support in terms of human responsiveness from ICOP and DMP feels like miles ahead of Intel.

  10. Salts

    It's How Much!

    I think this is a really hard sell for intel, like another post said 3 years ago I probably would have been all over this like a rash, now no thanks, that boat has sailed. There really are just so many better, cheaper and more relevant solutions available.

    Pi or BBB black if you need linux and networking out of the box

    The Arduino range if you want stand alone control and a choice of hardware from 8 bit MCU up to 32 bit ARM, or the freescale freedom boards at about $12 using mbed.org, TI's Tiva C board again about $12 and free delivery world wide, if you need an arduino type environment for the Tiva use http://energia.nu/‎

    There are also some promising open source IDE's for ARM, emIDE, emBlocks both of which can use openOCD for debugging and I had better not forget Eclipse.

    The Arduino, RPi and BBB have established, vibrant communities and RPi foundation have already claimed the high ground in the education sector and projects like http://fritzing.org/ I imagine are great for teaching electronics with Arduino in schools.

  11. Eeep !

    How about comparint it with Netduino as well

    Isn't this basically a Netduino Plus (quibble over spec differences after checking http://www.coolcomponents.co.uk/netduino-plus-2-net-c-development-board.html)

    [BTW: While I liked the Arduino sketch idiom, my brain always seems to want to do things on the edge of what it (or the IDE) supports - perhaps I'm not "grokking" Arduino. You can dismiss this comment as just the dodderings of an old person that has developed for embedded systems based on 8051/8052/Z80/6502/68xxx/80x86 in assembler/C for writing/debugging for products that were commercial products]

  12. John Smith 19 Gold badge
    Meh

    So Intel - Windows == Big, expensive, power hungry and can't run what most people buy Intel for

    And you'd want to buy this because?

  13. Will Godfrey Silver badge

    Totally misses the point

    It's a camel - Horse designed by a committee!

    I use Arduinos for all sorts of things - quite often programming on a board while I'm developing an idea then poping the chip out and putting it in a custom board for whatever it doing. I've done some really fast I/O that this hobbled abortion couldn't even begin to look at.

  14. WaveSynthBeep

    Lost the plot

    I received one of these on Monday. My previous experience was with trying to use a first-generation Intel NUC in an embedded application, which lead me to conclude that Intel doesn't really understand embedded (it needs a 19V power supply, WTF?). Let's see if Galileo is different.

    Unboxing with Galileo, there's the board, a power supply, and a booklet of disclaimers in umpteen languages. No instructions at all.

    OK, go off to the website to read the quick start guide. Set up the Arduino software, it tells me to update the firmware. But my board has newer firmware than is available in the download bundle, fail.

    Right, try the LED blink demo, that works.

    Now, I want this as a Linux box, so lets see if we can get Linux up. Write an SD card as per the instructions. Put it in and power up. Nothing happens. No serial output, no LED flash.

    Of course there's no display so I can't see if it's booting. Reading the instructions, boot messages and EFI menus go to the serial port. Which is not the USB port I'm attached with, but the weird 3.5mm jack. For which no cable was supplied. The instructions helpfully say you need to make a serial cable. But most computers don't have serial ports any more. 3.3V serial to USB dongles are common now, and I have one available. But the jack socket is RS232 levels, which it won't do. So I need to make a 3.5mm to DB9 adaptor, and then have a full RS232 to USB adaptor so I can plug it into a computer.

    To even see the boot messages.

    After all this palaver (ie some minutes), the LED is flashing, so something must be happening. But I don't have ethernet handy (I'm at work, getting stuff on the network is time consuming, laptop has no ethernet port), so I have no other means of interacting with it. /dev/ttyGS0 is the Arduino programming USB serial provided over a USB Gadget driver, which is fine except ttyGS0 doesn't work until the board has booted - and you can't enable a terminal on ttyGS0 without having the board booted and already logged into it. Normal Arduino boards have a USB-serial converter onboard which solves all these problems - not this one.

    The SD card is the kernel and a .ext3 file on a FAT partition, so I can't even try traditional mount-the-SD-on-a-PC tricks. (Well I could loopback mount the .ext3 but this is getting awkward)

    Plus the distro is weird (Yocto). It doesn't run vanilla distros like Debian, so I can't just image an SD card and go. (Actually someone has almost managed that, but it doesn't like libpthread for some reason, and images aren't yet available). Yocto looks OK for deploying embedded Linux in a commercial environment, but rebuilding your distro from scratch isn't something you want to do when casually hacking.

    Of course, none of this is mentioned in the quickstart guide - and there's only a fairly sparse forum to fall back to.

    Hardware-wise, there are two full-speed I/O pins, the rest are via I2C. That's hopeless for bitbanging any kind of protocol. It's actually a Linux box running an 'Arduino environment' as the only process. A worse idea I couldn't imagine. Why did they think Arduino was a sensible environment to target?

    And the Quark chip runs finger-burningly hot.

    I'd really love a small, cheap, Intel board with either GPIO or USB (it's to be a JTAG server for some third-party JTAG tools that's only built for x86). But I'm wondering whether to cut my losses at this point as they clearly have no idea. Maybe someone will do a Raspbian for it and solve all the problems - until then it'll live in the ever-growing pile of abandoned dev boards.

    1. A Twig

      Re: Lost the plot

      In future - can you do the reviews for this sort of thing for El Reg?

      Exactly the sort of things I want to be reading about this stuff... Ta :)

    2. Nigel 11

      Re: Lost the plot

      NUC isn't intended for embedded at all. If for anything, it's for the Mac Mini market. See my post above re GA-C1037UN-EU for details of a PC board that is easy to run off a vehicle 12V supply (or a 12V power brick) with far more interface options than an NUC. The board itself has a standard ATX power connector, the Pico-PSU range is the other half of the solution, and the C1307 CPU is 17W TDP and fanless.

      1. WaveSynthBeep

        Re: Lost the plot

        NUC is advertised for 'digital signage' - which is fine if you have a mains plug, but no good if you need to integrate into an existing setup (which only has 12V for example).

        PC motherboards are fine except they aren't small. I can't easily slip one inside my product as you could with a Pi-sized thing. The other problem many of these boards have is connector placing: I can't mount one on a spare bit of back panel to make the ethernet available, because I need to make space for the ruddy VGA connector to stick out, and the back panel needs to be 170mm tall to accommodate an ITX motherboard (mounted vertically as the rest of the case is used for something else). These boards are also not thin having big heatsinks and airflow requirements.

        1. Adrian 4

          Re: Lost the plot

          I can't see why anyone would want to use x86. It's been strangled by backwards compatibility. the sooner it dies, the better.

          But if you must have a small x86 board, could you use PC104 ?

          1. Frank Rysanek

            Re: PC104

            PC104 is a form factor, rather than a CPU architecture thing - though it's true that I've seen a number of x86 CPU's in a PC104 form factor, but only a few ARM's...

            PC104 is a relatively small board, whose special feature is the PC104 and/or PCI104 connector, making it stackable with peripherial boards in that same format. Other than that, it's also relatively expensive. And, it's easy to forget about heat dissipation in the stack.

            If you need a richer set of onboard peripherials or a more powerful CPU (Atom in PC104 has been a joke), you may prefer a slightly bigger board, such as the 3.5" biscuit. There are even larger formats, such as the 5.25 biscuit or EPIC, which is about as big as Mini-ITX. The bigger board formats allow for additional chips and headers on board, additional connectors along the "coast line", and additional heat dissipation.

            If OTOH you need a very basic x86 PC with just a few digital GPIO pins, and you don't need an expansion bus (PCI/ISA), there are smaller formats than PC/104 - such as the "Tiny Module" (from ICOP, with Vortex) or the various SODIMM PC's.

            The Arduino format is special in that it offers a particular combination of discrete I/O pins, digital and analog - and not much else... and I agree with the other writers who point out that it's a good prototyping board for Atmega-based custom circuits.

    3. Nigel 11

      Re: Lost the plot

      And the Quark chip runs finger-burningly hot.

      Presumably it is engineered to do so. As were Atoms before. And any chip well-designed for passive cooling (because you need a fairly large delta-T before convection gets going).

      I remember an old Athlon system I once serviced. The heatsink fan had failed and I sizzled my finger on the heatsink (ie over 100C - heaven knows what the chip temperature was). Nevertheless it was "working perfectly". (The perceived problem was a failed CD drive). And it carried on working perfectly until it became obsolete a couple of years later.

      Going back even further, I saw a power supply that had become overloaded because of a fault elsewhere, but which only failed when a rectifier diode melted its soldered connections and dropped off the circuit board. It was still a working diode.

      CMOS silicon is very tolerant of high temperatures. The CMOS switching speed drops in inverse proportion to the temperature in degrees absolute, so the Tmax for a chip is usually the temperature above which the manufacturer will not guarantee correct function. Running too hot is akin to overclocking (which is why overclockers are into radical heatsink designs). Tmax is certainly not the temperature at which the chip will be destroyed in seconds. It gets much hotter when being soldered in place. Operational life is shortened by high temperature operation, but chips will function for decades and become obsolete long before ... dropping life expectancy from 30 years to 15 years rarely matters.

      1. Vic

        Re: Lost the plot

        > CMOS silicon is very tolerant of high temperatures.

        Yeah, after a fashion...

        The problem of high Tj isn't instant catastrophic failure, it's a reduction in device longevity; the chip simply doesn't last as long as it otherwise would.

        In some markets, that makes no difference - devices are obsoleted long before they fail. Other markets would simply not accept that sort of lifespan...

        Vic.

      2. Frank Rysanek

        Re: finger-burningly hot = well designed for passive cooling

        > > And the Quark chip runs finger-burningly hot.

        >

        > Presumably it is engineered to do so. As were Atoms before.

        >

        agreed! :-) My words exactly. Many ATOM-based fanless designs are a joke.

        Compare that to the Vortex86. You can typically hold your finger on that, even without any kind of a heatsink if the board is large enough. On tiny boards, it takes a small passive heatsink that you can still keep your finger on after some runtime. That for the Vortex86DX clocked at 800 MHz at full throttle. With some power saving and underclocking, it doesn't take a heatsink.

        > And any chip well-designed for passive cooling

        > (because you need a fairly large delta-T before convection gets going).

        >

        Thanks for explaining the mindset of all the nameless Chinese R&D folks.

        I'm on the other side of the barricade - I'm a troubleshooter with a small industrial/embedded hardware distributor, I'm effectively paid by system integrator people (our customers) to sooth their "burned fingers".

        Imagine that you need an embedded PC board, at the heart of some book-sized control box. That box will be mounted in a cabinet. The folks at Westermo used to say that every "enclosure" adds about 15 degrees Celsius of temperature. And you have maybe 2-3 enclosures between your heatsink and the truly "ambient" temperature. In my experience, that 15 degrees applies to very conservatively designed electronics, with sub-1W-class ARM MCU's on the inside. For computers worth that name, where you aim for some non-trivial compute power, the 15* are a gross under-estimation. You have to calculate with Watts of power consumption = heat loss, thermal conductivity at surfaces and thermal capacity of coolant media (typically air) - even in the "embedded PC" business, far from the server collocation space.

        Note that there are electrolytic capacitors on the motherboard, surrounding the CPU or SoC and VRM etc. They're not necessarily the solid-polymer variety. With every 10*C down, the longevity of these capacitors doubles. For low-ESR capacitors, It's typically specified at 2000 hours at 105*C. Twice that at 95*C etc.

        Now... back to the mindset of our typical customer: it's fanless, right? so we can mount this in a tiny space in an unventilated box, run some cables in the remaining tight space on the inside... and sell that as a vehicle-mounted device... and remain unpunished, right? Let's go ahead with that...

        (Where do you get convection around the CPU heatsink in that?)

        The typical mindset of our suppliers' R&D is: let's sell this with the minimum possible heatsink, that will alow our bare board survive a 24hour burn-in test in open air, without a stress-load application running on the CPU (just idling).

        Some particular fanless PC models are built in the same way. The most important point is to have an aluminium extrusion enclosure with some sexy fins on the outside. It doesn't matter if only a half of them is actually thermocoupled to the CPU and chipset, never mind the RAM and VRM and all the other heat sources on the inside (they'll take care of themselves). The enclosure needs to have fins and some cool finish, for eyewash effect - make it golden elox or harsh matte look. If it looks real mean, all the better - you can put the word "rugged" in your PR datasheets. Never mind if the surface of the fins is clearly insufficient to dissipate 15W of heat, on the back of an envelope (or just by the looks, to a seasoned hardware hacker). Perhaps also the computer maker's assembly team add a cherry on top, by optimizing the thermocoupling a bit: you can relax your aluminium milling tolerances a bit if you use 1 mm of the thermocouple chewing gum. Never mind that the resulting thermal coupling adds 20 Kelvins of temperature gradient. Even better, if the internal thermal bridge block designed by R&D is massive enough, you can probably just skip thermocouple paste or chewing gum alltogether, to accelerate the seating step on the assembly line... It takes maybe 20 minutes at full throttle before the CPU starts throttling its clock due to overheating, and the QC test only takes 2 minutes and is only carried out on every 20th piece of every batch sold.

        Customer projects (close to the end user) that go titsup get later settled between purchasing and RMA departments and various project and support bosses and maybe lawyers - no pissed off troubleshooter techie has ever managed to wrap his shaking fingers around the faraway R&D monkey's throat :-)

        If anyone is actually interested in practical advice, to get long-lived embedded PC's in production operation, I do have a few tips to share:

        If you can keep your fingers on it, and it doesn't smell of melting plastic, it's probably okay. Do this test after 24 hours of operation, preferably in the intended target environment (enclosure, cabinet, ambient temp).

        If you insist on playing with high-performance fanless stuff, do the heat math. You don't need finite-element 3D modeling, just back of the envelope math. What are the surfaces of your enclosures, times the heat transfer coefficients, times the wattage. What gradients can you come up with? Pay attention to all the heat-producing and hot components on your PCB's. All the parts inside your fanless enclosure principally run hotter than the "thermocoupled envelope". Putting sexy inward-facing heatsinks on hot components doesn't help much, inside a fanless enclosure. Consider that adding a tiny fan will turn this "roast in your own juice" feature of a fanless enclosure inside out.

        If you intend to purchase third-party off-the-shelf fanless PC's for your project (complete with the finned enclosure), take a few precautionary masures: Take a look inside. Look for outright gimmicks and eyewash in thermal design, and for assembly-level goof-ups (missing thermocouple paste). Install some OS and run some burn-in apps or benchmarks to make the box guzzle maximum possible power. If there are temperature sensors on the inside, watch them while the CPU is busy - lm_sensors and speedfan are your friends. Some of the sensors (e.g. the CPU's coretemp) can be tricky to interpret in software - don't rely on them entirely, try opening the box and quickly touching its internal thermocoupling blocks and PCB's close around the CPU.

        Single-board setups should be generally more reliable than a tight stack of "generic CPU module (SOM/COM) + carrier board" - considering the temperature dilatation stresses between the boards in the stack. In fanless setups, the optimum motherboard layout pattern is "CPU, chipset, VRM FET's and any other hot parts on the underside" = easy to thermocouple flat to the outside heatsink". Note that to motherboard designers, this concept is alien, it may not fit well with package-level pinout layouts for easy board routing.

        Any tall internal thermal bridges or spacers are inferior to that design concept.

        Yet unfortunately the overall production reliability is also down to many other factors, such as soldering process quality and individual board-level design cockups... so that, sadly, the odd "big chips on the flip side" board design concept alone doesn't guarantee anything...

        If you're shopping for a fanless PC, be it a stand-alone display-less brick or a "panel PC", notice any product families where you have a choice of several CPU's, say from a low-power model to a "perfomance mobile" variety. Watch for mechanical designs where all those CPU's share a common heatsink = the finned back side of the PC chassis. If this is the case, you should feel inclined to use the lowest-power version. This should result in the best longevity.

        If you have to use a "closed box with fins on the outside" that you cannot look inside, let alone modify its internals, consider providing an air draft on the outside, across its fins. Add a fan somewhere nearby in your cabinet (not necessarily strapped straight onto the fins).

        Over the years, I've come to understand that wherever I read "fanless design", it really means "you absolutely have to add a fan of your own, as the passive heatsink we've provided is barely good enough to pass a 24hour test in an air-conditioned lab".

        If your outer cabinet is big enough and closed, use a fan for internal circulation. Use quality bearings (possibly ball bearings or VAPO), possibly use a higher-performance fan and under-volt it to achieve longer lifetime and lower noise. Focus on ventilation efficiency - make sure that the air circulates such that it blows across the hot parts and takes the heat away from them.

        Even an internal fan will cut the temperature peaks on internal parts that are not well dissipated/thermocoupled, thus decreasing the stress on elyt caps and temperature-based mechanical stresses (dilatation) on bolts and solder joints. It will bring your hot parts on the inside to much more comfortable temperature levels, despite the fact that on the outer surface of your cabinet, the settled temperature will remain unchanged!

        If you merely want a basic PC to display some user interface, with no requirements on CPU horsepower, and for some reason you don't like the ARM-based panels available, take a look at the Vortex. Sadly, Windows XP are practically dead and XPe are slowly dying, and that's about the ceiling of what Vortex can run. Or you can try Linux. You get paid off by 3-5 Watts of power consumption and hardware that you can keep your finger on.

        Examples of a really bad mindset: "I need a Xeon in a fanless box, because I like high GHz. I need the absolute maximum available horsepower." or "I need high GHz for high-frequency polling, as I need sub-millisecond response time from Windows and I can't desing proper hardware to do this for me." or "I need a speedy CPU because I'm doing real-time control in Java and don't use optimized external libraries for the compute-intensive stuff". I understand that there *are* legitimate needs for big horsepower in a rugged box, but they're not the rule on my job...

  15. Anonymous Coward
    Anonymous Coward

    400 Mhz?

    What is this, 1998?

    1. diodesign (Written by Reg staff) Silver badge

      Re: 400 Mhz?

      *microcontroller*

      C.

      1. Steve Todd

        Re: 400 Mhz?

        The problem is that for a microcontroller it is woefully short on IO, and for an application processor it's pathetically slow. X86 simply isn't good at this kind of work, and god knows why Intel thought that it would be.

        When it came to creating microconttollers ARM went away and re-engineered their cores into two additional families - the M series and the R series. These were optimised for their roles (the R series are for real time work BTW) and loaded down with IO on the chip (the latest STM M4F processors have up to 168 GPIO pins, 24 ADC channels and 2 DACs for example).

        1. WaveSynthBeep

          Re: 400 Mhz?

          Also as an application processor there is no software ecosystem. There's tons of x86 Linux distros out there, but it won't run any of them (without yet-to-be-done hackery). Yocto is just getting off the ground as an embedded system platform, but it's not a 'hacker' OS like Debian or even OpenWRT, it's more an 'appliance' OS - make a change, rebuild all the packages, run the regression tests, signoff by management, ship firmware v1.23.45.6 to the factory. You aren't really intended to ssh in and run emacs to change things.

          They provide the Arduino ecosystem but it's no good as a microcontroller.

          So I'm yet to work out what it /is/ good for.

          1. Steve Todd

            Re: 400 Mhz?

            It also seems that the Quark is based on the 486 core, with the same number of clocks per instruction. As a result it will be no faster than an M4F @168MHz (and probably even @100MHz). So it's more expensive than an ARM, draws more power, has less and poorer IO while not being any faster. What was the point again?

            1. WaveSynthBeep

              Re: 400 Mhz?

              Since I haven't seen this anywhere, here's /proc/cpuinfo (I finally managed to start telnetd and get in, using ethernet):

              Poky 9.0.2 (Yocto Project 1.4 Reference Distro) 1.4.2 clanton

              / # uname -a

              Linux clanton 3.8.7-yocto-standard #1 Tue Oct 1 00:07:32 IST 2013 i586 GNU/Linux

              / # cat /proc/cpuinfo

              processor : 0

              vendor_id : GenuineIntel

              cpu family : 5

              model : 9

              model name : 05/09

              stepping : 0

              cpu MHz : 399.076

              cache size : 0 KB

              fdiv_bug : no

              hlt_bug : no

              f00f_bug : yes

              coma_bug : no

              fpu : yes

              fpu_exception : yes

              cpuid level : 7

              wp : yes

              flags : fpu vme pse tsc msr pae cx8 apic pge pbe nx smep

              bogomips : 798.15

              clflush size : 32

              cache_alignment : 32

              address sizes : 32 bits physical, 32 bits virtual power management:

              It even ships with the f00f_bug! Welcome to 1997 all over again!

              1. Frank Rysanek

                Re: 400 Mhz?

                Oh it's got CMPXCHG8? Means it can run Windows XP? cept for the missing graphics :-)

    2. Solmyr ibn Wali Barad

      Re: 400 Mhz?

      CPU stuck in 1998, AC stuck in 2001. Lovely.

      /spoiler alert/ Megahertz wars are long over. They lost.

  16. Anonymous Coward
    Anonymous Coward

    Maybe this is naive but why isn't it being compared to an Arduino Yun?

    1. Steve Todd

      The YUN is another odd fish

      It has the same, low powered, microcontroller and IO as the UNO and a more powerful but still limited application processor for the WiFi. The DigiX is a cheaper and much more capable microcontroller with WiFi, the UDOO has a fully powered application processor and a much more powerful microcontroller combined (and is effectively what the Arduino Tre is going to be). Given this, why exactly would you buy a YUN?

  17. Loyal Commenter Silver badge

    So....

    Does half of what a RPi does, costs twice as much.

    Why?

This topic is closed for new posts.

Other stories you might like