Tuesday, April 29, 2014

IOIO Bluetooth and Windows 8 / 8.1

Notes on using the IOIO with Windows 8 over Bluetooth

This post describes the results of controlling various versions of the IOIO Firmware from Windows 8 over Bluetooth.  Initial content was extracted from http://joe.blog.freemansoft.com/2014/04/ioio-v1-dealing-with-firmware-versions.html and expanded with additional content.

I used the HelloIOIOConsole.jar  sample program to test connectivity between Windows 8 and an IOIO V1 running different Application firmware.  I also tested Mac OS/X Mavericks.

HelloIOIOConsole.jar results 4/2014
Java Application V1 3.03/3.23 V1 3.26/4.0 V1 ?.00/5.00
Windows 8.1
No Communication
Constant reconnects
Works Not Tested
Windows 8.1
No Communication
Constant reconnects
Fails handshake without patch

Works with patch described below

Not Tested
Windows 8.1
No Communication
Constant reconnects
Fails with Version Mismatch
(as expected)
Not Tested
OS/X Mavericks
Works Works Not Tested
OS/X Mavericks
- Works Not Tested
OS/X Mavericks
- Fails with Version Mismatch
(as expected)
Not Tested

Using HelloIOIOConsole.jar on a Mac running Mavericks

My Macbook had no trouble pairing with the IOIO V1 with Bluetooth adapter. 4545 is the pairing code. The Bluetooth connection will go idle after some time and change from "Connected" to "Not Connected".  The IOIO serial device  ports on the Mac continue to exist even if the connection has gone to sleep. Bluetooth is re-connected when a program accesses the outbound serial device tied to the IOIO.  The Mac just worked.

Determining my Application Firmware Version using a Mac

I first tried HelloIOIOConsole, version 5, the latest, application java -jar HelloIOIOConsole.jar. That failed with the following output on my device.  Eureka!  It looks like I actually have Bootloader 303 and Firmware 323

App-IOIO0500.zip HelloIOIOConsole.jar[I/IncomingState] IOIO Connection established. Hardware ID: SPRK0016 Bootloader ID: IOIO0303 Firmware ID: IOIO0323[V/IOIOImpl] Querying for required interface ID[E/IOIOImpl] Required interface ID is not supported[E/IOIOBaseApplicationHelper] Incompatible IOIO firmwareioio.lib.api.exception.IncompatibilityException: IOIO firmware does not support required firmware: IOIO0005

Then I tried HelloIOIOConsole application version 4 java -jar HelloIOIOConsole.jar. Still no love with this combination.
App-IOIO0400.zip HelloIOIOConsole.jar[I/IncomingState] IOIO Connection established. Hardware ID: SPRK0016 Bootloader ID: IOIO0303 Firmware ID: IOIO0323[V/IOIOImpl] Querying for required interface ID[E/IOIOImpl] Required interface ID is not supported[E/IOIOBaseApplicationHelper] Incompatible IOIO firmwareioio.lib.api.exception.IncompatibilityException: IOIO firmware does not support required firmware: IOIO0004

Finally, I ran HelloIOIOConsole application version  java -jar HelloIOIOConsole.jar. The program ran fine and was able to manipulate the Bluetooth attached device..
App-IOIO0330.zip HelloIOIOConsole.jar[I/IncomingState] IOIO Connection established. Hardware ID: SPRK0016 Bootloader ID: IOIO0303 Firmware ID: IOIO0323[V/IOIOImpl] Querying for required interface ID[V/IOIOImpl] Required interface ID is supported[I/IOIOImpl] IOIO connection established
This means I am running version 3.x (!)

Using HelloIOIOConsole with Windows 8 with Firmware 3.03/3.23

I was unable to run any version of HelloIOIOConsole on Windows 8 with my IOIO V1 running firmware 3.23. None of them ever got far enough to verify a version match between the app and the firmware.

The PC and IOIO pair over Bluetooth without any issues.  Virtual COM ports are created.

The IOIO bluetooth connection status never changes from "Not Connected" to "Connected" even after letting HelloIOIO run for a while. Windows 8 told me that there was a driver failure every time a COM port was (re)opened.

