Intel Quark SoC running Windows IoT on Intel Galileo (rev 1) - Page 1
Forum section: electronics / general

author: miguelvp
author_rank: Super Contributor
timestamp: August 24, 2014, 08:43:31 pm
content: 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.htmYou 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/#msg500527The 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 machineActually 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.htmAs 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.htmYesterday 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 templatehttps://ms-iot.github.io/content/HelloBlinky.htmand 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:// 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 consolevoid CustomLogging(char* str){OutputDebugStringA(str); // for VS Outputprintf(str); // for commandline output}int _tmain(int argc, _TCHAR* argv[]){return RunArduinoSketch();}void setup(){// TODO: Add your code hereCustomLogging("Hello Blinky!\n");// initialize the digital pin as an output.pinMode(led, OUTPUT);}void loop(){// TODO: Add your code hereCustomLogging("LED ON\n");digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)delay(1000); // wait for a secondCustomLogging("LED OFF\n");digitalWrite(led, LOW); // turn the LED off by making the voltage LOWdelay(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://// 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 Timestampmov 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:C:\windows\system32>tlist -v0 32 0 System ProcessCommand Line:0 32 4 SystemCommand Line:0 32 180 smss.exeCommand Line:0 32 260 csrss.exeCommand Line: 0 32 288 wininit.exeCommand Line: wininit.exe1 32 296 csrss.exeCommand Line: 1 32 312 winlogon.exeCommand Line: winlogon.exe0 32 332 services.exeCommand Line: 0 32 344 lsass.exe Svcs: SamSsCommand Line: C:\windows\system32\lsass.exe 0 32 420 svchost.exe Svcs: BrokerInfrastructure,DcomLaunch,Power,SystemEventsBrokerCommand Line: C:\windows\system32\svchost.exe -k DcomLaunch 0 32 456 svchost.exe Svcs: RpcEptMapper,RpcSsCommand Line: C:\windows\system32\svchost.exe -k RPCSS 0 32 536 svchost.exe Svcs: LanmanServer,ProfSvc,UsertokenCommand Line: C:\windows\system32\svchost.exe -k netsvcs 0 32 564 svchost.exe Svcs: Dhcp,lmhostsCommand Line: C:\windows\System32\svchost.exe -k LocalServiceNetworkRestricted 0 32 580 svchost.exe Svcs: nsiCommand Line: C:\windows\system32\svchost.exe -k LocalService 0 32 604 svchost.exe Svcs: CryptSvc,Dnscache,LanmanWorkstationCommand Line: C:\windows\system32\svchost.exe -k NetworkService 0 32 692 svchost.exe Svcs: BootshCommand Line: C:\windows\system32\svchost.exe -k Bootshsvc 0 32 708 svchost.exe Svcs: CoreUIRegistrarCommand Line: C:\windows\system32\svchost.exe -k CoreUI 0 32 744 cmd.exeCommand Line: C:\windows\system32\cmd.exe /K C:\Windows\System32\Boot\synctime.cmd 0 32 752 msvsmon.exeCommand Line: C:\Tools\RemoteDebugger\msvsmon.exe /silent /nostatus /nosecuritywarn /nofirewallwarn /noclrwarn 0 32 760 Galileo_eboot.exeCommand Line: C:\Windows\System32\Galileo_eboot.exe 0 32 776 httpsrv.exeCommand Line: httpsrv.exe http://+:80/ 0 32 784 ftpd.exeCommand Line: ftpd.exe 0 32 792 telnetd.exeCommand Line: telnetd.exe "logonuitext -c cmd.exe" 23 0 32 800 mwstartnet.exeCommand Line: mwstartnet.exe 0 32 844 msvsmon.exeCommand Line: C:\Tools\RemoteDebugger\msvsmon.exe /CHILDSERVER f8 "+:4018" {D3C4A7EE-BF0A-4DFA-A528-37F82D32C36D} 0x0 f4 ec e8 f0 /silent+ /servicemode- 0 32 924 cmd.exeCommand Line: cmd.exe 0 32 1084 tlist.exeCommand Line: tlist -vIt does have an http server running and this is what it shows:Code:Test Web server running on MinWintask listfile listmemory statisticsTask list:Code:mintasklistImage Name PID Services========================= ====== =============================================System Idle Process 0 N/ASystem 4 N/Aunknown 180 N/Aunknown 260 N/Awininit.exe 288 N/A 142439165unknown 296 N/Awinlogon.exe 312 N/A 946704075unknown 332 N/Alsass.exe 344 N/A 3688591984svchost.exe 420 N/A 728549736svchost.exe 456 N/A 240216553svchost.exe 536 N/A 299939892svchost.exe 564 N/A 534471125svchost.exe 580 N/A 70027273svchost.exe 604 N/A 317419388svchost.exe 692 N/A 59986282svchost.exe 708 N/A 47981723cmd.exe 744 N/A 69157825msvsmon.exe 752 N/A 667937796Galileo_eboot.exe 760 N/A 2899972115httpsrv.exe 776 N/A 75800204ftpd.exe 784 N/A 30306579telnetd.exe 792 N/A 374316189mwstartnet.exe 800 N/A 61796899msvsmon.exe 844 N/A 124821234cmd.exe 924 N/A 113322671mintasklist.exe 1892 N/A 30138456File list doesn't work.memory statistics:Code:memstat34 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.htmWith this module I got from china for $4:http://www.wvshare.com/product/LCD1602-3.3V-blue.htmThat 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 onehttp://www.findchips.com/search/intel%20quarkhttp://www.mouser.com/Semiconductors/Integrated-Circuits-ICs/_/N-6j73k?Keyword=intel+quark&FS=True

