2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Hello!

Can i use ULINK JTAG debugger with IAR or Crosswors studios?

I search google and find no results :(
--
Best regards,
Roman Antoshchenkov
mailto:d...@rambler.ru

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> Can i use ULINK JTAG debugger with IAR or Crosswors studios?
>
> I search google and find no results :(

Why not use it with Keil, for which it's intended?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello, Paul.

> Why not use it with Keil, for which it's intended?

It's a good question.

I need time to porting projects from IAR to Keil.

--
Best regards,
Roman Antoshchenkov
mailto:d...@rambler.ru

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, =C0=ED=F2=EE=F9=E5=ED=EA=EE=E2 =D0=EE=EC=E0=
=ED =C2=E8=EA=F2=EE=F0=EE=E2=E8=F7 wrote:
>
> Hello!
>=20
> Can i use ULINK JTAG debugger with IAR or Crosswors studios?
>=20
> I search google and find no results :(
>=20
>=20
> --=20
> Best regards,
> Roman Antoshchenkov
> mailto:djantoxa@...
>
Hi,

Ulink works with Keil and with Keil and also with Keil. Segger J-Link works=
with IAR and with Keil and with Crossworks and with.....
So get yourself an original black J-Link if you want to switch compilers an=
d stick to the hardware.=20
http://www.segger.com/jlink.html

To be honest I do not understand your problem. The compiler whether from Ke=
il or IAR is so much more expensive than the hardware, the time wasted not =
to have the corresponding xxx-Link is so much more than the hardware, what =
is the problem to buy the correct hardware?

Bob

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

> Ulink works with Keil and with Keil and also with Keil. Segger J-Link
works
> with IAR and with Keil and with Crossworks and with.....
> So get yourself an original black J-Link if you want to switch compilers
> and stick to the hardware.
> http://www.segger.com/jlink.html
>
> To be honest I do not understand your problem. The compiler whether from
> Keil or IAR is so much more expensive than the hardware, the time wasted
> not to have the corresponding xxx-Link is so much more than the hardware,
> what is the problem to buy the correct hardware?

One assumes that hardware is a real cost, whereas software isn't.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello, Paul.
> One assumes that hardware is a real cost, whereas software isn't.

You are rigth! I do not commercial devices. And using free versions of
IAR.

--
Best regards,
Roman Antoshchenkov
mailto:d...@rambler.ru

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
>
> > what is the problem to buy the correct hardware?
>
> One assumes that hardware is a real cost, whereas software isn't.
>

One also assumes that one's own development time is not a real cost
either. If you are

a) not paying programmers
b) not being paid to program
c) not producing a commercial product
d) haven't got better things to do in your spare time

all that time wasted trying to work out how to use 'free' unsupported
development software costs nothing as well ;-)

--
Chris Burrows
Armaide v2.0: LPC2xxx Development System
http://www.cfbsoftware.com/armaide

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Chris,

Sometime somewhere life could be more complicated than you could imagine.
If suddenly your salary will be reduced in 4 times, will it mean that life is wasted?
Will you find an other well-paid job? Will you forget programming even it is not paid well?
So don't harry to blame someone for using unsupported tools ;-)

Regards
Vladimir

----- Original Message -----
From: cfbsoftware1
To: l...@yahoogroups.com
Sent: Thursday, June 11, 2009 3:08 AM
Subject: [lpc2000] Re: ULINK for IAR (Crossworks)

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
>
> > what is the problem to buy the correct hardware?
>
> One assumes that hardware is a real cost, whereas software isn't.
>

One also assumes that one's own development time is not a real cost
either. If you are

a) not paying programmers
b) not being paid to program
c) not producing a commercial product
d) haven't got better things to do in your spare time

all that time wasted trying to work out how to use 'free' unsupported
development software costs nothing as well ;-)

--
Chris Burrows
Armaide v2.0: LPC2xxx Development System
http://www.cfbsoftware.com/armaide

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

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

