Read/nBusy via interrupt

Read/nBusy via interrupt

[Ben Dooks]

Does anyone here have any comments over the pros/cons of using
an interrupt which goes off to wait for a NAND flash ready/not-busy
signal?

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: Read/nBusy via interrupt

[Thomas Gleixner]

On Fri, 2004-10-29 at 00:06 +0100, Ben Dooks wrote:
> Does anyone here have any comments over the pros/cons of using
> an interrupt which goes off to wait for a NAND flash ready/not-busy
> signal?

Sure.

- It makes totaly sense for long lasting operations like program/erase.
- It's overkill for read operations.

You can make it work by supplying a wait function, which implements the
irq driven wait for program/erase. Don't forget the timeout !

tglx

Re: Read/nBusy via interrupt

[Aras Vaichas]

Ben Dooks wrote:
> Does anyone here have any comments over the pros/cons of using
> an interrupt which goes off to wait for a NAND flash ready/not-busy
> signal?
> 

pros of using interrupt:
* faster MTD access (maybe, depends on polling rate) but as a percentage of 
total access time it probably doesn't make much difference.
* less cpu overhead

cons of using interrupt:
* more pins used up on CPU
* more code to write and debug!
* more interrupts going off in system
* more pins needed on MTD -> more expensive boards and chips, longer board 
design times

I'll give you an example from a hardware point of view by way of the Atmel 
Dataflash AT45DB081B.

http://rocky.digikey.com/WebLib/Atmel/Web%20Data/AT45DB081B.pdf
http://www.atmel.com/dyn/products/product_card.asp?family_id=616&family_name=DataFlash%26reg%3B&part_id=2470

The Atmel Dataflash is bootable by the AT91RM9200, and is actually a NOR part 
made to look like a serial NAND.

If you take a look at the 8-CASON part, you'll notice that in order to reduce 
pin count, they leave out the ready/nbusy signal because this information can 
be obtained by polling. This is really a matter of board space as you can fit 
1Megabyte of bootable FLASH into a surface mount 8pin package by leaving out 
this pin.

If you wanted to improve performance, you would simply find out how long the 
MTD usually stays busy for and only resume polling after that time.

If you can spare the board space, why not use interrupts? Make it a kernel 
option. MTD_EADYNBUSY_INTERRUPT ?


Aras Vaichas

Re: Read/nBusy via interrupt

[Thomas Gleixner]

On Fri, 2004-10-29 at 09:43 +1000, Aras Vaichas wrote:
> Ben Dooks wrote:
> > Does anyone here have any comments over the pros/cons of using
> > an interrupt which goes off to wait for a NAND flash ready/not-busy
> > signal?
> > 
> 
> pros of using interrupt:
> * faster MTD access (maybe, depends on polling rate) but as a percentage of 
> total access time it probably doesn't make much difference.

For program and erase it makes a lot of difference. The waiting process
releases the CPU and gets woken when the job is done. Arguing with
percentage of total access time is utter crap here. The poll/yield loop
involves unneccecary context switches, which can significantly influence
the overall system performance on smaller systems.

> * less cpu overhead
> 
> cons of using interrupt:
> * more pins used up on CPU

No. Usually R/B is connected anyway.

> * more code to write and debug!

About 20 lines. I'm scared.

> * more interrupts going off in system

They go only off, when a long lasting operation is in progress

> * more pins needed on MTD -> more expensive boards and chips, longer board 
> design times

He ? NAND FLASH has a ready/busy pin, which does not produce extra
costs. What's the longer design time per pin on complex boards ?
A typical 32bit embedded system CPU board uses alone about 500 pins for
connecting CPU, SDRAM, power and the on chip peripherals. Do you really
want to tell me, that 1 more pin will increase board costs and design
time significantly ?

> If you take a look at the 8-CASON part, you'll notice that in order to reduce 
> pin count, they leave out the ready/nbusy signal because this information can 
> be obtained by polling. This is really a matter of board space as you can fit 
> 1Megabyte of bootable FLASH into a surface mount 8pin package by leaving out 
> this pin.

This is a 1 MByte boot FLASH designed for space constraint devices. You
need a CPU which can boot from those. 

We are talking about NAND >= 32MB, which is often used for filesystems.

> If you wanted to improve performance, you would simply find out how long the 
> MTD usually stays busy for and only resume polling after that time.

Nice plan. Using what ? Typical erase/program time, maximum
erase/program time ? And waiting in the worst case 10ms for something
what takes 3ms ? This improves performance a lot.

