HacDC Wiki - User contributions [en]

Category:Community

2009-01-04T12:47:52Z

Hudson: Undo revision 1734 by 69.207.36.58 (Talk) -- page needs protection

Category:Community

2009-01-04T12:33:45Z

Hudson: Undo revision 1730 by 59.63.41.172 (Talk) -- more vandalism

AVR Tutorial: Bootstrapping the AVR

2009-01-03T05:42:29Z

Hudson: Wikified pinout and added link to Secure bootloader

So you want to program an AVR, but you don't have a programmer? Do you have a parallel port? Then fear not!

The AVR chips are set up to flash their program memory through a serial connection with the host computer, so programming them is mostly a matter of getting the right lines to the chip, with the rest taken care of by the AVRdude software.

The simplest way to get started is with one of the parallel-port "programmers". The basic procedure is to a) look at the docs for AVRdude's various parallel port adapters, b) look at the pinouts for the chip you're using, and c) wire the right pins on the parallel port to the right pins on your AVR.

For instance, the DAPA (Direct AVR Parallel Access) "programmer" makes the following connections between the parallel port pins and the AVR:

{|
! Parallel Pin
! AVR
|-
| 1 || SCK
|-
| 2 || MOSI
|-
| 11 || MISO
|-
| 16 || RESET
|-
| 20 || GND
|-
| 21 || GND
|}

Connect the wires and test it out! Type '''avrdude -n -v -p tiny13 -c dapa''' and you should see your part recognized and the fuse settings displayed. (Make sure to substitute your part name for tiny13. Type '''avrdude -p help''' to see the list of supported parts.)

For a much more complicated boot strap technique, there is the [[secure bootloader]] that uses AES encrypted firmware images.

[[Category: AVR Tutorial]]

Secure bootloader

2009-01-03T05:37:10Z

Hudson: Added to [:Category:AVR Tutorial]]

<noinclude>
[[Category:AVR Tutorial]]
</noinclude>
= Overview =

There are six priorities that this secure AVR bootloader provides:

# Secure hardware
# Encrypted firmware
# Signed firmware
# Per-device firmware
# Enforced limitations
# Operable with standard tools

== Secure hardware ==