author: miguelvp
author_rank: Super Contributor
timestamp: August 24, 2014, 10:11:33 pm
content: And it also has an FTP daemon so I can (up/down)load files via FileZillaThis 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 imageEdit: but wait, this is windows so sure Explorer should be able to access it. And of course it does:

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 12:29:39 am
content: Quote from: miguelvp on August 24, 2014, 08:43:31 pmSo 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.3Vhttps://www.sparkfun.com/products/255So I just need to solder the header for the breadboard, should be simple

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 02:47:38 am
content: Failnot 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 just230Hz.https://communities.intel.com/message/207904Edit: 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 2Quotehttp://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.htmlSo 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 230HzCode://put the LCD into 4 bit or 8 bit modeif (! (_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 modewrite4bits(0x03);delayMicroseconds(4500); // wait min 4.1ms// second trywrite4bits(0x03);delayMicroseconds(4500); // wait min 4.1ms// third go!write4bits(0x03);delayMicroseconds(150);// finally, set to 4-bit interfacewrite4bits(0x02);} else {// this is according to the hitachi HD44780 datasheet// page 45 figure 23// Send function set command sequencecommand(LCD_FUNCTIONSET | _displayfunction);delayMicroseconds(4500); // wait more than 4.1ms// second trycommand(LCD_FUNCTIONSET | _displayfunction);delayMicroseconds(150);// third gocommand(LCD_FUNCTIONSET | _displayfunction);}Maybe I can use all 8 data wires instead, but it wont be able to do the timings either.

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 03:46:46 am
content: 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.1415The 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

author: amyk
author_rank: Super Contributor
timestamp: August 25, 2014, 12:23:15 pm
content: 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?

author: Kjelt
author_rank: Super Contributor
timestamp: August 25, 2014, 01:08:48 pm
content: I was wondering the same thing, what is the intended endproduct?

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 02:46:10 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: August 25, 2014, 03:09:26 pm
content: 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 candidateOnly 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.

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 03:59:00 pm
content: 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.htmlAs 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.

author: miguelvp
author_rank: Super Contributor
timestamp: August 27, 2014, 01:08:56 am
content: 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 itAnd 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.

author: David Hess
author_rank: Super Contributor
timestamp: August 27, 2014, 04:32:01 pm
content: 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.

author: miguelvp
author_rank: Super Contributor
timestamp: August 27, 2014, 04:54:39 pm
content: Quote from: David Hess on August 27, 2014, 04:32:01 pmFWIW 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.

author: boz
author_rank: Regular Contributor
timestamp: August 28, 2014, 04:39:43 am
content: Quote from: Kjelt on August 25, 2014, 01:08:48 pmThere 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 overIronically, 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..

author: Kjelt
author_rank: Super Contributor
timestamp: August 28, 2014, 10:35:54 am
content: Quote from: boz on August 28, 2014, 04:39:43 amYeah 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.

author: EEVblog
author_rank: Unknown
timestamp: August 28, 2014, 12:11:47 pm
content: Quote from: Kjelt on August 28, 2014, 10:35:54 amYeah 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.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.

author: David Hess
author_rank: Super Contributor
timestamp: August 28, 2014, 02:11:31 pm
content: Quote from: EEVblog on August 28, 2014, 12:11:47 pmI 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.

author: miguelvp
author_rank: Super Contributor
timestamp: August 28, 2014, 04:03:20 pm
content: Don't forget they have the atom and the Edison dev boardhttp://www.intel.com/content/www/us/en/do-it-yourself/edison.html?wapkw=intel+edisonToo bad they didn't go with the Quark after all, it would have been pretty awesome to have a computer in an SD cardAs 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

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 29, 2014, 02:12:53 am
content: Quote from: Kjelt on August 28, 2014, 10:35:54 amIntel 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 public860 , dud but had some potential,32 bit Risc for workstation market. first silicon had some bug, quickly shit-canned960 , non dud, 32 bit Risc found its way into some laser printers and suchProbably others I forgot.

