This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: drivers for LPC2xxx on-chip peripherals
- From: Hans Rosenfeld <rosenfeld at grumpf dot hope-2000 dot org>
- To: Sergei Gavrikov <w3sg at SoftHome dot net>
- Cc: ecos-patches at ecos dot sourceware dot org
- Date: Mon, 13 Aug 2007 01:56:52 +0200
- Subject: Re: drivers for LPC2xxx on-chip peripherals
- References: <20070712152151.GA9252@grumpf.hope-2000.org> <20070812213139.GA6590@ubuntu>
On Mon, Aug 13, 2007 at 12:31:39AM +0300, Sergei Gavrikov wrote:
> > It shouldn't be hard to extend the driver to fully support the simpler
> > devices using all 8k blocks.
Implementing this is really simple, I can do it but someone would have
to test it. This would also involve some checking of the exact LPC2xxx
variant, but I think I could do that at compile time since the HAL
#defines this.
> So, do you have a time to fix it? I did think about one addition, it
> would be or something like flash_lpc2xxx_parts.inl source either some
> expansion your flash_arm_lpc2xxx.c. As I known, there are 3 kinds of the
> LPC2XXX flash geometry. I cut a bit of my code from my own programmer
> for LPC2XXX parts (that had been written in Tcl):
>
> [snipped]
>
> What do you think about? Can you add same mapper in your flash lpc2xxx
> driver code? Do you have a time for this? It would give us a universal
> control for any known LPC2XXX parts.
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.
--
%SYSTEM-F-ANARCHISM, The operating system has been overthrown