I tried several versions of HellloIOIOConsole. The image at right shows up every time the console app runs and connects to a serial port. This message pops up several times.  Tapping on it takes you to the Bluetooth management screen which then tells you:
Adding your device didn't work. First remove it from your PC, and then try again.
The windows event log shows the following.
The mutual authentication between the local Bluetooth adapter and a device with Bluetooth adapter address (00:15:83:44:b9:e7) failed.
It feels like some kind of driver / protocol problem I don't understand.  This is fixed with later versions of the Application Firmware

Using HelloIOIOConsole with Windows 8 with Firmware 3.11/4.00

The PC and IOIO pair over Bluetooth without any issues. Here is the success matrix for HelloIOIOConsole.jar:

  1. PC Application version 3.23 works great. It logs the IOIO hardware and firmware versions and accepts commands.
  2. PC Application version 4.00 hangs "waiting for handshake".
  3. PC Application version 5.03 connects and logs the IOIO hardware and firmware version and and correctly terminates because the app uses a later IOIOlib than allowed for the 4.00 firmware

Fixing PC IOIOLib 4.00 to work with Windows 8

SerialPortIOIOConnection.java in IOIOLibPC requres that three lines of code be commented out.  You can find the source file at:
 Comment out lines 73-75


to look like



OS/X and Linux are more forgiving when working with Bluetooth and IOIO

Wednesday, April 23, 2014

"What do you do for a living?" Pre-Sales Engineer

My family told me that they don't know what I do for work.  This was kind of surprising since everyone tells me that I never shut up about what I'm working on.

This post is an attempt to explain what I do/did as a "Pre-Sales Engineer".  I've played this part while working for software or hardware companies that sold "technical" products.  These ranged from Logic Analyzers and Embedded development tools to development and application platforms to Internet support products like web and mail servers.

Note:  I'll probably use "Field Engineer", "Sales Engineer" and "Pre-sales Engineer" interchangeably throughout this document.

You Got Mad Skills

A Pre-Sales Engineer has the rare skill of being comfortable with technology and with people.   Pre-sales technical resources explain technology to techies, implement a solution, map the benefits of technology to business problems and interact with business users and managers..  Pre-sales Engineers are nerds who can talk to non-techies without killing them with jargon.  

The Pre Sales Engineer (PSE)

Sales representatives own the account.
They are accountable for the team's success and carry most of the financial risk associated with account performance. Sales representatives handle the higher level customer relationships, track deals and handle first level technical discussions with mid to upper level management.

The Pre-Sales Engineer is the technical half of a sales team in a partnership where the sales representative is in charge.  PSEs must be "sales ready" while also having good technical skills.  Pre-sales engineers tend to handle the technical relationships and 2nd level product discussions.

Pre-sales technical resources exist to help the sales process. They exist to help close the deal and make the next deal possible.  Companies sometimes also use field technical resources to help cement technical partnerships with organizations that can help bring in future business.  A company may spend technical resources on a systems integrator or reseller to enable them to bring in business on some channel.  Ex: higher education, government, etc.

Sales engineers can be inside or outside. Inside sales teams tend to work smaller accounts or external companies that aggregate other smaller accounts. Their customer interactions are all online/remote.  Inside teams may handle sub-parts of larger accounts. Outside sales teams are expensive and tend to focus on larger or strategic accounts.  Outside teams do digital meetings but also travel for in-person events.  EX: All of pre-sales technical resources for a large on line bookseller and cloud provider worked inside until a couple years ago.  It was only after they started getting true enterprise or government type deals that they spun up an team that was more outside oriented. I've always worked outside.

Job Responsibilities

Pre-sales engineers own the technical side of the sale. "Own" can mean a bunch of things depending on the complexity of the technology, the seniority of the engineer and the trust level and technical expertise of the sales rep. Essentially the engineers job is to understand the business problem , map that to the technical product to provide a business solution and to overcome technical objections.  They help package/re-package products and services to meet the customer needs by using previous solutions and customers as examples of how the solution comes together.

Pre-Sales Activities

Pre-sales activity involves initial calls, live meetings, webinars, discussions with the sales rep, customer presentations and product demonstrations. PSEs create customized presentations and demonstrations that target that customer's needs.  These can be minor customization or major amounts of work based on how far along this is in the sales cycle and how important the deal is.

