ARM IDE & kit similar to CCS for PIC's?

In article <ljadc3t02l1v7bluv91igdfdnuqcfeotni@4ax.com>, Anton Erasmus 
<nobody@spam.prevent.net> writes
>On Fri, 17 Aug 2007 20:43:29 +0100, Chris Hills <chris@phaedsys.org>
>wrote:
>
>>In article <69pbc3pu9n8tkfgffd41kfqedbutbuolum@4ax.com>, Jonathan Kirwan
>><jkirwan@easystreet.com> writes
>>>On Fri, 17 Aug 2007 18:35:07 +0100, Chris Hills <chris@phaedsys.org>
>>>wrote:
>>>
>>>>In article <3ac9c39ad10dids2pvfmgn2u3ommmv6pum@4ax.com>, Jonathan Kirwan
>>>><jkirwan@easystreet.com> writes
>>>>>On Thu, 16 Aug 2007 22:13:53 +0200, Anton Erasmus
>>>>><nobody@spam.prevent.net> wrote:
>>>>>
>>>>>>On Sun, 12 Aug 2007 22:17:20 -0000, The_Todd <toddberk@gmail.com>
>>>>>>wrote:
>>>>>>
>>>>>>>Bear with me as I'm a student mechanical engineer and micro
>>>>>>>controllers are my hobby.
>>>>>>>
>>>>>>>I've become quite familiar with PIC microcontrollers using the CCS
>>>>>>>compiler which I am quite fond of. I started out with their education
>>>>>>>development kit that was a fantastic resource that came with the great
>>>>>>>compiler, hardware, and an excellent work book with simple examples
>>>>>>>and explanations. Its here: http://ccsinfo.com/content.php?page=education
>>>>>>>
>>>>>>>My question is: Is there anything similar to the CCS IDE for the ARM
>>>>>>>controllers? A reasonably priced ($300) well supported and documented
>>>>>>>thats easy to use IDE that supports JTAG etc...? I'm not interested in
>>>>>>>the GNU GCC.
>>>>>>
>>>>>>Both Hitex and Raisonance makes commercial IDEs that can integrate
>>>>>>with GNU GCC. You do not need to write makefiles etc. Both have
>>>>>>demo versions you can download. The basic difference between the
>>>>>>demo and full versions is that the debug support is limited with the
>>>>>>demo versions. Both sell development kits that has the IDE and gcc
>>>>>>bundled with the kit with documentation on getting examples going on
>>>>>>the development kits. The Hitex documentation looks better than the
>>>>>>Raisonance documentations.
>>>>>
>>>>>This debug limitation seems (to me) to be prevalent in the ARM JTAG
>>>>>tool field.  It seems that nearly everyone offering a "simple, cheap,
>>>>>JTAG tool" for ARMs have proprietary debug interfaces,
>>>>
>>>>There are several types of JTAG. The parralell-port ones and the USB
>>>>ones. Most of the parallel-port ones are VERY basic and require a lot of
>>>>work in software as they are usually just a buffer IC. .
>>>
>>>I'm thinking in particular of the USB variety.
>>>
>>>>The USB variants tend to have MCU's in them and therefore can do more in
>>>>the JTAG-debugger  firmware
>>>
>>>Granted.
>>>
>>>>There is a standard RDI interface that most adhere to either as a
>>>>standard or as an optional interface. Though as mentioned most, for
>>>>speed and increased integration use their own system.
>>>
>>>I'm not familiar with the RDI interface.  However, I definitely recall
>>>reading, for example, that the JLINK driver is intentionally limited
>>>in terms of code size (not sure if it was strictly 'code,' but there
>>>was a definite, arbitrary limit placed upon it by the provided
>>>drivers.)
>>
>>Not at all. There are no limits on the J-link (or U-link, R-link,
>>SAM-ICE )
>>Where did you get that information from?
>
>The Raisonance R-Link that one get with their cheap development
>kit has limitations. It only allows 16K RAM Debugging. If one buys the
>IDE, then one has unlimited RAM debugging, but one has to buy their
>more expensive R-link Pro, together with the IDE, which then allows
>unlimted Flash and RAM debugging.

