Intel Quark SoC running Windows IoT on Intel Galileo (rev 1)

[miguelvp]

So I haven't get the free board yet, but Microsoft added support for people that already has or purchases a Galileo Board.
The new image they offer is compatible with Intel's latest firmware for the board.

https://ms-iot.github.io/content/IBoughtAGalileo.htm

You need to register to download the files.

I'm running on Windows 7 so other than having to install a Windows 8 application to make the image it was a piece of cake.
Only thing needed was a 32GB class 10 microSD card (but you can use a 16GB one instead). I have a USB to microSD adapter so I can inspect the content of the boot disk in Win7 and add programs, or just deploy it from the debugger.

I was writing updates in the Buy/Sell/Wanted topic, but this belongs here instead, so I'm starting this thread with some of that content in there and adding more here.

The previous thread is:
https://www.eevblog.com/forum/buysellwanted/free-intel-galileo-board-from-microsoft/msg500527/#msg500527

The only thing I don't have as per their instructions is a USB to Ethernet adapter to hook the Galileo via Ethernet directly to a USB port, but it works fine if you connect it to your Hub.

Took me around 30 minutes, maybe a bit longer to get the firmware updated and the windows image burned into the microSD card booted and I was able to telnet to it from my Win7 machine



Actually I can telnet to it from my Android Transformer Prime with keyboard dock.

I already downloaded the free Visual Studio Express 2013 as per their instructions:

https://ms-iot.github.io/content/SetupPC.htm

As well as setting up the Galileo after updating the firmware and making the windows image as per their instructions as well:

https://ms-iot.github.io/content/SetupGalileo.htm

Yesterday I didn't get the Galileo Watcher program to show the device but I could access it by IP address, today it shows fine and I didn't have to modify the host table or anything.

I followed their blinky example, by using their provided VS Express 2013 template
https://ms-iot.github.io/content/HelloBlinky.htm
and even if the code generated was slightly different than the one shown in that link it produced everything and I was able to deploy and debug the little app:



Here is the code the template produced:

Code: [Select]

// Main.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "arduino.h"

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// Helper function for logging to debug output and the console
void CustomLogging(char* str)
{
OutputDebugStringA(str); // for VS Output
printf(str); // for commandline output
}

int _tmain(int argc, _TCHAR* argv[])
{
return RunArduinoSketch();
}

void setup()
{
// TODO: Add your code here

CustomLogging("Hello Blinky!\n");
// initialize the digital pin as an output.
pinMode(led, OUTPUT);

}

void loop()
{
// TODO: Add your code here

CustomLogging("LED ON\n");
digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
delay(1000);               // wait for a second
CustomLogging("LED OFF\n");
digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
delay(1000);               // wait for a second
}

I also tried to see if the QueryPerformanceCounter windows call worked and it did based on some ~14MHz clock.

But since it's an x86 chip then I did try to embed assembler to get the actual CPU time stamp counter and it works as well.

Code: [Select]

//
// Read Timestamp Counter
//
inline void GetTimeStampCounter(__int64 *timeStampCounter)
{
DWORD dwLow, dwHigh;
_asm
{
RDTSC           // 0F 31 RDTSC Read time-stamp counter into EDX:EAX.
mov dwLow, eax // Get Low Timestamp
mov dwHigh, edx // Get High Timestamp
}
*timeStampCounter = dwHigh;
*timeStampCounter = *timeStampCounter << 32;
*timeStampCounter |= dwLow;
}

It averages to about  405300000 cycles per second, so it's not really at 400MHz CPU it's a bit higher.

This is all that is running by default:

Code: [Select]

C:\windows\system32>tlist -v
 0 32    0 System Process
     Command Line:
 0 32    4 System
     Command Line:
 0 32  180 smss.exe
     Command Line:
 0 32  260 csrss.exe
     Command Line:
[0]  0 32  288 wininit.exe
     Command Line: wininit.exe
 1 32  296 csrss.exe
     Command Line:
[0]  1 32  312 winlogon.exe
     Command Line: winlogon.exe
 0 32  332 services.exe
     Command Line:
[0]  0 32  344 lsass.exe       Svcs:  SamSs
     Command Line: C:\windows\system32\lsass.exe
[0]  0 32  420 svchost.exe     Svcs:  BrokerInfrastructure,DcomLaunch,Power,SystemEventsBroker
     Command Line: C:\windows\system32\svchost.exe -k DcomLaunch
[0]  0 32  456 svchost.exe     Svcs:  RpcEptMapper,RpcSs
     Command Line: C:\windows\system32\svchost.exe -k RPCSS
[0]  0 32  536 svchost.exe     Svcs:  LanmanServer,ProfSvc,Usertoken
     Command Line: C:\windows\system32\svchost.exe -k netsvcs
[0]  0 32  564 svchost.exe     Svcs:  Dhcp,lmhosts
     Command Line: C:\windows\System32\svchost.exe -k LocalServiceNetworkRestricted
[0]  0 32  580 svchost.exe     Svcs:  nsi
     Command Line: C:\windows\system32\svchost.exe -k LocalService
[0]  0 32  604 svchost.exe     Svcs:  CryptSvc,Dnscache,LanmanWorkstation
     Command Line: C:\windows\system32\svchost.exe -k NetworkService
[0]  0 32  692 svchost.exe     Svcs:  Bootsh
     Command Line: C:\windows\system32\svchost.exe -k Bootshsvc
[0]  0 32  708 svchost.exe     Svcs:  CoreUIRegistrar
     Command Line: C:\windows\system32\svchost.exe -k CoreUI
[0]  0 32  744 cmd.exe
     Command Line: C:\windows\system32\cmd.exe  /K C:\Windows\System32\Boot\synctime.cmd
[0]  0 32  752 msvsmon.exe
     Command Line: C:\Tools\RemoteDebugger\msvsmon.exe  /silent /nostatus /nosecuritywarn /nofirewallwarn /noclrwarn
[0]  0 32  760 Galileo_eboot.exe
     Command Line: C:\Windows\System32\Galileo_eboot.exe
[0]  0 32  776 httpsrv.exe
     Command Line: httpsrv.exe http://+:80/
[0]  0 32  784 ftpd.exe
     Command Line: ftpd.exe
[0]  0 32  792 telnetd.exe
     Command Line: telnetd.exe "logonuitext -c cmd.exe" 23
[0]  0 32  800 mwstartnet.exe
     Command Line: mwstartnet.exe
[0]  0 32  844 msvsmon.exe
     Command Line: C:\Tools\RemoteDebugger\msvsmon.exe /CHILDSERVER f8 "+:4018" {D3C4A7EE-BF0A-4DFA-A528-37F82D32C36D} 0x0 f4 ec e8 f0 /silent+ /servicemode-
[0]  0 32  924 cmd.exe
     Command Line: cmd.exe
[0]  0 32 1084 tlist.exe
     Command Line: tlist  -v

It does have an http server running and this is what it shows:

Code: [Select]

Test Web server running on MinWin

task list
file list
memory statistics

Task list:

Code: [Select]

mintasklist

Image Name                   PID Services
========================= ====== =============================================
System Idle Process            0 N/A
System                         4 N/A
unknown                      180 N/A
unknown                      260 N/A
wininit.exe                  288 N/A      142439165
unknown                      296 N/A
winlogon.exe                 312 N/A      946704075
unknown                      332 N/A
lsass.exe                    344 N/A     3688591984
svchost.exe                  420 N/A      728549736
svchost.exe                  456 N/A      240216553
svchost.exe                  536 N/A      299939892
svchost.exe                  564 N/A      534471125
svchost.exe                  580 N/A       70027273
svchost.exe                  604 N/A      317419388
svchost.exe                  692 N/A       59986282
svchost.exe                  708 N/A       47981723
cmd.exe                      744 N/A       69157825
msvsmon.exe                  752 N/A      667937796
Galileo_eboot.exe            760 N/A     2899972115
httpsrv.exe                  776 N/A       75800204
ftpd.exe                     784 N/A       30306579
telnetd.exe                  792 N/A      374316189
mwstartnet.exe               800 N/A       61796899
msvsmon.exe                  844 N/A      124821234
cmd.exe                      924 N/A      113322671
mintasklist.exe             1892 N/A       30138456

