> 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
ULINK for IAR (Crossworks)
Started by ●June 10, 2009
Reply by ●June 11, 20092009-06-11
Reply by ●June 11, 20092009-06-11
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?
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
>
>
Reply by ●June 11, 20092009-06-11
--- 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
>
> > 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
Reply by ●June 12, 20092009-06-12
> 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
> 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
Reply by ●June 12, 20092009-06-12
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)
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)
Reply by ●June 12, 20092009-06-12
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)
>
>
>
>
>
>
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)
>
>
>
>
>
>