Lpc2000

Hello.

I use IAR C for ARM V4.20a, and I try write FIQ as:
__fiq __arm void my_fiq (void) 

When I open listing, I see this prologue code:

00000000 04E04EE2 SUB LR,LR,#+0x4 
00000004 0F5F2DE9 STMDB SP!,{R0-R3,R8-R12,LR} 

But fiq has own shadow registers r8-r15. 
Why compiler saves this registers in stack?
I think, that this is not necessary and make undesirable overhead.
Can I avoid this somehow?

At 07:57 AM 5/5/05 +0000, andy_moz wrote:
>I use IAR C for ARM V4.20a, and I try write FIQ as:
>__fiq __arm void my_fiq (void)
>
>When I open listing, I see this prologue code:
>
>00000000 04E04EE2 SUB LR,LR,#+0x4
>00000004 0F5F2DE9 STMDB SP!,{R0-R3,R8-R12,LR}
>
>But fiq has own shadow registers r8-r15.
>Why compiler saves this registers in stack?
>I think, that this is not necessary and make undesirable overhead.
>Can I avoid this somehow?

Never trust the compiler for this sort of work.  Do it in assembler.  I've 
run into too many compilers with either poor or outright broken code 
generation in this area to ever rely on it.

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
http://www.aeolusdevelopment.com/

At 06:31 AM 5/5/2005, Robert Adsett wrote:
>...
> >But fiq has own shadow registers r8-r15.
> >Why compiler saves this registers in stack?
> >I think, that this is not necessary and make undesirable overhead.
> >Can I avoid this somehow?
>
>Never trust the compiler for this sort of work.  Do it in assembler.  I've
>run into too many compilers with either poor or outright broken code
>generation in this area to ever rely on it.
>
>Robert

That's kind of sad statement to make.


// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

At 03:45 PM 5/5/05 -0700, Richard wrote:
>At 06:31 AM 5/5/2005, Robert Adsett wrote:
> >...
> > >But fiq has own shadow registers r8-r15.
> > >Why compiler saves this registers in stack?
> > >I think, that this is not necessary and make undesirable overhead.
> > >Can I avoid this somehow?
> >
> >Never trust the compiler for this sort of work.  Do it in assembler.  I've
> >run into too many compilers with either poor or outright broken code
> >generation in this area to ever rely on it.
> >
> >Robert
>
>That's kind of sad statement to make.

Maybe I've just worked with too many compilers, but experience leads me to 
distrust them more the further they get from the core language.  I'm wary 
of any non-standard keyword.  Mind you that's not the only reason I do the 
epilogue and prologue in assembler.  It is also one of the best ways of 
forcing oneself to get to understand the minutia of what happens during an 
interrupt.  I do consider that important knowledge for anyone doing any 
serious work on a micro if interrupts are involved.  Besides, it's not as 
if an interrupt epilogue and prologue are difficult to write.  Anyone doing 
embedded work should have sufficient proficiency with assembly language to 
do that.

I am quite happy with the body of the interrupt being in C in many cases 
although I have run into cases where the body could not be done in C.

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
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Richard <richard-lists@i...> wrote:
> At 06:31 AM 5/5/2005, Robert Adsett wrote:
> >...
> > >But fiq has own shadow registers r8-r15.
> > >Why compiler saves this registers in stack?
> > >I think, that this is not necessary and make undesirable 
overhead.
> > >Can I avoid this somehow?
> >
> >Never trust the compiler for this sort of work.  Do it in 
assembler.  I've
> >run into too many compilers with either poor or outright broken 
code
> >generation in this area to ever rely on it.
> >
> >Robert
> 
> That's kind of sad statement to make.

That might seem sad and cynical, but I think it is true.

THose compilers that generate ISR wrappers with prgmas etc only cater 
for a limited interrupt handling model. To get a reliable system you 
are far better off doing all the interrupt wrapping yourself in 
assembly, then calling regular C functions (without wierd attributes). 
This gives you more flexibility (different irq models), better 
portability (between compilers) and better maintainability (more 
predictable, not subject to problems with different versions of 
compilers).

As for fiqs, the way I see them is as a way to get some sort of "spare 
CPU thread" running, ie they are not just high priority interrupts. As 
an example of what I mean, I have seen fiqs used for "soft dma". If 
you start using C functions in a fiq, then, IMHO, you've missed the 
point.
In this way, the fiq is entirely written in assembler to keepo it very 
small and exploit all the special register stuff.

If you want to do further processing from a fiq event, then you can 
use the VICSoftInt function to schedule a regular interrupt for 
further processing.

IMHO.






> 
> 
> // richard (This email is for mailing lists. To reach me directly, 
please 
> use richard at imagecraft.com)

At 03:32 AM 5/6/05 +0000, embeddedjanitor wrote:
>--- In lpc2000@yahoogroups.com, Richard <richard-lists@i...> wrote:
> > At 06:31 AM 5/5/2005, Robert Adsett wrote:
> > >...
> > > >But fiq has own shadow registers r8-r15.
> > > >Why compiler saves this registers in stack?
> > > >I think, that this is not necessary and make undesirable
>overhead.
> > > >Can I avoid this somehow?
> > >
> > >Never trust the compiler for this sort of work.  Do it in
>assembler.  I've
> > >run into too many compilers with either poor or outright broken
>code
> > >generation in this area to ever rely on it.
> > >
> > >Robert
> >
> > That's kind of sad statement to make.
>
>That might seem sad and cynical, but I think it is true.
>
>THose compilers that generate ISR wrappers with prgmas etc only cater
>for a limited interrupt handling model. To get a reliable system you
>are far better off doing all the interrupt wrapping yourself in
>assembly, then calling regular C functions (without wierd attributes).
>This gives you more flexibility (different irq models), better
>portability (between compilers) and better maintainability (more
>predictable, not subject to problems with different versions of
>compilers).

Well put.  In the end compiler writers have limited resources to develop 
and test.  If I have a choice about where I want them to put their efforts 
it's in basic code generation.  Interrupt epilogue and prologue (or task 
switching or machine register access or.... ) are easily handled in 
assembly leaving the bulk of the code to standard C or C++ code.

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
http://www.aeolusdevelopment.com/

