pmbus

pmbus在avr32开发板平台上tiny24中的实现。

#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 2008-04-25 11:23 PDT by <db@ascent>.
# Source directory was `/root32/home/db/avr/usi_slave'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#   9036 -rw-r--r-- README
#  35147 -rw-r--r-- COPYING
#   1569 -rw-r--r-- Makefile
#  11893 -rw-r--r-- main.c
#  19306 -rw-r--r-- pmbus.c
#  16452 -rw-r--r-- usi_i2c_slave.c
#   3321 -rw-r--r-- usi_i2c_slave.h
#   1722 -rw-r--r-- smbus_glue.h
#   2849 -rw-r--r-- prod_misc.h
#  52083 -rw-r--r-- pmbus_peek.c
#  16515 -rwxr-xr-x pmbus_slave.elf
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
if touch -am -t 200112312359.59 $$.touch >/dev/null 2>&1 && test ! -f 200112312359.59 -a -f $$.touch; then
  shar_touch='touch -am -t $1$2$3$4$5$6.$7 "$8"'
elif touch -am 123123592001.59 $$.touch >/dev/null 2>&1 && test ! -f 123123592001.59 -a ! -f 123123592001.5 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$1$2.$7 "$8"'
elif touch -am 1231235901 $$.touch >/dev/null 2>&1 && test ! -f 1231235901 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$2 "$8"'
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 200112312359.59 123123592001.59 123123592001.5 1231235901 $$.touch
#
if mkdir _sh01132; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= README ==============
if test -f 'README' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'README' '(file already exists)'
else
  $echo 'x -' extracting 'README' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'README' &&
