Forums

ULINK for IAR (Crossworks)

Started by Unknown June 10, 2009
> 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

An Engineer's Guide to the LPC2100 Series

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
>
>



--- 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

> 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

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:

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)
>
>
>
>
>
>