At 06:38 AM 5/6/2005, Robert Adsett wrote:
>...
> > > >Never trust the compiler for this sort of work.  Do it in
> >assembler.  I've
> > > >run into too many compilers with either poor or outright broken
> >code
> > > >generation in this area to ever rely on it.
> > > >
> > > >Robert
> > >
> > > That's kind of sad statement to make.
> >
> >That might seem sad and cynical, but I think it is true.
> >
> >THose compilers that generate ISR wrappers with prgmas etc only cater
> >for a limited interrupt handling model. To get a reliable system you
> >are far better off doing all the interrupt wrapping yourself in
> >assembly, then calling regular C functions (without wierd attributes).
> >This gives you more flexibility (different irq models), better
> >portability (between compilers) and better maintainability (more
> >predictable, not subject to problems with different versions of
> >compilers).
>
>Well put.  In the end compiler writers have limited resources to develop
>and test.  If I have a choice about where I want them to put their efforts
>it's in basic code generation.  Interrupt epilogue and prologue (or task
>switching or machine register access or.... ) are easily handled in
>assembly leaving the bulk of the code to standard C or C++ code.
>
>Robert

Keep in mind that I am one of those compiler writers. Regardless whether a 
compiler company can reasonably support certain extensions that some 
customers may need, my comments about it being "sad statement to make" is a 
response to your statement basically saying that you were not getting good 
results from the compilers and the implications is that you were not 
getting good responses from the compiler vendors for support either.


// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

At 02:55 PM 5/6/05 -0700, Richard wrote:
>At 06:38 AM 5/6/2005, Robert Adsett wrote:
> >...
> >Well put.  In the end compiler writers have limited resources to develop
> >and test.  If I have a choice about where I want them to put their efforts
> >it's in basic code generation.  Interrupt epilogue and prologue (or task
> >switching or machine register access or.... ) are easily handled in
> >assembly leaving the bulk of the code to standard C or C++ code.
> >
> >Robert
>
>Keep in mind that I am one of those compiler writers. Regardless whether a
>compiler company can reasonably support certain extensions that some
>customers may need, my comments about it being "sad statement to make" is a
>response to your statement basically saying that you were not getting good
>results from the compilers and the implications is that you were not
>getting good responses from the compiler vendors for support either.

Catching up on some correspondence.  I spent until 1 in the morning Monday 
on a service call for a client who usually only calls me in on these when 
things are too difficult for his techs.  I ended up dealing with series of 
simple problems (one ended up being a missing! fuse).  I think the techs 
must have fallen asleep.  That of course set me behind.

Actually Richard, I did realize you were one of those compiler writers.  I 
hope you didn't think I was casting aspersions.  And frankly, I don't 
consider a compiler producing bad code for an interrupt keyword to be a bad 
result for a compiler, since I don't consider that to be part of the 
compilers job.  Not being able to multiply two 16 bit numbers together 
correctly, that's a bad compiler and unfortunately, I've seen that too.

Generally I want a pretty utilitarian compiler.  Command line driven, no 
IDE, the smallest number of extensions possible, startup source code, 
bullet-proof code generation, a companion assembler and the best optimizer 
possible.  I don't need or particularly want interrupt support, in-line 
assembler, wizards or keywords to provide access to some particular micro 
feature (usually I only need access to such features for a very (very) 
small portion of the code and that can be easily done in assembly).  I will 
avoid if at all possible, dongles be they hardware or software,compilers 
that only allow access to assembly via in-line assembly, compilers w/o 
linkers and compilers w/o a command line that provides access to all of the 
compiler options.  I already have a good editor and a good make and I don't 
need another one with it's own new set of interface prejudices forced upon 
me.

Compiler extensions can be necessary, but quite frankly, I've yet to see 
the need for any on the ARM architecture.

Support from compiler vendors is all over the map.  One compiler I used, I 
was always using a beta version since they kept fixing bugs I ran into.  I 
suppose that''s good support in the sense that they kept fixing the 
problems (and this was download via modem before internet connections were 
commonplace).

One of my most annoying support issues was not with a compiler vendor but 
an RTOS vendor.  I was developing on a chip that had a lot of errata and 
partly as a result of that I was using a low optimization level on the 
compiler.  I spent some time (weeks) trying to track down a bug that would 
appear and disappear with little apparent rhyme or reason.  It appeared 
that the context was getting corrupted and naturally interrupts were a 
prime suspect.  I finally tracked it down to an operation in the RTOS that 
was supposed to be atomic but took two store operations.  Interestingly 
enough the operation was atomic when the optimizer was turned up since the 
compiler generated a sequence that effectively disabled interrupts during 
the two stores.  With the optimizer was turned down the operation was 
broken into a slightly longer non-atomic sequence.  Being a good customer I 
reported the oversight of not protecting this operation in order to ensure 
it was atomic.  The response?  It wasn't considered a bug since it didn't 
occur at the higher optimization levels!

The worst compiler issue was the 16 bit multiplication above which was 
blamed as being an ANSI requirement.  We replaced the compiler ;)

The best support is the support you don't need :)

Having said that, I've never used a compiler seriously that hasn't broken 
in use.  The only exception so far is GCC and I expect that's just a matter 
of time.  And most of those compilers have been well known and respected.

Enough of the soapbox for now :)

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
http://www.aeolusdevelopment.com/

Robert

> One of my most annoying support issues was not with a compiler vendor but
> an RTOS vendor.  I was developing on a chip that had a lot of errata and
> partly as a result of that I was using a low optimization level on the
> compiler.  I spent some time (weeks) trying to track down a bug that 
> would
> appear and disappear with little apparent rhyme or reason.  It appeared
> that the context was getting corrupted and naturally interrupts were a
> prime suspect.  I finally tracked it down to an operation in the RTOS 
> that
> was supposed to be atomic but took two store operations.  Interestingly
> enough the operation was atomic when the optimizer was turned up since 
> the
> compiler generated a sequence that effectively disabled interrupts during
> the two stores.  With the optimizer was turned down the operation was
> broken into a slightly longer non-atomic sequence.  Being a good 
> customer I
> reported the oversight of not protecting this operation in order to 
> ensure
> it was atomic.  The response?  It wasn't considered a bug since it didn't
> occur at the higher optimization levels!

May I cite you when discussing with customers about the pro's of an 
assembly
written RTOS :-)


-- 
42Bastian Schick

Robert

