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

In article , Jonathan Kirwan writes

Because they use a proprietary interface and their own IP

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

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.

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

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.

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

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

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

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.

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

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

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

At a very reasonable cost.

SO you are sorted then.

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

Yes, it is. Aside from x86, anyway.

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

Jon

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.

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

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.

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.

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.

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

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

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

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

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

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.

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

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

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.

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.

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.

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.

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.

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.

This, I still need to research. Any pointers?

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.

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?

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.

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.

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

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

Jon

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

high

doesn't

compared

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 , Jonathan Kirwan writes

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.

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.

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

In article , Jonathan Kirwan writes

OK we agree...

They are producing tools to support their software. They do not have to produce anything that works with GCC or GDB. If they do they can charge for it. They do not have to make the protocols or specs open or free.

All you are asking for is commercial companies to work fro free so you don't have to spend money when it is not in their interests to do so.

There is nothing stopping you producing a JTAG and the Sw. Making the Sw free and the JTAG low costs fro hobby users if YOU want that. No one else has to.

There are limitations to everything in this world. You can get tools without the limitations you are talking about but you have to find the ones for the market you are looking at.

Ask them.

Then research and ask questions.

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

I think you've abundantly made my point for me. Thanks. I'll leave it there. No point beating a dead horse, so to speak.

Jon

That becomes clear as one investigates deeper, of course. But it doesn't cause me to change anything I said.

Which are limited. Some students and hobbyists will want to make far more extensive use of the tools. Which, as you say, means they need to look elsewhere. No argument.

Who is included in their target and who is specifically excluded is not very clear from reading the sites. I could wish for a clearer annunciation. I suspect that some folks start out expecting one thing, buy such units, find out the details later, and are only then sadly disabused of prior misconceptions.

An earlier point I made was different from this, more focused on my surprises about finding a market area where I anticipated seeing at least several good USB JTAG alternatives, for hobbyists and students, to those motivated primarily as a compiler sales tool. I'd still like to see some examples 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.

Since I'm pretty new to this area and since you cannot recall any, perhaps someone else can help identify one.

Jon

Ask who, what? You snipped what I was saying and because of that I'm not even sure what particular thing you are addressing.

If you are talking about Segger and Keil, etc., I've indeed had to make the phone calls and ask. I've also called and emailed a number of other folks, as well. Including posting in a yahoo group or two about it. So far, I don't find you disagreeing with me on the facts. Just disagreeing about some wrong idea you perceive about me -- that I want to force commercial companies to slit their own throats. You go on and on about that misconception and cannot seem to follow what I'm actually pointing out, as a result.

Hmm.. I think I am.

Jon

This is such a basic question I am aghast that you have asked it.

You got that right--you have indeed misunderstood. Source covered by the GPL, without a license exemption, says that anything linked and DISTRIBUTED with in binary form requires release of the source to alllow rebuild and relinks. The GPL kicks in when you start making copies, modification, or distributions only, any other activity is outside the scope of the license. License exemptions are not uncommon, I can think immediately of FreeRTOS and Qt which are at least dual-licensed.

...such as? I count 78 BSPs that we have made public.

You misunderstand the context of BSP here. The BSP in CrossWorks for ARM allows you to create projects using a wizard-style interface. I'm not talking of just putting something together and releasing source/loader of a project which you copy from to get a new project. CrossWorks is more sophisticated than that, allowing you to view the board support packages you've installed, see their documentation, and so on, all from within the IDE. I haven't seen anything like it in the other ARM IDEs I've looked at.

-- Paul.

To elaborate on that, the pure GPL is seldom used for *any* libraries (although the FSF keep trying to persuade people to use it for libraries). Some libraries use a modified GPL, such as FreeRTOS or the library code within gcc (as you quoted below). Many free libraries for non-embedded applications use the LGPL, which specifically allows the rest of the code to be of any license, as long as the linking to the LGPL code is done dynamically (i.e., the end user is free to update or improve the free library code regardless of the application binary). Libraries aimed at embedded systems usually do not have any such restrictions (though they might have others, such as a requirement that modifications to the library source be made freely available).

It is quite possible, however, for vendors to release GPL'ed versions of the libraries (or RTOS, or other code) precisely so that it cannot be used for closed source development, while also releasing the same libraries under a different license (at a cost) that allows your code to use any license. A good example of this is the QT libraries from TrollTech. I have no idea whether the same thing applies to Rowley's "hobby" version of their ARM compiler - it would certainly be a perfectly good business model to do so, and in keeping with the goals of open source and of a commercial business.

In article , Paul Curtis writes

I wanted to clarify all the points so that we all have the same understanding. I have found that "what everyone knows" is usually wrong.

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

< snip >

I have no problem with customers developing source code with CrossWorks for their own use and to share with other hobbyists using a Personal License. MakingThings and the Make Controller is a good example, I think--they develop their code in CrossWorks and provide it to their customers who can use CrossWorks or plain GNU tools to rebuild the application.

The only items that cannot be redistributed are source code and object files we ship as part of CrossWorks and our Board Support Package sources. These sources are clearly marked with copyright noticies.

I must admit that I have not considered a dual license for our source code.

-- Paul.

Just a small point in this argument - you *are* aware that professionals choose to use free and open source, are you not? For example, some professionals *choose* to use Linux or FreeBSD as their development platform? And some professionals *choose* to use free and open source development tools? And some professionals *choose* to use free and open source on their embedded targets? Some people make their choices based entirely on purchase cost price (or lack thereof), but others make their choices based on the quality of the tools, how the tools fit in with their environment, the quality of the support, the licensing costs or requirements, the long-term sustainability of the toolset, and many other factors.

Here's a couple of links for you (sorry for the long links - some websites have horrible page reference schemes):

You might also want to consider whether it is appropriate for you to base your business on a website running an open source webserver, running on an open source operating system (a free clone of a commercial open source operating system, no less), if free and open source software is merely for hobby users or those too mean to pay for "proper" software.

There are times when an open source solution is the right choice, and times when when a closed source solution is the right choice. And sometimes you want a free or lost cost solution, sometimes you can budget for a high price, high quality solution - totally independently of the open/closed decision. Any vendor with a business sense would look at open source (either as a host platform, or in terms of supporting gcc/gdb) as an opportunity, and would assess the worth of potential customers against the cost of developing or re-selling the tools - only a fool would write them off on the basis of prejudice.

mvh.,

David

Op Sat, 18 Aug 2007 22:09:02 +0200 schreef Jonathan Kirwan :

I know one tool vendor that comes very close to your requirements: iSYSTEM. They make several ARM emulators in the range from tens to thousands of euros, and a free (of charge) Windows IDE. Your requirements:

1. Yes. (Also Ethernet.)
2. Yes. (Also scan chain options, idle TCK's and a different speed during init.)
3. Yes. (But Windows API's only.)
4. Not quite. But a GDB server is supported as a plug-in DLL, and with the Windows API you could write your own GDB server.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

But only if the library is licensed under GPL. It seems that the LGPL is not the same thing, and GNU don't seem to like it :-)

And the license for a library can introduce exceptions to the GPL:

In fact, gcc is intended to be usable for commercial, closed-source, proprietary work:

Frank