File list doesn't work.

memory statistics:

Code: [Select]

memstat

34 percent of memory is in use.
There are     239 total Mbytes of physical memory.
There are     155 free  Mbytes of physical memory.
There are    1263 total Mbytes of paging file.
There are    1183 free  Mbytes of paging file.
There are    2047 total Mbytes of virtual memory.
There are    2042 free  Mbytes of virtual memory.
There are       0 free  Mbytes of extended memory.

The onboard LED project pretty much does the same other than with a built in led and it uses Sleep instead of delays.

Next I'm going to try the 16x2LCD project:
https://ms-iot.github.io/content/16x2LCD.htm

With this module I got from china for $4:
http://www.wvshare.com/product/LCD1602-3.3V-blue.htm

That I got with an assortment of parts:


I'm pretty impressed so far with what this pentium class SoC can do. The chip itself and variations go for under $20 quantity one

http://www.findchips.com/search/intel%20quark
http://www.mouser.com/Semiconductors/Integrated-Circuits-ICs/_/N-6j73k?Keyword=intel+quark&FS=True

[miguelvp]

And it also has an FTP daemon so I can (up/down)load files via FileZilla

This is the boot directory where autorun.cmd lives and you can use that to start programs automatically.

Only downside so far is that it's a full OS, so you really need to shut it down before powering off or the boot time will take longer.



Edit: to fix the image

Edit: but wait, this is windows so sure Explorer should be able to access it. And of course it does:

[miguelvp]

Next I'm going to try the 16x2LCD project:
https://ms-iot.github.io/content/16x2LCD.htm

With this module I got from china for $4:
http://www.wvshare.com/product/LCD1602-3.3V-blue.htm

So it seems their sample uses a 1602K display and I have a 1602D one, only difference is that the sparkfun one they use uses 5V and the one I have uses 3.3V

https://www.sparkfun.com/products/255

So I just need to solder the header for the breadboard, should be simple

[miguelvp]

Fail not sure if the module is not working (I doubt it) or the Gen 1 of the Galileo is not up to par for driving the LCD directly, after all the GPIOs on rev1 are driven by an I2C controller and it's not the speediest at just 230Hz.

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

Edit: although a couple of pins can go way quicker as per the response to the question on the linked message.

I guess I'll test the LCD module on a different board (like the PSoC Pioneer) to make sure it's working and then deal with the Galileo. The one that Microsoft is shipping I believe is the Gen 2

6-pin 3.3V USB TTL UART header replaces 3.5mm jack RS-232 console port for Linux debug.
New 6-pin connector mates with standard FTDI* USB serial cable (TTL-232R-3V3) and popular USB-to-Serial breakout boards.
12 GPIOs now fully native for greater speed and improved drive strength.

http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html

So time to debug this, maybe the display code doesn't initialize the chip to work in 4 bit mode correctly.

Edit: yup the timings won't match at just 230Hz

Code: [Select]

  //put the LCD into 4 bit or 8 bit mode
  if (! (_displayfunction & LCD_8BITMODE)) {
    // this is according to the hitachi HD44780 datasheet
    // figure 24, pg 46

    // we start in 8bit mode, try to set 4 bit mode
    write4bits(0x03);
    delayMicroseconds(4500); // wait min 4.1ms

    // second try
    write4bits(0x03);
    delayMicroseconds(4500); // wait min 4.1ms
   
    // third go!
    write4bits(0x03);
    delayMicroseconds(150);

    // finally, set to 4-bit interface
    write4bits(0x02);
  } else {
    // this is according to the hitachi HD44780 datasheet
    // page 45 figure 23

    // Send function set command sequence
    command(LCD_FUNCTIONSET | _displayfunction);
    delayMicroseconds(4500);  // wait more than 4.1ms

    // second try
    command(LCD_FUNCTIONSET | _displayfunction);
    delayMicroseconds(150);

    // third go
    command(LCD_FUNCTIONSET | _displayfunction);
  }