OK so the R-link does have a limit if used with their entry level SW . 
AFAIK there are no limits on the others.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <ip5cc3p6qsflap5squ2d7bn4e0k241ogvj@4ax.com>, Jonathan Kirwan 
<jkirwan@easystreet.com> writes
>On Fri, 17 Aug 2007 21:59:47 +0200, Anton Erasmus
><nobody@spam.prevent.net> wrote:
>
>>On Thu, 16 Aug 2007 20:21:30 GMT, Jonathan Kirwan
>><jkirwan@easystreet.com> wrote:
>>
>>>On Thu, 16 Aug 2007 22:13:53 +0200, Anton Erasmus
>>><nobody@spam.prevent.net> wrote:
>>>
>>>>On Sun, 12 Aug 2007 22:17:20 -0000, The_Todd <toddberk@gmail.com>
>>>>wrote:
>>>>
>>>>>Bear with me as I'm a student mechanical engineer and micro
>>>>>controllers are my hobby.
>>>>>
>>>>>I've become quite familiar with PIC microcontrollers using the CCS
>>>>>compiler which I am quite fond of. I started out with their education
>>>>>development kit that was a fantastic resource that came with the great
>>>>>compiler, hardware, and an excellent work book with simple examples
>>>>>and explanations. Its here: http://ccsinfo.com/content.php?page=education
>>>>>
>>>>>My question is: Is there anything similar to the CCS IDE for the ARM
>>>>>controllers? A reasonably priced ($300) well supported and documented
>>>>>thats easy to use IDE that supports JTAG etc...? I'm not interested in
>>>>>the GNU GCC.
>>>>
>>>>Both Hitex and Raisonance makes commercial IDEs that can integrate
>>>>with GNU GCC. You do not need to write makefiles etc. Both have
>>>>demo versions you can download. The basic difference between the
>>>>demo and full versions is that the debug support is limited with the
>>>>demo versions. Both sell development kits that has the IDE and gcc
>>>>bundled with the kit with documentation on getting examples going on
>>>>the development kits. The Hitex documentation looks better than the
>>>>Raisonance documentations.
>>>
>>>This debug limitation seems (to me) to be prevalent in the ARM JTAG
>>>tool field.  It seems that nearly everyone offering a "simple, cheap,
>>>JTAG tool" for ARMs have proprietary debug interfaces, Windows
>>>drivers, and so on.  This can mean complications for Linux development
>>>and unexpected problems for those imagining they are getting a useful
>>>tool and realizing too late that the debug interface has been hobbled,
>>>intentionally.
>>
>>Yes, It is a problem. Rowley at least offers a Linux as well as
>>Windows version. I cannot recall what the Rowley demo limitations
>>is.
>
>Thanks for that.
>
>What surprises me, generally here, is that ARM is the forte of the GNU
>GCC tools.
No it's not. Arm is one of the few chips GCC is closer to the other 
compilers.

>For all that, the JTAG debugger tools are often not what one might
>expect out of a piece of hardware.  The first warning should be, I
>suppose, that these tools are directly provided BY a compiler vendor
>(Keil, for example) or provided somewhat indirectly but strongly
>pushed by other compiler vendors (IAR, for example.)  As a consequence
>of their own business needs, I think, the hardware isn't treated
>business-wise as hardware tools often are -- well documented for those
>wishing to write their own software to access the full features of the
>hardware -- but instead as a compiler sales tool.

The Keil and IAR HW tools are there specifically to support their 
software. Why would Keil IAR,  etc provide tools to support someone 
else's compilers and debuggers.

Segger do of course support gdn and Gcc with their Sw and hardware. 
However they are commercial and do not to FOSS


>Now for all that, Paul at Rowley has chosen to provide yet-another
>JTAG tool.  But he has explained his reason, and it's a good one.

Everyone has their own business and technical reasons for choosing a 
tool to support or use. The reasons will make sense to their *BUSINESS* 
model  we are in a business not a hobby.

>Still, I had expected to see tools that fully supported the variations
>in the ARM core arena, were fully documented as hardware/firmware
>devices so that others could readily develop their own software

Why?  Why should I give you the information to use my tools with some 
one else's SW rather than buy mine?

>to
>fully use them, and sold by hardware companies who are doing business
>AS hardware companies and not with some other axe to grind.  Instead,
>many of these devices (not all) seem to be marketing tools for
>compiler companies or else

Yes absolutely. No one has ever hide to hide the fact that  most of the 
JTAGS provided by compiler companies are, as I have said several times, 
purely there to support sales of their own compilers and debuggers.

>(as in the case of Segger) quite simply a
>step on the way to selling a high priced

The drivers are not high priced compared to other professional 
offerings.
If you want to go GCC, FOSS and gdb they there are other JTAGS 
available.

>driver that finally opens up
>the features of the hardware you've bought into without expecting this
>bait and switch, so to speak.

That is unjustified. They make things quite plain on their web site and 
literature.


If you are that unhappy witht he current state of the market stop 
whining write your own SW to work with a JTAG you have done yourself.




-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <oq5cc3523igrm89pa34vpfmb99e0ac10qo@4ax.com>, Jonathan Kirwan 
<jkirwan@easystreet.com> writes
>>>
>>>But let's say you are developing under Linux or, even better, FreeBSD.
>>>What's the situation with ULINK2 here?
>>>
>>>Jon
>>
>>There is no situation with U-link.
>
>Agreed.
>
>But to me, it's just a piece of hardware.  It provides a link between
>a USB port and a standard JTAG connector on a target board.  There is
>firmware inside, but there is no good reason I can think of why that
>firmware interface isn't completely publicly disclosed,

Because they use a proprietary interface and their own  IP

> so that 3rd
>parties may, if they wish, write appropriate drivers for full access
>to the hardware capabilities exposed by the firmware inside it.

UVison does that. uLINk is ONLY there to support uVsion NO OTHER REASON

>
>>The Keil  U-link is a piece of hardware specifically designed to support
>>sales of the Keil debugger software.  No more than that.
>
>That's just a restatement of the reality.  However, as I said above, I
>think the point is that it is easy for someone walking into this
>situation to mentally treat a JTAG debugger/downloader tool as a
>hardware tool.  Not as something you can only use specifically with
>Keil debuggers running under their very few supported operating
>environments.

Why?  At no time is it ever treated as anything other than part of the 
Keil tool change. If you want to play by different rules that is your 
affair but stop complaining about it.


>Of course, I checked.  But as I said earlier, there is no good reason
>why the firmware interface isn't completely publicly disclosed.

They don't want to. If they make it available people will use it with 
tools other than uVision they don't want that as they want to sell Keil 
tools.

You don have to buy their JTAG.  Why would you want to if you are not 
going to sue the Keil uVision? There are plenty of other JTAGS out there

>  (This
>is NOT the same thing as asking for the source code to the firmware to
>be disclosed -- only the protocols.)  If that were the case, others
>would quickly write the appropriate servers for gdb.

There are no appropreat gdb servers for the Kiel U-link the ONLY debug 
environment for the Keil U-link is the Keil uVision. If you don't like 
that don't buy the U-link.

Why did you? There are plenty of others about.


>>If you are developing under Linux, Free BSD, Solaris,  VMS, AIX  etc
>>you need to buy a JTAG that has support in those environments.
>
>That is an obvious truth.  It doesn't address what _should be_,
>though.

It does.  That IS what should be. You want something different and are 
complaining that your view is not supported by reality.

>>I am sure there are quite a few JTAGs that have been developed by the
>>FOSS community  (in fact I know there are,  I saw some about 5 years
>>ago)   that have Linux SW . However they are SEVERELY limited because
>>they have no WS windows support......
>
>Actually, I think Windows support almost comes with the territory.

No. There are many JTAG tools that have support for OS that are not MW 
Windows.

>There is a lot of effort that has already gone into allowing execution
>of linux programs under Windows (cygwin?) and into generally adapting
>the GNU GCC compilers for that.  So I don't expect that direction to
>be a serious problem for much of a length of time.  Some of the JTAG
>tools work both ways, too.  For example, I believe there is a free (or
>provided with the tool without extra cost) gdb server for the JLINK.

No the GDB server for the J-link is chargeable,.  But one exists.
There is also a JTAG RDI interface as well

>But as I understand it, that one has severe limits and again the
>protocol is not disclosed so that others can reasonably work to remedy
>that problem on their own.

Of course the protocol is not disclosed.  You buy and use tools you 
don't messaround in side them If you want to do that don't use 
professional tools use the FOSS ones.

>But you mentioned "RDI" and I haven't had
>a chance to research that, yet.  So perhaps I'm wrong here.

Remote Debug Interface. It is the universal JTAG interface you are 
looking for.....


>>Horses for courses.
>I suppose.  But I'd rather that these tools not be treated as a
>"software * hardware" thing and instead as a "software + hardware"
>thing.  In other words, the hardware/firmware is fully documented as a
>tool separated from the software that it may be used with and where
>3rd parties can

Nope....... If you want to do that sign the NDA

>reasonably and meaningfully add value when and where
>they wish to do so.  None of this requires exposure of the internal
>firmware's source code.  Just a complete document regarding signals,
>power supplies, and protocols needed to operate the device one is
>buying.  I don't believe this is unreasonable.

Not difficult to get. Just ask nicely and sign the NDA.

>>Keil U-link is for supporting Keil software
>
>Yes, I got that from you, already.
>
>>Segger J-link is an entry level professional tool The support software
>>is chargeable but the do have  a gdb server.
>
>Yes, there is a separate, unrestricted gdb server that they provide at
>a fairly high cost.
At a very reasonable cost.

>>For Linux and Free BSD there (must be) hardware aimed at it.
>
>I've already found some.
>
>>Try www.Rowely.co.uk  (But don't tell them I sent you It will ruin my
>>street cred  :-)
>
>Paul has already generously provided his own tools and I'm in debt to
>him for that.  They are excellent from my limited use so far, as has
>been his help aside.

SO you are sorted then.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I'm going to piece these responses up a bit.  It's too long....

