| David Brownell | 2e10c84 | 2006-01-11 11:23:49 -0800 | [diff] [blame] | 1 | spi_butterfly - parport-to-butterfly adapter driver |
| 2 | =================================================== |
| 3 | |
| 4 | This is a hardware and software project that includes building and using |
| 5 | a parallel port adapter cable, together with an "AVR Butterfly" to run |
| 6 | firmware for user interfacing and/or sensors. A Butterfly is a $US20 |
| 7 | battery powered card with an AVR microcontroller and lots of goodies: |
| 8 | sensors, LCD, flash, toggle stick, and more. You can use AVR-GCC to |
| 9 | develop firmware for this, and flash it using this adapter cable. |
| 10 | |
| 11 | You can make this adapter from an old printer cable and solder things |
| 12 | directly to the Butterfly. Or (if you have the parts and skills) you |
| 13 | can come up with something fancier, providing ciruit protection to the |
| 14 | Butterfly and the printer port, or with a better power supply than two |
| David Brownell | 9c1da3c | 2006-01-21 13:21:43 -0800 | [diff] [blame] | 15 | signal pins from the printer port. Or for that matter, you can use |
| 16 | similar cables to talk to many AVR boards, even a breadboard. |
| 17 | |
| 18 | This is more powerful than "ISP programming" cables since it lets kernel |
| 19 | SPI protocol drivers interact with the AVR, and could even let the AVR |
| 20 | issue interrupts to them. Later, your protocol driver should work |
| 21 | easily with a "real SPI controller", instead of this bitbanger. |
| David Brownell | 2e10c84 | 2006-01-11 11:23:49 -0800 | [diff] [blame] | 22 | |
| 23 | |
| 24 | The first cable connections will hook Linux up to one SPI bus, with the |
| 25 | AVR and a DataFlash chip; and to the AVR reset line. This is all you |
| 26 | need to reflash the firmware, and the pins are the standard Atmel "ISP" |
| David Brownell | 9c1da3c | 2006-01-21 13:21:43 -0800 | [diff] [blame] | 27 | connector pins (used also on non-Butterfly AVR boards). On the parport |
| 28 | side this is like "sp12" programming cables. |
| David Brownell | 2e10c84 | 2006-01-11 11:23:49 -0800 | [diff] [blame] | 29 | |
| 30 | Signal Butterfly Parport (DB-25) |
| 31 | ------ --------- --------------- |
| 32 | SCK = J403.PB1/SCK = pin 2/D0 |
| 33 | RESET = J403.nRST = pin 3/D1 |
| 34 | VCC = J403.VCC_EXT = pin 8/D6 |
| 35 | MOSI = J403.PB2/MOSI = pin 9/D7 |
| 36 | MISO = J403.PB3/MISO = pin 11/S7,nBUSY |
| 37 | GND = J403.GND = pin 23/GND |
| 38 | |
| 39 | Then to let Linux master that bus to talk to the DataFlash chip, you must |
| 40 | (a) flash new firmware that disables SPI (set PRR.2, and disable pullups |
| 41 | by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and |
| 42 | (c) cable in the chipselect. |
| 43 | |
| 44 | Signal Butterfly Parport (DB-25) |
| 45 | ------ --------- --------------- |
| 46 | VCC = J400.VCC_EXT = pin 7/D5 |
| 47 | SELECT = J400.PB0/nSS = pin 17/C3,nSELECT |
| 48 | GND = J400.GND = pin 24/GND |
| 49 | |
| David Brownell | 9c1da3c | 2006-01-21 13:21:43 -0800 | [diff] [blame] | 50 | Or you could flash firmware making the AVR into an SPI slave (keeping the |
| 51 | DataFlash in reset) and tweak the spi_butterfly driver to make it bind to |
| 52 | the driver for your custom SPI-based protocol. |
| 53 | |
| 54 | The "USI" controller, using J405, can also be used for a second SPI bus. |
| 55 | That would let you talk to the AVR using custom SPI-with-USI firmware, |
| 56 | while letting either Linux or the AVR use the DataFlash. There are plenty |
| 57 | of spare parport pins to wire this one up, such as: |
| David Brownell | 2e10c84 | 2006-01-11 11:23:49 -0800 | [diff] [blame] | 58 | |
| 59 | Signal Butterfly Parport (DB-25) |
| 60 | ------ --------- --------------- |
| 61 | SCK = J403.PE4/USCK = pin 5/D3 |
| 62 | MOSI = J403.PE5/DI = pin 6/D4 |
| 63 | MISO = J403.PE6/DO = pin 12/S5,nPAPEROUT |
| 64 | GND = J403.GND = pin 22/GND |
| 65 | |
| 66 | IRQ = J402.PF4 = pin 10/S6,ACK |
| 67 | GND = J402.GND(P2) = pin 25/GND |
| 68 | |