> Generally I want a pretty utilitarian compiler.  Command line driven, no
> IDE, the smallest number of extensions possible, startup source code,
> bullet-proof code generation, a companion assembler and the best 
> optimizer
> possible.  I don't need or particularly want interrupt support, in-line
> assembler, wizards or keywords to provide access to some particular micro
> feature (usually I only need access to such features for a very (very)
> small portion of the code and that can be easily done in assembly).  I 
> will
> avoid if at all possible, dongles be they hardware or software,compilers
> that only allow access to assembly via in-line assembly, compilers w/o
> linkers and compilers w/o a command line that provides access to all of 
> the
> compiler options.  I already have a good editor and a good make and I 
> don't
> need another one with it's own new set of interface prejudices forced 
> upon
> me.

I agree on this, but for selling a GUI is the thing. Even better an IDE.
My problem with IDEs is, that most if not all are limited. Some do not 
allow
you to build libraries, other hide compiler/linker switches the 
command-line
tool offers but most do not allow to integrate code generators into the 
build
process.
A simple makefile-line:

sconf.c : hello-phyCore2294.xml
	sconf -c $<

is not possible in any IDE I'v seen so far (even not Eclipse, but this one 
is a
horror anyway with only 450MHz :-(

Just the 2cents from an emacs/make addict :-)

-- 
42Bastian Schick

This is not to oversell ourselves or anything, but what you wrote is 
exactly some of the reasons we are somewhat successful. I make conscious 
effort and business decisions to respond to customer wishes. For example, 
by this time, I can outsource or at least have someone else handles the 
initial support, but I found that customers love the fact if they ask us a 
question, they usually get answers from the guy who writes the compilers. 
Our business is now big enough that I have more and more people working for 
me, and I am writing less and less code (but the code generators are mine, 
all mine, bwahahahaha, oops, sorry...), but I think I will continue to do 
this for a while.

Mind you, I don't believe we can make everybody happy and I won't accept 
customer abuses (oh the stories I can tell!), but I enjoy helping people to 
solve their problems, while we are able to put food on the table for the kids.

At 09:15 PM 5/12/2005, Robert Adsett wrote:
>[massive snip...]
>
>Enough of the soapbox for now :)
>
>Robert

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

At 06:45 AM 5/13/05 +0200, 42Bastian Schick wrote:
>Robert
>
> > Generally I want a pretty utilitarian compiler.  Command line driven, no
> > IDE, the smallest number of extensions possible, startup source code,
> > bullet-proof code generation, a companion assembler and the best
> > optimizer
> > possible.  I don't need or particularly want interrupt support, in-line
> > assembler, wizards or keywords to provide access to some particular micro
> > feature (usually I only need access to such features for a very (very)
> > small portion of the code and that can be easily done in assembly).  I
> > will
> > avoid if at all possible, dongles be they hardware or software,compilers
> > that only allow access to assembly via in-line assembly, compilers w/o
> > linkers and compilers w/o a command line that provides access to all of
> > the
> > compiler options.  I already have a good editor and a good make and I
> > don't
> > need another one with it's own new set of interface prejudices forced
> > upon
> > me.
>
>I agree on this, but for selling a GUI is the thing. Even better an IDE.

Yep, I don't expect vendors to stop providing IDEs.  As long as they leave 
a fully functional command line I won't squeal too much although I do 
begrudge the wasted effort.  I sometimes wonder how many editors they think 
I need.

The only decent IDE I've ever seen was Tasking's.  They OEM'ed 
Codewright.  If you already had a good and familiar editor though that is 
still just a waste.

>A simple makefile-line:
>
>sconf.c : hello-phyCore2294.xml
>         sconf -c $<

A man after my own heart :)

>Just the 2cents from an emacs/make addict :-)

Emacs led to Brief which led me to Codewright and now that Borland has 
killed both of those ....

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
http://www.aeolusdevelopment.com/

> I agree on this, but for selling a GUI is the thing. Even better an IDE.
> My problem with IDEs is, that most if not all are limited. Some do not
> allow
> you to build libraries, other hide compiler/linker switches the
> command-line
> tool offers but most do not allow to integrate code generators into the
> build
> process.
> A simple makefile-line:
>
> sconf.c : hello-phyCore2294.xml
> 	sconf -c $<
>
> is not possible in any IDE I'v seen so far (even not Eclipse, but this one
> is a
> horror anyway with only 450MHz :-(
>
> Just the 2cents from an emacs/make addict :-)

My 2c...

I hate IDEs because they lock you in and hide stuff. Too often they force you 
to do things their way. The hiding is a pain because frequently you need to 
do just that little bit more than the IDE offers and you end up digging 
through proprietary ugly configuration stuff.

For me, first prize is:
Source Navigator: Code browsing and editing. The code browser handles all the 
cross references etc so you can hop around your code easily.

Command line make, ld etc  for building.

I think of an IDE as a Swiss Army knife. It is basically a bad to middling 
knife, a bad pair of scissors and a reasobnable corkscrew rolled into one 
easy to use tool. If you want a proper knife, scissors or corkscrew you don't 
use a Swiss Army knife.

Charles and co,

Am I correct that you are just embittered about the way the development 
tools industry is going?

I think you are are totally wrong on the subject of IDEs, and I don't 
believe you've ever used a modern IDE  properly on a real project (from 
start, to completion), or would ever want to.

You should not be sending the wrong signals to younger generation 
programmers who are getting used to IDE based products from birth (well 
pretty soon in any case). Please stop this nonsense.

Here's what I think you should do:
Try out Rowley Associates CrossStudio**** for a couple of projects. Let 
everyone know at LPC2000 how you get on, and whether you still think 
IDE's are waste of time.  You have no excuse, because there is a 30 day 
evaluation of the FULL package available from the Rowley site which you 
can try out:

http://www.rowley.co.uk/arm/index.htm

Where I work, our R&D team have just completed a number of fairly 
complicated projects (450K code) using the above tools, with hundreds of 
modules, where we needed non standard linker scripts for various run 
time environments. It's was all doable within the IDE, and saved in 
project file. We can rebuild a complete project (from CVS) and load it 
into a chip via JTAG with a single click. It's like typing in the name 
of a batch file at the command prompt, but quicker. We can optionally 
connect a debugger (after the code has started running!) just to see 
what's happening - more difficult from a command line I expect.

Yes, we've all done the GNU tools makefile, linker scripts etc, and run 
them from a batch file stuff etc, I myself was a die hard command line 
developer for years - but what a pain, and waste of time. It made we 
feel like a hippy. Remember, makefiles, linker scripts etc were the 
things which put many engineers off from using GNU tools, while IDEs 
have enabled engineers to adopt GNU based tools more readily.