Sales representatives usually own pre-screening calls and relationship construction. First meetings are exploratory spent understanding customers true problems in contrast to their expressed problems. The sales rep and the PSE work together to map out the solution space for their products at each customer. You never know from call to call how deep the call will be or how on-target the customer.  Some prospects will bring the wrong people to a meeting, will have a totally different problem than described or may be unexpectedly interested in drilling down to understand how a product can be used.  This can happen in the same meeting as the conversation moves across a room. Meetings can be stressful while trying to understand true requirements, agendas, and bias towards your or other companies.  Pre-sales engineers deal with people who know nothing about the problems space.  They deal with people who understand the problem and solutions better than the PSE.  Existing customers often know the product better than the PSE because they live in some piece of it on a daily basis

Good sales reps do a pre-meeting walk through for every meeting to make sure the team is on the same page as far as goals and to make sure everyone understands what is known about the customer.  There are also follow up conversations after each meeting/call to make sure everyone heard or saw the same thing.   Many PSEs work on multiple teams with different operating styles.  PSE resources are expensive so they may be pooled with multiple reps or assigned to specific reps.  A sales team may have dozens of calls per week with overlapping meetings and discussions. The PSE is responsible for keeping track of where each sales process is at and what tasks needs to be done.

RFP responses often also fall on the PSE.   No product is an exact match for a proposal unless it was written explicitly for the product. In either case, it is up to the PSE to help craft a response that describes how the product meets the request as much as possible while mentioning advantages that may cause the request to be re-defined. This is hard for many technicians who tend to very direct and literal in their interpretation of requirements or specs.

Sales reps like to retain control over activities because they are the ones rewarded for success and accountable for failure. PSEs can operate semi-independently handling customer calls , questions and presentations at the sales rep's direction.  The amount of power given to a PSE is directly proportional to the trust the sales team has that the PSE understands the product, won't say anything stupid, knows when to be quiet and understands the products the sales representative's style well enough to be and independent contributor.  

Proof of Concept, Prototype and Pilot

Many sales processes have a "bake off" or prototype phase where the customer wants to see the product in action in their environment or targeted at their business or problem space.  Prospects use these to verify the functionality or to try and eliminated companies to shrink down the amount of choices they have. These events tend to be on short time lines.  Product companies often try to get the customers to pay for part of these efforts to make sure they customers are serious and to make sure they have "skin in the game" with respect pushing to a completed state. 

Pre sales engineers are one of the few resources totally controlled and "owned" by the sales group.  This means the sales group will often augment paid PoC efforts or completely fund them out of the sales team using the Pre-sales engineers. Pre-Sales Engineers must know their products well enough to scope and develop small implementations as part of these efforts.  This can be a very technical event depending on the complexity of the product being demonstrated.

PoC efforts need to be done as quickly as possible in a "good enough" fashion that satisfies the customer's meaningful requirements.  They SE may have to figure out the most important areas based on feedback from the customer's various stakeholders.  The business may want to see one thing, technicians another and finance or operations a different area.  A PoC is not delivering a production ready environment. It is delivering enough that people can see the end state or that something will work.  These are high pressure events where the sales team may often also expect the PSE to continue handling other sales issues for this or other customers.  I've seen people working out of their hotel room at night while travelling to other customers or a trade shoe.  Expectation management with respect to time commitments and deliverables are keys to success in PoC efforts.

Post Sale Support

Primary customer support is usually handled by product technical support, post sales consulting teams or account managers.  The sales team often retains control of the account but only gets involved in post-sales issues as part of ongoing sales opportunities. PSEs sometimes help with planning for initial implementations or act as second tier or "on site" support if the primary technical resources can't resolve an issue. 

Evangelism and Marketing

There are many situations where a company or it's products must be positioned, demonstrated and described that are not tied to an individual sale.  Trade shows, marketing webinars, user groups, departmental technology demonstrations and partner events often require PSE support to give presentations, do demos, participate in panel discussions, answer questions or do basic training.  These types of events let the company get in front of more prospects without having to visit each one individually.  Some companies have technical marketing, developer evangelism or outbound technical publicity groups that handle the bulk of this work but they usually still rely on remote field resources for staffing.  PSEs may also be called upon to create the scripts or demonstrations and demonstration environments for these events.