> If you can spare the board space, why not use interrupts? Make it a kernel 
> option. MTD_EADYNBUSY_INTERRUPT ?

There's no option neccecary at all. This is board related and has to be
solved by the board driver anyway. The functionality to do so is already
there.

tglx

Re: Read/nBusy via interrupt

[Aras Vaichas]

Thomas Gleixner wrote:
> On Fri, 2004-10-29 at 09:43 +1000, Aras Vaichas wrote:
> 
>>Ben Dooks wrote:
>>
 >>>Does anyone here have any comments over the pros/cons of using
 >>>an interrupt which goes off to wait for a NAND flash ready/not-busy
 >>>signal?
 >>>
 >>
 >>pros of using interrupt:
 >>* faster MTD access (maybe, depends on polling rate) but as a percentage of
 >>total access time it probably doesn't make much difference.
 >
 > For program and erase it makes a lot of difference. The waiting process
 > releases the CPU and gets woken when the job is done. Arguing with
 > percentage of total access time is utter crap here. The poll/yield loop
 > involves unneccecary context switches, which can significantly influence
 > the overall system performance on smaller systems.

"utter crap", is that ISO standard terminology?

I said "faster MTD access". I wasn't talking about efficiency. I was talking 
about the latency between the polling period and the interrupt ... and the 
latency divided by the total access time probably isn't that much as a 
percentage of time "wasted".


>>cons of using interrupt:
>>* more pins used up on CPU
>
> No. Usually R/B is connected anyway.

usually? If the software doesn't need it, then why would you connect it?


>>* more code to write and debug!
> 
> About 20 lines. I'm scared.

No need to be scared. Software engineers don't come for free. development time 
== money.


>>* more interrupts going off in system
> 
> They go only off, when a long lasting operation is in progress

But still more interrupts, I was simply stating the obvious in order to list 
all pros and cons as a complete list.


>>* more pins needed on MTD -> more expensive boards and chips, longer board 
>>design times
> 
> He ? NAND FLASH has a ready/busy pin, which does not produce extra
> costs. What's the longer design time per pin on complex boards ?
> A typical 32bit embedded system CPU board uses alone about 500 pins for
> connecting CPU, SDRAM, power and the on chip peripherals. Do you really
> want to tell me, that 1 more pin will increase board costs and design
> time significantly ?

I never said it would affect it significantly (or did I?). I was simply stating 
the fact that the time does increase. Every pin on a chip costs extra and when 
you are planning on making 10,000+ per year of a product, that price difference 
makes a affects your company's bottom line. If you don't believe me, then take 
a look at the Digikey page for the AT45DB081 and take a long hard look at unit 
price versus pin count.

And yes, routing extra pins does cost more because it takes more time to place 
them. (remember that time == money equation?) Especially if you are trying to 
fit a whole Linux capable system into a small area for a portable, handheld 
product.


>>If you take a look at the 8-CASON part, you'll notice that in order to reduce 
>>pin count, they leave out the ready/nbusy signal because this information can 
>>be obtained by polling. This is really a matter of board space as you can fit 
>>1Megabyte of bootable FLASH into a surface mount 8pin package by leaving out 
>>this pin.
> 
> This is a 1 MByte boot FLASH designed for space constraint devices. You
> need a CPU which can boot from those. 

Doesn't it count as an MTD device? Where did this kernel option come from -> 
"CONFIG_MTD_AT91_DATAFLASH" ??


> We are talking about NAND >= 32MB, which is often used for filesystems.

Ben didn't mention "NAND >= 32MB, which is often used for filesystems", or 
perhaps I read the initial email incorrectly ... hmmm, my bad. The Dataflash 
has a ready/nbusy signal as well. I keep a filesystem on the Dataflash! Am I 
doing something wrong?!? Oh no ... !


>>If you can spare the board space, why not use interrupts? Make it a kernel 
>>option. MTD_EADYNBUSY_INTERRUPT ?
> 
> There's no option neccecary at all. This is board related and has to be
> solved by the board driver anyway. The functionality to do so is already
> there.

Good. That's great!

Thomas, your reply to my email was so ridiculously over the top and harsh. I 
was simply offering an opinion and some information on a useful MTD device from 
the position of someone with hardware experience. Perhaps next time you should 
re-think the tone of your replies and consider the signal-to-noise ratio of 
what you write. I'm sure this forum will be a better place for it.

:)

regards,

Aras

Re: Read/nBusy via interrupt

[jasmine]