On Sat, 18 Aug 2007 15:55:04 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>In article <ip5cc3p6qsflap5squ2d7bn4e0k241ogvj@4ax.com>, Jonathan Kirwan 
><jkirwan@easystreet.com> writes
>>On Fri, 17 Aug 2007 21:59:47 +0200, Anton Erasmus
>><nobody@spam.prevent.net> wrote:
>>
>>>On Thu, 16 Aug 2007 20:21:30 GMT, Jonathan Kirwan
>>><jkirwan@easystreet.com> wrote:
>>>
>>>>On Thu, 16 Aug 2007 22:13:53 +0200, Anton Erasmus
>>>><nobody@spam.prevent.net> wrote:
>>>>
>>>>>On Sun, 12 Aug 2007 22:17:20 -0000, The_Todd <toddberk@gmail.com>
>>>>>wrote:
>>>>>
>>>>>>Bear with me as I'm a student mechanical engineer and micro
>>>>>>controllers are my hobby.
>>>>>>
>>>>>>I've become quite familiar with PIC microcontrollers using the CCS
>>>>>>compiler which I am quite fond of. I started out with their education
>>>>>>development kit that was a fantastic resource that came with the great
>>>>>>compiler, hardware, and an excellent work book with simple examples
>>>>>>and explanations. Its here: http://ccsinfo.com/content.php?page=education
>>>>>>
>>>>>>My question is: Is there anything similar to the CCS IDE for the ARM
>>>>>>controllers? A reasonably priced ($300) well supported and documented
>>>>>>thats easy to use IDE that supports JTAG etc...? I'm not interested in
>>>>>>the GNU GCC.
>>>>>
>>>>>Both Hitex and Raisonance makes commercial IDEs that can integrate
>>>>>with GNU GCC. You do not need to write makefiles etc. Both have
>>>>>demo versions you can download. The basic difference between the
>>>>>demo and full versions is that the debug support is limited with the
>>>>>demo versions. Both sell development kits that has the IDE and gcc
>>>>>bundled with the kit with documentation on getting examples going on
>>>>>the development kits. The Hitex documentation looks better than the
>>>>>Raisonance documentations.
>>>>
>>>>This debug limitation seems (to me) to be prevalent in the ARM JTAG
>>>>tool field.  It seems that nearly everyone offering a "simple, cheap,
>>>>JTAG tool" for ARMs have proprietary debug interfaces, Windows
>>>>drivers, and so on.  This can mean complications for Linux development
>>>>and unexpected problems for those imagining they are getting a useful
>>>>tool and realizing too late that the debug interface has been hobbled,
>>>>intentionally.
>>>
>>>Yes, It is a problem. Rowley at least offers a Linux as well as
>>>Windows version. I cannot recall what the Rowley demo limitations
>>>is.
>>
>>Thanks for that.
>>
>>What surprises me, generally here, is that ARM is the forte of the GNU
>>GCC tools.

>No it's not.

Yes, it is.  Aside from x86, anyway.

>Arm is one of the few chips GCC is closer to the other compilers.

That's another way to look at the picture, I suppose.  It doesn't
change or disagree with my comment in the least.

Jon

More pieces....

On Sat, 18 Aug 2007 15:55:04 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>In article <ip5cc3p6qsflap5squ2d7bn4e0k241ogvj@4ax.com>, Jonathan Kirwan 
><jkirwan@easystreet.com> writes
><snip>
>
>>For all that, the JTAG debugger tools are often not what one might
>>expect out of a piece of hardware.  The first warning should be, I
>>suppose, that these tools are directly provided BY a compiler vendor
>>(Keil, for example) or provided somewhat indirectly but strongly
>>pushed by other compiler vendors (IAR, for example.)  As a consequence
>>of their own business needs, I think, the hardware isn't treated
>>business-wise as hardware tools often are -- well documented for those
>>wishing to write their own software to access the full features of the
>>hardware -- but instead as a compiler sales tool.
>
>The Keil and IAR HW tools are there specifically to support their 
>software. Why would Keil IAR,  etc provide tools to support someone 
>else's compilers and debuggers.

I'm not saying they should.  They can choose to operate any way they
want to.  I'm remarking on my surprises about the field generally and
also about the fact that one can easily be caught unaware, stepping
into this arena for the first time.  It's not entirely clear.  I found
the JLINK situation particularly convoluted, in fact.  I had to make
phone calls to folks who knew about these things, in some detail,
before the situation began to resolve itself out in more clear
fashion.  Frankly, and I can't say this with any certainty at all but
it is my impression, I think some of this confusion (or the lack of
clarity, at least) is a bit intentional.  Of course, to each their own
impressions.

>Segger do of course support gdn and Gcc with their Sw and hardware. 
>However they are commercial and do not to FOSS

So what?  I've no argument that Segger has every right to operate the
way they please.  Same with IAR.  Same with Keil/ARM.  You are
completely missing my point.  I suppose because you are reading me
with a jaundiced eye, looking for motivations I don't have, instead of
taking me at face value.

I'll try again.

The background for the point I'm making here is that the GNU tools are
pretty well vetted for ARM.  There is a well-worn path here.  (If you
disagree with this, you and I will NEVER find common ground on these
points and you and I might as well quit talking right now.)  GNU tools
are often used by hobbyists and, over recent years, the ARM7TDMI core
is being found in many, many more attractive packagings for hobbyist
use and the cost of "getting a quality board done" is now rather
modest and there is even the possibility of doing toaster-oven (with
paste) SMT mounting in your kitchen.  Not only that, companies like
Embedded Artists are producing rather low-cost, high functionality
boards that are in the hobbyist range.  In other words, it seems to me
that there is a wider audience in the hobbyist market for these kinds
of cpus.

