Nandpro supported device interfaces:

	LPC2148 Olimex USB header board
	High performance 16MB/2Mins
	LibUsb driver

	Parallel Printer Port, SPP mode
	Low performance, 16MB/35mins (cpu dependant)
	Dlportio printer port driver


Seven connections must be made from MAINBRD to the HW device interface.
	MAINBRD connects as specified to either Olimex board, or a PC printer port.

ArmLpc	Olimex		LPT				MAINBRD

SS	EXT1-3		DB25.1	--R---	J1D2.2
MISO	EXT1-6		DB25.11 -->|--  J1D2.4	Diode, observe polarity!
P0.28	EXT2-1		DB25.16	--R---	J2B1.6
GND	EXT1-26		DB25.18	------	J1D2.6	or 	J2B1.12
MOSI	EXT1-7		DB25.14	--R---	J1D2.1
SCK	EXT1-5		DB25.2	--R---	J1D2.3			
P0.29	EXT2-2		DB25.17	--R---	J2B1.5


USB Install:
	Flash the .hex file to the LPC2148.
	Connect LPC2148 to computer USB.
	Point "found new hardware" to the "custom.inf"
	Windows reports: "Your new hardware is ready to use"

USB Hardware:
	Connect only wires from EXT connectors to MAINBRD.
	No resistors or diodes at all. For sure! Do not add them!


LPT Install:
	Run the port95nt.exe application to install the DlPortio driver

LPT Hardware:
	Some parallel ports run at 3.3v others at 5v. The MAINBRD is 3.3 volts.
	It is recommend to use 100 ohm series saftey resistors (R)
	 for all lpt connections except for DB25.11 and DB25.18 (GND), as shown above.
	Testing with 5 volt lpt and NO resistors didn't burn anything up though. YMMV :P
	For DB25.11 connect diode exactly as shown. It is highly recommended to
	 connect the diode to the MAINBRD end rather than the PC end of the wire.
	 Preferred diode is BAT41 or other Schottkey switch diode with low forward voltage drop.
	 1N4148/53, 1N914, type switching diodes should be also be ok,
	 but are not quite as good. 1N400X are rectifiers and not good at all.
	This solution isn't perfect but you typically dont leave it hooked up forever anyway.
	If someone wants to design and post a buffer circuit go right ahead. I can't be bothered ;)

	Make connections to MAINBRD and run the app.
	MAINBRD needs to be plugged in to AC power.
	Actually powered on or not does not matter.
	While running NandPro application reset will occur.
	After nand operation is complete, reset will be released.

	printf("NandPro dev: -r# Filename (HexStartBlock HexBlockCount)\t->Read\n");	
	printf("NandPro dev: -w# Filename (HexStartBlock HexBlockCount)\t->Write\n");	
	printf("NandPro dev: -e# (HexStartBlock HexBlockCount)\t\t->Erase\n\n");
	printf("dev: is hardware interface usb: or lpt:\n");
	printf("dev: can also be a filename:, to be used as a 'Virtual Nand Device'\n");
	printf("# is nand size (16, 64, 256, 512) in MegaBytes\n");
	printf("(Optional) block ranges, defaults to entire device\n");
	printf("-r# Reads saving file RAW (with ECC)\n");
	printf("-R# Reads saving file without ECC\n");
	printf("-w# Writes RAW (with ECC) file\n");
	printf("+W# Write while ADDING ECC from file without ECC\n");
	printf("+w# Write while FIXING ECC from RAW (with ECC) file\n");

Typical command line:

Read entire 16M flash, including ECC:
	NandPro dev: -r16 nand.bin

Write entire 16M flash, including ECC:
	NandPro dev: -w16 nand.bin

Advanced command line examples:

Read encrypted key vault with ECC:
nandpro dev: -r16 rawkv.bin 1 1

Read encrypted key vault from a "Virtual Nand" dev:, named vnand.bin, with ECC :
nandpro vnand.bin: -r16 rawkv.bin 1 1

Write encrypted key vault:
nandpro dev: -w16 rawkv.bin 1 1

Flash a xell.bin compiler output (no ECC) to block 40, adding ECC while flashing:
nandpro dev: +W16 xell.bin 40

Read config block from a "Virtual Nand", named vnand.bin, without ECC:
nandpro vnand.bin: -R16 configblk.bin 0x??? 1

Write above config block to dev: adding the ECC back in:
nandpro dev: +W16 configblk.bin 0x??? 1

Write a "small" python.ECC file to "full size" "Virtual Nand" :
nandpro vnand.bin: -w16 python.ECC

Write to a dev:, from another file, fixing ECC while writing:
nandpro dev: +w16 DumpWithErrors.bin

General Notes:

Reading and writing defaults to the entire device.
The start block argumnet is optional and dictates the starting block to program.
The ending block is also optional, and end if no block is specified, programming will
	continue until end of file or end of specified nand size.

Large block nands have different ECC format than small block nands.
The software uses the detected device's ECC format for all (+) write operations.
Files written RAW (-) are not translated in any way.

The "nand size" argument only sets the limit of available blocks for device operations.
	It is not hardware related, and need not exactly match the true device.
There is no need to erase before programming.

You can hex edit a block, and use Nanpro to fix or add its ECC when you write it back,
	using the (+) option.

The "Case" of the command generally indicates if I/O file will contain ECC or not
	Upper Case:	No ECC
	Lower Case:	RAW (with ECC)

The "Virtual Nand" file can be read or be programmed, as if it where a device.
The "Virtual Nand" file must be a raw file, containing ECC.
This can be used to extract or inject data from\to an existing raw dump.
Example: To inject a "small" python image into an existing
	"full size" image, or to extract individual blocks from an existing raw dump.



2.0b Release notes:

This release fixes a bug when a sector fails to write, ie it will retry the block now. 
Before it could corrupt the rest of the write. Reading was unaffected.
Also new feature, allows a "virtual nand device": Which is a RAW file, that nandpro pretends is a nand
It can then extract/inject individual blocks from a image, instead of a nand (ie no hardware)
For example you could inject a small xell into a large image with the following:
nandpro completerawimage.bin: -w16 xell.ecc