As engineers we should be concentrating on delivering commercially and 
technically successful projects, striving to save on development time, 
but not spending too much time  pondering about what's under the hood of 
a compiler suite. (Though I am not necessarily saying one should have 
blind faith in dev tools, and not take note of what is being generated!!!)

This is why we have IDEs. They focus engineers on one thing: The project.

****[By the way I am not a 'Rowley' sales agent. It's just that Rowley 
is a very good example of how an IDE should work. We evaluated IAR, Keil 
and others, but  found Rowley to have the richest set of development 
tools within one development suite, but at a fraction of the cost (\ufffd500) 
of the competition. We went for Rowlay approximately nine months ago, 
and have never looked back]

Cheers

Jane
 
Charles Manning wrote:

>
> > I agree on this, but for selling a GUI is the thing. Even better an IDE.
> > My problem with IDEs is, that most if not all are limited. Some do not
> > allow
> > you to build libraries, other hide compiler/linker switches the
> > command-line
> > tool offers but most do not allow to integrate code generators into the
> > build
> > process.
> > A simple makefile-line:
> >
> > sconf.c : hello-phyCore2294.xml
> >       sconf -c $<
> >
> > is not possible in any IDE I'v seen so far (even not Eclipse, but 
> this one
> > is a
> > horror anyway with only 450MHz :-(
> >
> > Just the 2cents from an emacs/make addict :-)
>
> My 2c...
>
> I hate IDEs because they lock you in and hide stuff. Too often they 
> force you
> to do things their way. The hiding is a pain because frequently you 
> need to
> do just that little bit more than the IDE offers and you end up digging
> through proprietary ugly configuration stuff.
>
> For me, first prize is:
> Source Navigator: Code browsing and editing. The code browser handles 
> all the
> cross references etc so you can hop around your code easily.
>
> Command line make, ld etc  for building.
>
> I think of an IDE as a Swiss Army knife. It is basically a bad to 
> middling
> knife, a bad pair of scissors and a reasobnable corkscrew rolled into one
> easy to use tool. If you want a proper knife, scissors or corkscrew 
> you don't
> use a Swiss Army knife.
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 13/05/2005
>  
>

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Jane Highland wrote:

>Charles and co,
>
>Am I correct that you are just embittered about the way the development 
>tools industry is going?
>
>I think you are are totally wrong on the subject of IDEs, and I don't 
>believe you've ever used a modern IDE  properly on a real project (from 
>start, to completion), or would ever want to.
>
>You should not be sending the wrong signals to younger generation 
>programmers who are getting used to IDE based products from birth (well 
>pretty soon in any case). Please stop this nonsense.
>  
>
Wrong signals ?

Ever run source navigator ?  Not that much different from using eclipse 
+ cdt plugin .

And what happens when those younger programmers have to work on a system 
there isn't
an ide for ? Or have to work on a product which hasn't had an ide 
developed for it yet ?

Or have to work on maintenance on a older product without an ide ?

Sorry, I can't do that, as there is no ide ?
Get real , we need to be able to work with what ever tools are available.

Ever got fimilar with using command line tools ?
Can be faster especially when compiling when you need to add or change 
options.

All depends on what you are used to and what you are allowed or have to use.

Just because someone uses an ide or not doesn't make them a better 
programmer.

>Here's what I think you should do:
>Try out Rowley Associates CrossStudio**** for a couple of projects. Let 
>everyone know at LPC2000 how you get on, and whether you still think 
>IDE's are waste of time.  You have no excuse, because there is a 30 day 
>evaluation of the FULL package available from the Rowley site which you 
>can try out:
>
<snip stuff about crossworks for arm (which I happen to be half way 
through the eval time)

Ide's can be helpful and they can be very useless , annoying and frustrating to use
(certain ide c.w)



>Cheers
>
>Jane 
>
Lets not have a religious debate. Each to their own preferences

When discussing ide's the discussion always seems to degenerate into 
emacs vs gvim/vim/vi vs ...

Alex

--- In lpc2000@yahoogroups.com, Jane Highland <janehighland@y...> 
wrote:
> Charles and co,
> 
> Am I correct that you are just embittered about the way the 
development 
> tools industry is going?
> 
> I think you are are totally wrong on the subject of IDEs, and I 
don't 
> believe you've ever used a modern IDE  properly on a real project 
(from 
> start, to completion), or would ever want to.
> 
> You should not be sending the wrong signals to younger generation 
> programmers who are getting used to IDE based products from birth 
(well 
> pretty soon in any case). Please stop this nonsense.
> 
> Here's what I think you should do:
> Try out Rowley Associates CrossStudio**** for a couple of 
projects. Let 
> everyone know at LPC2000 how you get on, and whether you still 
think 
> IDE's are waste of time.  You have no excuse, because there is a 
30 day 
> evaluation of the FULL package available from the Rowley site 
which you 
> can try out:
> 
> http://www.rowley.co.uk/arm/index.htm
> 
> Where I work, our R&D team have just completed a number of fairly 
> complicated projects (450K code) using the above tools, with 
hundreds of 
> modules, where we needed non standard linker scripts for various 
run 
> time environments. It's was all doable within the IDE, and saved 
in 
> project file. We can rebuild a complete project (from CVS) and 
load it 
> into a chip via JTAG with a single click. It's like typing in the 
name 
> of a batch file at the command prompt, but quicker. We can 
optionally 
> connect a debugger (after the code has started running!) just to 
see 
> what's happening - more difficult from a command line I expect.
> 
> Yes, we've all done the GNU tools makefile, linker scripts etc, 
and run 
> them from a batch file stuff etc, I myself was a die hard command 
line 
> developer for years - but what a pain, and waste of time. It made 
we 
> feel like a hippy. Remember, makefiles, linker scripts etc were 
the 
> things which put many engineers off from using GNU tools, while 
IDEs 
> have enabled engineers to adopt GNU based tools more readily.
> 
> As engineers we should be concentrating on delivering commercially 
and 
> technically successful projects, striving to save on development 
time, 
> but not spending too much time  pondering about what's under the 
hood of 
> a compiler suite. (Though I am not necessarily saying one should 
have 
> blind faith in dev tools, and not take note of what is being 
generated!!!)
> 
> This is why we have IDEs. They focus engineers on one thing: The 
project.
> 
> ****[By the way I am not a 'Rowley' sales agent. It's just that 
Rowley 
> is a very good example of how an IDE should work. We evaluated 
IAR, Keil 
> and others, but  found Rowley to have the richest set of 
development 
> tools within one development suite, but at a fraction of the cost 
(£500) 
> of the competition. We went for Rowlay approximately nine months 
ago, 
> and have never looked back]
> 
> Cheers
> 
> Jane
>  

Hello, I didn't have time yet to really work with LPC, but there's 
also DEV-C++ (http://www.bloodshed.net/dev/devcpp.html), wich is 
free and seems to be a really nice IDE, if you download only the 
executable it could be use with GNUARM..

Does everyone here ( at least that was programming in 1990 ) remember
the OS wars. DOS command line vs. that new fangled Windows 3.0/3.1 and
OS/2.

Its happening all over again.

Please let the market decide. Those who do not like/want any IDE can
go build their own, and NOT give their money to the IDE writers. 

Please leave this argument in the past.

I remember them well. And I still have a dedicated DOS machine, I use it 
for my PCB design package, since I've never yet found a better one that 
runs under windows, and for quick and dirty testing, especially data 
analysis from micros. I tried doing this in Windows, but even my 
2.8Giggle Hurts running XP/Builder doesn't beat my PIV 550Meg running 
DOS/Borland C. Sure I could go Linux, but then I'd have to find a CAD 
package I liked, fork out around $10k for it and retrain my PCB maker 
and myself to use it.

The market decided, I'm alone with my CAD package, and probably close to 
alone with DOS, but when you've absolutely got to run stuff real fast 
I'd rather have DOS than win anything. I used Wordstar 4 (circa 1987) 
until 1997, when a client insisted on WORD format documents. that was 
when I bought my first windows based machine. WS did everything I needed 
from a word processor, I don't do anything more with Word for XP than I 
did with WS, except WS is only 77k long, the entire package is only 
440k, vs the 400Megs plus that Office uses. Until around 2000 my main 
machines were still DOS based. The windows machine was a curiosity used 
for clients documents only.

Al

donhamilton2002 wrote:

> Does everyone here ( at least that was programming in 1990 ) remember
> the OS wars. DOS command line vs. that new fangled Windows 3.0/3.1 and
> OS/2.
>
> Its happening all over again.
>
> Please let the market decide. Those who do not like/want any IDE can
> go build their own, and NOT give their money to the IDE writers.
>
> Please leave this argument in the past.
>
>
>
>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 13/05/2005
>  
>

At 10:57 AM 5/15/05 +0100, Jane Highland wrote:
>Charles and co,

I'm going to try to take some time to respond to this since I think it 
deserves a thoughtful response and I don't wish this to degenerate into a 
flame war.

>Am I correct that you are just embittered about the way the development
>tools industry is going?

I don't believe so.  My own comments are the result of experience with 
multiple IDEs.  The embedded tools industry is headed in multiple 
directions at once not surprisingly.  Some of those are following the 
desktop trends and some are opposed.

The trends I see
         - a move towards IDEs integrated with the compiler, this matches 
the desktop trends towards monolithic application suites.
         - Dongles, particularly FLEXlm.  This is in opposition to the 
desktop where copy protection was dropped as counter productive years 
ago.  Interestingly enough, I've started seeing hints that embedded tool 
makers are having second thoughts as well.
         - No more documentation.  A trend echoed in both the desktop and 
open-source communities.  The belief seems to be that if the help file is 
not sufficient a PDF file will be.  Often the documentation disappears at 
about the same time that dongles are added.

>I think you are are totally wrong on the subject of IDEs, and I don't
>believe you've ever used a modern IDE  properly on a real project (from
>start, to completion), or would ever want to.

Well, I do use a modern IDE, I suspect Charles does too.  The core of my 
IDE is a modern editor.  It allows me to edit all of my source code for 
multiple target platforms, calls make to rebuild and then assists me in 
finding any errors from the resulting analysis, generation, compile and 
link passes. I've tried a number of compiler included IDEs and never lasted 
more than a few days before their inadequacies got to me.  The only 
exception was a compiler that included an OEM'd commercial editor at about 
the same time as I was looking for a replacement to the current editor I 
was using.  One of the problems I have is that if I used IDEs that came 
with the compiler I'd have to use multiple different IDEs all with there 
own quirks etc... and then integrate in the code generation, static 
analysis tools and revision management tools for each one.  I prefer not 
having to stop and think, 'how do I start the process with this one?'.

>You should not be sending the wrong signals to younger generation
>programmers who are getting used to IDE based products from birth (well
>pretty soon in any case). Please stop this nonsense.

Oh, come now.  Just because I have my own preferences for Editor.  Whether 
we are carpenters, machinists or developers we should know and cherish our 
tools.  A quality familiar tool becomes an extension of oneself.  So it is 
with editors.  Just because I prefer an IDE that doesn't happen to come 
with compiler doesn't make me an evil persona misleading the young ;)


>Yes, we've all done the GNU tools makefile, linker scripts etc, and run
>them from a batch file stuff etc, I myself was a die hard command line
>developer for years - but what a pain, and waste of time. It made we
>feel like a hippy. Remember, makefiles, linker scripts etc were the
>things which put many engineers off from using GNU tools, while IDEs
>have enabled engineers to adopt GNU based tools more readily.

Actually the main reason I started using GNU make was that it was difficult 
to find a decent build environment.  I had been using Borland's make and 
needed a replacement that worked with multiple compilers, code generators 
and other tools.  GNU make fit the bill, no other tool even came 
close.  This need to support multiple compilers may be a big part of the 
difference between our views of compiler included IDEs.  BTW, how have you 
integrated lint with your IDE?  Most of the compiler included IDEs I've 
seen don't have very good provision for that, much less for various code 
generators.

As long as you are happy with the compiler includes IDE go ahead, editors 
are as much a matter of personal preference as they are of any objective 
reality.  I'll keep using a single IDE for my projects, sigh at what I see 
as a waste of resources in the IDE included with the compiler for the 
latest micro and move on.

I don't expect compiler companies to stop developing a myriad of interfaces 
and IDEs but I do expect them to keep including a fully functional command 
line so I can keep using my favourite tools.

At some point I expect I'll give Richard's wizards a try to see if they are 
any better than the ones I've tried so far.

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
http://www.aeolusdevelopment.com/