2nd Level or "SWAT" Engineering

Many technical sales organizations have multiple levels of PSE.  There is often a step-up tier for more senior folks that are called in after the initial work is done. These may be Subject Matter Experts for particular products or vertical markets. A SME may be an expert in video or key cards for a security company.  A vertical market may be a specialty, like finance, medical, government or some other area that has special needs and standards.

What the Day Looks Like

The actual breakdown varies by product an industry.  My experience feels something like that to the right.  Some folks mostly do proposal respnses.  Their time breakdown is probably completely different.

Sales: True sales activity including presentation prep, meeting prep, actual customer communication, and deal planning.  

Self Training:  PSEs must become experts in their products which involves a lot of self motivated training.  They also self-train while building demonstrations and doing PoC.

Post-Sale: Customer satisfaction leads to future business.  PSEs have direct customer involvement and advocate  for the customer themselves or for customer requested product changes. PSEs also maintain technical contact with the customer while the sales reps prospect for new deals.

Dealing with Sales Representatives

Sales representatives are different beasts.  They think differently and are motivated differently that most of their technical counterparts. They believe products are a good fit when the PSE doesn't quite see that (yet). They ignore or work around objections that may seem fatal to a technical person.  Sales reps can be compensation driven because they accept the risk / reward balance of commission based compensation. Good sales representatives understand how to drive a process and understand how people think.  I have found working with sales reps to be a generally rewarding experience.

Sales representatives tend to come in two flavors, hunters and farmers:

  • Hunters:  These folks tend to be more aggressive tracking and bringing down the big deal. They are often great in a startup or when a company is trying to make a name for itself.  Hunters are not always great as account managers or annuity builders.  Sometimes you will run into a hunter that is a true barbarian whose first instinct is always to pick an aggressive sales posture.
  • Farmers:  These tend to work longer term deals, sometimes forgoing short term opportunities if they feel the product or customer isn't really ready.  Farmers can take a beating inside a company because they may not force close deal on short timelines. Companies tend to use these folks for relationship management and for customer satisfaction. 
Sales representatives are usually commission or quota based. They will also occasionally bend a deal to better fit they way the company structured quota or bonuses. That's one of those things a technical person has to learn to live with.

Difficulties for Technicians in non Technical Settings

Customer visits have a dress code.  Technicians may not think appearance is important but first impressions and dress do matter when dealing with customers.

Technical folks tend to take a question literally and answer it assuming there is a "right answer".  They need to understand the real purpose of the question.  Sometimes the question is more of a "how do we use your product to do it the way we used to" when the answer needs to be "this is how you solve a business problem a new way".  Sometimes folks ask hard questions as part of a "stump the chump" contest.  PSEs need to handle that too.  A lot of early technical questions exist to winnow down the number of vendors they need to talk to.  Technicians need to be aware of this and not say "no" until they have to.

Technical folks tend to provide short answers when the answer is "yes".  They tend to provide a long winded response when the answer is "maybe" or "not exactly".  All answers have to be given within the context of the meeting and the place within the sales pipeline.  This is something people folks may need coaching and training to learn to handle.

Technical folks also tend to be specific when they know the answers but very fuzzy when they don't.  This improves as the person learns more about the product, features and customer business processes.

Sales representatives and their management often operate on a quota system.  This may drive the teams planning and thinking during certain times of a quarter or year.  A sales rep may view the likelihood of a deal based on size or product mix where the PSE may view it based on technological match.

Customers sometimes are experts and sometimes don't even know the basics.  This may happen in the same meeting.  PSEs have to adjust to these disparate expertise levels.


My experience tells me that corporations train their PSEs more aggressively than about almost any other technical position. PSEs need to understand products and techologies well enough to explain it to others, to demonstrate in high pressure situation and build small PoCs or deployments using the technology. Companies, like VMWare,  push PSEs through rigorous certification processes before letting people in front of customers. Training has to be done in a hurry so the PSE is useful but very deep so the PSE has credibility with the people they are in front of.  Some times this is like drinking from a firehose!


