paul@35 | 1 | Introduction
|
paul@35 | 2 | ------------
|
paul@35 | 3 |
|
paul@35 | 4 | The ArduinoAm29F010 project provides software and a circuit to program
|
paul@35 | 5 | Am29F010 flash memory devices using an Arduino board (tested with the Arduino
|
paul@35 | 6 | Duemilanove, but likely to work with the Arduino Uno and directly-related
|
paul@35 | 7 | boards). In addition, guidance about the use of such flash memory devices is
|
paul@36 | 8 | provided for use with microcomputer systems, such as the Acorn Electron and
|
paul@36 | 9 | BBC Microcomputer range.
|
paul@35 | 10 |
|
paul@6 | 11 | The Am29F010-90PC product has been used to test the software and hardware
|
paul@35 | 12 | design described here. The PDIP variant of the device, as opposed to the
|
paul@35 | 13 | various other packages employed in the product range, is the variant most
|
paul@35 | 14 | suitable for use with the Arduino.
|
paul@35 | 15 |
|
paul@36 | 16 | It is attractive to try and use such flash memory devices as an alternative to
|
paul@36 | 17 | EPROM devices, mostly for the practicality and increased convenience involved
|
paul@36 | 18 | in programming them, needing only a suitably-wired circuit and conventional
|
paul@36 | 19 | microcomputer/microcontroller voltage levels. It is also interesting to try
|
paul@36 | 20 | and make the extra space provided by such devices available to the systems in
|
paul@36 | 21 | which they will be deployed.
|
paul@36 | 22 |
|
paul@35 | 23 | Contact, Copyright and Licence Information
|
paul@35 | 24 | ------------------------------------------
|
paul@35 | 25 |
|
paul@35 | 26 | The author can be contacted at the following e-mail address:
|
paul@35 | 27 |
|
paul@35 | 28 | paul@boddie.org.uk
|
paul@35 | 29 |
|
paul@35 | 30 | Copyright and licence information can be found in the docs directory - see
|
paul@35 | 31 | docs/COPYING.txt and docs/gpl-3.0.txt for more information.
|
paul@35 | 32 |
|
paul@35 | 33 |
|
paul@6 | 34 |
|
paul@25 | 35 | Using the Software
|
paul@25 | 36 | ==================
|
paul@25 | 37 |
|
paul@25 | 38 | First of all, to use the Arduino-based programming solution, the Arduino needs
|
paul@25 | 39 | to have a program transferred to it. The program is compiled using the
|
paul@25 | 40 | Makefile provided, using the simple command...
|
paul@25 | 41 |
|
paul@25 | 42 | make
|
paul@25 | 43 |
|
paul@25 | 44 | To upload the program, the "upload" target is used as follows:
|
paul@25 | 45 |
|
paul@25 | 46 | make upload
|
paul@25 | 47 |
|
paul@25 | 48 | It is likely that this will fail unless appropriate permissions are available
|
paul@25 | 49 | on the device through which the Arduino is accessed on the host machine. Thus,
|
paul@25 | 50 | a privileged invocation is likely to be necessary:
|
paul@25 | 51 |
|
paul@25 | 52 | sudo make upload
|
paul@25 | 53 |
|
paul@38 | 54 | Configuring the Software
|
paul@38 | 55 | ------------------------
|
paul@38 | 56 |
|
paul@38 | 57 | By default, the software is configured for a circuit using 74HC273 flip-flop
|
paul@38 | 58 | integrated circuits. In the Makefile, the CIRCUIT variable is set as follows:
|
paul@38 | 59 |
|
paul@38 | 60 | CIRCUIT = 74HC273
|
paul@38 | 61 |
|
paul@38 | 62 | To change this to support 74HC595 shift register integrated circuits, the
|
paul@38 | 63 | variable is set as follows:
|
paul@38 | 64 |
|
paul@38 | 65 | CIRCUIT = 74HC595
|
paul@38 | 66 |
|
paul@38 | 67 | Clean the generated files and run make again after reconfiguring:
|
paul@38 | 68 |
|
paul@38 | 69 | make clean && make
|
paul@38 | 70 |
|
paul@26 | 71 | Testing the Program
|
paul@26 | 72 | -------------------
|
paul@26 | 73 |
|
paul@25 | 74 | With the program uploaded, it should now be possible to communicate with the
|
paul@25 | 75 | Arduino. Unless the programming circuit has been constructed, however, there
|
paul@25 | 76 | will not be any effect of communicating with the Arduino, other than to check
|
paul@25 | 77 | that the program is operational. Running the upload.py script as follows will
|
paul@25 | 78 | permit such a test:
|
paul@25 | 79 |
|
paul@25 | 80 | ./upload.py -i
|
paul@25 | 81 |
|
paul@25 | 82 | Again, it is likely that this will need to be run in a privileged fashion as
|
paul@25 | 83 | follows:
|
paul@25 | 84 |
|
paul@25 | 85 | sudo ./upload.py -i
|
paul@25 | 86 |
|
paul@25 | 87 | The script should act as a terminal, showing a ">" prompt that can accept
|
paul@25 | 88 | various commands. Merely getting the prompt should be enough of an indication
|
paul@25 | 89 | that the program is functioning on the device.
|
paul@25 | 90 |
|
paul@26 | 91 | Issuing read commands permits the testing of addresses in the device:
|
paul@26 | 92 |
|
paul@28 | 93 | location sector
|
paul@32 | 94 | R00000 0x0000 0 (the first location in the device)
|
paul@32 | 95 | R07fff 0x7fff 1 (the final location in sector 1)
|
paul@28 | 96 | R10000 0x10000 4 (the first location in sector 4)
|
paul@28 | 97 | R1ffff 0x1ffff 7 (the final location in the device)
|
paul@26 | 98 |
|
paul@26 | 99 | Uploading and Testing Images
|
paul@26 | 100 | ----------------------------
|
paul@26 | 101 |
|
paul@25 | 102 | Once the programming circuit has been constructed (see "Arduino Interfacing"
|
paul@25 | 103 | below), the upload.py script can be used to upload data to the Am29F010
|
paul@25 | 104 | device. For example:
|
paul@25 | 105 |
|
paul@25 | 106 | sudo ./upload.py jungle.rom
|
paul@25 | 107 |
|
paul@25 | 108 | This will take jungle.rom and write it to the first sector of the Am29F010. To
|
paul@25 | 109 | verify the operation, the following command can be used:
|
paul@25 | 110 |
|
paul@25 | 111 | sudo ./upload.py -v jungle.rom
|
paul@25 | 112 |
|
paul@25 | 113 | To write to other sectors, an option can be specified. For example:
|
paul@25 | 114 |
|
paul@25 | 115 | sudo ./upload.py -s 1 junglecode.rom
|
paul@25 | 116 |
|
paul@25 | 117 | Again, the operation can be verified as follows:
|
paul@25 | 118 |
|
paul@25 | 119 | sudo ./upload.py -s 1 -v junglecode.rom
|
paul@25 | 120 |
|
paul@25 | 121 | Note that the -s option must appear first.
|
paul@25 | 122 |
|
paul@25 | 123 | The upload.py script can accept multiple files and will write each of them to
|
paul@25 | 124 | consecutive sectors. However, it can be more prudent to write files
|
paul@25 | 125 | individually, especially if the circuit is behaving in a less than completely
|
paul@25 | 126 | reliable fashion.
|
paul@25 | 127 |
|
paul@26 | 128 | A Note on Sectors
|
paul@26 | 129 | -----------------
|
paul@26 | 130 |
|
paul@26 | 131 | Each sector is 16 kilobytes long, which corresponds to a 14-bit address range
|
paul@28 | 132 | (0x0000 to 0x3FFF). The Arduino interface described below supports 17-bit
|
paul@28 | 133 | addressing (A0...A16), permitting access to eight sectors (at 0x0000, 0x4000,
|
paul@28 | 134 | 0x8000, 0xC000, 0x10000, 0x14000, 0x18000 and 0x1C000). The simple mapping from
|
paul@28 | 135 | a ROM cartridge to the device leaves A16 grounded and thus unable to access the
|
paul@28 | 136 | upper four sectors in the device. However, A16 could be connected to VCC to
|
paul@28 | 137 | access the upper four sectors.
|
paul@26 | 138 |
|
paul@34 | 139 |
|
paul@34 | 140 |
|
paul@34 | 141 | Making a Printed Circuit Board
|
paul@34 | 142 | ==============================
|
paul@34 | 143 |
|
paul@34 | 144 | The pcb directory contains resources for making a PCB with the Fritzing
|
paul@34 | 145 | software. In order to track changes in these resources, they have been
|
paul@34 | 146 | unpacked from a file saved by Fritzing, and so must be packed together into
|
paul@34 | 147 | such a file before being given to Fritzing. This can be done using a script
|
paul@34 | 148 | provided:
|
paul@34 | 149 |
|
paul@34 | 150 | ./make_pcb.sh
|
paul@34 | 151 |
|
paul@34 | 152 | This will produce a file called ArduinoAm29F010-arduinouno.fzz containing the
|
paul@34 | 153 | resources in a zip archive as Fritzing expects.
|
paul@34 | 154 |
|
paul@35 | 155 | This PCB is featured as a project on the Fritzing Web site:
|
paul@35 | 156 |
|
paul@35 | 157 | http://fritzing.org/projects/arduino-am29f010-programming-shield
|
paul@35 | 158 |
|
paul@34 | 159 |
|
paul@34 | 160 |
|
paul@17 | 161 | Device Compatibility
|
paul@17 | 162 | ====================
|
paul@17 | 163 |
|
paul@17 | 164 | For use with an Acorn Electron ROM cartridge or other board providing a ROM
|
paul@17 | 165 | socket, the compatibility of the Am29F010 needs to be assessed in the context
|
paul@17 | 166 | of the ROM sockets likely to be provided.
|
paul@17 | 167 |
|
paul@17 | 168 | Original ROM Pinout Am29F010 Pinout
|
paul@17 | 169 | ------------------- ---------------
|
paul@17 | 170 |
|
paul@17 | 171 | 1 \/ 32 VCC
|
paul@17 | 172 | A16 2 31 WE#
|
paul@17 | 173 | 1 \/ 28 VCC A15 3 30
|
paul@17 | 174 | A12 2 27 A14 A12 4 29 A14
|
paul@17 | 175 | A7 3 26 A13 A7 5 28 A13
|
paul@17 | 176 | A6 4 25 A8 A6 6 27 A8
|
paul@17 | 177 | A5 5 24 A9 A5 7 26 A9
|
paul@17 | 178 | A4 6 23 A11 A4 8 25 A11
|
paul@17 | 179 | A3 7 22 OE# A3 9 24 OE#
|
paul@17 | 180 | A2 8 21 A10 A2 10 23 A10
|
paul@17 | 181 | A1 9 20 CS# A1 11 22 CE#
|
paul@17 | 182 | A0 10 19 D7 A0 12 21 DQ7
|
paul@17 | 183 | D0 11 18 D6 DQ0 13 20 DQ6
|
paul@17 | 184 | D1 12 17 D5 DQ1 14 19 DQ5
|
paul@17 | 185 | D2 13 16 D4 DQ2 15 18 DQ4
|
paul@17 | 186 | GND 14 15 D3 GND/VSS 16 17 DQ3
|
paul@17 | 187 |
|
paul@17 | 188 | Superimposing the Am29F010 onto a ROM socket would provide compatibility for
|
paul@17 | 189 | all pins from A12 to GND/VSS and from A14 to D3/DQ3.
|
paul@17 | 190 |
|
paul@17 | 191 | Pin 1 in a ROM socket would correspond to A15 but is not necessarily
|
paul@17 | 192 | connected, nor, perhaps, is A14 since only 14 bits are required to address 16
|
paul@17 | 193 | kilobytes, although there may be 32 kilobyte sockets connecting A14 and using
|
paul@20 | 194 | 15 bits to address 32K. A16 and A15 would probably be connected to ground to
|
paul@20 | 195 | ensure correct operation, but could also be wired to a selection mechanism so
|
paul@20 | 196 | that the entire contents of the flash memory might be exposed.
|
paul@17 | 197 |
|
paul@36 | 198 | Pin 28 in a ROM socket would provide power, but the corresponding pin 30 on an
|
paul@17 | 199 | Am29F010 is not connected. Thus pin 30 would need routing to pin 32 for the
|
paul@17 | 200 | flash device socket.
|
paul@17 | 201 |
|
paul@17 | 202 | Pin 31 for the Am29F010 would need to be asserted. Thus pin 30 might also be
|
paul@17 | 203 | routed to pin 31, so that the device would remain read-only at all times.
|
paul@17 | 204 |
|
paul@20 | 205 | Dual ROM Adapter Usage
|
paul@20 | 206 | ======================
|
paul@20 | 207 |
|
paul@20 | 208 | A single Am29F010 device could be wired to two ROM sockets in order to provide
|
paul@20 | 209 | data to both. The above wiring guide would be employed, with connections from
|
paul@20 | 210 | both sockets being connected to the Am29F010, but additional logic would be
|
paul@20 | 211 | required for the CS# signals originating from the sockets in order to expose
|
paul@20 | 212 | the appropriate region of flash memory. ROM #1 would be served by a "lower"
|
paul@20 | 213 | 16K region; ROM #2 would be served by an "upper" 16K region; A14 would be used
|
paul@20 | 214 | to switch between these regions.
|
paul@20 | 215 |
|
paul@20 | 216 | When ROM #1's CS# signal is low, an attempt to read from ROM #1 would be
|
paul@20 | 217 | occurring, and thus A14 would be held low. And when ROM #2's CS# signal is
|
paul@20 | 218 | low, an attempt to read from ROM #2 would be occurring, and thus A14 would be
|
paul@20 | 219 | held high.
|
paul@20 | 220 |
|
paul@22 | 221 | Meanwhile, the CS# signal for the two ROM sockets would need to be combined to
|
paul@22 | 222 | produce a resultant CE# signal for the Am29F010.
|
paul@22 | 223 |
|
paul@22 | 224 | ROM #1 CS# ROM #2 CS# Am29F010 A14 Am29F010 CE#
|
paul@22 | 225 | ---------- ---------- ------------ ------------
|
paul@22 | 226 | 0 0 Not defined Not defined
|
paul@22 | 227 | 0 1 0 0
|
paul@22 | 228 | 1 0 1 0
|
paul@22 | 229 | 1 1 Not defined 1
|
paul@20 | 230 |
|
paul@22 | 231 | It might therefore be possible to connect A14 to ROM #1's CS# signal. And the
|
paul@22 | 232 | resultant CE# signal could be the product of an AND gate:
|
paul@22 | 233 |
|
paul@22 | 234 | Am29F010 CE# = ROM #1 CS# AND ROM #2 CS#
|
paul@22 | 235 |
|
paul@25 | 236 | Wiring Details
|
paul@25 | 237 | --------------
|
paul@25 | 238 |
|
paul@22 | 239 | ROM #1 ROM #2 74HC08 Am29F010
|
paul@22 | 240 | ------ ------ ------ --------
|
paul@22 | 241 | CS# 1A A14
|
paul@22 | 242 | CS# 1B
|
paul@22 | 243 | 1Y CE#
|
paul@25 | 244 | OE# OE#
|
paul@0 | 245 |
|
paul@25 | 246 | ROM (Common) 74HC08 Am29F010
|
paul@25 | 247 | ------------ ------ --------
|
paul@25 | 248 | VCC VCC
|
paul@25 | 249 | GND GND
|
paul@25 | 250 | VCC VCC
|
paul@25 | 251 | VCC WE#
|
paul@25 | 252 | D0 DQ0
|
paul@25 | 253 | D1 DQ1
|
paul@25 | 254 | D2 DQ2
|
paul@25 | 255 | D3 DQ3
|
paul@25 | 256 | D4 DQ4
|
paul@25 | 257 | D5 DQ5
|
paul@25 | 258 | D6 DQ6
|
paul@25 | 259 | D7 DQ7
|
paul@25 | 260 | A0 A0
|
paul@25 | 261 | A1 A1
|
paul@25 | 262 | A2 A2
|
paul@25 | 263 | A3 A3
|
paul@25 | 264 | A4 A4
|
paul@25 | 265 | A5 A5
|
paul@25 | 266 | A6 A6
|
paul@25 | 267 | A7 A7
|
paul@25 | 268 | A8 A8
|
paul@25 | 269 | A9 A9
|
paul@25 | 270 | A10 A10
|
paul@25 | 271 | A11 A11
|
paul@25 | 272 | A12 A12
|
paul@25 | 273 | A13 A13
|
paul@25 | 274 | GND A15
|
paul@25 | 275 | GND A16
|
paul@25 | 276 | GND GND
|
paul@0 | 277 |
|
paul@26 | 278 | Note that A15 and A16 are left grounded, effectively exposing only the first
|
paul@26 | 279 | two sectors of the device. By connecting either or both of these to VCC, other
|
paul@26 | 280 | pairs of sectors can be manually selected. A mechanism could also be devised
|
paul@26 | 281 | to allow selection using logic, but this is not explored here.
|
paul@26 | 282 |
|
paul@34 | 283 |
|
paul@34 | 284 |
|
paul@0 | 285 | Arduino Interfacing
|
paul@0 | 286 | ===================
|
paul@0 | 287 |
|
paul@28 | 288 | Arduino can employ at most 14 digital pins (plus 5 switchable analogue pins),
|
paul@28 | 289 | whereas the Am29F010B requires 17 address pins, 8 data pins, plus 3 control
|
paul@38 | 290 | pins to be utilised. (Note that digital pin 13 also drives an LED and pins 0
|
paul@38 | 291 | and 1 are unavailable if the serial interface is being used.)
|
paul@38 | 292 |
|
paul@38 | 293 | Using 74HC273 Flip-Flops
|
paul@38 | 294 | ------------------------
|
paul@0 | 295 |
|
paul@0 | 296 | One solution is to map the 3 control pins directly to the Arduino, then to
|
paul@38 | 297 | channel addresses and data via 8 common pins, with addresses being stored in
|
paul@38 | 298 | latches or flip-flops, and then to employ two remaining pins to control the
|
paul@38 | 299 | latches. When neither latch is selected, the data pins will be used to read or
|
paul@38 | 300 | write data from the flash memory.
|
paul@0 | 301 |
|
paul@28 | 302 | In this scheme, A16 must be directly controlled by an additional pin, separate
|
paul@28 | 303 | from the latch-based mechanism. As a result, only 14 pins are needed on the
|
paul@28 | 304 | Arduino.
|
paul@0 | 305 |
|
paul@21 | 306 | 74HC273 Pinout
|
paul@21 | 307 | --------------
|
paul@21 | 308 |
|
paul@21 | 309 | MR# 1 \/ 20 VCC
|
paul@21 | 310 | Q0 2 19 Q7
|
paul@21 | 311 | D0 3 18 D7
|
paul@21 | 312 | D1 4 17 D6
|
paul@21 | 313 | Q1 5 16 Q6
|
paul@21 | 314 | Q2 6 15 Q5
|
paul@21 | 315 | D2 7 14 D5
|
paul@21 | 316 | D3 8 13 D4
|
paul@21 | 317 | Q3 9 12 Q4
|
paul@21 | 318 | GND 10 11 CP
|
paul@21 | 319 |
|
paul@3 | 320 | Arduino 74HC273 #1 74HC273 #2 Am29F010
|
paul@3 | 321 | ------- ---------- ---------- --------
|
paul@5 | 322 | A5 CE#
|
paul@14 | 323 | A4 OE#
|
paul@14 | 324 | A3 WE#
|
paul@14 | 325 | 2 CP
|
paul@14 | 326 | 3 CP
|
paul@27 | 327 | 4 D3 D3 DQ3
|
paul@27 | 328 | 5 D2 D2 DQ2
|
paul@27 | 329 | 6 D1 D1 DQ1
|
paul@27 | 330 | 7 D0 D0 DQ0
|
paul@17 | 331 | 8 D4 D4 DQ4
|
paul@17 | 332 | 9 D5 D5 DQ5
|
paul@17 | 333 | 10 D6 D6 DQ6
|
paul@17 | 334 | 11 D7 D7 DQ7
|
paul@2 | 335 | Q0 A0
|
paul@2 | 336 | Q1 A1
|
paul@2 | 337 | Q2 A2
|
paul@2 | 338 | Q3 A3
|
paul@2 | 339 | Q4 A4
|
paul@2 | 340 | Q5 A5
|
paul@2 | 341 | Q6 A6
|
paul@2 | 342 | Q7 A7
|
paul@2 | 343 | Q0 A8
|
paul@2 | 344 | Q1 A9
|
paul@2 | 345 | Q2 A10
|
paul@2 | 346 | Q3 A11
|
paul@2 | 347 | Q4 A12
|
paul@2 | 348 | Q5 A13
|
paul@2 | 349 | Q6 A14
|
paul@2 | 350 | Q7 A15
|
paul@28 | 351 | A2 A16
|
paul@17 | 352 | 5V MR# MR#
|
paul@2 | 353 | 5V VCC VCC VCC
|
paul@2 | 354 | GND GND GND VSS
|
paul@0 | 355 |
|
paul@0 | 356 | Set Address
|
paul@0 | 357 | -----------
|
paul@0 | 358 |
|
paul@2 | 359 | 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
|
paul@2 | 360 | 74HC273 #1 D[7...0] = A[7...0]
|
paul@2 | 361 | 74HC273 #1 CP = 0; 74HC273 #2 CP = 1
|
paul@2 | 362 | 74HC273 #2 D[7...0] = A[15...8]
|
paul@28 | 363 | Am29F010 A16 = A[16]
|
paul@0 | 364 |
|
paul@0 | 365 | Write Data
|
paul@0 | 366 | ----------
|
paul@0 | 367 |
|
paul@0 | 368 | Configure pins as D[7...0]
|
paul@2 | 369 | WE# = 0
|
paul@2 | 370 | 74HC273 #1 CP = 0; 74HC273 #2 CP = 0
|
paul@2 | 371 | 74HC273 #3 D[7...0] = D[7...0]
|
paul@2 | 372 | WE# = 1
|
paul@0 | 373 |
|
paul@0 | 374 | Read Data
|
paul@0 | 375 | ---------
|
paul@0 | 376 |
|
paul@0 | 377 | Configure pins as Q[7...0]
|
paul@2 | 378 | OE# = 0
|
paul@2 | 379 | 74HC273 #1 CP = 1; 74HC273 #2 CP = 0
|
paul@2 | 380 | Q[7...0] = 74HC273 #0 Q[7...0]
|
paul@2 | 381 | OE# = 1
|
paul@25 | 382 |
|
paul@38 | 383 | Using 74HC595 Shift Registers
|
paul@38 | 384 | -----------------------------
|
paul@38 | 385 |
|
paul@38 | 386 | Another solution is to map the 3 control pins directly to the Arduino, then to
|
paul@38 | 387 | channel addresses via a single pin to a pair of shift registers, and then
|
paul@38 | 388 | employ two remaining pins to control the shift registers. Eight separate data
|
paul@38 | 389 | pins will be used to read or write data from the flash memory.
|
paul@38 | 390 |
|
paul@38 | 391 | In this scheme, A16 must be directly controlled by an additional pin, separate
|
paul@38 | 392 | from the shift-register-based mechanism. As a result, only 15 pins are needed
|
paul@38 | 393 | on the Arduino.
|
paul@38 | 394 |
|
paul@38 | 395 | 74HC595 Pinout
|
paul@38 | 396 | --------------
|
paul@38 | 397 |
|
paul@38 | 398 | QB 1 \/ 16 VCC
|
paul@38 | 399 | QC 2 15 QA
|
paul@38 | 400 | QD 3 14 SI
|
paul@38 | 401 | QE 4 13 G#
|
paul@38 | 402 | QF 5 12 RCK
|
paul@38 | 403 | QG 6 11 SCK
|
paul@38 | 404 | QH 7 10 SCLR#
|
paul@38 | 405 | GND 8 9 QH'
|
paul@38 | 406 |
|
paul@38 | 407 | Arduino 74HC595#1 74HC595#2 Am29F010
|
paul@38 | 408 | ------- --------- --------- --------
|
paul@38 | 409 | A5 CE#
|
paul@38 | 410 | A4 OE#
|
paul@38 | 411 | A3 WE#
|
paul@38 | 412 | 2 SCK SCK
|
paul@38 | 413 | 3 RCK RCK
|
paul@38 | 414 | 4 DQ3
|
paul@38 | 415 | 5 DQ2
|
paul@38 | 416 | 6 DQ1
|
paul@38 | 417 | 7 DQ0
|
paul@38 | 418 | 8 DQ4
|
paul@38 | 419 | 9 DQ5
|
paul@38 | 420 | 10 DQ6
|
paul@38 | 421 | 11 DQ7
|
paul@38 | 422 | 12 SI
|
paul@38 | 423 | QA A0
|
paul@38 | 424 | QB A1
|
paul@38 | 425 | QC A2
|
paul@38 | 426 | QD A3
|
paul@38 | 427 | QE A4
|
paul@38 | 428 | QF A5
|
paul@38 | 429 | QG A6
|
paul@38 | 430 | QH A7
|
paul@38 | 431 | QA A8
|
paul@38 | 432 | QB A9
|
paul@38 | 433 | QC A10
|
paul@38 | 434 | QD A11
|
paul@38 | 435 | QE A12
|
paul@38 | 436 | QF A13
|
paul@38 | 437 | QG A14
|
paul@38 | 438 | QH A15
|
paul@38 | 439 | A2 A16
|
paul@38 | 440 | 5V SCLR# SCLR#
|
paul@38 | 441 | 5V VCC VCC VCC
|
paul@38 | 442 | GND G# G#
|
paul@38 | 443 | GND GND GND VSS
|
paul@38 | 444 |
|
paul@25 | 445 | Pins
|
paul@25 | 446 | ====
|
paul@25 | 447 |
|
paul@25 | 448 | A0-A16 17-bit addressing
|
paul@25 | 449 | DQ0-DQ7 8-bit data transfer
|
paul@25 | 450 | CE# chip enable
|
paul@25 | 451 | OE# output enable
|
paul@25 | 452 | WE# write enable
|
paul@25 | 453 | VCC 5V
|
paul@25 | 454 | VSS ground
|
paul@25 | 455 | NC (not connected)
|
paul@25 | 456 |
|
paul@34 | 457 |
|
paul@34 | 458 |
|
paul@34 | 459 | Technical Notes
|
paul@34 | 460 | ===============
|
paul@34 | 461 |
|
paul@36 | 462 | Information about the operation of the Am29F010 device can be gained from a
|
paul@36 | 463 | perusal of the datasheet, and a summary of some of the pertinent details can
|
paul@36 | 464 | be found below.
|
paul@36 | 465 |
|
paul@25 | 466 | Low-Level Operations
|
paul@34 | 467 | --------------------
|
paul@25 | 468 |
|
paul@25 | 469 | CE# high standby
|
paul@25 | 470 | CE# low read, write or output disable
|
paul@25 | 471 |
|
paul@25 | 472 | OE# high, WE# high output disable
|
paul@25 | 473 | OE# low, WE# high read
|
paul@25 | 474 | OE# high, WE# low write
|
paul@25 | 475 |
|
paul@25 | 476 | Thus, for reading and writing:
|
paul@25 | 477 |
|
paul@25 | 478 | OE# = not WE#
|
paul@25 | 479 |
|
paul@25 | 480 | Timing
|
paul@34 | 481 | ------
|
paul@25 | 482 |
|
paul@25 | 483 | According to the datasheet, addresses are latched on the falling edge of the
|
paul@25 | 484 | latest of WE# and CE#, data is latched on the rising edge of the latest of WE#
|
paul@25 | 485 | and CE#.
|
paul@25 | 486 |
|
paul@25 | 487 | Strategy:
|
paul@25 | 488 |
|
paul@25 | 489 | 1. Start with CE#, OE#, WE# high (standby, output disable)
|
paul@25 | 490 | 2. Bring CE# low (output disable)
|
paul@25 | 491 | 3. Set addresses
|
paul@25 | 492 | 4. Bring WE# or OE# low for operation (write or read)
|
paul@25 | 493 | 5. Read or write data
|
paul@25 | 494 | 6. Bring WE# or OE# high (output disable)
|
paul@25 | 495 |
|
paul@25 | 496 | Operation Modes
|
paul@34 | 497 | ---------------
|
paul@25 | 498 |
|
paul@25 | 499 | By default, the device is in read mode, meaning that merely bringing OE# low
|
paul@25 | 500 | will produce data for the asserted address.
|
paul@25 | 501 |
|
paul@25 | 502 | To issue commands to change the mode involves write operations with specific
|
paul@25 | 503 | address and data arguments.
|
paul@25 | 504 |
|
paul@25 | 505 | Sectors
|
paul@34 | 506 | --------
|
paul@25 | 507 |
|
paul@25 | 508 | A[16...14] selects each 16KB sector and is referred to as the sector address
|
paul@25 | 509 | or SA in the documentation.
|
paul@25 | 510 |
|
paul@25 | 511 | Commands
|
paul@34 | 512 | --------
|
paul@25 | 513 |
|
paul@25 | 514 | Reset (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$F0)
|
paul@25 | 515 |
|
paul@25 | 516 | Autoselect (manufacturer) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
|
paul@25 | 517 | (A=$X00; read)
|
paul@25 | 518 | => D=$01
|
paul@25 | 519 |
|
paul@25 | 520 | Autoselect (device) (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$90);
|
paul@25 | 521 | (A=$X01; read)
|
paul@25 | 522 | => D=$20
|
paul@25 | 523 |
|
paul@25 | 524 | Simple reset (A=$XXXX; D=$F0)
|
paul@25 | 525 |
|
paul@25 | 526 | Sector erase (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$80);
|
paul@25 | 527 | (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=SA; D=$30)
|
paul@25 | 528 |
|
paul@25 | 529 | Program (A=$5555; D=$AA); (A=$2AAA; D=$55); (A=$5555; D=$A0);
|
paul@25 | 530 | (A=PA; D=PD)
|
paul@25 | 531 |
|
paul@36 | 532 | Note that A16 is held low when issuing the constant addresses in the above
|
paul@36 | 533 | commands.
|
paul@36 | 534 |
|
paul@25 | 535 | Progress
|
paul@25 | 536 | --------
|
paul@25 | 537 |
|
paul@25 | 538 | Programming and erasure commands employ data pins as follows:
|
paul@25 | 539 |
|
paul@25 | 540 | Programming Erasure
|
paul@25 | 541 | DQ7 On completion: DQ7-out On completion: 1
|
paul@25 | 542 | DQ6 During: toggling value During: toggling value
|
paul@25 | 543 | DQ5 On failure: 1 On failure: 1
|
paul@25 | 544 | DQ3 Sector erase begun: 1
|
paul@25 | 545 |
|
paul@25 | 546 | A read operation is required to obtain these outputs, typically with the same
|
paul@36 | 547 | address used to initiate each operation. The algorithm described in the
|
paul@36 | 548 | datasheet that tests DQ7 and DQ5 is employed to determine whether an operation
|
paul@36 | 549 | has completed. It should be noted that the toggling effect on DQ6 occurs from
|
paul@36 | 550 | read to read, not at some particular frequency.
|