At 04:17 PM 5/15/05 +0000, donhamilton2002 wrote:
>Does everyone here ( at least that was programming in 1990 ) remember
>the OS wars. DOS command line vs. that new fangled Windows 3.0/3.1 and
>OS/2.
>
>Its happening all over again.

Yep, now they are fighting over Linux/Windows.  I still prefer DOS for 
things like test benches.  Spreadsheets , word processors etc.. have moved 
on, often for the good.

>Please let the market decide. Those who do not like/want any IDE can
>go build their own, and NOT give their money to the IDE writers.

Not giving money to IDE writers is not an option.  You generally get one 
with the compiler whether you want it or not.  I'll whine about that on 
occasion, but I'll only really get upset if I can only access the compiler 
through the provided IDE or someone tells me an idiot for not using it.

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
http://www.aeolusdevelopment.com/

At 02:10 AM 5/16/05 +1000, Alex Gibson wrote:
>Ever run source navigator ?  Not that much different from using eclipse
>+ cdt plugin .

I've been casually looking for a replacement for my current editor since it 
is no longer supported.  I'd forgotten about source navigator, thanks for 
the reminder.

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
http://www.aeolusdevelopment.com/

>> The market decided, I'm alone with my CAD package, and probably 
close to alone with DOS, but when you've absolutely got to run stuff 
real fast
I'd rather have DOS than win anything.  <<

No Al, you're not alone. I too run a DOS package. I've yet to find a 
Windows CAD package that comes anywhere close to being as good as my old 
DOS one for a whole number of reason.

I had a f*ckwit of a boss where I used to work who was constantly 
badgering me to change to a Windows one. The minute I left, he changed 
it and the other engineers there hate the new version. I often think the 
market is decided by complete buffoons passing off as managers who think 
  they know better than the engineers what is the best way to go.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
wrote:
> At 10:57 AM 5/15/05 +0100, Jane Highland wrote:
> >Charles and co,
> 
> I'm going to try to take some time to respond to this since I think
it 
> deserves a thoughtful response and I don't wish this to degenerate
into a 
> flame war.

[deleted]

> BTW, how have you 
> integrated lint with your IDE?  Most of the compiler included IDEs
I've 
> seen don't have very good provision for that, much less for various
code 
> generators.

KEIL's uVision3 has *lint* provision, [and CVS as well].

BTW, I do not work for KEIL.
 
*Objectivity* made me write this observation.
:-)

--roger

At 06:54 PM 5/15/05 +0000, roger_lynx wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
>wrote:
> > At 10:57 AM 5/15/05 +0100, Jane Highland wrote:
> > >Charles and co,
> >
> > I'm going to try to take some time to respond to this since I think
>it
> > deserves a thoughtful response and I don't wish this to degenerate
>into a
> > flame war.
>
>[deleted]
>
> > BTW, how have you
> > integrated lint with your IDE?  Most of the compiler included IDEs
>I've
> > seen don't have very good provision for that, much less for various
>code
> > generators.
>
>KEIL's uVision3 has *lint* provision, [and CVS as well].
>
>BTW, I do not work for KEIL.
>
>*Objectivity* made me write this observation.
>:-)

Ahh, good to see some do.  Does it support 3'rd part code generators as 
well?  The one compiler included IDE I knew that got all of this 'right' 
(that obviously being a rather subjective term ;) was Tasking, which used 
an OEM version of Codewright.  They, unfortunately, dongled their compiler 
a few years ago.  I had to buy a version of one of their compilers 
recently, unfortunately still dongled although they have eased up on it a 
bit.  They are still shipping an OEM version of Codewright.

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
http://www.aeolusdevelopment.com/

On 15 May 2005, at 6:44 pm, Robert Adsett wrote:
> Yep, now they are fighting over Linux/Windows.

And Mac OS X.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

I won't make any more comments than below on this subject.
IDE choice is such a religious issue that it can burn a lot of very valuable 
effort.

However, I am driven to write because I beleive the posting has bias and is 
misinforming.

On Sunday 15 May 2005 21:57, you wrote:
> Charles and co,
>
> Am I correct that you are just embittered about the way the development
> tools industry is going?

No I am not at all embittered.If an IDE works for you, fine, use it.

> I think you are are totally wrong on the subject of IDEs, and I don't
> believe you've ever used a modern IDE  properly on a real project (from
> start, to completion), or would ever want to.

I have a few times. What I didn't particularly like was that the IDE worked 
"its way" and did not give me the flexibility I wanted. Typically, IDEs lock you in, limit what you can 
do, and provide a very bland way of looking at software development.

For the same reason I get the mutters about using compiler/vendor specific 
pragmas etc. 


By using unbundled tools I essentially get myself an IDE on the fly that I 
can fiddle with and gives me lots of options.

For example, I will often use three different debuggers depending on what I 
am doing. I use ddd, insight and raw gdb, because each has a particularly 
valuable way of doing a few things, so I regularly switch debuggers depending 
on what I am doing. I find "one size fits all"  mentality that exists in IDEs 
is just too limiting.

Example 2: I work with multiple host OSs. IDEs are typically Windows only 
(except eclipse) and the unbundled tools approach allows me to work across 
platforms. In this age of globalisation at the project level, these 
flexibilities are becoming more important.

I also believe that effective embedded development requires a good 
understanding of what the tools do, how they work etc. IDEs make that harder 
because they hide so much. I don't believe all those Wizzards etc do much 
that is very useful. I have used them a few times to generate a start-up that 
I have then modified, but so often they have generated wrong stuff and I have 
lost faith.

>
> You should not be sending the wrong signals to younger generation
> programmers who are getting used to IDE based products from birth (well
> pretty soon in any case). Please stop this nonsense.

Just because they are getting used to it does not mean it is right.  Just 
because I say "there are altentatives and I don't like them" does not make 
them wrong.

I don't particularly care if people use IDEs or not, but I feel compelled to 
state my experiences (I have over 20 years of embedded programming 
experience). There are alternatives to IDEs and many people use these 
alternatives with great effect.


>
> Here's what I think you should do:
> Try out Rowley Associates CrossStudio**** for a couple of projects. Let
> everyone know at LPC2000 how you get on, and whether you still think
> IDE's are waste of time.  You have no excuse, because there is a 30 day
> evaluation of the FULL package available from the Rowley site which you
> can try out:
>
> http://www.rowley.co.uk/arm/index.htm