cfbsoftware1 ha scritto:
> --- In l...@yahoogroups.com ,
> "Paul Curtis" wrote:
>>
>>> what is the problem to buy the correct hardware?
>>
>> One assumes that hardware is a real cost, whereas software isn't.
>> One also assumes that one's own development time is not a real cost
> either. If you are
>
> a) not paying programmers b) not being paid to program c) not
> producing a commercial product d) haven't got better things to do in
> your spare time
>
> all that time wasted trying to work out how to use 'free' unsupported
> development software costs nothing as well ;-)
>
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 =E2=82=AC 40=
00,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.
> -- Chris Burrows Armaide v2.0: LPC2xxx Development System
> http://www.cfbsoftware.com/armaide
>

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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 =E2=82=AC =
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-braine=
r issue: you buy them to save you setup time. They need to work well and b=
e 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 a=
nd 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 to=
ols 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, a=
nd I have no intention of arguing against that either. Market forces do wh=
at they usually do.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk=20
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

HI!
you cant work in IAR with your ULINK since it only supports Keil starter
kits and not others......

regards
balaji
2009/6/10 =E1=CE=D4=CF=DD=C5=CE=CB=CF=D7 =F2=CF=CD=C1=CE =F7=C9=CB=D4=CF=D2=
=CF=D7=C9=DE

> Hello!
>
> Can i use ULINK JTAG debugger with IAR or Crosswors studios?
>
> I search google and find no results :(
>
> --
> Best regards,
> Roman Antoshchenkov
> mailto:d...@rambler.ru =20=20
>
[Non-text portions of this message have been removed]

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 =E2=82=AC 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 =E2=82=AC 200000,00 =
value
projects, more of them are projects for less then =E2=82=AC 20000,00 value =
so =E2=82=AC
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
=E2=82=AC 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.
>
> -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and
> now Cortex-M3 processors
>
>

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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "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 =E2=82=AC 4000,00 tool if I can use a similar o=
ne
> >> 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.
>=20
> 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 =E2=82=AC 200000,0=
0 value
> projects, more of them are projects for less then =E2=82=AC 20000,00 valu=
e so =E2=82=AC
> 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
> =E2=82=AC 4000,00 or so for every microcontroller I use and used; they ar=
e 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 argume=
nt is not really valid. On the other hand, looking at free tools the free o=
nes for ARM are among the best because so many people use them.
Doing all kind of microcontroller related things professionally, I am convi=
nced that it is worth to go for commercial tools. The question is whether t=
he commercial tools are from IAR / Keil with dedicated and very good compil=
ers or whether they could be from Rowley or Raisonance, GCC compiler and im=
proved libraries combined with a professional debugger interface and flash =
programming implemented for NXP and most other devices.=20
There is one thing where Keil beats all others, the device simulator, not j=
ust an instruction set simulator. Easy to use and by definition trace build=
-in. IAR supports the wides range of microcontroller families, so if you wa=
nt to use one user interface across a wide variety of architectures, you sh=
ould think about IAR. Crossworks and RIDE7 support a smaller range of MCUs =
but those are very popular and the packages are very good deals.=20

Bob
http://www.mcu-related.com
http://www.lpc2000.com/tools
http://www.mcu-raisonance.com/~lpc21xx23xx24xx-arm7tdmi-nxp__microcontrolle=
rs__sfp~sfp__T016:frlul8k4bkw.html
http://www.rowley.co.uk/arm/

lastly, any chance you could eliminate the html-content off your posting, p=
lease? It only creates garbage

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> > >
> > > Hi,
> > >
> > >> My company works developing electronics, firmware and=20
> 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=
=E2=82=AC30 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=C3=9CV as meeting the requirements for safety related system=
s.
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "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

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

lpc2100_fan ha scritto:
> --- In l...@yahoogroups.com ,
> "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
>>>> =C3=A2=E2=80=9A=C2=AC 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 =C3=A2=E2=
=80=9A=C2=AC
>> 200000,00 value projects, more of them are projects for less then
>> =C3=A2=E2=80=9A=C2=AC 20000,00 value so =C3=A2=E2=80=9A=C2=AC 4000,00 fo=
r 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 =C3=A2=E2=80=9A=C2=AC 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, 6833=
2
-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__microcontrol=
lers__sfp~sfp__T016:frlul8k4bkw.html
> llers__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
>
>

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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, 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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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...@yahoogroups.com
Sent: Thursday, June 11, 2009 7:59 PM
Subject: Re: [lpc2000] Re: ULINK for IAR (Crossworks)

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

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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...@yahoogroups.com, "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...@yahoogroups.com
> Sent: Thursday, June 11, 2009 7:59 PM
> Subject: Re: [lpc2000] Re: ULINK for IAR (Crossworks)
>
>
>
>
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )