Thanks CMata_Intel, there is some good information in that link. I can also deduce most of the information out of the three main manuals, plus the MRAA sources and the like. I also like the color diagrams showing some of the pins that Fab-Lab.eu has in that document.

One of the other boards/processors I like to work with these days is the Teensy 3.1 by pjrc. One of the things I have found very useful when working with these processors as they ship a 4x6" card with each processor that color codes and shows what each IO pin does. Many pins can be used for multiple things, so it is nice to see. Also some functions can be mapped to different pins. Here is a quick and dirty picture showing what I mean:

I wish Intel would generate something like this as I always have at least one of these floating on my desk at all times.

Another option that I am thinking about and also has been suggested to me by Brendan Le Foll (MRAA) is to build a variant that uses the MRAA library and simply generate wrappers for the functions, like pinMode, digitalWrite... Might be an interesting approach, as if functionality is added to MRAA or new board definitions, the same programs could easily be adapted... Something for me to think about. One issue is that MRAA is not currently part of the Arduino IDE downloads...

Yes, as you know the mraa library needs to be imported, as you successfully did in another thread, I encourage you to keep us aware of your incoming results. Also, remember that currently we are working on new documentation so something like this could be documented in the future.

Currently I have a variant that I have built with the pin information that matches what is in MRAA. Actually it is a good exercise as I found a bug in the MRAA table, which was fixed today.

I have started to test it, but so far when I try to run simple sketches, it pretty well hangs the Edison out to dry. The Debug terminal stops working... I can normally upload new sketches, but as long as a sketch has been loaded, it is killing something. I have started to debug.

So far all of my changes were done in the Variant code, but next may need to add a call out to the main code that sets the pin mode. Will probably implement it with a function that is set as weak in the main code base, that can be replaced in the variant. It needs to change how PU resistors are handled. In the BO board, it needs to set the values in the /sys/kernel/debug/pin_debug... values... Hope to have this done in the morning and then see what else may be killing the system.

As I mentioned in the previous reply, I am starting to debug. So far some of the issues I see and am working on:

in the function:

int sysfsGpioSetDrive(unsigned int gpio, unsigned int mode)

On the Arduino board, the PU stuff is set in one place an on the breakout board it is set in a different place. The string for the Filesystem location is in the variant.h files, which is good, but the values to set are not. And for example arduino board you have "hiz" and on BO you have "nopull". I currently have modified sysfs.c to have a callout variantGpioSetDrive where in the BO case, I do it different. But thinking of redoing and instead put #defines in for the different strings and have sysfs use these. If they are not defined, have it define the default...

The more important issue I am looking at right now is how the fast_gpio works. There is a hard coded table in fast_gpio_pci.c that is defined specific to the Arduino breakout board:

static struct fgpio_pci_info fgpio_info[] = {

{ 130, GPIO_REG_OFFSET(130) }, //IO0

{ 131, GPIO_REG_OFFSET(131) }, //IO1

{ 128, GPIO_REG_OFFSET(128) }, //IO2

{ 12, GPIO_REG_OFFSET(12) }, //IO3

{ 129, GPIO_REG_OFFSET(129) }, //IO4

{ 13, GPIO_REG_OFFSET(13) }, //IO5

{ 182, GPIO_REG_OFFSET(182) }, //IO6

{ 48, GPIO_REG_OFFSET(48) }, //IO7

{ 49, GPIO_REG_OFFSET(49) }, //IO8

{ 183, GPIO_REG_OFFSET(183) }, //IO9

{ 41, GPIO_REG_OFFSET(41) }, //IO10

{ 43, GPIO_REG_OFFSET(43) }, //IO11

{ 42, GPIO_REG_OFFSET(42) }, //IO12

{ 40, GPIO_REG_OFFSET(40) }, //IO13

{ 44, GPIO_REG_OFFSET(44) }, //IO14

{ 45, GPIO_REG_OFFSET(45) }, //IO15

{ 46, GPIO_REG_OFFSET(46) }, //IO16

{ 47, GPIO_REG_OFFSET(47) }, //IO17

{ 14, GPIO_REG_OFFSET(14) }, //IO18

{ 165, GPIO_REG_OFFSET(165) } //IO19

};

First attempt may be to simply disable fast gpio in my stuff to see if that cures the issue and/or have the mapping of the common pins in my pin table. Example Pin 0 of BO board is Edison IO Pin 182, so in my table should map it to be pin 6, such that it uses that table entry. And BO board 5 is hardware pin 135, which is not in above table so disable it for now...

Next approach is to have the fast gpio init code, simply build this table, which is not hard as it is a simple mapping:

The causing the board not to want to work was caused by me trying to be agressive and do like it does for the Arduino board and initialize all pins to Input_hiz. Turns out some of those pins are important for other things, like SPI, USB, USarts... So things did not work well. Currently only initializing the same ones as the Arduino IDE did.

So now have a simple sketch running: This currently toggles logical pin 0 on and off (digitalWrite(0, HIGH))...

Currently none of them are using the fast GPIO mode, will hack on that next. May do minimal version of only those pins in hard coded table first... Or maybe I will implement the init code that will build the table instead of hard coding it...

I soldered on some male pins to the breakout stuff on the bottom of the Intel BO board. I then jumpered the SPI pins over to a breakboard, I also plugged in an Adafruit 8 pin level shifter into the breadboard. and I hooked up my Adafruit 2.8" TFT display to the other side of the the voltage level shifters. After fixing the Pin mux table and the like, I now have the graphic test program compiling using Arduino IDE and running on the display. The display hangs some of the time,but my guess is my jumpers are not always giving the greatest contacts...

I probably can not make the touch part of this display work (without more external stuff) as I believe it needs two analog inputs... Or alternatively if the processor itself has touch support (like the teensy ). But just happy got this part up and going.