My excuse it this. It is a waste of my time. I already have a perfectly 
acceptable set of tools already.  If you or Rowley pay for my time I might.


> As engineers we should be concentrating on delivering commercially and
> technically successful projects, striving to save on development time,
> but not spending too much time  pondering about what's under the hood of
> a compiler suite. (Though I am not necessarily saying one should have
> blind faith in dev tools, and not take note of what is being generated!!!)

I too deliver multi-k-line solutions using command line tools.

The tranparency is far more difficult with IDEs.
I find that so often the lack of transparency robs you of development time 
etc.

If you don't ponder what is under the hood you will never get sufficient 
understanding to build effective embedded products. On one product I worked 
on, using command line tools has allowed me to do all sorts of configuration 
and compression steps that IDEs would not allow (or at least only do 
reluctantly).  

Not everyone in the team needs to do this. In the projects I work on, only 
one or two people need to know the low level grubby stuff and the rest just 
know "add your C file name to this file".

I'm looking for an optimized JTAG decoder built for fixed-point ARM7.
Is there such a thing, and where do I go look?  Or, is there a
compression standard other that JPEG that gives similar compression with
less CPU bandwidth from a fixed-point CPU like ARM?

I'm using the IJG JPEG decoder, which is excellently written and highly
portable.  Unfortunately, I need about 8X more speed.  I'm going to a
faster CPU with more RAM, but I think it will ultimately take something
more (faster algorithm or implementation) to make everyone happy.

Any advice or insight is greatly appreciated.

Thanks.

Crap.  This message obviously makes no sense.  Please replace "JTAG"
with "JPEG".  I am looking for a faster JPEG decoder for ARM.

> -----Original Message-----
> From: lpc2000@yahoogroups.com
> [mailto:lpc2000@yahoogroups.com] On Behalf Of James Dabbs
> Sent: Sunday, May 15, 2005 7:53 PM
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Optimized ARM JTAG Decoder
> 
> 
> I'm looking for an optimized JTAG decoder built for
> fixed-point ARM7. Is there such a thing, and where do I go 
> look?  Or, is there a compression standard other that JPEG 
> that gives similar compression with less CPU bandwidth from a 
> fixed-point CPU like ARM?
> 
> I'm using the IJG JPEG decoder, which is excellently written
> and highly portable.  Unfortunately, I need about 8X more 
> speed.  I'm going to a faster CPU with more RAM, but I think 
> it will ultimately take something more (faster algorithm or 
> implementation) to make everyone happy.
> 
> Any advice or insight is greatly appreciated.
> 
> Thanks.
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
>

Robert Wood wrote:

> >> The market decided, I'm alone with my CAD package, and probably
> close to alone with DOS, but when you've absolutely got to run stuff
> real fast
> I'd rather have DOS than win anything.  <<
>
> No Al, you're not alone. I too run a DOS package. I've yet to find a
> Windows CAD package that comes anywhere close to being as good as my old
> DOS one for a whole number of reason.

The best thing about my package is that it came fully documented, some 
20+manuals, included all the file formats etc. had its own extended 
memory manager, in the days of 640-k DOS, that has NEVER crashed, and is 
fully extendable by the user. It's probably about 40% or more my own 
work by now. For example I updated the graphics from 800x600 max to 1280 
x 1024, wrote a metric option for it, my own fill procedures. If I want 
a feature it's there, if I don't, like the enforced document control in 
protel, I can roll my own thing.

> I had a f*ckwit of a boss where I used to work who was constantly
> badgering me to change to a Windows one. The minute I left, he changed
> it and the other engineers there hate the new version. I often think the
> market is decided by complete buffoons passing off as managers who think
>   they know better than the engineers what is the best way to go.

Unfortunately I'm not in a position to complain to the boss, she'd 
divorce me if I did.

Al

>
>
> ------------------------------------------------------------------------
> Yahoo! Groups Links
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lpc2000/
>        
>     * To unsubscribe from this group, send an email to:
>       lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 13/05/2005
>  
>

Hi,

I just wanted to share my thoughts (broader
perspective \ufffd not limiting to LPCs alone) on this. I
am an engineer with experience starting with 8bit PICs
to superscale 64bit MIPS multi-processors & have used
a lot of IDEs to do projects from start-to-finish.

Definitely IDEs offer a lot to young engineers (like
myself a couple of years back), as it is easy to work
with & gets the work done with simple image structures
\ufffd which is what is needed in most of the projects.

For others who work with very complex image structure
involving multiple images loaded & executed at various
times & address ranges, with complex load / execution
address mapping for various sections within each image
\ufffd it is almost impossible with IDE tools alone & it is
practice to write the image map by hand (by way of
linker scripts -- ARM calls it scatter load map files)
& also the startup assembly file by hand. GNU make
with shell scripts (some useful commands) can help in
a lot of pre / post processing with the rich set of
tools provided by unix (or cgywin on windows \ufffd I am a
windows person (emacs & VI are still difficult for
me), but I have seen the wonders one can do with unix
utilities like sed, awk \ufffd very powerful indeed). With
Makefile you know exactly what happens piece-by-piece
& you have greater control.

IDEs vs command line tools (GNU make & scripts) can be
compared to point & shoot cameras vs SLRs. By the way
I still use a point & shoot camera for all my pictures
\ufffd hey it works great for me & I don\ufffdt see a reason for
owning a SLR now. That doesn\ufffdt mean someone using it
spend  the extra money & effort in vain. It is
person-to-person & is need based ( I did not
appreciate Makefiles & scripts until the need came for
it much longer after I started my f/w career). With
debuggers, I still use UI debuggers, with GDB -
Insight & even at places I was pushed to use gcc tools
without insight, I use it with emacs to make it look
close to UI debuggers.

CLI tools:
Do you need it? & Can you handle it? For those who
would eventually end up working with complex images \ufffd
should start on them & at 1st it looks very difficult
to work with but later on it is as simple as writing a
README file on notepad. 

Cheers & hope this benefits someone,
-Mike.


		
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/

On Monday 16 May 2005 12:25, James Dabbs wrote:
> Crap.  This message obviously makes no sense.  Please replace "JTAG"
> with "JPEG".  I am looking for a faster JPEG decoder for ARM.

I hate it when I do that too :-).


