Lpc2000

As usual, I'm gonna jump right out there and parade around my naivete
for the spectators...

So,  I got me an old LPC2106 board, and a brand-spankin-new 2148
board, and I've got examples from Keil, IAR, Embedded Artists,
Aoleous, WinARM, etc.  Most of them I've gotten to work.  However, I
have wound up with the world's ugliest stack of mistmatched lpcxyz.h
files, .ld files, makefiles, and the whole nine yards.  Every single
project does the same thing in terms of building, pretty much the same
startup, etc.  Even on stuff made origonally for GCC, there's still
about 99 ways to 'set up' a project (don't get me wrong, this is a
'good thing' in general), but I spend alot of time on cut & paste,
move this register definion to that header, etc.

Now I finally get to my question.  Any support for creating a
'standard' project.  I suspect that's one of the newbie's biggest
complaints.  And I've been around the block maybe once, and it's still
making me crazy.  Especially given how much similarity there is, even
with the commercial stuff, ala IAR & Keil in terms of headers, at
least.  So I'm volunteering to make a distribuition that would include
a peer-reviewed 'best-practices' type set for a raw project, including
a standard set of headers for each lpc now in existence, and make &
.ld.  Since IAR/Keil seems pretty header-friendly, I would even like
to make it compatible with them as well (though I don't know if their
project files that replace make & .ld are 'open').  Before everone
tells me that there's too much customization that *has* to be done,
let me say, I just want to make a 'standard' project that will work
for as many as possible.  Anytime you want to do something fun, you're
going to have to become an expert anyway.  But I haven't seen why I
can make 90% of the examples out there play nice by making a standard
project format to drop them into.  The PIC & AVR guys do it, I think
we should too.  <wink><After all, if we steal from their ranks,
philips will keep making more new lpc's for us to play with></wink>

So, is this a good idea, or no?  Nor do I know anything about a
preferred location, etc.  I'll do the headers, if people give me data
for the new stuff (i.e. 2103), and I have a makefile expert I can
probably do some arm twisting on.  So mostly I'm just asking if it
will be well recived, and if anyone will be willing to review it & try
it on their code.

Steve

On the surface, I like your idea.  But, just on the surface.  One of 
the things that makes Linux complex is the entire configuration 
process and the fact that it runs on so many platforms with so many 
options.  Not that complexity is limited to Linux.

But, any attempt to make a collection of files that work for all cases 
and all platforms is bound to be difficult for newbies, such as 
myself, to grasp.  And, inevitably, it won't be documented.  Kind of 
like newlib.  Great code, no documentation.

FWIW, WinAVR does a fairly decent job of documentation.  But the whole 
package is small.  A few thousand lines of code over a few dozen 
files.  No, I haven't counted them...  But I do use it, at least as a 
model.

I tend to like the KISS principle.  If a line of code isn't necessary, 
toss it.

Other opinions will vary...

Richard

Having started programming microcontrollers in the PIC world, I too
lamented
the lack of comparable standard header files. I think it's a good idea
and
I'd be glad to be a guinea pig and test it on the LPC's that I've got
(currently 2106
and 2131). 

All the best,
Dave

--
Dave Fifield
dave@...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Franks wrote:
> As usual, I'm gonna jump right out there and parade around my naivete
> for the spectators...
> 
> So,  I got me an old LPC2106 board, and a brand-spankin-new 2148
> board, and I've got examples from Keil, IAR, Embedded Artists,
> Aoleous, WinARM, etc.  Most of them I've gotten to work.  However, I
> have wound up with the world's ugliest stack of mistmatched lpcxyz.h
> files, .ld files, makefiles, and the whole nine yards.  Every single
> project does the same thing in terms of building, pretty much the same
> startup, etc.  Even on stuff made origonally for GCC, there's still
> about 99 ways to 'set up' a project (don't get me wrong, this is a
> 'good thing' in general), but I spend alot of time on cut & paste,
> move this register definion to that header, etc.
> 
> Now I finally get to my question.  Any support for creating a
> 'standard' project.  I suspect that's one of the newbie's biggest
> complaints.  And I've been around the block maybe once, and it's still
> making me crazy.  Especially given how much similarity there is, even
> with the commercial stuff, ala IAR & Keil in terms of headers, at
> least.  So I'm volunteering to make a distribuition that would include
> a peer-reviewed 'best-practices' type set for a raw project, including
> a standard set of headers for each lpc now in existence, and make &
> .ld.  Since IAR/Keil seems pretty header-friendly, I would even like
> to make it compatible with them as well (though I don't know if their
> project files that replace make & .ld are 'open').  Before everone
> tells me that there's too much customization that *has* to be done,
> let me say, I just want to make a 'standard' project that will work
> for as many as possible.  Anytime you want to do something fun, you're
> going to have to become an expert anyway.  But I haven't seen why I
> can make 90% of the examples out there play nice by making a standard
> project format to drop them into.  The PIC & AVR guys do it, I think
> we should too.  <wink><After all, if we steal from their ranks,
> philips will keep making more new lpc's for us to play with></wink>
> 
> So, is this a good idea, or no?  Nor do I know anything about a
> preferred location, etc.  I'll do the headers, if people give me data
> for the new stuff (i.e. 2103), and I have a makefile expert I can
> probably do some arm twisting on.  So mostly I'm just asking if it
> will be well recived, and if anyone will be willing to review it & try
> it on their code.

Yes, I think it's a good idea.
I'm a big fan of open-source code. I have some pretty good startup
code and makefiles from embedded artists (it came with my dev.kit)
but I would like to be able to republish the code without having
to worry if it is legal to do so.

All the best,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1qERETD6mlrWxPURAl+YAKCGFkbP3ybBHZIK8RCdRGYb4hJBkQCfbstq
eygsQASd8M8P4yyAgB8XRZ4=
=xMmK
-----END PGP SIGNATURE-----

ok... I will weigh in on this one.
I think you should pretty much stick with the simple "Hello World" 
thing. Making a one-size fits all project is a little bit too onerous 
for most of us out here. What we usually do is make a 
platform-specific one-size fits all for the family of products for our 
clients/customers/bosses.

This is what works for me.

I would...however, really welcome any new driver libraries...fully 
tested, and debugged, complete with documentation, (in the header 
files of course), with some example usage.

Ken Wada

--- In lpc2000@yahoogroups.com, Steve Franks <stevefranks@i...> wrote:
>
> As usual, I'm gonna jump right out there and parade around my 
naivete
> for the spectators...
> 
> So,  I got me an old LPC2106 board, and a brand-spankin-new 2148
> board, and I've got examples from Keil, IAR, Embedded Artists,
> Aoleous, WinARM, etc.  Most of them I've gotten to work.  However, I
> have wound up with the world's ugliest stack of mistmatched lpcxyz.h
> files, .ld files, makefiles, and the whole nine yards.  Every single
> project does the same thing in terms of building, pretty much the 
same
> startup, etc.  Even on stuff made origonally for GCC, there's still
> about 99 ways to 'set up' a project (don't get me wrong, this is a
> 'good thing' in general), but I spend alot of time on cut & paste,
> move this register definion to that header, etc.
> 
> Now I finally get to my question.  Any support for creating a
> 'standard' project.  I suspect that's one of the newbie's biggest
> complaints.  And I've been around the block maybe once, and it's 
still
> making me crazy.  Especially given how much similarity there is, 
even
> with the commercial stuff, ala IAR & Keil in terms of headers, at
> least.  So I'm volunteering to make a distribuition that would 
include
> a peer-reviewed 'best-practices' type set for a raw project, 
including
> a standard set of headers for each lpc now in existence, and make &
> .ld.  Since IAR/Keil seems pretty header-friendly, I would even like
> to make it compatible with them as well (though I don't know if 
their
> project files that replace make & .ld are 'open').  Before everone
> tells me that there's too much customization that *has* to be done,
> let me say, I just want to make a 'standard' project that will work
> for as many as possible.  Anytime you want to do something fun, 
you're
> going to have to become an expert anyway.  But I haven't seen why I
> can make 90% of the examples out there play nice by making a 
standard
> project format to drop them into.  The PIC & AVR guys do it, I think
> we should too.  <wink><After all, if we steal from their ranks,
> philips will keep making more new lpc's for us to play with></wink>
> 
> So, is this a good idea, or no?  Nor do I know anything about a
> preferred location, etc.  I'll do the headers, if people give me 
data
> for the new stuff (i.e. 2103), and I have a makefile expert I can
> probably do some arm twisting on.  So mostly I'm just asking if it
> will be well recived, and if anyone will be willing to review it & 
try

> it on their code.
> 
> Steve
>