Pre-sales engineers tend to make more than their developer counterparts.  Companies pay extra for people who both understand technology and can communicate with technical and non-technical humans in high pressure situations.  I'd guess that pre-sales engineers make about 20% more than their inside engineering counterparts.  They also normally get a performance bonus on top of that.  My experience has been that sales-engineers get about 80% base and 20% bonus.  Sales representatives can be the inverse of that. Many pre-sales engineers move to sales but many are more risk averse and stay more on the technical side.

Friday, April 18, 2014

IOIO V1 Dealing with Firmware Versions and Android, PC and Mac

Last updated 4/18/2013

IOIO programs run on Android devices, PCs or other types of computers. They communicate over USB or Bluetooth to firmware programmed into the IOIO Pic chip.   Control programs are built using an IOIOlib library that knows the communication protocol between the program machine and the IOIO board.  Both sides of this communication must agree on the protocol and payload of this communication.

Each version of the IOIO firmware comes with its own library that was built for that firmware. Host programs must be linked to an IOIO library whose major version number is less than or equal to the major version of the your device's firmware. This works because Ytai tries to make sure that firmware is backwards compatible with previous versions.

  • Programs compiled against any version 3.yy IOIOlib should be able to communicate with any 3.xx Firmware devices. EX: Programs built against 3.23 can talk with IOIO devices running Firmware 3.26.  I was able to run demo programs from the public V3.30 downloads with my V1 running firmware 3.23.
  • Programs compiled against firmware V4.xx or V5.xx will will probably not communicate with devices running Firmware 3.x.
This means that you may not be able to use the latest programs in the Google Play store when using with an IOIO board with older firmware. None of the example programs in the store (4/2014) would communicate with my IOIO V1 and its two year old v3.23 firmware.

Determining if App and Firmware Version are compatible

My PC and Mac testing where done over a Bluetooth link because IOIO V1 can only talk to PCs over Bluetooth.   The IOIO V1 can talk to Android devices over USB or over Bluetooth.  My hacked Nook Simple Touch does not have a Bluetooth adapter so I tested using ADB on top of USB.  I had no idea what firmware I had when I recently tried to talk to my two year old IOIO board. I was able to figure it out running different versions of HelloIOIOConsole on a PC / Mac.

See http://joe.blog.freemansoft.com/2014/04/ioio-bluetooth-and-windows-8-81.html for test results with Mac OS/X and Windows 8/8.1.

Running Android Applications with Android (V2.1) Firmware 3.03/3.23

None of the Google Play store example IOIO programs could communicate with my IOIO.  This was because those apps were bound to newer visions of the firmware than the 3.x in my V1.

I downloaded the App version 3.30 bundle, unpacked it, and side loaded it onto my Nook android tablet.  The 3.30 version apps ran fine with my 3.x which makes me reinforces my feeling Google Play store versions were built recently against the later version than was running on my IOIO.
Written 4/2014

I haven't tested the Google Play store apps with Firmware 3.11/4.00

IOIO Bootloader and Firmware Upgrades

V2 boards can be updated using PCs or external programmers. I do not have a V2 board to test.

V1 boards must be updated using older Android devices or external programmers.  Newer versions of Android changed something that renders them useless for programming. This is one of the reasons the IOIO OTG was built to be programmable with PCs.

You can upgrade firmware using two IOIO boards, one as programmer and one as target. IOIOManager can use the bootloader to replace the application or can use the built in programmer mode to replace both the bootloader and the application.

I was unable to update the Application with my Nook Simple Touch because the Nook Simple Touch never saw my device. It may be a version mismatch between what I downloaded and my V1 hardware version number

I was able to update the bootloader and firmware on my V1 unit after purchasing another V1 off of EBay.  The Nook Simple Touch had no trouble programming the boot loader and application firmware using one V1 to program the other and then the reverse.


 to be written

Wednesday, April 9, 2014

Upgrading the HP Chromebook 14 (Falco) SSD

Walmart sells an HP Chromebook 14 with T-Mobile 3G for $350.  The unit comes with 4GB of RAM and a 16GB SSD.  The SSD is way more than you need as an average Chromebook user.  Microcenter currently has the same Chromebook without the T-Mobile 3G for $250 with a 16GB SSD and $270 with a 32GB SSD.  Linux heads and other nerds, like me, always want to upgrade their devices.

