Hi:

Most debuggers have that same behavior for local variables. You just need to declare those variables as static, and you will be able to see their value during debugging. If you need to reclaim the used memory, simple remove the static declaration, once you are finish debugging.

Regards,

Alex.

--- In l..., "Vladimir Ljaschko" wrote:
>
> Hi,
>
> The topic started from hw debug tools so I think I need a warning about:
>
> "Crossworks and RIDE7 support a smaller range
> > of MCUs but those are very popular and the packages are very good
> > deals.
> Recently I buy a Primer2 kit from Raisonance and today I started to use
> Ride7."
>
> Ride 7 is nice IDE for GCC, with behavior very close to IAR, but for debuging ...:-(
> First what you will meet is that values of variables which placed in registers will not correctly displayed, and it is hard.
> Debuging in such conditions lost sense.
>
> Regards
> Vladimir
>
> ----- Original Message -----
> From: M. Manca
> To: l...
> Sent: Thursday, June 11, 2009 7:59 PM
> Subject: Re: [lpc2000] Re: ULINK for IAR (Crossworks)
>
>
>
>
>
>

Hi,

The topic started from hw debug tools so I think I need a warning about:

"Crossworks and RIDE7 support a smaller range
> of MCUs but those are very popular and the packages are very good
> deals.
Recently I buy a Primer2 kit from Raisonance and today I started to use
Ride7."

Ride 7 is nice IDE for GCC, with behavior very close to IAR, but for debuging ...:-(
First what you will meet is that values of variables which placed in registers will not correctly displayed, and it is hard.
Debuging in such conditions lost sense.

Regards
Vladimir

----- Original Message -----
From: M. Manca
To: l...
Sent: Thursday, June 11, 2009 7:59 PM
Subject: Re: [lpc2000] Re: ULINK for IAR (Crossworks)

> I do know this Linus is doing everything he can to eliminate the
> possibility of binary distributions.

Linus? You must be trolling.

> No problem; I don't do commercial development. But if I did do
> commercial development, I wouldn't bet the company on 'free' libraries
> and I would want to read the rest of the toolchain licenses very carefully.

Of course, you should! For 'free' and 'commercial' stuff alike.

--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

--- In l..., Wouter van Ooijen wrote:
>
> > The problem with using the 'free' tools for creating commercial products
> > is that NOBODY ON EARTH understands the implications of the licensing.
>
> A great many people do understand the implications. If you just use
> tools (!= libraries) they are in nearly all cases zero.

It's true that GCC seems to be unemcumbered. The libraries are not.

>
> > It gets more complex when variations of the licensing apply to libraries
> > like newlib.
>
> I agree that libraries, and especially mixes of libraries, are a problem.
>
> > Heaven forbid that you try to create a commercial app for
> > Linux.
>
> Why? You can even solve most library problems by using dynamic linking.

I'm not certain how dynamic linking works across various versions of Linux. I don't know that the interface is unchanging or at least backwards compatible.

I do know this Linus is doing everything he can to eliminate the possibility of binary distributions.

In the meantime, it's not important. I don't do commercial development.

>
> > This subject has been discussed here before and I seriously doubt that a
> > definitive answer was discovered re: how much source you have to deliver
> > as a result of choosing to use free tools or libraries.
>
> tools: none
> libraries: read the library license
>
> > If I were to develop a commercial product, I would want a toolchain that
> > had no requirement that I ever deliver source or that imposed no
> > redistribution restrictions or that at least specified clearly what was
> > and what was not redistributable. I would want a commercial compiler
> > just to avoid conflict with the licensing terms applied to 'free'
> > tools/libraries. I would want the ability to distribute pure binary images.
>
> I agree that I want that too.
>
> > The commercial compiler might very well be based on GCC but the
> > libraries should be proprietary and redistributable without restriction.
>
> Such distributions are available, so what's your problem?

No problem; I don't do commercial development. But if I did do commercial development, I wouldn't bet the company on 'free' libraries and I would want to read the rest of the toolchain licenses very carefully.
>
> --
>
> Wouter van Ooijen

Richard

Wouter van Ooijen ha scritto:
>> So, actually I can say that GCC plus a specific library is actually
>> the best solution. In more then 10 years of activity we wrote a
>> standard C liibrary all in C source and we normally use it and not
>> the library present in gcc or commercial compilers.
>
> How exactly do you do this? There are some parts of the library that
> the compiler needs implicitly (memcopy, divide, etc), did you write
> those too? Or did you ensure that those are linked and nothing else?
> If so what are the license implications for those?

You can use a specific C standard library and then use it with a
specific compiler.
Some days ago I wrote the C standard library I am using, it is strictly
a C standard library so libs normally used with GCC are bigger. Also
files management may be an issue, for instance GCC implementation of
printf uses inside the generic approac (based on fprintf) that is the
main cause of its low speed and big waste of code memory. In mine
library I use a pointer to a putchar like function to redirect the
printf output where the application needs (sometimes an uart port,
sometimes a display and so on). Same thing for memory allocation scheme,
in mine library is possible to change the allocation system just change
a function pointer.
For my point of view, C embedded libraries have to provide some sort of
configurable printf to support just a subset of its options and
different devices, some sort of configurable memory allocation scheme
and a simple module to manage startup, exit() and atexit(). Also I don't
know how many commercial C compilers have C99 standard library support.

In embedde systems I would expect to have some sort of standard library
to manage the internal peripherals (of course a different one for every
mcu type) possibly always with the same or similar syntax.
>
> --
>
> Wouter van Ooijen
>
> -- ------- Van Ooijen Technische
> Informatica: www.voti.nl consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
>
>

> So, actually I can say that GCC plus a specific library is actually the
> best solution. In more then 10 years of activity we wrote a standard C
> liibrary all in C source and we normally use it and not the library
> present in gcc or commercial compilers.

How exactly do you do this? There are some parts of the library that the
compiler needs implicitly (memcopy, divide, etc), did you write those
too? Or did you ensure that those are linked and nothing else? If so
what are the license implications for those?
--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

> The problem with using the 'free' tools for creating commercial products
> is that NOBODY ON EARTH understands the implications of the licensing.

A great many people do understand the implications. If you just use
tools (!= libraries) they are in nearly all cases zero.

> It gets more complex when variations of the licensing apply to libraries
> like newlib.

I agree that libraries, and especially mixes of libraries, are a problem.

> Heaven forbid that you try to create a commercial app for
> Linux.

Why? You can even solve most library problems by using dynamic linking.

> This subject has been discussed here before and I seriously doubt that a
> definitive answer was discovered re: how much source you have to deliver
> as a result of choosing to use free tools or libraries.

tools: none
libraries: read the library license

> If I were to develop a commercial product, I would want a toolchain that
> had no requirement that I ever deliver source or that imposed no
> redistribution restrictions or that at least specified clearly what was
> and what was not redistributable. I would want a commercial compiler
> just to avoid conflict with the licensing terms applied to 'free'
> tools/libraries. I would want the ability to distribute pure binary images.

I agree that I want that too.

> The commercial compiler might very well be based on GCC but the
> libraries should be proprietary and redistributable without restriction.

Such distributions are available, so what's your problem?

--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

lpc2100_fan ha scritto:
> --- In l... ,
> "M. Manca" wrote:
>>
>> Paul Curtis ha scritto:
>>>
>>>
>>> Hi,
>>>
>>>> My company works developing electronics, firmware and software
>>>> for other companies, so we have to deal with microcontrollers
>>>> choosen by our customers that normally don't buy C compilers
>>>> and other development tools. So we can buy development tools if
>>>> there is a good budget or if we think that we will use those
>>>> tools in the future. We buyed arm tools because arm is always
>>>> growing but also arm tools have their problems. For instance,
>>>> GCC compiler suite and IAR compiler suite are not so different
>>>> in term of speed and memory used if you don't use GCC libraries
>>>> (if you do you will find that expecially printf family of
>>>> functions waste a lot of code memory). So why have I to buy a
>>>> â‚¬ 4000,00 tool if I can use a similar one that is free? I f
>>>> we have to buy development tool every time our customers ask to
>>>> us to use a new microcontroller we will go out of budget or our
>>>> customers have to pay also for the tools and they don't because
>>>> they give out of the factory the development.
>>>
>>> For businesses that value engineering time, purchasing tools is a
>>> no-brainer issue: you buy them to save you setup time. They need
>>> to work well and be supported well in order to make the
>>> investment work. This means that you price the tool for the
>>> intended market.
>>>
>>> You need some engineer time to invest in free (open source and
>>> no-financial-cost) tools to get them set up. Do it once and use
>>> them again and again and you're not going to go far wrong.
>>>
>>> I can't argue against using no-cost tools--for some parts of the
>>> world it's going to be hard to justify the purchase of what I
>>> consider inexpensive tools given the disparity between wages in
>>> that country and the selling price of the tools. For some it's
>>> like a point of view bordering on religion, and I have no
>>> intention of arguing against that either. Market forces do what
>>> they usually do.
>>
>> Italy is not exactly a part of the world where we don't understand
>> these arguments. The problem is that no all our projects are â‚¬
>> 200000,00 value projects, more of them are projects for less then
>> â‚¬ 20000,00 value so â‚¬ 4000,00 for development tools are too
>> much. My point of view is that the problem is the customer that
>> needs its product and try to lower all development cost without
>> understand what he needs to have its product. So, probably
>> customers prefer to pay for a tool that they will directly use then
>> a tool that will use their consultant (to be honest some time they
>> give us their tools to use and this is obviously the best
>> situation). Personally I am not an open source tool fanatic or
>> expert, I commonly use commercial tools expecially in PC software
>> development but their price is more affordable (they are sold also
>> in more reduced versions) then the major part of embedded
>> development tools. I can't think to pay â‚¬ 4000,00 or so for every
>> microcontroller I use and used; they are more then 50 and they
>> require 14 different C compilers (some are simple different
>> models). Also I can say that a lot of good job was done with GCC
>> compilers and also free IDEs as for AVR microcontrollers. Some
>> companies also choose to sell low price tools as Zilog and
>> Microchip so I really think that microprocessor vendors have to
>> think to their main business also offering low price tools to
>> attract new customers. Of course your opinion have to be different
>> because you are a development tool vendor and correctly this is
>> your main business and you know your effort to develop and sell
>> your product, this is true.
>>> Hi,
>
> there are some many ARM devices from different vendors, I think your
> argument is not really valid.
Ok, I used:
-Hitachi HD6301X, HD6301Y, H8323, H8534, H83048, H83067, H82134/8, H8S2148
-Motorola 6805, 68HC11A8, 68HC11E9, 68HC11F1, 68HC11K4, 68HC12, 68331, 68332
-Zilog eZ8Encore, eZ80Acclaim, Z8
-Intel/various vendors 8031, 8751, 8344, 80C196, 80386SX, 80386EX
-Microchip PIC12xxx, PIC 16F84, PIC18F14K50, PIC18F4450, dspICXXX
-Atmel AVRtiny25/45/85 AVRMegaxxx
for these mcu I need 14 different compilers/debuggers (only for
Hitachi/Renesas 3 different compilers) some of them, the olders, are the
most expensive so when I used them I rent the hw debuggers.

About Atmel and Microchip the investment were very affordable due to low
cost of hw debuggers and also the C compilers; same story for Zilog, but
their IDE/Compiler/debugger is at good level just from the last release.

About ARM microcontrollers the situation is better because they normally
require the same hw debugger and its price is low. The problem about
compilers is that also commercial compilers have bugs and they have to
be solved as in GCC compilers, sometime GCC compilers bugs were solved
in shorter times then in commercial debuggers. Also updating policies
have to be considered before to buy a commercial compiler.
Strictly speaking about C compiler efficiency I absolute confirm the
analysys you may find on Raisonance web.
So, actually I can say that GCC plus a specific library is actually the
best solution. In more then 10 years of activity we wrote a standard C
liibrary all in C source and we normally use it and not the library
present in gcc or commercial compilers.

On the other hand, looking at free
> tools the free ones for ARM are among the best because so many people
> use them. Doing all kind of microcontroller related things
> professionally, I am convinced that it is worth to go for commercial
> tools. The question is whether the commercial tools are from IAR /
> Keil with dedicated and very good compilers or whether they could be
> from Rowley or Raisonance, GCC compiler and improved libraries
> combined with a professional debugger interface and flash programming
> implemented for NXP and most other devices.

The problem is that the price you have to pay have to be correct for
your end business. If you plan to use also ARM microcontrollers or just
2 or 3 microcontroller types the investment is affordable, if you think
to use 20 or 30 microcontroller types probably you have to consider
other possibilities.

There is one thing where
> Keil beats all others, the device simulator, not just an instruction
> set simulator. Easy to use and by definition trace build-in.

I really don't know so much their tools. I am considering to buy MCB1700
from them for our next project, then I will evaluatealso their tools and
I would say something.

IAR
> supports the wides range of microcontroller families, so if you want
> to use one user interface across a wide variety of architectures, you
> should think about IAR.

Yes, this is true but their IDE may be ok for little microcontrollers,
because a lot of useful tools are missed.

Crossworks and RIDE7 support a smaller range
> of MCUs but those are very popular and the packages are very good
> deals.
Recently I buy a Primer2 kit from Raisonance and today I started to use
Ride7.
>
> Bob http://www.mcu-related.com
> http://www.lpc2000.com/tools
> http://www.mcu-raisonance.com/~lpc21xx23xx24xx-arm7tdmi-nxp__microcontrollers__sfp~sfp__T016:frlul8k4bkw.html
>
> http://www.rowley.co.uk/arm/ lastly, any chance you could eliminate the html-content off your
> posting, please? It only creates garbage
>
>

--- In l..., "lpc2100_fan" wrote:
> there are some many ARM devices from different vendors, I think your argument is not really valid. On the other hand, looking at free tools the free ones for ARM are among the best because so many people use them.

>
> Bob

The problem with using the 'free' tools for creating commercial products is that NOBODY ON EARTH understands the implications of the licensing.

It gets more complex when variations of the licensing apply to libraries like newlib. Heaven forbid that you try to create a commercial app for Linux. Maybe that's why there aren't many (any?) commercial apps for Linux. Apps are either free (open source) or they don't exist.

This subject has been discussed here before and I seriously doubt that a definitive answer was discovered re: how much source you have to deliver as a result of choosing to use free tools or libraries.

If I were to develop a commercial product, I would want a toolchain that had no requirement that I ever deliver source or that imposed no redistribution restrictions or that at least specified clearly what was and what was not redistributable. I would want a commercial compiler just to avoid conflict with the licensing terms applied to 'free' tools/libraries. I would want the ability to distribute pure binary images.

The commercial compiler might very well be based on GCC but the libraries should be proprietary and redistributable without restriction.

Richard

> > >
> > > Hi,
> > >
> > >> My company works developing electronics, firmware and
> software for
> > >> other companies, so we have to deal with microcontrollers choosen

I'm not sure why the original simple question warranted such a long thread. The answer is "no" you cannot use ULINK with IAR or CrossWorks.

If money is so tight, use CrossWorks with an Amontec Tiny interface - about €30 for the hardware I think.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

An Engineer's Guide to the LPC2100 Series