For a test I deleted the sketch that starts up, as while it starts it sets the digital pin 9 to Output, when the sketch does that is also makes the Pin high, vs. being set to low, which means that there is a momentary high before my code sets it low! This is a problem, as it turns on the motor on that port briefly, changing the position.
I connected to the linux terminal, and set up the digital output in /sys/class/gpio/gpio19 using instructions found here:
the minute I switch the port to Output , the pin goes high, then I can set the drive type, "strong", "hiz", etc.
but it initializes with a high bit when GPIO for that pin is set to output
I'm running the Yocto 3.8.7-yocto-standard, I built it following the Intel instructions here:
That’s interesting, I am going to take a look at it if I found something useful I’ll let you know.
iSimon & JPM,
Since I don't have a Galileo Board to test this on,
all that follows may be wrong. But ...
The data sheet for the Cypress CY8C9540A
would appear to suggest why "the pin",
which presumably is at J1B1:8, goes HI
For the data sheet says:
The Output Port Registers (08h - 0Fh)
... are used for writing data to GPIO ports.
By default, all [these] ports are in pull-up mode.
Why this glitch also occurs when the system is reinitialized
might be answered by probing the XRES Pin of the CY8C9540A (U8:35).
If that goes HI during system reinitialization, the "ports"
ware being put back in "pull up mode allowing quasi-bidirectional I/O."
You _may_ be able to change this default behavior by tweaking
the data in the chip's EEPROM. See Cypress AN2304. But before
I started down _that_ rabbit path, I'd try putting
a weak pulldown resistor on J1B1:8 if I had a board to "play" with.
What I initially thought was a issue with a reboot process happened because on reboot it was loading my Arduino sketch, where I initialize the port to set it as an output port, and then write a 0 to the port to be on the safe side.
What I noticed was that the port is going high during the initialization of the port to an output, from the in state, while in the in State it may very well pull up to a High by default, and this is settable in the EEPROM of the Cypress chip. Though the issue is that when the port switches from input to output that the bit is by default set high.
I deleted the sketch and when I reboot the board, the pin doesn't go high, as I found by querying the Cypress chip through the sysfs file system that its actually set to the HiZ state.
Then I started doing the experiments from the linux command line:
// go to directory in SysFS file system:
// initialize gpio28 in SysFS
echo -n "28" > export
// enter newly created gpio28 SysFS entry:
There you find the following contents of /sys/class/gpio/gpio28 :
active_low drive power/ uevent
direction edge subsystem@ value
You can look at the default state of the values by doing the following:
// look at default value
// look at direction before setting it:
*Note: Apparently we can't yet query what drive is set to, so we don't know which HiZ state it's set to yet.
// set the port so we can output to it:
echo -n "out" > direction
*Note: Now we actually find that the bit has been set to 1 on the physical port!
Here is where it gets really interesting:
// set value to 0
echo -n "1" > value
// port is now set to 0
echo -n "in" direction
// *Note: The port still remains at 0, or in a HiZ state, but def. not a 5V logic 1 signal.
// *** This is where things start getting weird, now we will find that value is set to 1 when the port is in Input mode
// *** Switching back to Output mode even though value is set to 1 doesn't go high on the next setting of direction to Out!
echo -n "out" > direction
I think something in the state machine in the driver for the port has an issue / error happening; or at least something in the logic isn't right.
I'm having the same problem and a 10K pulldown did not help. Please let us know what you find out! Thanks.
I may decide to add not gates and go to negative logic but that will be tough to fit on my tiny little shield.
The pins will take on whatever value was last send / stored on the card for example if all the pins were low when you shut the Intel down they will be low when you boot. I beleive it's just a /sys/class/gpio/gpioPIN/value read.