The reason I ask this is because this is an issue with the Raspberry Pi, and I need to know how your board handles this situation. With the Pi, if I set the GPIO pins in the state I want in software, for example OUTPUT and in a HIGH condition, the state may or may not be retained after a reboot of the device depending on how the processor sets the default of each GPIO port at boot; I have no control over this. To make matters worse, after a reboot, some pins will be HIGH, some LOW, some INPUTS and some OUTPUTS, and this occurs before I can change it back in software in a start-up script. Even worse than that, updating the firmware can change the default state of the pins at boot without any warning. So my way around this is to only use GPIO pins that are always in a LOW and OUTPUT state at boot, severely limiting the amount of GPIO ports I can use. However, I am still at the mercy of a firmware update change. For my project it is imperative that at an absolute minimum that the state of all GPIO outputs are in a LOW condition at boot, and preferably set to be OUTPUTS if possible. Therefore I would need for the pins to either default to that state at boot or retain the setting I make in software before the reboot.
Re: State of GPIO's after reboot? In short you can have the Pins state/function pretty much how you like. IE their initial state at boot time (so persistent across reboots) as well as (to a certain extent) 'on demand' at run-time. So I don't think you'll have the same issues as you've had in the past with the rPi (if I understand correctly). Have you read this guide yet? Pages 31-34 inclusive talk about Pinmuxing (IE the initial state of the GPIO's on boot), how it works, how to set it, code examples etc. I'll do a quick summary for you which illustrates the answer to your question... No problem. Just ensure that the GPIO is in the correct array (there are three arrays, 'inputmode[]', 'outputmode_low[]' and 'outputmode_high[]'). EG you would place 'MX6QD_PAD_SD2_DAT0__GPIO_MODE' into the 'mx6qd_set_in_outputmode_low[]' array ('qd' = quad and 'dl' = dual. Ensure it isn't in one of the other arrays), rinse and repeat. Objective achieved! There are also Pin diagrams on Page 29 of that guide but you can also see this and this which might be clearer. I'm sure armed with that information, a little experimentation you'll be sorted. Report back on how you get on please, other rPi users may find it useful in a compare/contrast way.
Re: State of GPIO's after reboot? I need the same. I thik you can made a program, and run at startup. But I dont know nathing of linux LOL On IMX6 side, on DUE side, GPIO configurations is write on eeprom memory, this save the config. Waiting.. XD
Re: State of GPIO's after reboot? It also depends on how you are using the pins. If you are going to use them all from the arduino side, as arduino pins and maybe just talk serial to the Linux side then you can easily set the pins up however you want in the sketch that you load into the arduino side. As soon as you power up the board that sketch starts running very time and thus sets the pins how you want them. If you want to control them directly from the Linux side then it is as Jim said. I get what you are saying though - how can you be 100% sure that the pins aren't set output high at power up, thus commanding your add on hardware to do something at initial power up until the OS is fully loaded and your software starts running. It's an interesting question and something I hadn't really thought about until now.
Re: State of GPIO's after reboot? Well remember the UDOO is a little different to Arduino as there are two CPU's on a single board, with Pins that are 'shared' (well defined, as to which CPU gets which and in what state). This is before Linux OS gets fully loaded of course because this is thrown into the Linux Kernel. Therefore it's clear that the i.MX6 comes up first, loading the Pinmuxing settings, the SAM3X8E comes up second - It cannot be any other way. Therefore (unless there is an undiscovered bug) you can be 100% confident of consistent & known behaviour as to the state/allocation of the Pins. @Flamenawer - the UDOO Due doesn't have EEPROM and doesn't work like that due to the above reasons (IE the i.MX6 functions as the EEPROM for configuration of the SAM3X8E in this regard).
Re: State of GPIO's after reboot? I would be controlling the GPIO pins from the Linux side. Unless I am missing it in the documentation, I don't see anywhere in writing where the GPIO pin state would be persistent at re-boot. My current completed project is a fireworks launcher that I am considering upgrading to an UDOO, and I do take additional safety precautions, but you can understand my concern of the GPIO state. If someone could verify this with an actual UDOO it would be helpful.
Re: State of GPIO's after reboot? EDIT: Lifeboat_Jim. Am I reading your statement as I would have to set up the pins on the Arduino side so it boots in the proper state, and then set them again on the Linux side as appropriate?
Re: State of GPIO's after reboot? You know, I think we need somebody to actually test this to know 100% for sure... A simple LED setup on all the pins would go a long way towards knowing for sure, (at least if they're set to output) but alas I don't have any of my electronics gear right now to be able to set that up to try.
Re: State of GPIO's after reboot? No, the penny hasn't dropped for you yet on this topic. The i.MX6 on boot up (IE the Kernel) will load a file (as previously described) that defines what each Pin function is (the Pinmux, as Pins have multiple possible functions) AND what state (input/output, high/low etc). This is for ALL pins, across the whole board. The SAM3X8E (Arduino Due) inherits these functions and the initial state. At run time you can alter the state of a pin, but not it's function. Come on to our IRC channel if it still isn't clear and I'll explain in a different way. No, if you do it at boot time you don't need to do it again UNLESS you want to change the state behaviour dynamically during run time. If you do change the state you need to be very careful not to have both sides of the board pulling in different directions IE if the i.MX6 sets a Pin for Output then the SAM3X8E cannot set the same pin for Output also (of course both CPU's can read the Pin... that's fine)
Re: State of GPIO's after reboot? That sounds like it would do the trick, and as you said, the GPIO pins will be in whatever state I set up in that file, and consistent across boots, and in that state immediately upon plugging in the UDOO, and would be in that state on the Linux side throughout the loading of the OS and my program. When you say that you can not alter the function at runtime, I assume you are referring to GPIO, SPI, etc. as being the function and OUTPUT, INPUT, LOW or HIGH as being various states; that would also be understandable. On the Pi I can change OUTPUT, INPUT, LOW or HIGH at any time in my code; I would hope I could do that on the Linux side of the UDOO as well.
Re: State of GPIO's after reboot? You've got it! :-D Yes, the Function (such as GPIO, SPI, SPDIF, I2C etc) of a Pin and the State (IE Input, Output_High, Output_Low) of it are separate things. Note: Function & State are my terms... I haven't gone looking for the official terms, possibly the same. To read Direction & Value of a GPIO (on the i.MX6 Linux side) use 'cat /sys/class/gpio/gpioXX/direction' & 'cat /sys/class/gpio/gpioXX/value'. Not sure how to read the Function of a Pin without digging deeper though (that would be useful I think - could always parse the Config file of course). Some custom code on both the i.MX6 & SAM3X8E to push/receive those directions & values if you needed to know the boot up scenario perhaps? Yes, that's easy.... echo out > /sys/class/gpio/gpioXX/direction echo 0 > /sys/class/gpio/gpioXX/value (see page 28 of the Guide)
Re: State of GPIO's after reboot? Thanks for all that. At this point I have to do some reading and following of the forum to learn more about the device. I suspect that eventually someone will create a "C" library to talk directly to the hardware as things mature.
Re: State of GPIO's after reboot? Glad you're happy. If you could put [Solved] at the start of the thread title... may be helpful to others in future and draw a line under this.
No, I am waiting a few months to see how it works out reliability and functionality wise. I would also have to see much more support in the way of software libraries to support the devices various functions, much greater forum participation, troubleshooting fixes, etc. I would also probably wait for a rev 2 product after the hardware glitches get fixed. I have been through this once with the raspberry pi, so someone else's turn this time.