The Atmel AVR ATmega128 processor has many specific features designed
to make it very difficult for an attacker to retrieve the firmware
image from inside the chip for reverse engineering. These features
are designed for high-security applications such as cell phones,
against hostile adversaries with significant equipment budgets.
Examples of the effort required to read-out the memory can be found
in [http://www.flylogic.net/blog/?p=15 FlyLogic's reverse engineering examination of the ATmega169]. Their conclusion is that Atmel makes
the most secure microcontrollers on the market.

== Encrypted firmware ==

The firmware images that are sent to customers for updates are protected
with AES128 in CBC chaining mode, approved by the
[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security NSA for classified data].
The encryption keys and a random IV are stored in protected memory
inside the Mega128 and are not retrievable without significant
effort in excess of re-implementing the software. This prevents
anyone from reverse engineering a firmware update since only
Rotomotion and the AFCS itself are able to decrypt the firmware
image.

== Signed firmware ==

Only approved firmware can be loaded and any modification of the
file before flashing or after it is inside the device will prevent
the system from starting. The boot loader is not circumventable
without erasing the chip and its embedded decryption key, so it is
not possible to avoid the verification step. The loader uses SHA1
as an HMAC algorithm, the [http://www.itl.nist.gov/fipspubs/fip180-1.htm US NIST standard for message authentication].

Because the AES128 key and IV are used as part of the checksum,
only the holder of the keys is able to generate firmware
images that will authenticate and run on the device.
Even a single bit modification to the firmware image after flashing,
which is not possible due to the secure hardware, will cause the
authentication routine to fail. Any changes made to the encrypted
version before flashing will cause the entire image to be corrupted
and, obviously, fail to authenticate as well.

For high-security applications the chip can be configured to do an
automatic erase of the application if this checksum ever fails.

== Per-device firmware ==

Each device has its own AES128 key and random 16-byte IV, known only
to the developer and programmed into the secure memory of the Mega128.
Since this key is included in the sum for authentication as part
of the HMAC algorithm at boot time, it is not possible to load a
firmware image with extra features enabled onto another device.
For instance, if certain features are disabled for
export control reasons or for extra cost, it is not possible to use a firmware from
another customer on the one with reduced functionality.

== Enforced limitations ==

Several limitations on device features are possible, such as designating
a geographic area in which a GPS equiped device will operate or limitations
on number of hours that the device can be operated.
Using the HMAC algorithm present in the flash memory, it should be possible to also have a key-generation
algorithm to generate a one-time key that will allow operation over a specified
period of time or in a specified location.

== Standard tools ==

The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.

= Source code =

* AES code is based on AVR app note 231
* http://www.osresearch.net/~hudson/secload.tar.gz

== Generating encryption keys ==

The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.

== TODO ==

* The file is encrypted in CBC mode, so it is possible that known plaintext attacks against the interrupt vectors in the first few bytes. Supporting a randomized offset address and shuffling the pages in the file before encrypting would prevent this, but would complicate the bootload process.

* Instead of SREC and AVR109, perhaps the protocol should be changed to xmodem or zmodem so even less special software is required.

* The size of the bootloader requires an atmega128 with a 4 KB boot segment.

* Position the aes and sha1 functions at fixed locations in the boot segment so that they can be called by user code to perform HMAC validation.

* Performance measurement of AES and SHA1 algorithm. Can the boot time be reduced?

Secure bootloader

2009-01-03T03:43:07Z

Hudson: /* Source code */

= Overview =

There are six priorities that this secure AVR bootloader provides:

# Secure hardware
# Encrypted firmware
# Signed firmware
# Per-device firmware
# Enforced limitations
# Operable with standard tools

== Secure hardware ==

The Atmel AVR ATmega128 processor has many specific features designed
to make it very difficult for an attacker to retrieve the firmware
image from inside the chip for reverse engineering. These features
are designed for high-security applications such as cell phones,
against hostile adversaries with significant equipment budgets.
Examples of the effort required to read-out the memory can be found
in [http://www.flylogic.net/blog/?p=15 FlyLogic's reverse engineering examination of the ATmega169]. Their conclusion is that Atmel makes
the most secure microcontrollers on the market.

== Encrypted firmware ==

The firmware images that are sent to customers for updates are protected
with AES128 in CBC chaining mode, approved by the
[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security NSA for classified data].
The encryption keys and a random IV are stored in protected memory
inside the Mega128 and are not retrievable without significant
effort in excess of re-implementing the software. This prevents
anyone from reverse engineering a firmware update since only
Rotomotion and the AFCS itself are able to decrypt the firmware
image.

== Signed firmware ==

Only approved firmware can be loaded and any modification of the
file before flashing or after it is inside the device will prevent
the system from starting. The boot loader is not circumventable
without erasing the chip and its embedded decryption key, so it is
not possible to avoid the verification step. The loader uses SHA1
as an HMAC algorithm, the [http://www.itl.nist.gov/fipspubs/fip180-1.htm US NIST standard for message authentication].

Because the AES128 key and IV are used as part of the checksum,
only the holder of the keys is able to generate firmware
images that will authenticate and run on the device.
Even a single bit modification to the firmware image after flashing,
which is not possible due to the secure hardware, will cause the
authentication routine to fail. Any changes made to the encrypted
version before flashing will cause the entire image to be corrupted
and, obviously, fail to authenticate as well.

For high-security applications the chip can be configured to do an
automatic erase of the application if this checksum ever fails.

== Per-device firmware ==

Each device has its own AES128 key and random 16-byte IV, known only
to the developer and programmed into the secure memory of the Mega128.
Since this key is included in the sum for authentication as part
of the HMAC algorithm at boot time, it is not possible to load a
firmware image with extra features enabled onto another device.
For instance, if certain features are disabled for
export control reasons or for extra cost, it is not possible to use a firmware from
another customer on the one with reduced functionality.

== Enforced limitations ==

Several limitations on device features are possible, such as designating
a geographic area in which a GPS equiped device will operate or limitations
on number of hours that the device can be operated.
Using the HMAC algorithm present in the flash memory, it should be possible to also have a key-generation
algorithm to generate a one-time key that will allow operation over a specified
period of time or in a specified location.

== Standard tools ==

The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.

= Source code =

* AES code is based on AVR app note 231
* http://www.osresearch.net/~hudson/secload.tar.gz

== Generating encryption keys ==

The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.

== TODO ==

* The file is encrypted in CBC mode, so it is possible that known plaintext attacks against the interrupt vectors in the first few bytes. Supporting a randomized offset address and shuffling the pages in the file before encrypting would prevent this, but would complicate the bootload process.

* Instead of SREC and AVR109, perhaps the protocol should be changed to xmodem or zmodem so even less special software is required.

* The size of the bootloader requires an atmega128 with a 4 KB boot segment.

* Position the aes and sha1 functions at fixed locations in the boot segment so that they can be called by user code to perform HMAC validation.

* Performance measurement of AES and SHA1 algorithm. Can the boot time be reduced?

Secure bootloader

2009-01-03T02:38:56Z

Hudson: Added todo and link to source

= Overview =

There are six priorities that this secure AVR bootloader provides:

# Secure hardware
# Encrypted firmware
# Signed firmware
# Per-device firmware
# Enforced limitations
# Operable with standard tools

== Secure hardware ==

The Atmel AVR ATmega128 processor has many specific features designed
to make it very difficult for an attacker to retrieve the firmware
image from inside the chip for reverse engineering. These features
are designed for high-security applications such as cell phones,
against hostile adversaries with significant equipment budgets.
Examples of the effort required to read-out the memory can be found
in [http://www.flylogic.net/blog/?p=15 FlyLogic's reverse engineering examination of the ATmega169]. Their conclusion is that Atmel makes
the most secure microcontrollers on the market.

== Encrypted firmware ==

The firmware images that are sent to customers for updates are protected
with AES128 in CBC chaining mode, approved by the
[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security NSA for classified data].
The encryption keys and a random IV are stored in protected memory
inside the Mega128 and are not retrievable without significant
effort in excess of re-implementing the software. This prevents
anyone from reverse engineering a firmware update since only
Rotomotion and the AFCS itself are able to decrypt the firmware
image.

== Signed firmware ==

Only approved firmware can be loaded and any modification of the
file before flashing or after it is inside the device will prevent
the system from starting. The boot loader is not circumventable
without erasing the chip and its embedded decryption key, so it is
not possible to avoid the verification step. The loader uses SHA1
as an HMAC algorithm, the [http://www.itl.nist.gov/fipspubs/fip180-1.htm US NIST standard for message authentication].

Because the AES128 key and IV are used as part of the checksum,
only the holder of the keys is able to generate firmware
images that will authenticate and run on the device.
Even a single bit modification to the firmware image after flashing,
which is not possible due to the secure hardware, will cause the
authentication routine to fail. Any changes made to the encrypted
version before flashing will cause the entire image to be corrupted
and, obviously, fail to authenticate as well.

For high-security applications the chip can be configured to do an
automatic erase of the application if this checksum ever fails.

== Per-device firmware ==

Each device has its own AES128 key and random 16-byte IV, known only
to the developer and programmed into the secure memory of the Mega128.
Since this key is included in the sum for authentication as part
of the HMAC algorithm at boot time, it is not possible to load a
firmware image with extra features enabled onto another device.
For instance, if certain features are disabled for
export control reasons or for extra cost, it is not possible to use a firmware from
another customer on the one with reduced functionality.

== Enforced limitations ==

Several limitations on device features are possible, such as designating
a geographic area in which a GPS equiped device will operate or limitations
on number of hours that the device can be operated.
Using the HMAC algorithm present in the flash memory, it should be possible to also have a key-generation
algorithm to generate a one-time key that will allow operation over a specified
period of time or in a specified location.

== Standard tools ==

The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.

= Source code =

* http://www.osresearch.net/~hudson/secload.tar.gz

== Generating encryption keys ==

The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.

== TODO ==

* The file is encrypted in CBC mode, so it is possible that known plaintext attacks against the interrupt vectors in the first few bytes. Supporting a randomized offset address and shuffling the pages in the file before encrypting would prevent this, but would complicate the bootload process.

* Instead of SREC and AVR109, perhaps the protocol should be changed to xmodem or zmodem so even less special software is required.

* The size of the bootloader requires an atmega128 with a 4 KB boot segment.

* Position the aes and sha1 functions at fixed locations in the boot segment so that they can be called by user code to perform HMAC validation.

* Performance measurement of AES and SHA1 algorithm. Can the boot time be reduced?

Secure bootloader

2009-01-03T02:21:20Z

Hudson: Created page

= Overview =

There are five priorities that this secure AVR bootloader provides:

# Secure hardware
# Encrypted firmware
# Signed firmware
# Per-device firmware
# Enforced limitations

== Secure hardware ==

The Atmel AVR ATmega128 processor has many specific features designed
to make it very difficult for an attacker to retrieve the firmware
image from inside the chip for reverse engineering. These features
are designed for high-security applications such as cell phones,
against hostile adversaries with significant equipment budgets.
Examples of the effort required to read-out the memory can be found
in [http://www.flylogic.net/blog/?p=15 FlyLogic's reverse engineering examination of the ATmega169]. Their conclusion is that Atmel makes
the most secure microcontrollers on the market.

== Encrypted firmware ==

The firmware images that are sent to customers for updates are protected
with AES128 in CBC chaining mode, approved by the
[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security NSA for classified data].
The encryption keys and a random IV are stored in protected memory
inside the Mega128 and are not retrievable without significant
effort in excess of re-implementing the software. This prevents
anyone from reverse engineering a firmware update since only
Rotomotion and the AFCS itself are able to decrypt the firmware
image.

== Signed firmware ==

Only approved firmware can be loaded and any modification of the
file before flashing or after it is inside the device will prevent
the system from starting. The boot loader is not circumventable
without erasing the chip and its embedded decryption key, so it is
not possible to avoid the verification step. The loader uses SHA1
as an HMAC algorithm, the [http://www.itl.nist.gov/fipspubs/fip180-1.htm US NIST standard for message authentication].

Because the AES128 key and IV are used as part of the checksum,
only the holder of the keys is able to generate firmware
images that will authenticate and run on the device.
Even a single bit modification to the firmware image after flashing,
which is not possible due to the secure hardware, will cause the
authentication routine to fail. Any changes made to the encrypted
version before flashing will cause the entire image to be corrupted
and, obviously, fail to authenticate as well.

For high-security applications the chip can be configured to do an
automatic erase of the application if this checksum ever fails.

== Per-device firmware ==

Each device has its own AES128 key and random 16-byte IV, known only
to the developer and programmed into the secure memory of the Mega128.
Since this key is included in the sum for authentication as part
of the HMAC algorithm at boot time, it is not possible to load a
firmware image with extra features enabled onto another device.
For instance, if certain features are disabled for
export control reasons or for extra cost, it is not possible to use a firmware from
another customer on the one with reduced functionality.

== Enforced limitations ==

Several limitations on device features are possible, such as designating
a geographic area in which a GPS equiped device will operate or limitations
on number of hours that the device can be operated.
Using the HMAC algorithm present in the flash memory, it should be possible to also have a key-generation
algorithm to generate a one-time key that will allow operation over a specified
period of time or in a specified location.

= Source code =
Where to post source?

LED streetlights

2009-01-02T15:09:10Z

Hudson: /* Efficiency */ Added neon and florescent numbers ("better ballyhoo"?)

= Efficiency =

Interesting factoids about [http://dansdata.blogsome.com/2008/12/27/led-street-lighting-not-as-good-as-you-think/ replacing sodium vapor lamps with LEDs]
for city-wide lighting.

* The theoretical lumen/Watt figures for LEDs are worse than low-pressure sodium vapor lamps (100 lm/W versus 200 lm/W)
* White LEDs are actually blue LEDs with a consumable phosphor layer that turns opaque after a few years of operation.
* Combined RGB LEDs will have better efficiency than a "white" LED.

Other real-world tests have concluded that LED street lights have
about the same lumen/Watt in practice as the sodium vapor lamps
([http://www.olino.org/us/articles/2008/11/02/streetlamp-lioris-aduro-52 64 lm/W LEDs] versus [http://www.olino.org/us/articles/2008/12/29/indal-industria-aurora-streetlamp 67 lm/W Sodium vapor]).

Neon and florescent efficiency [http://www.signindustry.com/neon/articles/2003-07-11-RC-NeonandFlour.php3 depends on the color and shape]:
<blockquote>
[...] the fluorescent tube produces between 50 and 100 lumens of light per watt depending upon design. Compare this with the typical incandescent light bulb that produces between 10 and 20 lumens per watt. Neon light efficiency is based upon much fancier pants, the color of its output, which ranges from 10 lumens per watt for red to 60 lumens per watt for green or blue. One reason that green and blue tubes are more efficient is that phosphor coatings used to produce such colors better ballyhoo the high-energy ultraviolet light from the argon/mercury mix into visible colors. One reason that the fluorescent tube is more efficient than a neon tube is that a large straight tube offers less resistance to electrical current flow than a skinny bent one.
</blockquote>

= Obstacles =
Little Rock, AK wanted to replace their inefficient shielded lights
with more efficient fixtures, but their contract with Entergy is not
a simple $/kW formula: [http://www.arktimes.com/Articles/ArticleViewer.aspx?ArticleID=fce07cab-0dea-4fc5-b57e-f1145715f01e the energy company sets the price based on the type of fixture].

<blockquote>
[...] According to Henry, the city tested out more efficient 100–watt HPS bulbs in one Little Rock neighborhood about five years ago. When the city asked Entergy to set a rate for those fixtures, it was almost double the rate for the 150-watt HPS type.
When asked if Entergy was keeping Little Rock from being more energy efficient, Henry said simply, "Yes."
"But how do you fight Entergy?" Henry asked. "I mean, we've had people come in and show us new, more efficient lights and we've said, well, the problem is, it's not going to save us anything. It will be a whole lot less wattage and it will put light out on the street but we can't get any benefit out of it
because of the tariffs."
</blockquote>

= Commercial LED lamps =
[http://sparkfun.com SparkFun] sells LED lamps that are screw compatible with US light sockets:
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8716 75 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8714 12 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8717 3 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8715 1 W]

LED streetlights

2009-01-02T15:04:55Z

Hudson: /* Efficiency */ Mis typed URL

= Efficiency =

Interesting factoids about [http://dansdata.blogsome.com/2008/12/27/led-street-lighting-not-as-good-as-you-think/ replacing sodium vapor lamps with LEDs]
for city-wide lighting.

* The theoretical lumen/Watt figures for LEDs are worse than low-pressure sodium vapor lamps (100 lm/W versus 200 lm/W)
* White LEDs are actually blue LEDs with a consumable phosphor layer that turns opaque after a few years of operation.
* Combined RGB LEDs will have better efficiency than a "white" LED.

Other real-world tests have concluded that LED street lights have
about the same lumen/Watt in practice as the sodium vapor lamps
([http://www.olino.org/us/articles/2008/11/02/streetlamp-lioris-aduro-52 64 lm/W LEDs] versus [http://www.olino.org/us/articles/2008/12/29/indal-industria-aurora-streetlamp 67 lm/W Sodium vapor]).

= Obstacles =
Little Rock, AK wanted to replace their inefficient shielded lights
with more efficient fixtures, but their contract with Entergy is not
a simple $/kW formula: [http://www.arktimes.com/Articles/ArticleViewer.aspx?ArticleID=fce07cab-0dea-4fc5-b57e-f1145715f01e the energy company sets the price based on the type of fixture].

<blockquote>
[...] According to Henry, the city tested out more efficient 100–watt HPS bulbs in one Little Rock neighborhood about five years ago. When the city asked Entergy to set a rate for those fixtures, it was almost double the rate for the 150-watt HPS type.
When asked if Entergy was keeping Little Rock from being more energy efficient, Henry said simply, "Yes."
"But how do you fight Entergy?" Henry asked. "I mean, we've had people come in and show us new, more efficient lights and we've said, well, the problem is, it's not going to save us anything. It will be a whole lot less wattage and it will put light out on the street but we can't get any benefit out of it
because of the tariffs."
</blockquote>

= Commercial LED lamps =
[http://sparkfun.com SparkFun] sells LED lamps that are screw compatible with US light sockets:
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8716 75 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8714 12 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8717 3 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8715 1 W]

LED streetlights

2009-01-02T15:04:22Z

Hudson: Created page from mailing list post

= Efficiency =

Interesting factoids about [http://dansdata.blogsome.com/2008/12/27/led-street-lighting-not-as-good-as-you-t
hink/ replacing sodium vapor lamps with LEDs]
for city-wide lighting.

* The theoretical lumen/Watt figures for LEDs are worse than low-pressure sodium vapor lamps (100 lm/W versus 200 lm/W)
* White LEDs are actually blue LEDs with a consumable phosphor layer that turns opaque after a few years of operation.
* Combined RGB LEDs will have better efficiency than a "white" LED.

Other real-world tests have concluded that LED street lights have
about the same lumen/Watt in practice as the sodium vapor lamps
([http://www.olino.org/us/articles/2008/11/02/streetlamp-lioris-aduro-52 64 lm/W LEDs] versus [http://www.olino.org/us/articles/2008/12/29/indal-industria-aurora-streetlamp 67 lm/W Sodium vapor]).

= Obstacles =
Little Rock, AK wanted to replace their inefficient shielded lights
with more efficient fixtures, but their contract with Entergy is not
a simple $/kW formula: [http://www.arktimes.com/Articles/ArticleViewer.aspx?ArticleID=fce07cab-0dea-4fc5-b57e-f1145715f01e the energy company sets the price based on the type of fixture].

<blockquote>
[...] According to Henry, the city tested out more efficient 100–watt HPS bulbs in one Little Rock neighborhood about five years ago. When the city asked Entergy to set a rate for those fixtures, it was almost double the rate for the 150-watt HPS type.
When asked if Entergy was keeping Little Rock from being more energy efficient, Henry said simply, "Yes."
"But how do you fight Entergy?" Henry asked. "I mean, we've had people come in and show us new, more efficient lights and we've said, well, the problem is, it's not going to save us anything. It will be a whole lot less wattage and it will put light out on the street but we can't get any benefit out of it
because of the tariffs."
</blockquote>

= Commercial LED lamps =
[http://sparkfun.com SparkFun] sells LED lamps that are screw compatible with US light sockets:
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8716 75 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8714 12 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8717 3 W]
* [http://www.sparkfun.com/commerce/product_info.php?products_id=8715 1 W]

Talk:Writing Interactive Fiction with Inform 7

2008-12-14T19:59:55Z

Hudson: Makefiles for command line development

== Makefiles for command line development ==

I found the built-in editor with Inform7 somewhat frustrating, so I wrote a set of Makefile rules to allow me to do command line compiling while I edited the source files in my editor of choice. The build process is quite odd; first the Inform7 front-end generates I6 code from the .ni file, which is then compiled into z8 files. For test playing I used frotz.

<pre>
#!/usr/bin/make

# For OSX; for Linux i386 it is somewhere in /usr/local/bin
INFORM_PATH=/Applications/Inform.app/Contents/Resources/

I7_BIN=$(INFORM_PATH)/Compilers/ni
I7_LIB=$(INFORM_PATH)/Inform7/Extensions

I6_BIN=$(INFORM_PATH)/Compilers/inform-6.31-biplatform
I6_LIB=$(INFORM_PATH)/Library/Natural

ZCODE_VERSION=8
EXT=z$(ZCODE_VERSION)

ifdef DEBUG
DEBUG_OPTS=D
endif

#
# The arguments to the Inform6 compiler set:
# -E2SDwv$(ZCODE_VERSION)x \
# E2 Macintosh MPW-style error messages
# S Strict error-checking at runtime
# w Disable warning messages
# v8 Generate z-code version 8
# x Print # for every 100 lines compiled
#
# Optionally, if debugging is requested:
#
# D Insert "Constant DEBUG;" automatically
#
%.$(EXT): %.ni
TMPDIR=/tmp/inform7-$$$$
mkdir -p "$$TMPDIR"/{Build,Source,Index}
cp "$<" "$$TMPDIR"/Source/story.ni

"$(I7_BIN)" \
--rules "$(I7_LIB)" \
--extension=$(EXT) \
--package "$$TMPDIR" \

"$(I6_BIN)" \
-E2Swv$(ZCODE_VERSION)$(DEBUG_OPTS)x \
+"$(I6_LIB)" \
"$$TMPDIR/Build/auto.inf" \
-o "$@" \

</pre>

--- [[User:Hudson|Hudson]] 19:59, 14 December 2008 (UTC)

File:NGA-leds.jpg

2008-12-13T21:41:43Z

Hudson: Copied text of sign at art installation

Installation art piece at the National Gallery of Art with thousands of white LEDs by [http://www.nga.gov/exhibitions/villarealinfo.shtm Villareal]. The sign read:

<pre>
LEO VILLAREAL
American, b. 1967
Multiverse, 2008

light emitting diodes (LEDs), Mac mini, and electronic circuitry
On load from the artist
Courtesy Conner Contemporary Art, Washington DC
--------------------
The moving walkway between the East and West Buildings
has taken on a new dimension with the addition of a site-
specific LED sculpture by artist Leo Villareal. About 41,000
LEDs were inserted in the vaulted architecture of the walk-
way. The artist then programmed the electronic circuitry
to form kinetic configurations of white light conveying
associations ranging from artificial life to organic form.
The programming both instructs the lights and allows for
an element of chance. While it is possible that a pattern
wil repeat during a viewer's experience, it is unlikely. This
sculpture will be on view until November 2009.

Learn more about this installation at
www.nga.gov/villarea

This sculpture was generously funded by
Victoria P. and Roger Sant and Sharon P. and Jay Rockefeller.

Please do not touch the sculpture or the metal slats.
</pre>

File:NGA-leds.jpg

2008-12-13T21:04:52Z

Hudson: Typo in link

Installation art piece at the National Gallery of Art with thousands of white LEDs by [http://www.nga.gov/exhibitions/villarealinfo.shtm Villareal].

File:NGA-leds.jpg

2008-12-13T21:04:30Z

Hudson: Added link to artist

Installation art piece at the National Gallery of Art with thousands of white LEDs by [
http://www.nga.gov/exhibitions/villarealinfo.shtm Villareal].

File:NGA-leds.jpg

2008-12-13T20:59:11Z

Hudson: Installation art piece at the National Gallery of Art with thousands of white LEDs.

Installation art piece at the National Gallery of Art with thousands of white LEDs.

Neighborhood

2008-12-11T21:37:00Z

Hudson: /* Local spots near HacDC */ Remove Mayorga and re-organized into into subcategories and lists

== HacDC Location ==

HacDC is located at 1525 Newton St NW, Washington, DC 20010-3103

Metrorail: Green/Yellow line - [http://www.wmata.com/metrorail/Stations/station.cfm?station=75 Columbia Heights stop] - 14th & Irving

Metrobus:
* take S1 (16th Street–Potomac Park Line) or S2,4 (16th Street Line) to 16th & Irving Sts. NW
* or take H8 (Park Road–Brookland Line), H1 (Brookland–Potomac Park Line), or H2,3,4 (Crosstown Line) to 14th & Irving Sts. NW
* or take 42 (Mount Pleasant Line) to Lamont & Mount Pleasant Sts. NW

== Local spots near HacDC ==

[http://www.foodler.com/ foodler] includes several restaurants in delivery and takeout range of HacDC; their group order feature looks particularly convenient when the group members have e-mail and web access at hand.

* Wifi & coffee
** <strike>Mayorga Lounge</strike> - '''Now a sushi bar''' - [http://maps.google.com/maps?f=q&hl=en&geocode=&q=mayorga+lounge&sll=38.915492,-77.019938&sspn=0.008314,0.011737&ie=UTF8&ll=38.935578,-77.021456&spn=0.033248,0.046949&z=14&iwloc=A 3303 14th St NW]
** [http://www.trystdc.com/ Tryst] - free wifi during the weekday, none on weekends. - [http://maps.google.com/maps?q=2459+18th+nw+20009&ie=UTF8&oe=utf-8&client=firefox-a&t=h&z=16&g=2459+18th+nw+20009&iwloc=addr 2459 18th Street NW]
** [http://www.stickyfingersbakery.com/ Sticky Fingers] - Vegan bakery '''with wifi''' - [http://maps.google.com/maps?f=q&hl=en&geocode=&q=1370+Park+Road+NW,+Washington,+DC&sll=38.933909,-77.034931&sspn=0.014722,0.033345&ie=UTF8&ll=38.931722,-77.031991&spn=0.007361,0.016673&z=16&iwloc=addr 1370 Park Rd. NW]

* Food & Beer
** [http://theheightsdc.com/ The Heights] - [http://maps.google.com/maps?f=q&hl=en&geocode=&q=the+heights&sll=38.935578,-77.021456&sspn=0.033248,0.046949&ie=UTF8&ll=38.934176,-77.031755&spn=0.033249,0.046949&z=14&iwloc=A 3115 14th St NW]

* Sandwiches (delicious!)
** [http://potbelly.com/searchresultsnew.asp?txtAddr=1525+newton+st+nw&txtCity=washington&txtState=dc&txtZip= Potbelly] - 1400 Irving Street NW - Monday-Friday 7am-9pm - Saturday & Sunday 11am-9pm

* Pizza (also delicious!)
** [http://petesapizza.com/ Pete's New Haven Style Pizza] - 1400 Irving St Nw

* Latin American food and drinks:
** [http://www.rumberos-dc.com/ Rumberos] - [http://www.google.com/maps?q=restaurant&sll=38.930693,-77.032704&near=38.930693,-77.032704&cid=38930693,-77032704,12089469933345019767&li=lmd&z=14&t=m 3345 14th St NW]

Parts:
* Radio Shack - 3100 14th St NW; open Mon-Sat 9:00 am - 9:30 pm; Sunday 10:00 am - 7:30 pm
* Best Buy - 3100 14th St NW; open Mon-Sat 10am-9pm; Sunday 11am-7pm

[[Category:Community]]

Donation

2008-12-11T15:02:25Z

Hudson: Undo revision 1629 by 91.121.28.188 (Talk)

== Donating Money ==

''What's tax-deductible?''

''How to donate: cash, check, paypal''

== Donating Stuff ==

We're always on the lookout for donations. Put what you've got to good use! Donate it to HacDC!

E-mail [mailto:info@hacdc.org info@hacdc.org] if you have questions about specific items that do not appear here, or to arrange specific donation times. Otherwise, please stop by any of our public events with your donations!

MoF Report 2008 06 13

2008-12-11T15:01:49Z

Hudson: Undo revision 1630 by 91.121.28.188 (Talk)

Random factoid: People aren't cashing our checks!

= Financial Statements =

== Statement of Financial Position ==

{| cellspacing="10" cellpadding="0"
|-
| '''Assets'''
| '''Unrestricted'''
| '''Restricted'''
| '''Total'''
|-
| ''CURRENT ASSETS''
|
|
|
|-
| Cash (Checking)
| $18.31
| $82.43
| $100.74
|-
| Cash (PayPal)
| $1,417.16
|
| $1,417.16
|-
| Cash (Cash Box)
| $110.00
|
| $110.00
|-
|
|
|
|
|-
| ''OTHER ASSETS''
|
|
|
|-
| Security Deposit
| $850.00
|
| $850.00
|-
! Total Assets
| $2,395.47
| $82.43
| $2,477.90
|-
| '''Liabilities and Net Assets'''
| '''Unrestricted'''
| '''Restricted'''
| '''Total'''
|-
| ''CURRENT LIABILITIES''
|
|
|
|-
! Prepaid Dues
| $250.00
|
| $250.00
|-
! Total Liabilities
| $250.00
|
| $250.00
|-
| ''NET ASSETS''
|
|
|
|-
! Total Net Assets
| $2,145.47
| $82.43
| $2,227.90
|-
|}

== Statement of Financial Position ==

{| cellspacing="10" cellpadding="0"
|-
|
| '''Unrestricted'''
| '''Restricted'''
| '''Total'''
|-
| ''REVENUE AND OTHER SUPPORT''
|
|
|
|-
| Member Dues
| $3,050.00
|
| $3,050.00
|-
| [[Donation]] Income
| $1,939.80
| $82.43
| $2,022.23
|-
| Incorporators Contributions
| $1,750.00
|
| $1,750.00
|-
| Other Income
| $3.75
|
| $3.75
|-
! Total Revenue and Other Support
| $6,743.55
| $82.43
| $6,825.98
|-
| ''EXPENSES'' (Supporting)
|
|
|
|-
| Rent
| $2,550.00
|
| $2,550.00
|-
| Insurance
| $0.00
|
| $0.00
|-
| Network & Hosting
| $122.51
|
| $122.51
|-
| Equipment
| $1,003.91
|
| $1,003.91
|-
| Supplies
| $59.16
|
| $59.16
|-
| Transportation (Supplies)
| $136.63
|
| $136.63
|-
| Volunteer Meals
| $50.00
|
| $50.00
|-
| Incorporation Costs
| $84.66
|
| $84.66
|-
| Sponsorships
| $500.00
|
| $500.00
|-
! Total Expenses
| $4,680.51
|
| $4,680.51
|-
! Increase (Decrease) in Net Assets
| $2,145.47
| $82.43
| $2,227.90
|-
|}

[[Category:Financial Reports]]

User talk:Katie

2008-12-10T00:09:35Z

Hudson: Page protection

== Page protection ==

Thanks for protecting [[HacDC Multi-touch device]]. Any idea why that one page was such a target? You might considered installing [http://www.mediawiki.org/wiki/Extension:ReCAPTCHA Extension:ReCAPTCHA] to prevent anonymous autonomous bots from adding links to pages. So far it has prevented all of the spam postings on my Mediawiki installations. -- [[User:Hudson|Hudson]] 00:09, 10 December 2008 (UTC)

HacDC Multi-touch device

2008-12-09T13:30:28Z

Hudson: Undo revision 1576 by 125.244.126.196 (Talk)

== Multi-Touch Display Interface==

The discussion list for this project is [http://hacdc.org/mailman/listinfo/multi-touch-int-display_hacdc.org multi-touch-int-display@hacdc.org].

=== Meeting Minutes ===
* [[MTID030708 | Roadmap Meeting]]

=== Overview ===
Build the multi-touch display interface so that it can become a user interface for future HacDC projects as well as provide a collaboration interface for real-time multi-user-multi-touch applications, created by and for HacDC and its friends. http://en.wikipedia.org/wiki/Multi-touch

==== High Level Requirements ====
* When complete, device will be donated to HacDC
* Plans, instructions, parts list will be available to the public
* Source code will be available to the public
* Implement using FTIR http://cs.nyu.edu/~jhan/ftirtouch/
===== Reference Documentation =====
* Use Harry van der Veen building instructions as a guide http://www.multitouch.nl/documents/multitouchdisplay_howto_070523_v02.pdf
* User David Smith and David Holman instructions as a guide http://dundee.cs.queensu.ca/wiki/index.php/Building_a_Multi-Touch_Sensitive_Table
* Working Flash applications with multi-touch http://www.multitouch.nl/?p=23

==== Detailed Requirements ====
===== Operating System =====
* TBD

===== Package Management =====
* TBD

===== Software =====
*TouchLib http://www.whitenoiseaudio.com/touchlib/
*TouchLib Source Code http://code.google.com/p/touchlib/

===== 3rd Party Software =====
* TBD

===== Hardware =====

====== Tools ======
* Power drill + 5mm drill
* Standard size screwdriver (flathead & cross)
* Small sharp knife
* Scissors
* Different grits of sanding paper
* Wooden cubical object to wrap sanding paper around
* Copper or silver polish + towel
* Synthetic material saw

====== Materials ======
* Screws
* Glue (hotglue / white glue)
* Frame material (for example wood, aluminium or PVC)
* Connector strips
* Electronic wire (0,5 mm)
* R-LEDs + resistors
* Acrylic also known as plexiglas
* Black photo negatives
* Power source
* Power cable
* Webcam
* Projector
* Projection material (tracing paper)
* Silicone rubber
* Working computer
* Mirror (optionally)

==== Testing Resources ====
===== Equipment =====
* TBD

==== Test Plan ====
TBD

==== Design ====
TBD

==== Human Resources ====
* Project Coordinator: [[User:Rdegraci|RBD]]

==== Task Partitioning ====
* TBD

==== Timeline ====
Assume 4 hour days.
* TBD

==== Implementation ====
TBD

==== Component Testing ====
TBD

==== Integration Testing ====
TBD

[[Category:Ongoing_Projects]]

HacDC Multi-touch device

2008-12-09T05:29:03Z

Hudson: Undo revision 1574 by 61.164.67.91 (Talk)

HacDC Multi-touch device

2008-12-09T05:10:14Z

Hudson: This page needs to be locked! Undo revision 1572 by 121.246.133.180 (Talk)

HacDC Multi-touch device

2008-12-09T04:58:12Z

Hudson: Undo revision 1570 by 70.246.153.163 (Talk)

HacDC Multi-touch device

2008-12-09T04:53:12Z

Hudson: Vandalism -- Undo revision 1564 by 212.116.219.82 (Talk)

Talk:Project Red Phone

2008-12-09T04:52:02Z

Hudson: Freeworlddialup connection is online

== Freeworlddialup connection is online ==

I donated a [http://www.voip-info.org/wiki/view/Grandstream+Handytone-488 HT-488] SIP ATA to the space and wired it up to the pay phone. It uses [http://www.freeworlddialup.com/ FreeWorldDialup] for SIP connectivity (account 934122, phone 393-123-4567) with [http://www.ipkall.com/ IPKall] for inbound POTS calls (phone 253-243-2280). The accounts, passwords and details are written on a sticker on the bottom of the ATA and as of this evening it was functional. -- [[User:Hudson|Hudson]] 04:52, 9 December 2008 (UTC)

Inventory

2008-12-09T04:42:19Z

Hudson: Added image of printers being broken down for inventory.

[[Image:Printers.jpg|thumb|right|400px|Disassembling printers and sorting parts for inventory]]
== Equipment ==

=== Power Tools ===
* Table Saw
* Soldering Irons
* Reciprocating Saw
* Belt Sander w/ dust collection <ref name="offsite">This power tool may be stored offsite for security reasons. It can be requested by sending an email to info@hacdc.org</ref>
* Circular Saw

=== Hand Tools ===
* Screwdrivers
* Hammers

=== Furniture ===
=== Computers ===
* Complete Desktop Systems
* Laptop/Notebook Computers
* CRT Monitors
* LCD Monitors
* Computer Components
** Motherboards
** Video Cards
** Graphic Cards
** Sound Cards
** Memory Chips
** Processor Chips
** Modem Cards
** Ethernet Cards
* Printers
* Scanners
* External Modems
* Mice
* Keyboards

=== Other Capital Assets ===

== Parts & Supplies ==
* Audio Cables
* Ethernet Cables
* Radio Parts
* Power Cables
* Power Converters/Chargers

[[Category:Control Policy]] [[Category:Financial Operations Policy]]

== Other Assets in the Community ==

=== Skills ===
==== Marketing/Fundraising ====
==== Chemistry ====
==== Technical Writing/Documentation ====
==== Programming ====
* Perl
* PHP
** Derek Cooper (some)
* ASP
** Derek Cooper
* [http://en.wikipedia.org/wiki/Visual_Basic_for_Applications Visual Basic for Applications]
** Derek Cooper
* VB.Net
** Derek Cooper (some)
* Python
* C
* C+
* SQL Server
* XUL
** Derek Cooper
[[User:Dcooper|Dcooper]] 03:47, 6 May 2008 (UTC)

=== Hardware available for "the right project" ===

==== Test Equipment ====
This machinery may require some training and mentoring to use effectively.
* HP 2024b 4ch 200mhz oscilloscope [[User:Ashfixit|Ashfixit]]
* HP 10ghz spectrum analyzer [[User:Ashfixit|Ashfixit]]
* TTC T-berd T-1/ISDN communications test set [[User:Ashfixit|Ashfixit]]

==== Power Tools ====
* Drill [[User:Joncamfield|Joncamfield]]

==== Hand Tools ====
* Axe/sledge hammer combo (large, and also safety hazard) [[User:Joncamfield|Joncamfield]]
* Shovel (geek gardening project?) [[User:Joncamfield|Joncamfield]]
* Machete [[User:Joncamfield|Joncamfield]]

==== Furniture ====

==== Computers ====
* Complete Desktop Systems
**2 AMD [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_12264,00.html PIC]s, a small WinCE-based rugged computer; rumor has it that the bios prevents installing Linux [[User:Joncamfield|Joncamfield]]
* Laptop/Notebook Computers
**2 old but running laptops (ubuntu/xfce or DSL pre-installed) [[User:Joncamfield|Joncamfield]]
* CRT Monitors
* LCD Monitors
* Computer Components
** Motherboards
** Video Cards
** Graphic Cards
** Sound Cards
** Memory Chips
** Processor Chips
** Modem Cards
** Ethernet Cards
** Cell Phone Connectivity
***1 GSM-based PCMCIA card (sans simcard) [[User:Joncamfield|Joncamfield]]
* Printers
* Scanners
* External Modems
* Mice
* Keyboards
==Notes==
<references/>

[[Category:In the Space]]

File:Printers.jpg

2008-12-09T04:33:55Z

Hudson: uploaded a new version of "Image:Printers.jpg": Flipped the image upright.

Disassembling the printers on Microcontroller Monday 20081208.

File:Printers.jpg

2008-12-09T04:32:51Z

Hudson: Disassembling the printers on Microcontroller Monday 20081208.

Disassembling the printers on Microcontroller Monday 20081208.

User:Hudson/Unix room

2008-12-04T19:40:52Z

Hudson: New page: I was looking for a quote by Ken Thompson about his #1 failure with Unix's design (leaving the 'e' off the creat system call) and found this interview response by Rob Pike (fellow co-consp...

I was looking for a quote by Ken Thompson about his #1 failure
with Unix's design (leaving the 'e' off the creat system call)
and found this interview response by Rob Pike (fellow co-conspirator
in the invention of Unix):

<blockquote>

One odd detail that I think was vital to how the group functioned
was a result of the first Unix being run on a clunky minicomputer
with terminals in the machine room. People working on the system
congregated in the room - to use the computer, you pretty
much had to be there. (This idea didn't seem odd back then;
it was a natural evolution of the old hour-at-a-time way of booking
machines like the IBM 7090.)

The folks liked working that way, so when the machine
was moved to a different room from the terminals,
even when it was possible to connect from your private office,
there was still a `Unix room' with a bunch of terminals where
people would congregate, code, design, and just hang out.
(The coffee machine was there too.)

The Unix room still exists, and it may be the greatest
cultural reason for the success of Unix as a technology.
More groups could profit from its lesson, but it's really hard
to add a Unix-room-like space to an existing organization.
You need the culture to encourage people not to hide in
their offices, you need a way of using systems that makes a public
machine a viable place to work - typically by storing the data
somewhere other than the 'desktop' - and you need people like Ken
and Dennis (and Brian Kernighan and Doug McIlroy and Mike Lesk
and Stu Feldman and Greg Chesson and ...) hanging out in the room,
but if you can make it work, it's magical.

</blockquote>

I find that I miss the communal machine room environment and shared
machine Unix machines. These days everyone has Unix in their pocket
(hello, iPhone!) and private Unix laptops (hello, MacBooks!), so it
is far too easy to hide in the office, the cafe or at home rather
than work together with fellow geeks.

It also made it easier for new users to become inculculated into
the ways of doing things so that everyone had a shared culture.
The global Usenet culture was worlds different than the fractured
web-forum world, even after the beginning of the Eternal September.
Anyone who posted "FIRST!!1!" to Usenet would have received
a stern talking to from a local wheel user, rather than being able
to flame-away from the privacy of their own home.

In many ways, I wonder if the creation of spaces like [[Main Page|HacDC]] have more to do with a return to the communal environment. It isn't pair programming in the XP sense, but perhaps more communal discovery rather than communal development.

[[User:Hudson|Hudson]] 19:40, 4 December 2008 (UTC)

User:Hudson

2008-12-04T19:37:49Z

Hudson: Created my talk page

* I like [[/Unix room|Unix]]
* I like to [http://rotomotion.com make things fly]
* I like [http://www.osresearch.net/wiki/index.php/LaTeX_and_MediaWiki LaTeX]
* I like [http://www.osresearch.net/wiki/index.php/Rockets Rockets]

Reading List

2008-07-30T22:16:30Z

Hudson: Added a few more books and use the Template:Amazon template

The HacDC Reading list, featuring the finest hacker tomes. (If you have ideas on how to organize, categorize, and linkize these, use the discussion page. I've avoided adding too much detail, so as to minimize the amount of work that will need to be done to re-arrange the list once a more useful organization scheme is hatched.)

= Kid's Books =

= Non-Fiction =

=== Biography & History ===

* [http://www.mit.edu/hacker/hacker.html The Hacker Crackdown] by Bruce Sterling.
* [http://www.cryptonomicon.com/beginning.html In the beginning was the command line] by Neal Stephenson

=== Electronics ===

* {{amazon|0596514379|Fashioning Technology: A DIY Intro to Smart Crafting}} by Syuzi Pakhchyan
* {{amazon|0945053282|Getting Started in Electronics}} by Forrest Mims
: A very readable and nearly mathematics free guide to electronics components and schematics. There are many small projects that can be completed in a single evening of work.
* {{amazon|1878707035|Engineer's Notebook}} by Forrest Mims
: Continues where Getting Started in Electronics ends and has many cookbook solutions to common tasks. If you've seen the Radio Shack "Mini notebooks", this is a compilation of all of them.
* {{amazon|0071452818|Practical Electronics for Inventors}} by Paul Scherz
: Similar in to Forrest Mims' books, but with more theory and math. Lots of analog circuits and discrete logic examples.

=== Computers ===

* {{amazon|1593270038|Write Great Code Volume 1: Understanding the machine}}
: Excellent introduction to computer architecture. This is a guide to understanding how CPUs and memory hierarchies work, how numbers are represented, how arrays are laid out, and so on.
* {{amazon|1593270658|Write Great Code Volume 2: Thinking low-level, writing high-level}}
: Almost better than Volume 1, this one focuses on how to write better code by understanding what the CPU, memory and compiler are doing underneath all of the syntactic sugar provided by high-level languages. Very important information for anyone writing in a high level language (like C) for embedded systems (like the AVR).
* {{amazon|020161622X|The Pragmatic Programmer}}
: Language independent guidelines for writing better code, working better with development groups and management, and avoiding common problems.

=== Radio ===

=== Science ===

=== Philosophy ===

= Fiction =

=== Science Fiction ===

* {{amazon|0441012035|Neuromancer}} by William Gibson
* {{amazon|0553380958|Snow Crash}} by Neal Stephenson
* {{amazon|0441016073|Halting State}} by Charles Stross

=== Fantasy ===

Template:Amazon

2008-07-30T22:06:15Z

Hudson: Wrote documentation on how the template works

<noinclude>
= Generate a link to a book at Amazon =

== Usage ==

<nowiki>{{amazon|ASIN|Title}}</nowiki>

This will generate:

<nowiki>[http://www.amazon.com/dp/product/ASIN TITLE]</nowiki>

== Affiliates ==

If HacDC gets an affiliate account, update the link below to add in ''<nowiki>?tag=HACDC-AMAZON-ID</nowiki>'' and all the links to Amazon products will generate revenue for the organization.

</noinclude><includeonly>[http://www.amazon.com/dp/product/{{{1|}}} {{{2|}}}]</includeonly>

Template:Amazon

2008-07-30T21:59:59Z

Hudson: Removed excess white space

<noinclude>
Generate a link to a book at Amazon, possible adding in a HacDC affiliate account if one is created.

Usage:

<nowiki>{{amazon|ASIN|Title}}</nowiki>

This will generate:

<nowiki>[http://www.amazon.com/gp/product/ASIN TITLE]</nowiki>

</noinclude><includeonly>[http://www.amazon.com/gp/product/{{{1|}}} {{{2|}}}]</includeonly>

Template:Amazon

2008-07-30T21:56:28Z

Hudson: Created template to simplify links to Amazon (and maybe add HacDC affiliate ID)

<noinclude>
Generate a link to a book at Amazon, possible adding in a HacDC affiliate account if one is created.

Usage:

<nowiki>{{amazon|ASIN|Title}}</nowiki>

This will generate:

<nowiki>[http://www.amazon.com/gp/product/ASIN TITLE]</nowiki>

</noinclude>
<includeonly>[http://www.amazon.com/gp/product/{{{1|}}} {{{2|}}}]</includeonly>

Reading List

2008-07-30T21:31:03Z

Hudson: /* Electronics */ Added Mims and Scherz books. Made Pakhchyan a link to Amazon.

Suggested Classes

2008-07-27T16:28:40Z

Hudson: /* I'd like to learn... */ Added sections I'd like to teach

== I'd like to learn... ==

* how to make short-pinned locks for practicing [[Locksport]] -[[User:Katie|Katie]] 15:40, 23 July 2008 (UTC)
* ''add your wish here!''

== I'd like the teach... ==

* Slide rule usage
:I can teach beginning operations (multiplication, division, exponentiation, trig, logs, etc), but I'm pretty slow these days. [[User:Hudson|Hudson]] 16:28, 27 July 2008 (UTC)
* Osciloscopes and triggers
:How to use a scope and build a programable trigger using a microcontroller. [[User:Hudson|Hudson]] 16:28, 27 July 2008 (UTC)
* Unix tricks
:Efficient text processing using the Unix toolkit (vi, cut, sed, awk, perl, dc, etc). [[User:Hudson|Hudson]] 16:28, 27 July 2008 (UTC)
* Makefiles for microcontrollers
: How to automate the build, install, test cycle using a serial bootloader and make. [[User:Hudson|Hudson]] 16:28, 27 July 2008 (UTC)

[[Category:Classes]]