DiscoHAT compatibility for devices - Raspberry Pi Forums
my apologies noob question. did read links still did not understand everything.
building discohat has eeprom on if devicetree. pcb arrive in 2 weeks , hope have eeprom code written.
program running qlc+ best open source sound , light control application small theaters (i contributing qlc+ programmer http://www.qlcplus.org). discohat access 8 gpio pins , tx. device tree eeprom used if put discohat on top of raspberry pi 40 pin connector. 26 pin connector not able see devicetree eeprom.
programming point of view need access gpio pins in same way 26-pin , 40pin raspberry pi. hope device names not change different when devicetree eeprom added.
advantage of device tree modprobe kernel modules (if any) when senses discohat?
encouraging comments or advice appreciated. hope on right track adding eeprom on discohat.
--
karri
building discohat has eeprom on if devicetree. pcb arrive in 2 weeks , hope have eeprom code written.
program running qlc+ best open source sound , light control application small theaters (i contributing qlc+ programmer http://www.qlcplus.org). discohat access 8 gpio pins , tx. device tree eeprom used if put discohat on top of raspberry pi 40 pin connector. 26 pin connector not able see devicetree eeprom.
programming point of view need access gpio pins in same way 26-pin , 40pin raspberry pi. hope device names not change different when devicetree eeprom added.
advantage of device tree modprobe kernel modules (if any) when senses discohat?
encouraging comments or advice appreciated. hope on right track adding eeprom on discohat.
--
karri
karri, have made wise decision putting eeprom on discohat (great name - that's enough blog post). means users of "plus" format pi's, including pi 2, can use hat without needing manual configuration, provided shipping kernels contain correct modules. [ requirement if want call board hat... ]
there 3 main parts hat eeprom - board id section, gpio settings blob, , device tree overlay. first self explanatory - name of board, name of manufacturer, version numbers , uuid. gpio settings blob (binary large object) more interesting; allows gpio pins configured @ stage of boot process, including drive strength - can't configured within linux. however, applications configuration unnecessary, , settings made here need duplicated in device tree configure linux environment, don't feel need put in section.
there important bit - dt overlay. hardware doesn't need features of gpio blob can configured using overlay adding "dtoverlay=<overlay-name>" config.txt file; hat eeprom makes easier users loading overlay automatically. goes overlay going depend on details of hardware, since dt (supposed be) description of hardware. miniature plot of board wiring i'd guess using i2c (aside eeprom) , gpios. usual uart txd pin connected - going drive 1 of uarts, or gpio14? if can tell me how planning drive these pins - dedicated i2c device driver module or user-space code via i2c-dev, custom module drive gpios or more user-space code using /sys/class/gpio - can advise needs go in overlay.
there 3 main parts hat eeprom - board id section, gpio settings blob, , device tree overlay. first self explanatory - name of board, name of manufacturer, version numbers , uuid. gpio settings blob (binary large object) more interesting; allows gpio pins configured @ stage of boot process, including drive strength - can't configured within linux. however, applications configuration unnecessary, , settings made here need duplicated in device tree configure linux environment, don't feel need put in section.
there important bit - dt overlay. hardware doesn't need features of gpio blob can configured using overlay adding "dtoverlay=<overlay-name>" config.txt file; hat eeprom makes easier users loading overlay automatically. goes overlay going depend on details of hardware, since dt (supposed be) description of hardware. miniature plot of board wiring i'd guess using i2c (aside eeprom) , gpios. usual uart txd pin connected - going drive 1 of uarts, or gpio14? if can tell me how planning drive these pins - dedicated i2c device driver module or user-space code via i2c-dev, custom module drive gpios or more user-space code using /sys/class/gpio - can advise needs go in overlay.
raspberrypi
Comments
Post a Comment