Maybe I can use all 8 data wires instead, but it wont be able to do the timings either.

[miguelvp]

So I used the full 8 bit interface and I get something out of it, but it's in the wrong character set so I think the GPIO bus speed is still affecting the initialization.

The bottom row is supposed to say:
3.1415
The top one is the number of seconds since reset and left over from Hello! (the last three characters are supposed to say "lo!"


Not sure I can do much about this, other than don't use the GPIOs for anything that needs any kind of speed other than crawl. I gotta get a Gen2 board

[amyk]

I wonder what the point of this is - it's a reasonably powerful x86 CPU, but missing most of the peripherals of a standard PC. Can you at least boot DOS and run classic games on it?

[Kjelt]

I was wondering the same thing, what is the intended endproduct?

[miguelvp]

The end product is Microsoft entering the scene. I'm just playing around with it but I don't think they'll succeed because even one minute boot time is quite a lot for an embedded device.

But for the Internet of things that you can make your device more  Internet interactive they might have something. Still the startup time is just too slow for any practical purpose, and requiring a proper shutdown is impractical as well in my opinion.

But it does bring all the code and hardware drivers available to Windows to making your own device. The Galileo even has a PCI express in the back of the board.

As for the Quark itself, it's a low power affordable pentium class SoC.

As for running old DOS games, it should be able, still unsure what their plans are, I just think they are trying to see what they can do in this share of the market.

[Kjelt]

IoT hardware in my definition is something which fits in the palm of my hand can optionally be powered by max. 4 AA batteries and  last a year on them. Devices that are everywhere and noone notices them since they blend in with their environment. What I see on this page looks more a miniature PC then a IoT candidate 
Only thing I would like windows is as a GUI device. But hey I can be wrong. For now my money is on Arm cores in ultralow power micros from ST, NXP and the sorts.

[miguelvp]

Microsoft has said that the Galileo is the first of many, so they are not just targeting that board.

Galileo Gen 2 can actually do Power over Ethernet (with a required module), and there is no reason you can't run other OS on it. I mean linux works as well. With support for and open source embeded linux distro (Yocto 1.4 Poky).

The Galileo board is totally Open Source Hardware and Software for the Intel releases.

http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html

As for the Windows On Devices dev environment is extremely easy to pick up and the vast amount of x86 code available makes it very interesting to me.

Maybe not targeted to the very small devices, but for the mid range ones, for example you could use this as the brain of some test equipment hardware. It does have a JTag header, so you can use it to program other boards maybe?

Sure there are uses for it.

[miguelvp]

Just to make sure it wasn't the display, I dusted off my PSoC 4 Pioneer kit and hooked it up. And the display works just fine in 4 bit mode.

So it seems like the Gen 1 Galileo is not too useful when a $1 chip can outpace it

And of course the Pioneer takes about 2 seconds or less to boot and display the text, not 2 minutes.



That board on the right in the breadboard is just two pots and a buzzer, I'm using one of the pots to control the backlight.

[David Hess]

The slow and long latency I/O was the killer for me.  Why would I use the Galileo when it would need an external microcontroller to handle low latency I/O anyway?  With an ARM I would be operating with just one programming environment.

[miguelvp]

The slow and long latency I/O was the killer for me.  Why would I use the Galileo when it would need an external microcontroller to handle low latency I/O anyway?  With an ARM I would be operating with just one programming environment.

FWIW Generation 2 has native I/O support, not sure on the details.
But the PCIExpress won't have any latency or I/O limit on the Gen 1 board.

[boz]

I was wondering the same thing, what is the intended endproduct?

There isn't really one, Intel has nothing suitable for simple embedded control or the Internet of things despite their marketing telling everyone it has. Their stuff rocks for high power high processing but a 393 pin, X1000 (at $10 per 1000) is never going to be a contender for my next blinky.

Also Internet of things = Connected to the Internet = All the processing power you ever need in the cloud if required... For example you could easily use a arduino and network shield to connect to the internet check and get it to light a LED when a satellite flies over

Ironically, Intel were the leader in microcontrollers in the 80's with the 8031 before ARM was a twinkle in Acorns eye..

Nice work by the way..

[Kjelt]

Intel has nothing suitable for simple embedded control or the Internet of things despite their marketing telling everyone it has.

Ironically, Intel were the leader in microcontrollers in the 80's with the 8031 before ARM was a twinkle in Acorns eye..

Yeah they really dropped that ball, not that it is a bad thing perse the Pentium processors make them enough money, just that it is sad to see that this is what they came up with trying to get back in the playing field.

[EEVblog]

Ironically, Intel were the leader in microcontrollers in the 80's with the 8031 before ARM was a twinkle in Acorns eye..

Yeah they really dropped that ball, not that it is a bad thing perse the Pentium processors make them enough money, just that it is sad to see that this is what they came up with trying to get back in the playing field.
[/quote]

It's hardly an attempt to seriously get back into the microcontroller field. It's just them leveraging their existing tech to move into a niche segment with a bit lower power and a bit lower performance.
The Arduino compatible thing is a novel approach though.
Would be interesting to see how well it runs say OpenCV.

[David Hess]

It's hardly an attempt to seriously get back into the microcontroller field. It's just them leveraging their existing tech to move into a niche segment with a bit lower power and a bit lower performance.

I believe Intel's real motivation is to prevent ARM from doing to them what Intel did to the workstation and server processor vendors.  Occupying the low end allows for a network effect and  an economy of scale which funds further development.  When Intel played this game, their R&D budget was greater (an order of magnitude greater?) than all of the competing RISC architectures combined.

[miguelvp]

Don't forget they have the atom and the Edison dev board

http://www.intel.com/content/www/us/en/do-it-yourself/edison.html?wapkw=intel+edison

Too bad they didn't go with the Quark after all, it would have been pretty awesome to have a computer in an SD card



As for OpenCV this thing doesn't have a GPU, but I guess you could put a mini PCI Express Nvidia Quadro to help with the OpenCL/OpenCV

[chickenHeadKnob]

Intel has nothing suitable for simple embedded control or the Internet of things despite their marketing telling everyone it has.

Ironically, Intel were the leader in microcontrollers in the 80's with the 8031 before ARM was a twinkle in Acorns eye..

Yeah they really dropped that ball, not that it is a bad thing perse the Pentium processors make them enough money, just that it is sad to see that this is what they came up with trying to get back in the playing field.

Intel made numerous attempts to get back into various microprocessor markets but they had low endurance and tolerance for failure. Andy Grove and management could always compare and rely on the high margin x86 gravy train.

   examples:
   

• iApx32, a real slow dud, high level object oriented CISC instruction set, Intel's "Edsel"
• 80196 non dud, 16 bit , I think this was custom designed for a Robert Bosch engine controller and then released to public
• 860 , dud but had some potential,32 bit Risc for workstation market. first silicon had some bug, quickly shit-canned
• 960 , non dud, 32 bit Risc found its way into some laser printers and such

Probably others I forgot.

[David Hess]

Intel made numerous attempts to get back into various microprocessor markets but they had low endurance and tolerance for failure. Andy Grove and management could always compare and rely on the high margin x86 gravy train.

I have read before that this was as much politics as execution.  Any alternative to x86 that became too successful could threaten x86 as well which placed severe limits on how alternatives where marketed.

[djacobow]

It's hardly an attempt to seriously get back into the microcontroller field. It's just them leveraging their existing tech to move into a niche segment with a bit lower power and a bit lower performance.
The Arduino compatible thing is a novel approach though.
Would be interesting to see how well it runs say OpenCV.

I worked for Intel in the mid 90's. I worked on 80C196 and 296 lines of 16b controllers, and was a bit involved in the i960, too. Honestly, it was a lot of fun. Later I went to work on x86 and then, very sadly, ia64. Those were a lot less fun. The projects were bigger and much more heavily managed and there was less room for creativity. With the controllers, one guy could own a module from conception to artwork. It was great.

At the time I worked on controllers, I don't think Intel thought much of the business. They division really had two missions. One was to put /something/ useful in "last years fabs" and the second was to address markets that were underserved and as result limited x86 sales. For example, the 196's saw a lot of action in hard drives. Since x86 processors and hard drives used to ship 1:1, it made sense for Intel to do what it could to help the hard drive folks, hence specialty parts.

There used to be a lot of people at Intel who would be capable of bringing a good uC to market from soup to nuts. I can't quite understand why they can't/won't do it today. Perhaps part of the reason is that it's still not a high margin business.

[djacobow]

Intel made numerous attempts to get back into various microprocessor markets but they had low endurance and tolerance for failure. Andy Grove and management could always compare and rely on the high margin x86 gravy train.

I have read before that this was as much politics as execution.  Any alternative to x86 that became too successful could threaten x86 as well which placed severe limits on how alternatives where marketed.

I think there is some truth to this. i960 was a perfectly good, reasonably straightforward 32b RISC ISA. They could have taken it places and made brainiac versions as well as simple version just like ARM does. But they killed it. I don't know where it started, but when I was at Intel, the i960 was being run out of Chandler, no Santa Clara, and that put it at yet one more disadvantage.

Later, when they settled with DEC they actually picked up StrongARM and I suspect, an architectural license, too, with which they could have made just about anything. They did develop the technology as XScale. But neither StrongARM or XScale were microcontrollers, they were processors. And of course, even that they ultimately sold to Marvell.

I wonder if part of what has kept Intel out of good controllers is lack of a good (by their standards) combined logic + flash process. In the mid-90's they were actually piggy-backing a flash and processor die in one package for awhile. It was kind of cool since they could save on ATE by having the controller and flash test each other. I'd guess most controller guys do something like that nowadays.

[djacobow]

I believe Intel's real motivation is to prevent ARM from doing to them what Intel did to the workstation and server processor vendors.  Occupying the low end allows for a network effect and  an economy of scale which funds further development.

I think this exactly right. That's the battle they are fighting, but most probably losing. If you cannot compete in the low-end, you are ultimately toast.

People forget also that Intel was not highly respected in the microprocessor business for a long time. Sure, they sold a lot of processors for a lot of money, but processor people didn't think much of those parts. It was manufacturing, volume, and x86 compatibility that gave Intel the edge, certainly not performance.

But in the end, the performance came, too, and everybody else was toast. The Pentium Pro was the first Intel part to have better integer performance than its contemporaries, and  not laughably bad FP, too. Though the RISC guys pulled ahead a few more times, at that point the game was Really Over because Intel finally had worked out a microarchitecture that could make x86 really perform.

[miguelvp]

Later, when they settled with DEC

I remember that, apparently some managers blabbed about some tech in their pentium class that happened to belong to the DEC Alpha chip and was shown to Intel at some previous time.

Pity Intel didn't keep on developing the Alpha chip after they bought it from DEC maybe purchased to settle the lawsuit. Not sure because not a lot of details were made public, or I didn't care enough at the time to find them.

[David Hess]

I wonder if part of what has kept Intel out of good controllers is lack of a good (by their standards) combined logic + flash process. In the mid-90's they were actually piggy-backing a flash and processor die in one package for awhile. It was kind of cool since they could save on ATE by having the controller and flash test each other. I'd guess most controller guys do something like that nowadays.

Focusing on high margin parts would be enough to explain Intel ignoring the low end.  I thought existing programmable microcontrollers were sacrificing logic performance to use floating gate processes which can support EPROM, EEPROM, and Flash.