> > I'm looking for an optimized JTAG decoder built for
> > fixed-point ARM7. Is there such a thing, and where do I go
> > look?  Or, is there a compression standard other that JPEG
> > that gives similar compression with less CPU bandwidth from a
> > fixed-point CPU like ARM?

would think that you first need to evaluate the relative cost of a 
development vs extra hardware. 

If you feel that it is worth doing a special version of code to use cheaper 
CPUs, then I'd take the following approach:
0) If you are not very ARM-savvy, and have a budget, get someone else with 
ARM expertise to do it. eg. say www.bluewatersys.com whom I would recommend 
to anybody. 
- otherwise -
1) Write as much as you can in C. You can help your code run fast by 
following the ARM-friendliness guidelines mentioned a few times before. eg. 
Use U32 variables instead of U8 etc. Look at 
http://www.arm.com/pdfs/DAI0034A_efficient_c.pdf
2) Profile. You'll likely find that a small % of the code contributes a lot 
of overhead. Put effort into optimising that. Get clever using nifty ARM 
features etc.

In general you get better payback by highly optimising 5-10% of the code than 
doing a half-job on all the code.

-- CHarles

On 16 May 2005, at 12:52 am, James Dabbs wrote:
> I'm using the IJG JPEG decoder, which is excellently written and  
> highly
> portable.  Unfortunately, I need about 8X more speed.  I'm going to a
> faster CPU with more RAM, but I think it will ultimately take  
> something
> more (faster algorithm or implementation) to make everyone happy.

You might want to take a look at the RiscOS world- they've been doing  
graphics type stuff on relatively slow ARM hardware (compared to  
current PCs) for many years. You might not find anything suitable in  
an Open Source form, but you could try contacting the authors of some  
of the graphics programs to ask if they are interested in licensing  
an ARM optimised JPEG decoder to you.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

Robert Adsett wrote:

>At 02:10 AM 5/16/05 +1000, Alex Gibson wrote:
>  
>
>>Ever run source navigator ?  Not that much different from using eclipse
>>+ cdt plugin .
>>    
>>
>
>I've been casually looking for a replacement for my current editor since it 
>is no longer supported.  I'd forgotten about source navigator, thanks for 
>the reminder.
>
>Robert
>

Not reffering to codewright ?
I'd like something similar that runs on both linux and OS X (and 
freebsd) as well

Alex


[Non-text portions of this message have been removed]

Anyone looked at SlickEdit?
Looks like CodeWright and runs on all kinds of platforms.

Helge


-----Ursprungligt meddelande-----
Från: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] För Alex
Gibson
Skickat: den 16 maj 2005 15:41
Till: lpc2000@yahoogroups.com
Ämne: Re: [lpc2000] IDE vs. command line ARM development tools (or having
flair vs. wearing flairs)

Robert Adsett wrote:

>At 02:10 AM 5/16/05 +1000, Alex Gibson wrote:
>  
>
>>Ever run source navigator ?  Not that much different from using 
>>eclipse
>>+ cdt plugin .
>>    
>>
>
>I've been casually looking for a replacement for my current editor 
>since it is no longer supported.  I'd forgotten about source navigator, 
>thanks for the reminder.
>
>Robert
>

Not reffering to codewright ?
I'd like something similar that runs on both linux and OS X (and
freebsd) as well

Alex


[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

Jane

> Am I correct that you are just embittered about the way the development
> tools industry is going?

"is going" is correct.

> I think you are are totally wrong on the subject of IDEs, and I don't
> believe you've ever used a modern IDE  properly on a real project (from
> start, to completion), or would ever want to.

Because of my job I have to work with a lot of compilers (from 16Bit to 
64Bit) and
also a lot of IDE's. So I think I have pretty much experience.

- IDE's that integrate the debugger and don't let you easiely change code 
while
debugging are anoying (I know at least 5, 3 for ARM, one for ColdFire,one 
for PPC).
- I normaly use a desktop-switcher (win and linux), so an IDE limits me 
here, since
I can't move windows.

> Here's what I think you should do:
> Try out Rowley Associates CrossStudio**** for a couple of projects. Let
> everyone know at LPC2000 how you get on, and whether you still think
> IDE's are waste of time.  You have no excuse, because there is a 30 day
> evaluation of the FULL package available from the Rowley site which you
> can try out:

I will try this (it's on my road-map) and I will see if:
- I can integrate code-generators
- I can build libraries
- I can integrate special linkers (code-encryption and compression).

Cheers,

-- 
42Bastian Schick

donhamilton2002 <hamilton@...> schrieb am Sun, 15 May 2005 
16:17:35 -0000:

> Does everyone here ( at least that was programming in 1990 ) remember
> the OS wars. DOS command line vs. that new fangled Windows 3.0/3.1 and
> OS/2.
>
> Its happening all over again.
>
> Please let the market decide. Those who do not like/want any IDE can
> go build their own, and NOT give their money to the IDE writers.
>
> Please leave this argument in the past.

It's not about "IDE is evil ! CLI is good !", more about : "Make your IDE 
a worthy
tool with an interface open enough for special use-cases."

-- 
42Bastian Schick

Slickedit works pretty well.  Ashling use the Windows version with 
their LPC2000 tools.

Ian
--- In lpc2000@yahoogroups.com, "Helge Fabricius-Hansen" 
<helge.fabricius@t...> wrote:
>  
> Anyone looked at SlickEdit?
> Looks like CodeWright and runs on all kinds of platforms.
> 
> Helge
> 
> 
> -----Ursprungligt meddelande-----
> Från: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] För 
Alex
> Gibson
> Skickat: den 16 maj 2005 15:41
> Till: lpc2000@yahoogroups.com
> Ämne: Re: [lpc2000] IDE vs. command line ARM development tools (or 
having
> flair vs. wearing flairs)
> 
> Robert Adsett wrote:
> 
> >At 02:10 AM 5/16/05 +1000, Alex Gibson wrote:
> >  
> >
> >>Ever run source navigator ?  Not that much different from using 
> >>eclipse
> >>+ cdt plugin .
> >>    
> >>
> >
> >I've been casually looking for a replacement for my current editor 
> >since it is no longer supported.  I'd forgotten about source 
navigator, 

> >thanks for the reminder.
> >
> >Robert
> >
> 
> Not reffering to codewright ?
> I'd like something similar that runs on both linux and OS X (and
> freebsd) as well
> 
> Alex
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
>  
> Yahoo! Groups Links