WHAT IS THIS?
X
X	This is PMBus 1.1 [0] software intended to replace the firmware found
X	in the "Board Controller" [1] on the Atmel ATNGW100 [2], which is a
X	low cost ($US 90) Linux-oriented board suitable for developing and
X	deploying AVR32 based embedded systems.  This firmware can go into
X	an ATtiny24 microcontroller which is found on that board, but which
X	is not currently used for anything of note.
X
X	This is licensed under GNU GPLv3.  The distribution files include
X
X		README -- what you're reading
X		COPYING -- copy of GPLv3
X		Makefile -- to build under Linux
X		pmbus_slave.elf -- pre-built binary
X		pmbus_peek.c -- userspace tool talking to the firmware
X
X	Plus of course the source code with the I2C/PMBus protocol code
X	and microcontroller access:
X
X		main.c
X		pmbus.c
X		usi_i2c_slave.c
X		usi_i2c_slave.h
X		smbus_glue.h
X		prod_misc.h
X
WHY USE THIS?
X
X	There are several reasons this firmware may interest you:
X
X	- Achieving what was originally promised for that chip.  Despite
X	  documentation in the NGW100 board support package, the original
X	  firmware doesn't conform to any version of the PMBus spec.  It
X	  won't return strings properly.  Temperatures are encoded wrong.
X	  So is the board revision.
X
X	- This firmware provides a basis for building the kind of board
X	  controller the NGW design envisions.  Swap in a more capable
X	  chip (say, an ATtiny44), and it could do quite a lot.
X
X	- As a Linux developer, you may not be familiar with AVR8
X	  microcontrollers.  This little project can be a gentle
X	  introduction.
X
X	Fortunately, one place the documentation is incorrect is where it
X	says that the ATtiny can't be reprogrammed without taking it off
X	the board.  The "lock bits" have not actually been set, so it can
X	be reprogrammed using standard AVR8 tools.
X
X	The USI controller which this firmware uses is available in all the
X	ATtiny series chips plus larger ATmega{16,32,64}{5,9,50} chips, so
X	it should be easy to make it work on other AVRs.  (Retargetting to
X	AVRs using TWI controllers for I2C shouldn't hurt much, either.)
X
SUMMARY INSTRUCTIONS
X
X    Building
X	This package is distributed with a pre-built firmware image, as
X	well as the sources to build that image.  So you don't *need* to
X	build it yourself.
X
X	These sources build with gcc-avr; a simple Makefile is included,
X	which you may need to tweak.  On MS-Windows, use WinAVR-20071221
X	or newer; you may want to set up an AVR Studio project.  On Linux,
X	use a recent toolchain, but be careful of GCC 4.3.0 bugs.
X
X    Installing -- the hardware side
X	There are lots of ways to get firmware onto an AVR8 microcontroller;
X	you can read about them in many places.  I'll suggest using an AVR
X	Dragon [3] programming adapter (USB connection, $US 50) connected
X	to a six-pin ISP connector you solder onto your NGW100, but most
X	any AVR programming tool will work.
X
X	As for soldering that ISP connector ...  find the ATtiny24 chip on
X	your NGW100, and notice the pair of 6-pin footprints on the board
X	right next to it.  The footprint at the head of the ATtiny is the
X	ISP connector.
X
X    Installing -- the software side
X	Again, there are lots of choices.
X	
X	  * One command line option is to use "avrdude", on both Linux
X	    and Windows.  If you're using avrdude, you may first want
X	    to download backup copies of the EEPROM and flash data.
X	    Then erase everything and start from scratch.  
X	
X	  * AVR Studio also supports direct downloading (Windows only).
X
X	    However, *DO NOT* try to do this using the debugger (DebugWire)
X	    unless you first remove the zero ohm resistor connecting the
X	    ATtiny24 reset line to the AVR32 reset line!!  (It's labeled
X	    "0", and sits between the ATtiny24 and DataFlash chips.) 
X	    DebugWire won't work, because of a capacitor on that line.
X
X	Newer toolchains should pick up fuse settings from the firmware
X	image.  The defaults are OK, except you should set EESAVE:  once
X	you set up the EEPROM, you probably won't want to do it again.
X	
X	After you update the firmware, you should write two values into
X	the EEPROM.  That's easy with DebugWire and AVR Studio; just edit
X	the memory display.  You can also do it with ISP mode and avrdude.
X	 
X	  * Your board serial number, up to 10 ASCII characters starting
X	    at the beginning of the EEPROM.  Copy it from the sticker on
X	    the bottom of your NGW board; it's not the product name or
X	    the manufacture date code, and may be like "NGW01234".
X
X	  * Two bytes of temperature calibration data, starting at
X	    the tenth byte.  Start with the default offset, and update
X	    it based on the reported temperature.  (Or leave it as all
X	    zeroes or all ones, to use a default and correct it later.)
X
X    Using the new firmware
X	You may have noticed that nothing actually tries to talk to the
X	board controller, either from Linux or from U-Boot.  Strictly
X	speaking, the board's Ethernet addresses should be derived from
X	its serial number, which should be retrievable from the ATtiny24
X	controller (according to its limited documentation).  But there's
X	no point in trying that with the original firmware.
X
X	You can use the enclosed "pmbus_peek" userspace client.  It
X	uses the /dev/i2c-N interface, and lets you examine PMBus
X	devices such as this one.  (Watch the original Atmel firmware
X	misbehave!  It uses address 0x0b; this firmware uses 0x35.)
X
FIRMWARE CAPABILITIES
X
X	This firmware uses the SMBus alert mechanism for asynchronous
X	fault reporting.  Unfortunately Linux doesn't yet support that
X	mechanism, so if you care about faults you currently need to
X	poll for them.
X
X   Sample readings:
X	Here's output from the firmware installed on one NGW board.
X
X	The hardware revision is shown in octal, and comes from two
X	resistor ladders on the board.  The serial number was copied
X	by hand into the EEPROM.  (The last digits could be used to
X	generate Ethernet addresses for the board.)
X	
X	Notice that there is one pending status alert, triggered
X	by manufacturer-specific command #4.  It can be cleared,
X	possibly by code which notices the SMBALERT# signal.
X
X	This voltage might be a little bit high, but it's hard to say;
X	only the first three of those digits are significant.
X	
X	This temperature reading is with no chip-specific calibration.
X	It's using the default offset (275) ... which is eighteen
X	degrees too high.  The EEPROM should be updated to record an
X	offset of 275 - 18 = 257 = 0x0101, stored  little endian into
X	addresses 0x0a and 0x0b.  (0x0123 would store as 0x23 into 0x0a,
X	and 0x01 into 0x0b.)
X
X	# pmbus_peek -s 0x35
X	PMBus slave on /dev/i2c-0, address 0x35
X
X	Inventory Data:
X	  Manufacturer:		Software Shak
X	  Model:		NGW100 PMBus
X	  Revision:		fw/0.7, hw/022
X	  Serial:		NGW01837
X
X	PMBus revisions (0x21):	part I, ver 1.1; part II, ver 1.1
X	Capabilities (0x30):	SMBALERT#, 400 KHz
X
X	Status 1000: mfr
X	  MFR_SPECIFIC          10: mfr_status_4
X
X	Attribute Values:
X	  vout                  0349: 3.34593 Volts
X	  temperature_1         0028: 40 degrees Celsius
X
X	#
X
X   Supported operations:
X   	Here's some output showing the device identification data
X	and the results of QUERYing all PMBus 1.1 commands to see
X	what this firmware supports.
X	
X	# pmbus_peek -l 0x35
X	PMBus slave on /dev/i2c-0, address 0x35
X
X	Inventory Data:
X	  Manufacturer:		Software Shak
X	  Model:		NGW100 PMBus
X	  Revision:		fw/0.7, hw/022
X	  Serial:		NGW01837
X
X	PMBus revisions (0x21):	part I, ver 1.1; part II, ver 1.1
X	Capabilities (0x30):	SMBALERT#, 400 KHz
X
X	Supported Commands:
X	  03 clear_fault                w nodata
X	  19 capability                r  u8 (bitmask)
X	  1a query                     r  process_call
X	  30 coefficients              r  process_call
X	  78 status_byte               r  u8 (bitmask)
X	  79 status_word               r  u16 (bitmask)
X	  7e status_cml                r  u8 (bitmask)
X	  80 status_mfr_specific       r  u8 (bitmask)
X	  8b read_vout                 r  s16 (DIRECT), Volts
X	     Coefficients: READ b=0 m=25135 R=-2
X	  8d read_temperature_1        r  s16 (LINEAR), degrees Celsius
X	  98 pmbus_revision            r  u8 (bitmask)
X	  99 mfr_id                    r  block, ISO 8859/1 string
X	  9a mfr_model                 r  block, ISO 8859/1 string
X	  9b mfr_revision              r  block, ISO 8859/1 string
X	  9e mfr_serial                r  block, ISO 8859/1 string
X	  d4 mfr_specific_04            w (UNKNOWN call syntax)
X	  d5 mfr_specific_05            w (UNKNOWN call syntax)
X	#
X
X	Those two manufacturer-specific commands are for testing.
X	They trigger manufacturer-specific alerts, and raise an
X	SMBALERT# IRQ for the host to handle.
X
REFERENCES
X
X [0] PMBus is a consortium standard:
X
X	http://www.pmbus.org/
X
X [1] BSP documentation on the NGW100 board controller (not fully correct)
X
http://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Board_controller
X
X [2] Atmel's product description for the NGW100 board:
X
X	http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
X
X [3] Atmel's product description for the Dragon:
X
X 	http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891
SHAR_EOF
  (set 20 08 04 25 11 23 53 'README'; eval "$shar_touch") &&
  chmod 0644 'README' ||
  $echo 'restore of' 'README' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \