First of all, since the processor hardware is different, anything which directly accesses the processor hardware, registers or assembly code won't work.
Secondly, the Galileo quark processor doesn't do PWM, so all PWM is emulated through the Cypress chip. So any thing which bypasses the supplied PWM libraries won't work.
Thirdly, GPIO is different, some of the pins are multiplexed (shared) and the libraries handle the switching of these shared resources, anything which doesn't use the supplied libraries for GPIO may not work as it may not switch the muxes.
Anything which relies on deterministic timing (ie knowing the exact number of processor cycles) will have a different, non-deterministic timing on Galileo, so may not work.
Lastly, the code produced by AVR Arduino IDE sketches is physically different from code produced by the Intel Arduino IDE, so it's not portable. Anything which relies on pre-compiled AVR code won't work. Galileo runs a Linux operating system. The 'sketches' produced are bona-fide linux executables.
I hope I have got that right!
and what they need to do to get their arduino sketches working on a galileo
As with all code porting exercises, you should examing the intent and requirments of the code, rather than trying to just adapt the code to make it work.
Figure out what it is that the code is doing, rather than how it is doing it, and then implement that on the new hardware in the most efficient manner.
Code which doesn't interact with hardware should be easy to port and may even work as-is without modification. For code which interacts with hardware you should find the way to implement the same functionality on Galileo.
Hi Spider Kenny,
I really appreciate the time that you took to explain that.
Can I ask what you mean by pre-compiled AVR code? what would that be?
If I'm not mistaken SpiderKenny means that any code that refers to AVR library for the Atmel processor will not work on Galileo since the Quark processors is a different architecture. Some libraries are easy to modify and remove the AVR header but others are not since they are referring to registers on Atmel.
In addition to what other people have written, there is also the matter of protected memory. I have run in to a few Arduino libraries that have buggy code, such as referencing NULL pointers. On an Atmel processor where there's no memory protection, referencing a NULL pointer will not have the intended effect except maybe by coincidence, but it will execute. On Galileo, which is backed by a CPU running in protected mode, running Linux, referencing memory you do not own (such as NULL, which in Linux is location 0) will generate a segmentation fault and cause your sketch to crash. So a sketch that works, or mostly works, on an Arduino device may outright fail on Galileo because of a protection fault.