author: David Hess
author_rank: Super Contributor
timestamp: August 29, 2014, 03:49:46 am
content: Quote from: chickenHeadKnob on August 29, 2014, 02:12:53 amI 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.

author: djacobow
author_rank: Super Contributor
timestamp: August 29, 2014, 06:35:44 pm
content: Quote from: EEVblog on August 28, 2014, 12:11:47 pmI 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.

author: djacobow
author_rank: Super Contributor
timestamp: August 29, 2014, 06:48:56 pm
content: Quote from: David Hess on August 29, 2014, 03:49:46 amI 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.

author: djacobow
author_rank: Super Contributor
timestamp: August 29, 2014, 07:02:43 pm
content: Quote from: David Hess on August 28, 2014, 02:11:31 pmI 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.

author: miguelvp
author_rank: Super Contributor
timestamp: August 29, 2014, 07:11:58 pm
content: Quote from: djacobow on August 29, 2014, 06:48:56 pmI 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.

author: David Hess
author_rank: Super Contributor
timestamp: August 29, 2014, 08:20:39 pm
content: Quote from: djacobow on August 29, 2014, 06:48:56 pmFocusing 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.

author: David Hess
author_rank: Super Contributor
timestamp: August 29, 2014, 08:23:14 pm
content: Quote from: miguelvp on August 29, 2014, 07:11:58 pmAlpha had its own set of ISA warts so I am not convinced it would have made any difference over the long term.

author: Rigby
author_rank: Super Contributor
timestamp: September 03, 2014, 01:06:38 am
content: 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.) TheMinnowboard Maxespecially looks interesting, given the CPU and memory available, and theSharks Covewill be very interesting to Windows hardware developers who need IO.

author: Stonent
author_rank: Super Contributor
timestamp: September 03, 2014, 01:35:19 am
content: 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.

author: djacobow
author_rank: Super Contributor
timestamp: September 03, 2014, 02:17:23 am
content: Quote from: Rigby on September 03, 2014, 01:06:38 amThis 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.Quote from: Rigby on September 03, 2014, 01:06:38 amEh, 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).

author: Rigby
author_rank: Super Contributor
timestamp: September 03, 2014, 02:17:54 am
content: 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.

author: Stonent
author_rank: Super Contributor
timestamp: September 03, 2014, 07:04:11 am
content: Quote from: Rigby on September 03, 2014, 02:17:54 amIt should all be about just modifying the registry and including the missing files.

author: Rigby
author_rank: Super Contributor
timestamp: September 03, 2014, 12:55:04 pm
content: Quote from: Stonent on September 03, 2014, 07:04:11 amIf 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.

author: David Hess
author_rank: Super Contributor
timestamp: September 03, 2014, 05:13:20 pm
content: Quote from: Rigby on September 03, 2014, 12:55:04 pmI 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.

author: Rory
author_rank: Frequent Contributor
timestamp: September 03, 2014, 05:44:04 pm
content: Waiting for mine to show up, I'd like to try adapting some Powerbasic apps to the Quark.

author: Rigby
author_rank: Super Contributor
timestamp: September 04, 2014, 01:17:48 am
content: 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?

author: coppice
author_rank: Super Contributor
timestamp: September 04, 2014, 01:39:24 am
content: Quote from: djacobow on September 03, 2014, 02:17:23 amIntel 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.

author: David Hess
author_rank: Super Contributor
timestamp: September 04, 2014, 02:56:08 am
content: Quote from: coppice on September 04, 2014, 01:39:24 amOne 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.QuoteThere would not have been an 8086 PC business to drift except they agreed to license second sources at IBM's insistence.

author: coppice
author_rank: Super Contributor
timestamp: September 04, 2014, 03:16:40 am
content: Quote from: David Hess on September 04, 2014, 02:56:08 amAndy 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.Quote from: David Hess on September 04, 2014, 02:56:08 amIn 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.

author: miguelvp
author_rank: Super Contributor
timestamp: September 04, 2014, 04:13:26 am
content: Quote from: Rigby on September 04, 2014, 01:17:48 amI thought MMX and SSE were oriented for video and 3d, maybe some dsp can get gains from it too but not a show stopper.

author: coppice
author_rank: Super Contributor
timestamp: September 04, 2014, 04:17:15 am
content: Quote from: miguelvp on September 04, 2014, 04:13:26 amModern 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.

author: David Hess
author_rank: Super Contributor
timestamp: September 04, 2014, 09:54:56 am
content: Quote from: coppice on September 04, 2014, 04:17:15 amYou should read one of the rants from Linus Torvalds on the subject of optimizations and SSE versus REP MOVSB memory copies.

author: coppice
author_rank: Super Contributor
timestamp: September 04, 2014, 10:27:32 am
content: Quote from: David Hess on September 04, 2014, 09:54:56 amI 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.