With that background, I'd normally imagine that there would be a few
folks designing USB JTAG debuggers/code downloaders to complete the
picture and smooth the path for students and other hobbyists wanting
to learn using GNU development tools and some USB JTAG debugger.  What
I've found is a rather complex situation that seems difficult to
navigate, which is exactly the wrong thing for hobyyists and students.
It's not even particularly easy for me.  And I'm supposed to know what
I'm doing.  Luckily, I know how to make phone calls, write emails,
read a variety of web pages on the subject and eventually ferret out
some small measure of an understanding.  But I have to say that even
with my experience in this, there were still some unanticipated
surprises lurking.  And I would have hoped for better.  Particularly,
for hobbyists and students.  I conclude that the path is not so
well-worn for them.

None of this says anything about twising the arm of Keil, for example.
They have every right to do what they do.  On their own web page on
the ULINK2, they say they support GNU tools.  But you have to read
between the lines, when reading further on, that this support only
applies to their uVision.  One might very well take the impression
from that web page, reading about GNU tool support, that the ULINK2 is
fully compatible with a Linux installation of the GNU tools.  Until
one looks really closely and notices the check-off box for it on
uVision and then also takes the idea that uVision probably only runs
under Windows.

I know you will disagree, but I consider this a bit sly of them.  By
now, I'm sure they've had all manner of support calls regarding this
question and I've no doubt that the subject of putting up clearer
discussions about these details has arrived in internal meetings on
the subject.  It's not hard to include a better discussion on that web
page and I'm fairly sure that there has been a business decision made
to not do so.  Not good, in my mind.

This isn't just about Keil, either.  A different, but similar in a
way, situation exists with the JLINK.  I had to look at web pages
showing a yellow one and other pages showing a black one to realize
that there is something going on.  So I made a series of phone calls
and finally got an accurate accounting about this situation.  In
addition, I tracked down the Segger web site after reading other web
pages talking about limitations in the gdb server provided, to see for
myself the cost of buying an unlimited gdb server from them.  Nothing
in the ads selling a demo board and a USB JTAG JLINK unit included
information discussing the differences in hardware revisions, firmware
revisions (and there are some important differences here), or that the
gdb server might be intentionally hampered.  And you cannot easily
find this out.

As I've started to survey the field here, I've found that there remain
a number of intentionally designed-in limitations and other more
subtle ones (such as RTCK or firmware/hardware differences in a
product only listed as JLINK without any disclosure of which one of
myriad versions is being offered.)  It's a complex thing to navigate
for a hobbyist or student.

Jon

More...

On Sat, 18 Aug 2007 15:55:04 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>In article <ip5cc3p6qsflap5squ2d7bn4e0k241ogvj@4ax.com>, Jonathan Kirwan 
><jkirwan@easystreet.com> writes

>>Now for all that, Paul at Rowley has chosen to provide yet-another
>>JTAG tool.  But he has explained his reason, and it's a good one.
>
>Everyone has their own business and technical reasons for choosing a 
>tool to support or use. The reasons will make sense to their *BUSINESS* 
>model  we are in a business not a hobby.

Agreed.  As I've said before, you all are free to operate any way you
please.  And I can complain about it, if I choose to.  Mostly, I just
think this situation is confusing enough that people need to at least
be aware of the complexity.  And I'm glad to point that out, after the
discussions about it I've had in the last month or so.

>>Still, I had expected to see tools that fully supported the variations
>>in the ARM core arena, were fully documented as hardware/firmware
>>devices so that others could readily develop their own software
>
>Why?  Why should I give you the information to use my tools with some 
>one else's SW rather than buy mine?

Not you, Chris.  You are permitted to do anything you please.  And, if
it doesn't fit my needs, I'll just ignore you.

The point I was making is as I said in an earlier reply to this post
from you, today.  Read the part starting:

"The background for the point I'm making here is ..."
--and--
"With that background, I'd normally imagine that ..."

That covers where I'm coming from.  You are being defensive about
this.  And I'm not chipping at you, or how you want to do your
business.  I'm talking about something entirely different.  You just
cannot see it, because you are so deeply defensive that you cannot
read with understanding whenever you see "trigger words" to you.

>>to
>>fully use them, and sold by hardware companies who are doing business
>>AS hardware companies and not with some other axe to grind.  Instead,
>>many of these devices (not all) seem to be marketing tools for
>>compiler companies or else
>
>Yes absolutely. No one has ever hide to hide the fact that  most of the 
>JTAGS provided by compiler companies are, as I have said several times, 
>purely there to support sales of their own compilers and debuggers.

That's the way it seems regarding many of those with a greater
presence on the web.  That doesn't in any way mean that there should
NOT be some others offering alternate paths.  Yet, the situation
remains a seemingly complex one for hobbyists and students.

>>(as in the case of Segger) quite simply a
>>step on the way to selling a high priced
>
>The drivers are not high priced compared to other professional 
>offerings.

