Re: drivers for LPC2xxx on-chip peripherals

[Sergei Gavrikov <w3sg at SoftHome dot net>]

On Mon, Aug 13, 2007 at 01:56:52AM +0200, Hans Rosenfeld wrote:
> The real problem behind this is that the flash code does AFAIK not
> directly support flash memories with more than one erase block size.
> So for those devices I would have to either pretend that all blocks:
> - use the larger block size, 4 blocks of 64k,
>   that wouldn't be useful and would introduce further problems because
>   the last 8k of flash are reserved on those LPCs I know, or
> - use the smaller block size,
>   this would cause a dependency on malloc() or would introduce a large
>   static buffer for copying stuff around for every erase cycle, and
>   this would also cause a lot of unnecessary wear through extra
>   erase/write cycles.
> 
> I could probably implement the latter in a very simplistic way, not
> copying stuff around when erasing, and just document the odd behaviour,
> but that doesn't seem right to me. I'm also not sure that it would work
> at all with the current flash implementation. It would be better to
> rework the flash code to support multiple erase block sizes.

I would prefer to have more fake oper. cycles than any malloc(64*1024).
But that's just my opinion. And I did think yesterday even about "virtual
sector" stuff in 4 or 8K to resolve this issue. I.e. to introduce a
virtual erasing == a writing of 0xFF there (I talk about IAP oper. "Copy
RAM to Flash"). So, we would have (at first, no having the 'flash_v2'
features) a _slow_ but the _linear_ flash model.

Andrew, Does such a simplification go a far outside the eCos flash
standards?

And another solution would be to put in devs/flash/arm/lpc2xxx a generic
stub (variant low-level driver) which uses NXP IAP calls to operate with
on-chip lpc2xxx flash and a platform related code will be to use those
weak calls.

Well, it seems to me, to have anything in devs/flash/arm/lpc2xxx is the
better than to have nothing :-)

	Sergei