I recommend that you just a unit with the size SSD you think you can live with.  Upgrading a Chromebook 14 NGFF SSD is not for the faint of heart.  There are a bunch of small cables and at least 13 screws on the back and 3-5 inside that have to be removed. The keyboard is clipped into the base of the unit.  Those clips must all be worked loose.  The motherboard with the SSD on it is held in via 3-4 screws, the heat pipe linkage  to the CPU behind the fan and the USB port openings on the left hand side

Of course I didn't listen to my own advice and bought the Chromebook because it is pretty much a laptop except for the small disk which gave me an excuse to take the unit apart. I'm assuming you have no intention of taking this advise either.   MyDigitalDiscount http://Mydigitaldiscount.com is probably the best place to get the SSD.  They have lots of success stories around various Chromebooks.  The main flow for doing a replacement is:

  1. Back up any personal data.  Most of your stuff is probably in the cloud because that's the beauty of using a Chromebook.
  2. Create a recovery disk using an SD card or USB thumb drive.  Enter chrome:/imageburner in the chrome browser.  It will download the correct chromebook image for the HP Chromebook 14 and burn it to the card/drive
  3. Take the machine apart.  Use this http://chromebook-falco.blogspot.com/2013/11/here-are-mechanics-of-ngff-ssd-removal.html awesome walk-through. I was going to write this up but there really is no point with a guide like this one
  4. Swap the disk as part of step 2.
  5. Put the machine back together as part of step 2.
  6. Stick the recovery image back in the SD or USB slot.
  7. Power up the machine.
 http://chromebook-falco.blogspot.com has a bunch of interesting posts on how to dual boot, partition and do other various technical tasks.

Gratuitous Images

 The HP Chromebook comes in several loud colors. Its a good thing it comes with 7 hours of battery life to offset that.

 The screen is low resolution but has nice brightness and color. The machine is quite speedy.

This shows the screen you see when you enter chrome://imageburner Clicking "OK" here will download the image and burn it to the memory stick.

Chrome OS will automatically expand the 440MB archive and put it on the Recovery Media

Take the machine apart per the hardware instructions in http://chromebook-falco.blogspot.com/2013/11/here-are-mechanics-of-ngff-ssd-removal.html.  You will restore the O/S once you put it back together.  No SSD prep is required before insertion.

This is the screen you see when you power up the Chromebook after swapping the SSD. It wants you to insert a Recover Media so it can install the O/S

The Chromebook installs the Chome OS and then restarts.
You should see the "brand new" Chromebook wizard screens when you restart after the O/S installation.


It is fun upgrading your own "non upgradable" hardware. It is also risky so think before you do this.  You can end up with $300 of scrap.  Read this blog http://chromebook-falco.blogspot.com/2013/11/here-are-mechanics-of-ngff-ssd-removal.html for a deeper overview of the upgrade process.  I don't know this person. I just like their detail.

Tuesday, April 8, 2014

Intel Galileo - "What were they thinking?"

The Intel Galileo is one of the more frustrating embedded / small system boards I've worked with.  I'm really not sure what Intel was thinking.  It feels like one of those "we need to get into this market" types of projects that is an off target response to ARMs penetration in the home hobbyist / small systems market. Intel has some work to do if they are serious about this board.  I suspect they will abandon it and try again with some other product.

We've seen other projects from companies that have attempted to do the same thing.  The Microsoft .Net Micro Framework with the associated 2-3 board makers come to mind.  It was too small a market for Microsoft to commit any resources too. They open-sourced .NET MF and let it go fallow for at least two years.


  1. Intel did a great job hacking the Arduino IDE to make it easy to build and run Arduino style sketches without any real knowledge of how the board works.
  2. There is 8MB of flash memory.
  3. It uses a powerful X86 CPU.
  4. The board comes bundled with an all-country adapter.
  5. The board has an Arduino shield compatible header that works with some of the shields already on the market.
  6. There is a hardware console port that can be monitored in addition to the normal Arduino monitoring via the psuedo-tty USB connection.
  7. The board includes a hardwired Ethernet port.