But I've always been talking about hobbyists and students.  And it
isn't priced for them, obviously.

>If you want to go GCC, FOSS and gdb they there are other JTAGS 
>available.

Name a few that are (1) USB based, (2) support RTCK, (3) are well
documented for those wishing to write their own software to access the
full features of the hardware/firmware included, and (4) have
unfettered gdb servers available for them in source form so that they
can be compiled on various environments and modified, as needed.

I'm sincerely interested.

>>driver that finally opens up
>>the features of the hardware you've bought into without expecting this
>>bait and switch, so to speak.
>
>That is unjustified. They make things quite plain on their web site and 
>literature.

I've already pointed out elsewhere that this isn't true, in detail.
One only needs to look at Keil's web site for the ULINK2, for example,
to see my point made manifest.  And I can point out many more examples
in the case of the JLINK.  It is difficult to know exactly what you
are getting.  Period.

>If you are that unhappy witht he current state of the market stop 
>whining write your own SW to work with a JTAG you have done yourself.

I am free to discuss this in the context of the discussions here and I
don't have to obey your "put up or shut up" suggestion.  One can have
an opinion without having to be a solution provider.

Jon

On Sat, 18 Aug 2007 16:09:23 +0100, Chris Hills <chris@phaedsys.org>
wrote:

>In article <oq5cc3523igrm89pa34vpfmb99e0ac10qo@4ax.com>, Jonathan Kirwan 
><jkirwan@easystreet.com> writes
>>>>
>>>>But let's say you are developing under Linux or, even better, FreeBSD.
>>>>What's the situation with ULINK2 here?
>>>>
>>>>Jon
>>>
>>>There is no situation with U-link.
>>
>>Agreed.
>>
>>But to me, it's just a piece of hardware.  It provides a link between
>>a USB port and a standard JTAG connector on a target board.  There is
>>firmware inside, but there is no good reason I can think of why that
>>firmware interface isn't completely publicly disclosed,
>
>Because they use a proprietary interface and their own  IP

That's just a restatement of the situation, not an explanation.  So...
try again?

>> so that 3rd
>>parties may, if they wish, write appropriate drivers for full access
>>to the hardware capabilities exposed by the firmware inside it.
>
>UVison does that. uLINk is ONLY there to support uVsion NO OTHER REASON

Go look at my other post on this subject in reply to you, elsewhere.

>>>The Keil  U-link is a piece of hardware specifically designed to support
>>>sales of the Keil debugger software.  No more than that.
>>
>>That's just a restatement of the reality.  However, as I said above, I
>>think the point is that it is easy for someone walking into this
>>situation to mentally treat a JTAG debugger/downloader tool as a
>>hardware tool.  Not as something you can only use specifically with
>>Keil debuggers running under their very few supported operating
>>environments.
>
>Why?  At no time is it ever treated as anything other than part of the 
>Keil tool change. If you want to play by different rules that is your 
>affair but stop complaining about it.

Why should I stop complaining?  Because you say so?  No.

I think it is important to discuss some of the difficulties and I
don't need you telling me that in order to discuss them I have to
enter the business arena with a different solution.  That's crazy.

>>Of course, I checked.  But as I said earlier, there is no good reason
>>why the firmware interface isn't completely publicly disclosed.
>
>They don't want to.

Yes.  I'm sure glad you have such deep insight to offer here.  ;)

>If they make it available people will use it with 
>tools other than uVision they don't want that as they want to sell Keil 
>tools.

I gather that.  I'm glad, of course, that you are willing to put this
in writing.  What that means is that one needs to be VERY WARY and
VERY CAREFUL about what they want as student, hobbyist, or
professional developer versus what the motivations are for those
offering what appears otherwise to be a simple hardware tool.

I guess it just means "buyer beware."

>You don have to buy their JTAG.  Why would you want to if you are not 
>going to sue the Keil uVision? There are plenty of other JTAGS out there

I might simply because I like the idea of using the tool to program a
demo board I also buy.  Or I might buy a "yellow" JLINK along with a
demo board (the "yellow" one is only allowed to be sold with a demo
board or some similar situation and the "black" one is sold separately
-- and there are differences between them, even not counting firmware
versions) and imagine I can just play around with it, not realizing
before the purchase that there has been some intentional hampering of
gdb support.

One eventually WILL discover this, of course.  But I'd rather the
manufacturers make it abundantly clear at the outset, because I don't
think students and hobbyists are necessarily expected to ferret all
this out on their own.

>>  (This
>>is NOT the same thing as asking for the source code to the firmware to
>>be disclosed -- only the protocols.)  If that were the case, others
>>would quickly write the appropriate servers for gdb.
>
>There are no appropreat gdb servers for the Kiel U-link the ONLY debug 
>environment for the Keil U-link is the Keil uVision. If you don't like 
>that don't buy the U-link.

Agreed.  But on their web page for the ULINK2, they say they support
GNU tools.  You have to read between the lines, when reading further
on, that this support only applies to their uVision and then to
further infer that this means Windows-only and thus no gdb support.
It's not all that clear, unless you are looking for trouble and
reading closely.