> Thomas Gleixner wrote:

>> No. Usually R/B is connected anyway.
>
> usually? If the software doesn't need it, then why would you connect it?

Because hardware engineers usually design the hardware to be as flexible
as possible, in light of the fact that they don't know how the operating
system is going to want to use the hardware.

It's absolutely essential to implement interrupts on the RnB line if
you are going to run a realtime OS on the hardware, because polling
is 100% unacceptable in that situation.  You must poll with interrupts
disabled on a bus-connected Flash because otherwise interrupts and DMA
operations could potentially interfere with Flash operations.

Obviously in a realtime OS with target latency <50usecs, spending maybe
ten milliseconds with interrupts disabled is completely unacceptable.

So, connect the damned wire and shut up.

-J.,
software and hardware engineer.

Re: Read/nBusy via interrupt

[Thomas Gleixner]

On Fri, 2004-10-29 at 19:56 +1000, Aras Vaichas wrote:
> > No. Usually R/B is connected anyway.
> 
> usually? If the software doesn't need it, then why would you connect it?

There's a different between needs it and takes advantage of it. If I can
take advantage, then I will connect it. Using the R/B signal instead of
polling is an advantage.

> >>* more code to write and debug!
> > 
> > About 20 lines. I'm scared.
> 
> No need to be scared. Software engineers don't come for free. development time 
> == money.

Developing efficient polling might need software engineers too. 

> I never said it would affect it significantly (or did I?). I was simply stating 
> the fact that the time does increase. Every pin on a chip costs extra and when 
> you are planning on making 10,000+ per year of a product, that price difference 
> makes a affects your company's bottom line. If you don't believe me, then take 
> a look at the Digikey page for the AT45DB081 and take a long hard look at unit 
> price versus pin count.

I'm aware of high volume designs, where the pin count, pcb size ... has 
to be taken into account.

> Doesn't it count as an MTD device? Where did this kernel option come from -> 
> "CONFIG_MTD_AT91_DATAFLASH" ??

Did I say that ?

> 
> > We are talking about NAND >= 32MB, which is often used for filesystems.
> 
> Ben didn't mention "NAND >= 32MB, which is often used for filesystems", or 
> perhaps I read the initial email incorrectly ... hmmm, my bad. 

Ben was explicitly talking about NAND FLASH, where today the non
obsolete devices start at 32MB

> Thomas, your reply to my email was so ridiculously over the top and harsh. 

Sorry, It was not my intention to offend you. 

> I was simply offering an opinion and some information on a useful MTD device from 
> the position of someone with hardware experience. Perhaps next time you should 
> re-think the tone of your replies and consider the signal-to-noise ratio of 
> what you write. I'm sure this forum will be a better place for it.

Just FYI, I have >20 years hardware/software experience.

Talking about signal/noise ratio. Is an extensive explanation of
DataFlash in answer to a question on NAND FLASH signal or noise ?

tglx

Re: Read/nBusy via interrupt

[Aras Vaichas]

> 
>>Thomas, your reply to my email was so ridiculously over the top and harsh. 
> 
> Sorry, It was not my intention to offend you. 

No problem, it's good that we can all get flared up now again. It shows that we 
are passionate about what we do. In the end, it is just a job and it pays the 
bills. So no need to get so serious about it, there's so much more to life than 
being angry geeks! ;)


jasmine@linuxgrrls.org wrote:
 > Because hardware engineers usually design the hardware to be as flexible
 > as possible, in light of the fact that they don't know how the operating
 > system is going to want to use the hardware.

If this is the case, then the system isn't properly specified, and software 
needs to talk to hardware a little more.

On last Friday, the guy responsible for our hardware had to finish routing our 
PCB. We are replacing an ATmega128 (8bit) with the AT91RM9200 (32bit) in the 
*same* space (plus adding SDRAM, FLASH, Dataflash, ethernet and USB!). There 
came a point where he could route no more connections because there just wasn't 
enough room left - plus the law-of-diminishing-returns was beginning to apply. 
Therefore, he needed to know which signals were absolutely necessary for a 
fully functional design (according to the system spec.) So I had tell him that 
he could use the smaller MTD (without READY/nBUSY) and that it would still work 
with the existing software.


jasmine@linuxgrrls.org wrote:
 > So, connect the damned wire and shut up.

ROFL! So, in a word, "no", because there was no pin for the wire to be 
connected to!

It looks like we have thoroughly answered Ben's original question from various 
passionate points of view.

regards,

Aras