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.

[David Hess]

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.

Alpha had its own set of ISA warts so I am not convinced it would have made any difference over the long term.

[Rigby]

I'm not sure what Intel has to do with any of this.  Intel has always made processors, and Intel will always make processors.  The existence of the Quark has little to do with Arduino or anything else other than Intel seeing a market segment, doing some research, and discovering that there is room for something there.  Then, they either buy a company that's already there or they make a new CPU.

Employees don't start off developing i7 processors; they work on the smaller stuff and if they've got the right stuff they move up.  These low-end, low-performance devices are testbeds for employees and for designs.

It's Microsoft that's expanding out into new areas here, not Intel.  Sure, Intel has some new development boards, but they've always had SOME development boards kicking about.  Now they're getting somewhat serious about the low-end (which is new) and Microsoft is supporting that low-end hardware with real, honest-to-goodness operating systems (which is also new.)

The Minnowboard Max and the Sharks Cove boards are kind of where it's going to be for low-end embedded Windows development for the next few months, NOT the Galileo nor the Galileo Gen2 (neither of which make a lot of sense to me.)  The Minnowboard Max especially looks interesting, given the CPU and memory available, and the Sharks Cove will be very interesting to Windows hardware developers who need IO.

[Stonent]

So this is running Windows 6.3.9600 which is Windows 8.1 Update 1 or Server 2012 R2 Update 1.

I recently installed a VM of Microsoft Hyper V 2012 R2 core which boots up like windows but drops you to a powershell prompt when you log in.

At least the Hyper V server uses about 400MB of RAM when it is idle, but it is running some services, this probably is much less, but the fact remains it is windows so there should be a way to install applications on it and get them to display somewhere.

[djacobow]

Intel has always made processors, and Intel will always make processors. 

This is definitely not true. Andy Grove wrote a whole book (Only the Paranoid Survive) about converting Intel from a memory company to a processor company. The fact is, Intel once completely changed its business as a result of getting absolutely creamed in its existing memory business. It was a risky, and spectacularly successful change. Nobody knows if they've got the cajones to do it again, if, say, they realize that high margin desktop processors are becoming an endangered species.

Employees don't start off developing i7 processors; they work on the smaller stuff and if they've got the right stuff they move up. 

Eh, trueish, but there have definitely been times when junior engineers are put on big, major projects, usually with the idea that with guidance and good management they can still make a contribution. I remember one such project: Merced, the first IA64 part. It had hundreds of engineers on it, and many were fresh NCGs. I left shortly after, but perhaps from that fiasco they learned that wasn't such a great idea. However, IMHO, it wasn't junior engineers that sunk that ship, but an inability to manage such a large team along with a few dubious technical decisions (like the way they did x86 compatibility). Personally, I had worked on 1 1/2 "small" projects before my first involvement with a top-line x86 project, though on the latter I was doing pretty menial stuff to start (fault grading).

[Rigby]

The infrastructure required to remote admin or remote desktop into a Galileo isn't present, and we don't have the source to compile it.

The MinnowBoard MAX and Sharks Cove are what you're after if you want full desktop-like stuff.

[Stonent]

The infrastructure required to remote admin or remote desktop into a Galileo isn't present, and we don't have the source to compile it.

The MinnowBoard MAX and Sharks Cove are what you're after if you want full desktop-like stuff.

It should all be about just modifying the registry and including the missing files.

[Rigby]

It should all be about just modifying the registry and including the missing files.

If the Quark had all the CPU features that the binaries you copy over require, I would agree.  Alas, the Quark doesn't have a lot of things that have been standard in desktop & laptop CPUs for over a decade.  The Quark has no SIMD (MMX, SSE, etc.) instructions at all, and I doubt you'll find any modern Windows core stuff compiled without the need for those.

I would love to be proven wrong on this.

[David Hess]

The Quark has no SIMD (MMX, SSE, etc.) instructions at all, and I doubt you'll find any modern Windows core stuff compiled without the need for those.

I have run across an increasing number of applications and libraries which test for and require instruction extensions that they do not need so they cannot be used on older (but not that much older) Intel processors.

[Rory]

Waiting for mine to show up, I'd like to try adapting some Powerbasic apps to the Quark.

[Rigby]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

[coppice]

Intel has always made processors, and Intel will always make processors. 

This is definitely not true. Andy Grove wrote a whole book (Only the Paranoid Survive) about converting Intel from a memory company to a processor company. The fact is, Intel once completely changed its business as a result of getting absolutely creamed in its existing memory business. It was a risky, and spectacularly successful change. Nobody knows if they've got the cajones to do it again, if, say, they realize that high margin desktop processors are becoming an endangered species.

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers. 

[David Hess]

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

One of Grove's points in his book that it was not luck.  They saw what was going to happen in the memory market and made a deliberate choice to move while they were strong without knowing where they were going.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers.

There would not have been an 8086 PC business to drift except they agreed to license second sources at IBM's insistence.

[coppice]

Intel was the DRAM and EPROM company before it was the processor company. Then MOSTEK and the Japanese trashed their memory business, and they were lucky to make it through the transition to processors before the cash ran out.

One of Grove's points in his book that it was not luck.  They saw what was going to happen in the memory market and made a deliberate choice to move while they were strong without knowing where they were going.

Andy Grove saw that they were going to screw up DRAM technology, and produce junk nobody wanted, while the Japanese would invest in solving the problems and whip their asses? Interesting admission. The fact that many industry watchers where expecting them to go bankrupt doesn't really support the idea that their survival was not mostly luck.

Its interesting how history gets revised in such a short period. If you look up the 64k and 256k DRAM generations on the web you will find lots of stuff about the Japanese winning by dumping below cost. I remember when people like HP declared they would only use Japanese DRAM, as the American stuff prevented them offering meaningful SLAs to their computer customers. Cost is always an important factor, but it was reliability issues that let the Japanese win that time around.

Even in the mid 80s, when the IBM PC and its clones were already a big hit, Intel was on its knees. They couldn't get CMOS to work, and the 8086 business started drifting to their second sources, like AMD and Harris, who had really good CMOS processes. I think the company was eventually saved by its lawyers.

There would not have been an 8086 PC business to drift except they agreed to license second sources at IBM's insistence.

In those days you *had* to have second sources, or people wouldn't design your parts into anything strategic. Motorola and Intel both courted second sources for that reason. Intel also needed access to someone's CMOS processes, too. Motorola only needed second sources.

[miguelvp]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

I thought MMX and SSE were oriented for video and 3d, maybe some dsp can get gains from it too but not a show stopper.

[coppice]

A software author that does not use SSE or MMX instructions when they compile is unnecessarily crippling the performance of their program.

Seems that it would be someone in bed with Intel if you're right.

Can you name any examples?

I thought MMX and SSE were oriented for video and 3d, maybe some dsp can get gains from it too but not a show stopper.

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

[David Hess]

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

You should read one of the rants from Linus Torvalds on the subject of optimizations and SSE versus REP MOVSB memory copies.

[coppice]

Modern systems do all sorts of things with SSE. All floating point calculations are typically done with SSE, but much less obvious things, like memcpy() and memset(), use SSE. It turns out to be the fastest solution for various things, as you most 128 bits or 256 bits around for each operation.

You should read one of the rants from Linus Torvalds on the subject of optimizations and SSE versus REP MOVSB memory copies.

I know about that. The x86 processors of the last 2 or 3 years have finally made REP MOVSB perform well, but it used to perform really badly, and lead to the implementation of SSE based copying. I expect the standard memcpy will move back from SSE to a simple rep movsb, but the software is always waaaaaay behind the hardware.