>Why did you? There are plenty of others about.

Name a few that are (1) USB based, (2) support RTCK, (3) are well
documented for those wishing to write their own software to access the
full features of the hardware/firmware included, and (4) have
unfettered gdb servers available for them in source form so that they
can be compiled on various environments and modified, as needed.

I'm sincerely interested.

>>>If you are developing under Linux, Free BSD, Solaris,  VMS, AIX  etc
>>>you need to buy a JTAG that has support in those environments.
>>
>>That is an obvious truth.  It doesn't address what _should be_,
>>though.
>
>It does.  That IS what should be. You want something different and are 
>complaining that your view is not supported by reality.

My point was that you are just stating the obvious.

Now name a few that are (1) USB based, (2) support RTCK, (3) are well
documented for those wishing to write their own software to access the
full features of the hardware/firmware included, and (4) have
unfettered gdb servers available for them in source form so that they
can be compiled on various environments and modified, as needed.

I'm sincerely interested.

>>>I am sure there are quite a few JTAGs that have been developed by the
>>>FOSS community  (in fact I know there are,  I saw some about 5 years
>>>ago)   that have Linux SW . However they are SEVERELY limited because
>>>they have no WS windows support......
>>
>>Actually, I think Windows support almost comes with the territory.
>
>No. There are many JTAG tools that have support for OS that are not MW 
>Windows.

Name a few that are (1) USB based, (2) support RTCK, (3) are well
documented for those wishing to write their own software to access the
full features of the hardware/firmware included, and (4) have
unfettered gdb servers available for them in source form so that they
can be compiled on various environments and modified, as needed.

I'm sincerely interested.

>>There is a lot of effort that has already gone into allowing execution
>>of linux programs under Windows (cygwin?) and into generally adapting
>>the GNU GCC compilers for that.  So I don't expect that direction to
>>be a serious problem for much of a length of time.  Some of the JTAG
>>tools work both ways, too.  For example, I believe there is a free (or
>>provided with the tool without extra cost) gdb server for the JLINK.
>
>No the GDB server for the J-link is chargeable,.  But one exists.

Yes.  And you KNOW this isn't news to me.  I pointed out this fact in
my very first post here on the subject, so you should KNOW I already
know this fact.  You are saying nothing new to me and you know it is
of no help, nor does it address itself to my points.

>There is also a JTAG RDI interface as well

This, I still need to research.  Any pointers?

>>But as I understand it, that one has severe limits and again the
>>protocol is not disclosed so that others can reasonably work to remedy
>>that problem on their own.
>
>Of course the protocol is not disclosed.  You buy and use tools you 
>don't messaround in side them If you want to do that don't use 
>professional tools use the FOSS ones.

Name a few that are (1) USB based, (2) support RTCK, (3) are well
documented for those wishing to write their own software to access the
full features of the hardware/firmware included, and (4) have
unfettered gdb servers available for them in source form so that they
can be compiled on various environments and modified, as needed.

I'm sincerely interested.

>>But you mentioned "RDI" and I haven't had
>>a chance to research that, yet.  So perhaps I'm wrong here.
>
>Remote Debug Interface. It is the universal JTAG interface you are 
>looking for.....

Any tools you'd like to point out here that might nicely address the
needs of a hobbyist or student without code size limitations or hidden
costs to buy one?

>>>Horses for courses.
>>I suppose.  But I'd rather that these tools not be treated as a
>>"software * hardware" thing and instead as a "software + hardware"
>>thing.  In other words, the hardware/firmware is fully documented as a
>>tool separated from the software that it may be used with and where
>>3rd parties can
>
>Nope....... If you want to do that sign the NDA

It doesn't have to be that way.  I have purchased many a piece of
equipment with full disclosure of their operating details and
protocols.  This isn't new or news to those in the hardware business.
The problem seems to be that we have dominant software companies
selling hardware as a teaser for their software products and not
enough alternatives to that situation.  I'm not trying to solve this,
just point it out.

>>reasonably and meaningfully add value when and where
>>they wish to do so.  None of this requires exposure of the internal
>>firmware's source code.  Just a complete document regarding signals,
>>power supplies, and protocols needed to operate the device one is
>>buying.  I don't believe this is unreasonable.
>
>Not difficult to get. Just ask nicely and sign the NDA.

Really?  Would this mean that someone intending to put out a GPL'd gdb
server would be able to do so?  Or do you imagine that this NDA would
prevent that?

I think this is just a red herring of yours, Chris.  It's just the
same problem under another guise.

>>>Keil U-link is for supporting Keil software
>>
>>Yes, I got that from you, already.
>>
>>>Segger J-link is an entry level professional tool The support software
>>>is chargeable but the do have  a gdb server.
>>
>>Yes, there is a separate, unrestricted gdb server that they provide at
>>a fairly high cost.

>At a very reasonable cost.

Not for most students or hobbyists.  And even for professionals, one
might give it a second look.

