+1 for Gerald's "Add it to the cape" sentiment. ...and actually, given today's near zero-load CMOS inputs, having an assortment of I/O with pull-up and pull-down configured at reset makes it possible to directly tie GPIO pins to important signals (like chip selects or output enables) without having to add hardware inverters. I made good use of this capability (and the assortment of AM335x ball reset states) when designing the CRAMPS board, but it does take some planning and quite a bit of care to not mess anything up. :)
On 9/8/2015 12:14 PM, Gerald Coley wrote: > Definitely can add a lot of parts around it. Then again the board would > cost more and everyone would pay for that feature, whiter they used it or > not.. > > It would be less expensive to just add it to the cape on an add needed > basis and not on every single pin. > > Gerald > > On Tue, Sep 8, 2015 at 12:02 PM, rattus <[email protected]> wrote: > >> Completely understood; however, assuming one could meet board area and >> timing constraints, it might be possible to wrap the processor with a >> circuit prophylactic, as it were... >> >> I've also been part of several ARM-based core silicon projects, and it >> would have been possible for that (i.e. consistent pre-reset I/O state) to >> have been addressed at the chip level. >> >> Mike >> >> On Tuesday, September 8, 2015 at 5:56:32 AM UTC-6, Gerald wrote: >>> >>> I/O pin functionality is a function of the processor. Not the board. >>> >>> Gerald >>> >>> On Mon, Sep 7, 2015 at 10:05 PM, rattus <[email protected]> wrote: >>> >>>> On Monday, September 7, 2015 at 6:52:12 PM UTC-6, Graham wrote: >>>>> >>>>> Well, by definition, the boot programming pins are going to have the >>>>> pull-ups / pull-downs, so you know what they are going to be doing, until >>>>> over-ridden. >>>>> >>>>> Most processors start up with the programmable pins as inputs, then >>>>> move to the configured state. >>>>> >>>> >>>> If it were so... but it seems with such an abundance of modes and pins, >>>> a number of the pins I am using are in a variety if input, output, hi-Z and >>>> I/O defaults at powerup, most often with pullup or pull-downs. The good >>>> news is, I've added enough gating and the additional fast-starting Vdd to >>>> avoid conflicts. SPI attached peripherals (powered early) all need commands >>>> shifted in to drive outputs, so that's safe too. >>>> >>>> Now for the *next* Beaglebone, innocuous I/Os would be a great feature... >>>> >>>> Anything else can be dangerous to the pins. But, as Charles says, RTFM. >>>>> >>>> >>>>> If you are concerned, use the bus-isolation /transmission-gate chips, >>>>> power them early, supply your own pull-ups/pull-downs, and switch the >>>>> connection on when SYS_RESETn goes high. Then you are unconditionally >>>>> safe, and in-control. >>>>> >>>>> --- Graham >>>>> >>>> >>>> Thanks, >>>> >>>> Mike >>>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- Charles Steinkuehler [email protected] -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
