Grumpy Mike wrote: ShiftPlusOne wrote:
Grumpy Mike wrote:
So following that logic you should never plug anything into the GPIO pins until it has booted up.
Not sure how you got that from what I said.
Not sure how you can reach any other conclusion when you say:-
never assume any particular hardware or sotware state unless you have configured it
If if have put, say an output, on that pin, or any other pin for that matter, to be read with an input and your software will cope with it, but the OS goes and makes it into an output and pulses it before your software can get a look in then according to your philosophy you should only connect that pin after your software has started running to avoid damaging either your hardware or your Pi, possibly both.
This is not the way the rest of the computing world handles hardware I/O. If it is not fixed / can not be fixed, then you cut off the possibility of using that pin as an input. If that is the case then it better be make crystal clear.
Do you know of any other "nasties" hiding like this?
Let's examine the line of discussion here.
ShiftPlusOne makes the assertion " never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. "
This is true for all cases where auto-discovery and/or enumeration is not possible. PCI, PCIe, USB and other popular, modular interconnects all have defined methods for initial attachment and configuration of devices attached to a host bus. For a 40-way connector full of a random smattering (well, not random but may as well be for the purposes of discussion) GPIOs from a proprietary SoC there are no assumptions about bus state (other than the hardware-defined GND/3v3/5v/logic parameters) therefore we are completely free to define a cooperative probing and enumeration method.
Then you appear to conflate two issues:
So following that logic you should never plug anything into the GPIO pins until it has booted up. This somewhat conflicts with the advice your Hardware Engineers will give you, about never plugging anything into the GPIO pins when there is power on the board.
The inference is that the existence of preconfigured states, intentional or unintentional, should somehow preclude attaching hardware until after the boot process has completed and the apparent contradiction of "hotplug" on a non-hotplug connector creates a conflict.
No such conflict exists. The toggling of random GPIOs during the boot process is a bug in the bootloader. A holdover from the previous assumption of a fixed platform that will take literally five minutes of my time to fix (if Dom hasn't already done so) when I am next back in the office.
The larger perspective is the handling of the ID_SC and ID_SD pins. These were left reserved for a specific reason: such that the bootloader can probe for any attached boards and perform the duty of autoconfig such that said compliant boards "just work" (tm). There is also a reason that this specification is not yet defined: there are three (3) engineers actively involved in this design. To presume that we know all the answers is folly: we will almost certainly miss something in our analysis and therefore bake-in something inherently broken that hobbles some arbitrary use-case further down the line. The "B+ addons" forum was created with this in mind, and when we release the EEPROM specification for public comment the iterative process of deciding on a method for autoconfig of an entirely new, arbitrary interface should end up with a sane specification that avoids most of the pitfalls.
Rockets are loud.