>>>For Linux and Free BSD there (must be) hardware aimed at it.
>>
>>I've already found some.
>>
>>>Try www.Rowely.co.uk  (But don't tell them I sent you It will ruin my
>>>street cred  :-)
>>
>>Paul has already generously provided his own tools and I'm in debt to
>>him for that.  They are excellent from my limited use so far, as has
>>been his help aside.
>
>SO you are sorted then.

Which doesn't matter regarding the situation we've been discussing.

Jon

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:lshec39c8ddtenqu1b1cmlo98345qs2fqs@4ax.com...
> I'm going to piece these responses up a bit.  It's too long....
>
> On Sat, 18 Aug 2007 15:55:04 +0100, Chris Hills <chris@phaedsys.org>
> wrote:

>>>What surprises me, generally here, is that ARM is the forte of the GNU
>>>GCC tools.
>
>>No it's not.
>
> Yes, it is.  Aside from x86, anyway.
>
>>Arm is one of the few chips GCC is closer to the other compilers.
>
> That's another way to look at the picture, I suppose.  It doesn't
> change or disagree with my comment in the least.

I have to disagree with both of you. ARM is not the easiest target to produce high
quality code for, and GCC's ARM backend has had very little attention, so it doesn't
support many ARM specific optimizations. GCC is at least 10 years behind compared
to the best ARM compilers, both in terms of codesize and performance. It also
used to be far behind in terms of ARM architecture support, but that has changed.

Wilco 

On Sat, 18 Aug 2007 23:21:43 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>
>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:lshec39c8ddtenqu1b1cmlo98345qs2fqs@4ax.com...
>> I'm going to piece these responses up a bit.  It's too long....
>>
>> On Sat, 18 Aug 2007 15:55:04 +0100, Chris Hills <chris@phaedsys.org>
>> wrote:
>
>>>>What surprises me, generally here, is that ARM is the forte of the GNU
>>>>GCC tools.
>>
>>>No it's not.
>>
>> Yes, it is.  Aside from x86, anyway.
>>
>>>Arm is one of the few chips GCC is closer to the other compilers.
>>
>> That's another way to look at the picture, I suppose.  It doesn't
>> change or disagree with my comment in the least.
>
>I have to disagree with both of you. ARM is not the easiest target to produce high
>quality code for, and GCC's ARM backend has had very little attention, so it doesn't
>support many ARM specific optimizations. GCC is at least 10 years behind compared
>to the best ARM compilers, both in terms of codesize and performance. It also
>used to be far behind in terms of ARM architecture support, but that has changed.

Hi, Wilco.  I think ARM is probably the better vetted, though
(excepting perhaps x86.)  I'm not talking about it being the "easiest
target to produce high quality code for," here.  And I'm not comparing
GCC against commercial ARM compilers, either.  I'm just talking about
comparing GCC/ARM with GCC/other targets here.  With that
clarification, you may agree.

Jon

In article <sfkec3pjatdnkoqcq8caeuc3f3f3vuif1r@4ax.com>, Jonathan Kirwan 
<jkirwan@easystreet.com> writes
>On Sat, 18 Aug 2007 16:09:23 +0100, Chris Hills <chris@phaedsys.org>
>
>>>>I am sure there are quite a few JTAGs that have been developed by the
>>>>FOSS community  (in fact I know there are,  I saw some about 5 years
>>>>ago)   that have Linux SW . However they are SEVERELY limited because
>>>>they have no WS windows support......
>>>
>>>Actually, I think Windows support almost comes with the territory.
>>
>>No. There are many JTAG tools that have support for OS that are not MW
>>Windows.
>
>Name a few that are (1) USB based, (2) support RTCK, (3) are well
>documented for those wishing to write their own software to access the
>full features of the hardware/firmware included, and (4) have
>unfettered gdb servers available for them in source form so that they
>can be compiled on various environments and modified, as needed.

No idea off the top of my head. Try google, source forge etc. There is 
(was) at least one FOOS Jtag on there that I know of.

No idea if it is USB, it was parallel.

NO ONE is under any requirement to produce anything with gbb or gcc 
support. If they do they can charge for it. Nothing says anyone must 
produce free/FOSS tools for hobby users.

>>Not difficult to get. Just ask nicely and sign the NDA.
>
>Really?  Would this mean that someone intending to put out a GPL'd gdb
>server would be able to do so?  Or do you imagine that this NDA would
>prevent that?
>
>I think this is just a red herring of yours, Chris.  It's just the
>same problem under another guise.

You asked for the interface information. NOW you want to put out a GPL 
gdb  interface  I am sure they would not permit that why should they?

I do not see why you should randomly select some professional tools and 
demand that they become FOSS tools with gsb support that goes directly 
against their company objectives.

There are other JTAGS out there that support gdb. AFAIK they sw is not 
free and the HW costs more than the U-link or J-link.

>>At a very reasonable cost.
>
>Not for most students or hobbyists.

1 They are not in the hobby market.
2 Their student packages work with the FREE eval versions of their 
compilers.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/