Hi Frank, > On Jul 5, 2016, at 17:24 , Frank Rowand <frowand.list@xxxxxxxxx> wrote: > > On 07/05/16 01:31, Mark Brown wrote: >> On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote: >> >>> On the other hand, I have no previous detailed knowledge of the beagle >>> family. >> >> This is in no way specific to the BeagleBones, there's plenty of other >> boards out there with similar setups like the Raspberry Pi and its >> derivatives. > > Yes, absolutely. I'm just picking on the beaglebones because that is > what Pantelis has recently used for examples. (He has mentioned other > connector types and expansion boards in his presentations.) > > And we need to think beyond beaglebone, pi, arduino, and grove > type of connectors. > > Some other connectors that are obvious are pci and possibly usb. > Yes, in fact a growing number of platforms come with discoverable PCI/USB boards which provide the busses and interfaces that non-discoverable boards are plugged in. Think an i2c-bus on pci-e boards on which a number of I2C peripherals are located. The Vendor/Product IDs are the same for all these expansions boards since the h/w designers do not want to spend money on even a dip-switch or EEPROM for the IDs. > >>> - for bones with the same pinout: >>> - the pins are routed to different function blocks on the >>> SOC because different bones may have different SOCs? >>> - the different functional blocks are compatible or not? >> >> This is the general case, there will be a substantial level of >> compatibility between different base boards by virtue of the pinouts >> being the same but obviously there will be some variation in the >> specifics (and even where that exists it may not be enough to be visible >> at the DT level for the most part). That said there will doubtless be >> some plug in modules that want to rely on the specifics of a given base >> board rather than remain compatible with general users of the interface. >> > Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
