--- In , "berrycake33" <berrycake33@y...>
wrote: > --- In , Charles Manning <manningc2@a...>
> wrote:
> >
> > Since you have to support SD card anyway, why not just use a second > SD card
> > instead of the NAND?
> >
> > -- Charles
>
> Charles,
>
> Your explanation benefits me as well.
> Thanks !!
>
> Considering the cost and size,
> we perfer to use NAND flash as built-in memory.
> SD card is for external large storage use.
if you insist to use NAND see http://www.xilinx.com/bvdocs/appnotes/xapp354.pdf
Much easier would be to use SPI interface and for example
serial flash like M25P40 from ST (4Mbit/25MHz/8SO)
There is nothing wrong in using SD card for internal storage either.
--- In , "berrycake33" <berrycake33@y...>
wrote: > --- In , Charles Manning <manningc2@a...>
> wrote:
> >
> > Since you have to support SD card anyway, why not just use a second > SD card
> > instead of the NAND?
> >
> > -- Charles
>
> Charles,
>
> Your explanation benefits me as well.
> Thanks !!
>
> Considering the cost and size,
> we perfer to use NAND flash as built-in memory.
> SD card is for external large storage use. What capacity and speed exactly do you need?
Try serial flash (SPI) from ST like M25P40-4Mbit/25MHz/SO8 or bigger
(And you can have a number of devices on SPI bus)
Reply by berrycake33●April 7, 20042004-04-07
--- In , Charles Manning <manningc2@a...>
wrote: >
> Since you have to support SD card anyway, why not just use a second SD card > instead of the NAND?
>
> -- Charles
Charles,
Your explanation benefits me as well.
Thanks !!
Considering the cost and size,
we perfer to use NAND flash as built-in memory.
SD card is for external large storage use.
Reply by berrycake33●April 6, 20042004-04-06
--- In , Robert Adsett <subscriptions@a...>
wrote: > The obvious reason for doing this is to avoid
conflicts from multiple > process (or interrupts). Other wise you have to
maintain shadow copies of > the outputs and (in an interrupt protected piece
of code) update the shadow > and then the output. In psuedo code something
like:
>
> disable_interrupts()
> shadow_output = shadow_output & ~PERIPH_MASK -- zero area to be updated > shadow_output = shadow_output | (new_value &
PERIPH_MASK) -- update > with new value
> actual_output = shadow_output;
> enable_interrupts()
>
> Some other micros provide similar facilities. The ST10 uses a construct > where a single register affects the I/O bit but
maps two bit in the
> register to each output, one bit patter set the output, a second clears the > output and the other two cause no effect.
It's also used on internal > registers to avoid race conditions on bits that
may be affected by both the > peripheral HW and SW.
>
> Finally note the writeup on the IOPIN register in the user manual "Note: > for test purposes, writing to this register stores
the value in the output > register, bypassing the need to use both the
IOSET
> and IOCLR registers. This feature is of little or no use in an application > because it is not possible to write to individual
bytes in
> this register."
> Robert
>
Thanks, Robert !
You dispel my doubts.
Reply by Lewin A.R.W. Edwards●April 3, 20042004-04-03
> Since you have to support SD card anyway, why not just use a second SD
card > instead of the NAND?
He probably wants to support SSFDC given the description of the rest of
his project.
On Friday 02 April 2004 16:03, microbit wrote: > > > Why is the I2C and SPI all used up? Do
you really have the entire
> >
> > I2C
> >
> > > address space used up? Why can't you spare one of the GPIO
lines as
> >
> > an
> >
> > > SPI chip select and have an SPI flash?
> >
> > SPI gives up to about 128kbytes in a single chip. With NAND flash
you
> > can get up to 256MBytes in a single chip.
>
> On Atmel's DataFlash you get up to like 8 Mbytes in a SPI device, and
also
> with a
> handy dual RAM cache.
> The need to write sectors sequentially for levelling is a pain though.
NAND gives you up to 256MBytes in a single chip and is faster.
-- CHarles
Reply by Charles Manning●April 3, 20042004-04-03
On Friday 02 April 2004 17:46, berrycake33 wrote:
> We had considered NAND control pins,
> they are posited on the rest pins.
> For easy implementing the NAND flash driver,
> we'd like to put NAND data pins in a byte alignment.
Byte alignment is not really a big issue. When you read/write the GPIO all
this costs extra is an extra shift (which is a cheap operation - free in many
cases on ARM).
You do however want your pins to be consecutive if possible (ie D0=P0.n...
D7=P0.n+7)
> That would save some instructions, although the
Philips Set-Clear
> GPIO operation already costs more instructions to implement data I/O.
> ( anybody know that why Philips uses this kind of GPIO operation
> instead of direct setting 0 or 1 ? )
This is one of the first things that really seemed stupid the firt time I
looked at a micro that had set/clear registers. However it is actually very
efficient for cases where a register is used from multiple threads of
execution (eg. main loop and an interrupt service routine).
With set/clear, you just go ahead and set or clear pins. If you did not have
this you'd need to use a shadow register and disable/enable interrupts
which
gets far more costly.
>
> As for I2C and SPI, we use I2C for LCD and SPI for SD Card.
> Besides, we need to transfer data from NAND to SD Card.
OK, I'll bite.
Since you have to support SD card anyway, why not just use a second SD card
instead of the NAND?
-- Charles
Reply by Robert Adsett●April 2, 20042004-04-02
At 05:46 AM 4/2/04 +0000, you wrote: >That would save some instructions, although the
Philips Set-Clear
>GPIO operation already costs more instructions to implement data I/O.
>( anybody know that why Philips uses this kind of GPIO operation
>instead of direct setting 0 or 1 ? )
The obvious reason for doing this is to avoid conflicts from multiple
process (or interrupts). Other wise you have to maintain shadow copies of
the outputs and (in an interrupt protected piece of code) update the shadow
and then the output. In psuedo code something like:
disable_interrupts()
shadow_output = shadow_output & ~PERIPH_MASK -- zero area to be updated
shadow_output = shadow_output | (new_value & PERIPH_MASK) -- update
with new value
actual_output = shadow_output;
enable_interrupts()
Some other micros provide similar facilities. The ST10 uses a construct
where a single register affects the I/O bit but maps two bit in the
register to each output, one bit patter set the output, a second clears the
output and the other two cause no effect. It's also used on internal
registers to avoid race conditions on bits that may be affected by both the
peripheral HW and SW.
Finally note the writeup on the IOPIN register in the user manual "Note:
for test purposes, writing to this register stores the value in the output
register, bypassing the need to use both the IOSET
and IOCLR registers. This feature is of little or no use in an application
because it is not possible to write to individual bytes in
this register."
Robert
" 'Freedom' has no meaning of itself. There are always
restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, III
Reply by Alaric B Snell●April 2, 20042004-04-02
embeddedjanitor wrote:
> SPI gives up to about 128kbytes in a single chip.
With NAND flash you
> can get up to 256MBytes in a single chip.
>
> Also, NAND write speed is far faster.
Are there really no large NAND flash chips with an SPI interface? I've
seen SPI Flash with megabytes on, Atmel do a range of such chips.
> -- Charles
ABS
Reply by berrycake33●April 2, 20042004-04-02
--- In , Charles Manning <manningc2@a...>
wrote: > To implemt a NAND interface you will need more
than just the 8 data pins, you > will also need:
>
> CLE, ALE, CE, RE and WE.
>
> You can probably ignore the R/B line and jsut read back status.
>
> Assuming you are not using SPI at the same time as the NAND, youcould > potentially multiplex the SPPI data pins with two
NAND pins and save two pins. >
> NAND is pretty fun stuff. I suggest you go read stuff about NAND on the linux > mtd and YAFFS www.
>
> -- CHarles
We had considered NAND control pins,
they are posited on the rest pins.
For easy implementing the NAND flash driver,
we'd like to put NAND data pins in a byte alignment.
That would save some instructions, although the Philips Set-Clear
GPIO operation already costs more instructions to implement data I/O.
( anybody know that why Philips uses this kind of GPIO operation
instead of direct setting 0 or 1 ? )
As for I2C and SPI, we use I2C for LCD and SPI for SD Card.
Besides, we need to transfer data from NAND to SD Card.