Board and O/S

  1. You can fry the board if you plug in the USB connector before plugging in the power supply. I would expect this from a home brew board but not from a professionally created board targeted at the embedded marketplace.
  2. Sketches are lost across reboots when using the board as shipped.  This makes the board totally useless in any embedded application.  Imagine having to reprogram your Microwave every time you lost power.
  3. O/S configuration changes are lost across reboots when using the board as shipped.  This means you can't configure the network or start other processes without adding system calls to your sketches. 
  4. The on-board Linux is trimmed down to fit in the ROM.  It is hard modify the package so you are stuck with whatever Intel installed.  Systems like the Raspberry Pi and Chumby mandate that you use an SD card for the O/S and file space.  
    • Intel provides an SD card image that lets you add more features and save sketches across restarts. 
  5. The data sheet says that sketches can be saved in Flash memory. This does not appear to be true.  The operating system erases them on restart if it is true that they are put in flash.
  6. The documentation on the two versions of Linux feels different because they come from two different source tracks.  The in-ROM version is called a Board Support Package while the other is often referred to by the way it is built , "Yocto".
  7. The Galileo consumes a lot of electricity for its power.  It uses about 2X the power of a Raspberry Pi and several times the power of the ARM and TI based boards.
  8. The Quark CPU is X86 compatible but does not support certain features like some of the vector instructions.  Intel uses they Atom processor for phones and tablets which means low power and a wide understanding of software portability issues. They should have used the Intel Atom for this board also.


  1. Intel included a mini-card slot for a wireless network card.  The onboard Linux supports that card.  I'm not sure why they did that instead of just adding more USB ports. Other systems come pre-loaded with BroadCom or other wireless drivers that gives you access to a lot of inexpensive network cards. The Raspberry Pi works this way.
  2. Intel included a hard ware serial console port.  They used an audio jack similar to that used on a lot of router or homebrew hacking projects.  
    • Intel made theirs an actual RS-232 port that requires an RCA-to-DB9 cable.   Most laptops don't come with RS-232 ports any more so a lot of people need a second USB to DB9 cable. I can only guess the folks building the board were using desktop machines to work with the Galileo
    • Most other boards and hack products rely on FTDI style USB-to-5V or USB-to-3.3V adapter cables.  They can be purchased on line with RCA plugs already attached.
  3. Intel isn't capitalizing on the power of the quark processor to provide upgraded communications capabilities. USB supports multiple virtual endpoints. Some products use this to provide separate programming, console and other functionality across a single USB connector.  The Quark processor has plenty of CPU power to support this.
    1. The Arduino has a very simple model for the single serial port used for communications and programming. It simulates a serial port on the host system.  This makes it possible to use RF protocols in addition to hard-wire serial communication without any modification to the host programs.  They did this out of necessity because the early boards communicated to hosts using a simple UART through a serial-to-USB bridge chip.

Embedded Functionality

Most of the I/O pins are implemented in I/O expanders instead of being directly connected to the the CPU or system on chip.
  1. The Galileo is at least an order of magnitude slower for I/O operations because of the hardware and software architecture.  You just can't do some things with the Galileo that you can with cheaper, lower power boards.
  2. Two of the pins can be configured for high speed operation. This helps but requires custom register programming and is still not actually the same as an Arduino board.


The Intel Galileo feels like a "first try".  I personally would stay away from it and wait for their next attempt.

Thursday, April 3, 2014

GitHub "Clone to Desktop" with Windows GitHub.

You download GitHub code by "cloning" the repository to a local repository.  They call this a desktop clone. Each  GitHub repository home page has a neat "Clone to Desktop" button in the web interface that you would think clones the repository to your desktop.  

That button actually takes you to the GitHub Windows application download page even if you have the GitHub app already installed. This is where I usually get stuck and head off to some search engine for help.

The Windows GitHub application tries to tell you what to do at the bottom of the "local repository" screen.  It says to "Drag a repository here to add". That phrase always confused me. I can never figure out where to drag the repository from.

It turns out you are supposed to drag the URL for the repository from your browser onto the desktop application.  

Resize your browser window so you can drag the repository onto the GitHub windows application. It will immediately clone that repository to your local GitHub repository.

This example shows the location in the browser of the component you grab and drag onto the main GitHub application window.