每日彙整: 2016-11-11

樹莓派、樹莓派之學習、樹莓派之教育

樹莓派 HATs ︰ 軟體工具

僅僅一行指令，

hats/eepromutils/eepflash.sh
90 modprobe i2c_dev
91 dtoverlay i2c-gpio i2c_gpio_sda=0 i2c_gpio_scl=1

 

一段文字，

B+ ADD-ON BOARD / HAT DESIGN GUIDE

GPIO Pins

NOTE All references to GPIO numbers within this document are referring to the BCM2835 GPIOs (NOT pin numbers on the J8 GPIO header).

GPIO Configuration Sequencing

The default state for all Bank 0 pins on a Model B+ with recent firmware will be inputs with either a pull up or pull down. The default pull state can be found in the BCM2835 peripherals specificaion section 6.2 table 6-31 (see the “Pull” column). It will require positive software configuration to change the state of these pins.

The one exception to this rule is ID_SC and ID_SD. On a Model B+, GPIO0 (ID_SD) and GPIO1 (ID_SC) will be switched to ALT0 (I2C-0) mode and probed for an EEPROM. These pins will revert to inputs once the probe sequence has completed.

Videocore GPIO setup

*As of 11/03/15, this section has been (largely) implemented in firmware. Only the gpio_hysteresis, gpio_slew and back_power are currently unsupported. *

At a very early point in the boot process, either GPIOMAN (for recent firmware) or the Videocore platform code sets the initial state of GPIO pins.

Note: For legacy platform code, several defaults were hardcoded. A Pi B+ with old firmware will assume that it is a Model B and as such up to three output pins may be driven as outputs on boot. See the following section for the GPIOs that may be driven as output by default and the recommended method of designing hardware to guard against this.

After the GPIOMAN/platform code stage the VC bootloader will attempt to probe for an EEPROM attached to GPIO0 and GPIO1. If successful, a GPIO setup map (as described in the EEPROM data format) will be applied to Bank 0 pins.

Note: For newer firmware, a config.txt option exists to enable the UART on GPIO14/GPIO15 prior to booting the ARM. The EEPROM probe routine will override this behaviour if an EEPROM is found.

At this point the ARM is booted. Linux now has notional exclusive control over the settings for Bank 0 pins (except GPIO0 ALT0 and GPIO1 ALT0) from this point onward.

GPIO Requirements

GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely for board detection / identification. The only allowed connections to the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect anything else to these pins!

Raspberry Pi models A and B use some bank 0 GPIOs for board control functions and UART output:

GPIO6 -> LAN_RUN
GPIO14 -> UART_TX
GPIO16 -> STATUS_LED

If a user boots a B+ with legacy firmware these pins may get driven so an add-on board must avoid driving these, or use a current limiting resistor (or some other protection) if that is not possible. Note also that a board must not rely on the pull state of these pins during boot.

 

一張圖，

eeprom-circuit

 

與其說道盡 ID EEPROM 之諸諸種種，不如講其內藏有許多未公開的祕密。

 

比方甚麼是 dtoverlay 指令呢？最清楚之說明在

Device Trees, overlays, and parameters

3.5: Dynamic Device Tree

As of Linux 4.4, the RPi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in /proc/device-tree and can cause modules to be loaded and platform devices to be created and destroyed.

The use of the word “stack” above is important – overlays can only be added and removed at the top of the stack; changing something further down the stack requires that anything on top of it must first be removed.

There are some new commands for managing overlays:

3.5.1 The dtoverlay command

dtoverlay is a command line utility that loads and removes overlays while the system is running, as well as listing the available overlays and displaying their help information:

pi@raspberrypi:~ dtoverlay -h Usage:   dtoverlay <overlay> [<param>=<val>...]                            Add an overlay (with parameters)   dtoverlay -r [<overlay>] Remove an overlay (by name, index or the last)   dtoverlay -R [<overlay>] Remove from an overlay (by name, index or all)   dtoverlay -l             List active overlays/params   dtoverlay -a             List all overlays (marking the active)   dtoverlay -h             Show this usage message   dtoverlay -h <overlay>   Display help on an overlay   dtoverlay -h <overlay> <param>..  Or its parameters     where <overlay> is the name of an overlay or 'dtparam' for dtparams Options applicable to most variants:     -d <dir>    Specify an alternate location for the overlays                 (defaults to /boot/overlays or /flash/overlays)     -v          Verbose operation  Adding or removing overlays and parameters requires root privileges. </pre> <span style="color: #808080;">Unlike the <code>config.txt</code> equivalent, all parameters to an overlay must be included in the same command line - the <a style="color: #808080;" href="https://www.raspberrypi.org/documentation/configuration/device-tree.md#part3.5.2">dtparam</a> command is only for parameters of the base DTB.</span>  <span style="color: #808080;">Two points to note:</span> <ol> 	<li><span style="color: #808080;">Command variants that change kernel state (adding and removing things) require root privilege, so you may need to prefix the command with <code>sudo</code>.</span></li> 	<li><span style="color: #808080;">Only overlays and parameters applied at run-time can be unloaded - an overlay or parameter applied by the firmware becomes "baked in" such that it won't be listed by <code>dtoverlay</code> and can't be removed.</span></li> </ol> <h4><span style="color: #ff9900;">3.5.2 The dtparam command</span></h4> <span style="color: #808080;"><code>dtparam</code> creates an overlay that has the same effect as using a dtparam directive in <code>config.txt</code>. In usage it is largely equivalent to <code>dtoverlay</code> with an overlay name of <code>-</code>, but there are a few small differences:</span> <ol> 	<li><span style="color: #808080;"><code>dtparam</code> will list the help information for all known parameters of the base DTB. Help on the dtparam command is still available using <code>dtparam -h</code>.</span></li> 	<li><span style="color: #808080;">When indicating a parameter for removal, only index numbers can be used (not names).</span></li> </ol> <pre class="lang:default decode:true ">pi@raspberrypi:~ dtparam -h
Usage:
  dtparam                Display help on all parameters
  dtparam <param>=<val>...
                         Add an overlay (with parameters)
  dtparam -r [<idx>]     Remove an overlay (by index, or the last)
  dtparam -R [<idx>]     Remove from an overlay (by index, or all)
  dtparam -l             List active overlays/dtparams
  dtparam -a             List all overlays/dtparams (marking the active)
  dtparam -h             Show this usage message
  dtparam -h <param>...  Display help on the listed parameters
Options applicable to most variants:
    -d <dir>    Specify an alternate location for the overlays
                (defaults to /boot/overlays or /flash/overlays)
    -v          Verbose operation

Adding or removing overlays and parameters requires root privileges.

3.5.3 Guidelines for writing runtime-capable overlays

This area is poorly documented, but here are some accumulated tips:

  • The creation or deletion of a device object is triggered by a node being added or removed, or by the status of a node changing from disabled to enabled, or vice versa. Beware – the absence of a “status” property means the node is enabled.
  • Don’t create a node within a fragment that will overwrite an existing node in the base DTB – the kernel will rename the new node to make it unique. If you want to change the properties of an existing node, create a fragment that targets it.
  • ALSA doesn’t prevent its codecs and other components from being unloaded while they are in use. This can lead to kernel exceptions when an overlay is unloaded if a codec is deleted before the card using it. Experimentation found that devices are deleted in the reverse of fragment order in the overlay, so placing the node for the card after the nodes for the components allows an orderly shutdown.

3.5.4 Caveats

The loading of overlays at runtime is a recent addition to the kernel, and so far there is no accepted way to do this from userspace. By hiding the details of this mechanism behind commands the aim is to insulate users from changes in the event that a different kernel interface becomes standardised.

  • Some overlays work better at run-time than others. Parts of the Device Tree are only used at boot time – changing them using an overlay will not have any effect.
  • Applying or removing some overlays may cause unexpected behaviour, so it should be done with caution. This is one of the reasons it requires sudo.
  • Unloading the overlay for an ALSA card can stall if something is actively using ALSA – the LXPanel volume slider plugin demonstrates this effect. To enable overlays for sound cards to be removed, the lxpanelctl utility has been given two new options — alsastop and alsastart — and these are called from the auxiliary scripts dtoverlay-pre and dtoverlay-post before and after overlays are loaded or unloaded, respectively.
  • Removing an overlay will not cause a loaded module to be unloaded, but it may cause the reference count of some modules to drop to zero. Running rmmod -a twice will cause unused modules to be unloaded.
  • Overlays have to be removed in reverse order. The commands will allow you to remove an earlier one, but all the intermediate ones will be removed and re-applied, which may have unintended consequences.
  • Adding clocks under the /clocks node at run-time doesn’t cause a new clock provider to be registered, so devm_clk_get will fail for a clock created in an overlay.

