??? 07/03/06 18:39 Read: times |
#119584 - NAND control Responding to: ???'s previous message |
Stevan Pavlovic said:
I do not understand what do you mean by this "CLE and WP (if you care)". OK for WP, but If I do not use CLE, flash will always be selected and because I am going to use same pins (P0) of micro for flash and for low adress of SRAM, and for LATCH (74HC573-several, for some other signals), there could be problems with data of flash, or not? OK, I suppose I should have put a comma after CLE, as the (if you care) parenthetical was meant for WP only. Basically, you can tie WP deasserted if you don't care about a hardware write protect. CLE is not a chip select. It's the Command Latch Enable. It's used to indicate that the current data write cycle is writing a command (as opposed to an address, indicated by the assertion of ALE, or a data write, in which case neither ALE nor CLE is asserted). Of course you must drive CLE appropriately; otherwise, you'll never load commands into the flash chip and it won't do anything interesting. You can look at a NAND flash chip as a device with three registers: address register, command register and data register, and ALE and CLE select which register is being accessed. The functions of WE\, RE\ and CE\ are obvious. By "Glue," I mean you need to consider how you're attaching the flash to the micro. Maybe you want to have three locations in XDATA that decode to the address register, command register and data register. In that case, you'll need to decode the full address (on the latch output and P2) to determine if you should fire ALE or CLE. (I haven't done a timing analysis, so maybe this won't work!) Another way to do it would be to have ALE and CLE on discrete port pins. This means you wouldn't have to decode anything, you just set the appropriate pin then do the MOVX command to access the flash (you probably want to decode the address to determine if you should fire the SRAM's CE\ or the NAND's CE\) to write your address or data or command. A third way to do this is to expand on option 1. Rather than having one XDATA memory location for your NAND's data register, decode a space as big as the NAND's data register size (512 bytes or 2048 bytes (actually 528 bytes or 2112 bytes, so decode 1024 bytes or 4096 bytes); if you understand how NAND works, this makes sense (I hope)). You do this because you typically access NAND flash in pages; you read or write a whole page at a time, so if you were writing your access program in C, you'd do something like: char xdata NANDBASE[512] _at_ 0x8000; char xdata *pNand = NANDBASE; char Foo[512]; char *pFoo = Foo; // read a page: for (i = 0; i < PAGESIZE; i++) *pFoo++ = *pNand++; Anyways -- these are just thoughts how to do this; you'll have to look at specific hardware implementations to make sure your timing is good, etc etc. -a |
Topic | Author | Date |
AT89C51SND1C to NAND Flash | 01/01/70 00:00 | |
what does P1 have to do with memory addr | 01/01/70 00:00 | |
Mistake with P1 and P0 | 01/01/70 00:00 | |
well since you will not say it | 01/01/70 00:00 | |
Are you sure?? | 01/01/70 00:00 | |
NAND flash pinouts | 01/01/70 00:00 | |
NAND interface | 01/01/70 00:00 | |
Thank you -Glue Logic | 01/01/70 00:00 | |
NAND control | 01/01/70 00:00 | |
Thank you Andy![]() | 01/01/70 00:00 |