3.6: Supported overlays and parameters

As it is too time-consuming to document the individual overlays here, please refer to the README file found alongside the overlay .dtbo files in /boot/overlays. It is kept up-to-date with additions and changes.

 

何謂 i2c-gpio 耶？？請參閱

隨著斗轉星移，過去曾經麻煩的事情

Bit-banged I²C kernel driver

by kadamski » Tue Apr 16, 2013 10:10 am

I’ve made a handy kernel module for everybody wanting to use bit-banged host instead (or in addition to) hardware one. It’s like a wrapper for i2c-gpio kernel built-in module that let you dynamically create and remove i2c hosts on different gpio pins. It can be handy if you experience problems with hardware i2c clock stretching or you need more i2c hosts for some reason.

The code and some instructions can be found on my github. You need a custom kernel (with CONFIG_I2C_GPIO enabled) in order to use it. It got some limited testing so it should work but of course I don’t guarantee anything.

Anybody interested in testing this?

……

也已經簡單了。

# Overlay

Name:   i2c-gpio
Info:   Adds support for software i2c controller on gpio pins
Load:   dtoverlay=i2c-gpio,<param>=<val>
Params: i2c_gpio_sda             GPIO used for I2C data (default "23")

        i2c_gpio_scl             GPIO used for I2C clock (default "24")

        i2c_gpio_delay_us        Clock delay in microseconds
                                 (default "2" = ~100kHz)

※請參考『 Linux/drivers/i2c/busses/i2c-gpio.c 』

或許我們也應從善如流，一探春花春景的耶！！

【 dtoverlay=i2c-gpio 】

使用 i2c-gpio 預設值︰ GPIO23 是 SDA ， GPIO24 為 SCL ，串接回硬體 I2C ： GPIO0 SDA ， GPIO1 SCL 。因此樹莓派上有兩個 I2C Master 。

Bit-Banging-I2C

pi@raspberrypi ~ ls /dev/i2c* -l crw-rw---- 1 root i2c 89, 1  1月 29 14:52 /dev/i2c-1 crw-rw---- 1 root i2c 89, 3  1月 29 14:52 /dev/i2c-3 pi@raspberrypi ~

都可定址 GrovePi 也。

pi@raspberrypi ~ i2cdetect -y 3      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          -- -- 05 -- -- -- -- -- -- -- -- -- --  10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  70: -- -- -- -- -- -- -- --                           pi@raspberrypi ~ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- 05 -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
pi@raspberrypi ~ </pre> ── 摘自《<a href="http://www.freesandal.org/?p=47985">W!o+ 的《小伶鼬工坊演義》︰ 一窺全豹之系統設計‧探索‧戊</a>》     因此探索者需要先安裝好軟體工具也！！  sudo apt-get install i2c-tools sudo apt-get install python-smbus sudo apt-get install python3-smbus sudo apt-get install device-tree-compiler sudo apt-get install bsdmainutils    <pre class="lang:default decode:true">pi@raspberrypi:~ cd hats/eepromutils/
pi@raspberrypi:~/hats/eepromutils more README.txt  Utilities to create, flash and dump HAT EEPROM images.  Edit eeprom_setting.txt for your particular board and run through eepmake tool, then use eepflash tool to write to attached HAT ID EEPROM  Tools available:   eepmake: Parses EEPROM text file and creates binary .eep file   eepdump: Dumps a binary .eep file as human readable text (for debug)   eepflash: Write or read .eep binary image to/from HAT EEPROM pi@raspberrypi:~/hats/eepromutils make
pi@raspberrypi:~/hats/eepromutils ls eepdump    eepflash.sh      eepmake    eeprom_settings.txt  Makefile eepdump.c  eepflash.sh.bak  eepmake.c  eeptypes.h           README.txt pi@raspberrypi:~/hats/eepromutils