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

GCC is a very flexible system, with which comes some complexity. I once wrote a demo for a SAM7 using both IAR and GCC, and the GCC binary size was a fair bit larger. Somebody who knows more about GCC than me took the demo and modified the build switches to remove unused symbols (amongst other things) and sent the code back to me. I was amazed to find that the build size was then within a few bytes of that produced by IAR.

IDE's such as CrossWorks remove a lot of the complexity.

I very recently wrote a WEB server demo for a Cortex M3 (LM3S6965) and then compiled the same demo using GCC, Keil and IAR. The differences were 'interesting'. Especially as the WEB page served showed the stack usage high water mark. In two cases I provided my own (very cut down) sprintf() implementation, in one case it was not necessary.

Similarly, some time back I had a WEB server compiled using Rowley CrossWorks that was running very nicely. I later created a standard makefile for the same code and compiled it using GNUARM. It was very noticeable that using the CrossWorks libraries the RAM/stack usages was considerably less than the equivalent using the standard GNUARM implementation.

--
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 certified real time kernel for safety related systems.

< snip >

I have not run any comparisons; you will find that we do not produce competetive analysis reports and compare ourselves to other vendors in that way because the information would be out of date almost immediately. Constructing "tick lists" is an art to put your product in its best light. We prefer customers to evaluate our offering themselves.

-- Paul.

In article , Paul Curtis writes

We were discussing your ARM compiler not any of the others. IAR and Keil were also mentioned and again we all know it is the ARM compiler of theirs we are discussing.

So in this context we are discussing the compiler your company shipps for ARM with is the GCC and it was therefore being described as "The Rowley [ARM] Compiler"

As we are talking about ARM specifically we al knew what were are talking about. Thank god the other compiler vendors don't get as pedantic when there is no need..

Thanks for the over view.

Does this mean that if you link in a GPL library then you have to release the source of the application? That would mean that you could not use GCC with a GPL licence for commercial work. I assume I have miss understood somewhere?

I think some do.

Hardly. The same applies to anyone.

It is the same for most commercial compilers.

Thanks for the other comments.

Chris

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

In article , Anton Erasmus writes

The Hitex IDE is Hitop which is designed to drive their Emulators, It is not, and was never designed to be a really good programmer's IDE. It has too many limitations

I have not seen the Rasionance one but the Keil uVision will work with GCC and that is a VERY good editor, project control and simulator system,

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

In article , Jonathan Kirwan writes

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

The USB variants tend to have MCU's in them and therefore can do more in the JTAG-debugger firmware

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.

The majority are for windows as trhe majority of ARM cross compilers are on windows.

Which interface? How do you mean intentionally hobbled?

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

[...]

No, that is the intent of the GPL (as I understand it).

*However* you will find that the free libraries used for "embedded" applications are *not* in fact GPL licensed, so that they can be used in proprietary applications.

E.g, from part of the gcc library:

"In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable."

--

John Devereux

I'm thinking in particular of the USB variety.

Granted.

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

That's not the point, though. It's not about the bulk market some company is targeting. The point was about unexpected limitations in USB JTAG tools for ARM. I came at this with a clear and open mind and no expectations, at all, in this regard. Each day I spent running around on the web, regarding these USB JTAG tools for ARM7TDMI cores, I became increasingly surprised. Most of my early attention was focused upon one of the (as I later learned, many many incarnations of the) JLINK JTAG tool (SEGGER, IAR, etc.) and the Keil ULINK2 tool. In reading the technical details of the JLINK, I became increasingly aware of the many firmware and hardware variations, as well, and the difference between OEM units sold with demo boards and those sold separately. Then, I also became increasingly aware of limitations for the Keil ULINK2 software, which so far as I could find, cannot be used with a FreeBSD hosted development environment ... not because it isn't technically possible but instead because (1) Keil doesn't provide the required technical information to operate their ULINK2 devices so that

3rd parties can write the appropriate gdb servers, and (2) Keil doesn't provide the unlimited gdb servers, either.

(I later took a close look at Amontec, as well. And especially read the YAGARTO pages from Michael Fischer, where I learned more about some limitations in the gdb/debug situation.)

In addition, there are other complications in ARM7TDMI debug that may relate more to some ARM7TDMI chips than others. One side point here is that everything isn't quite as rosy as it might appear at first blush.

Now, I am NOT fully aware of the entire situation and I'll immediately modify this when presented with unambiguous, contrary information to some of it. But that was the scene that presented itself, shortly ago.

For example, the JLINK uses SEGGER drivers. For full debugging support, you need to pay an additional fee (too expensive for many hobbyists) to get it unlocked. The driver that comes with many of these tools is hobbled, by design. The debug interface for the ULINK from Keil is similarly limited to their own software, uVision; a closed software arrangement. I believe I understand that although uVision does support GNU tools, it only does so from Windows and they doesn't provide an unfettered gdb server in source so that it can be compiled for Linux, FreeBSD, etc.

The limitations vary. But, for example, if I were to purchase a JTAG tool like these with the expectation of being able to just go use my GNU software tools with the JTAG hardware I bought, under FreeBSD for example, and without some arbitrary code size limitation popping up or else some difficulty finding unrestricted debug support software, I might be taken aback by the reality that unfolds after the purchase.

Actually, though, I'm quite eager to hear about unlimited, unfettered USB JTAG debugger tools that fully support RTCK and have unlimited gdb servers (hopefully provided in source form.) I will be very pleased to find the situation much better than I imagine it to be, now.

I understand that I'm VERY NEW to this area, only this last month or so, and cannot possibly understand the full situation. So realize that I'm speaking not so much from an informed position as from an early entrant into this development situation.

Jon

But let's say you are developing under Linux or, even better, FreeBSD. What's the situation with ULINK2 here?

Jon

Yes.

No, it doesn't. Because GCC is a GPLed *program*, not a GPLed library.

And frankly, I'm quite surprised you have to ask this.

Yes. That's the price the author of that library requires for your use of their work.

You have misunderstood. "Using gcc" is not the same as "linking gcc into your program", which would trigger the GPL (gcc itself is GPL'd). The mere act of *using* a program does not cause its *output* (generated from your input) to inherit that program's license. An exception would be something like bison or yacc, which insert a huge chunk of its own source code into the output.

Perhaps you're thinking of libgcc, which has an explicit exception to the GPL which allows its inclusion in non-GPL binaries, assuming the compiler used is gcc?

And as an example of compatibility with proprietary ("commercial" is the wrong word for this argument, it just means you get paid, it has nothing to do with the license) products, consider that Microchip's tools are based on gcc, so they're GPL'd, yet people write proprietary code with them all the time. Also pretty much ALL Linux programs, including proprietary ones such as Oracle, are all built with gcc.

In article , Jonathan Kirwan writes

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?

Yes it is. Tools are made for the common engineering environments. If the compilers are on Windows the people doing the Jtags are going to write SW to interface their HW to them. In the case of Keil they are going to interface it to their compiler/debuggers

Limitations such as what?

You misunderstand. It is not a limitation. The design requirement does not need to support free BSD for obvious reasons. Why should it.

Why should they?

Why should they? I am sure that if you paid them they would do one. However they developed the U-link to work with their debugger/simulator. NOT GDB. You can't blame Keil for not doing a gdb server.. They only provide the U-link to support sales of their compiler/debugger software.....

If you want to do something else with their hardware other than it's intended use they don't have to help. Of course you could pay then the money for them to do an interface to a competing system...

Of course. What else would you expect? Segger make the J-link

It is not designed for hobbists. That is not their market.

No it's not

Absolutely. Why not? They have produced a small Jtag to support their own software. Your problem is what?

No. UVision can support the Gcc compiler and Keil's own simulator/debugger. The only reason Keil made the U-link was to support sales of their own debugger software.

Of course. It is the only one that is relevant to them,

Why on earth would the want to do that... Actually I expect they would if you will fund the work.

NOT like those because they are designed an implemented for a purpose different to the one you want to use them for.

EASY NO problem... There are quite a few JTAGS that will work in that combination..... However not the ones you have chosen. Those Jtags have severe limitations though.... They won't work with Keil, IAR, etc etc

No code limitations on the HW I am aware of. Where did you get that from?

Then buy the tools aimed at the Free BDS market.

The situation you have is picking up two low costs tools aimed at one market and you are complaining they don't do something they were never intended to do.

The J-link ant U-link are LOW COST systems. There ar eJTAGS that will cost you 1-5K GBB

This is obvious...

There are MANY J-tags out there. You have picked 2. The Keil only exists to support the sales of the Keil debugger.

The Segger was designed for professional engineers (not hobby use) and works with several top end compiler systems. It also has a range of addon software for various things. They do a gdb server but NOT a FOSS one.

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

In article , Jonathan Kirwan writes

There is no situation with U-link. The Keil U-link is a piece of hardware specifically designed to support sales of the Keil debugger software. No more than that.

If you are developing under Linux, Free BSD, Solaris, VMS, AIX etc you need to buy a JTAG that has support in those environments.

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

Horses for courses.

Keil U-link is for supporting Keil software Segger J-link is an entry level professional tool The support software is chargeable but the do have a gdb server.

For Linux and Free BSD there (must be) hardware aimed at it. Try

(But don't tell them I sent you It will ruin my street cred :-)

Regards Chris

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

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.

Regards Anton Erasmus

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, so that 3rd parties may, if they wish, write appropriate drivers for full access to the hardware capabilities exposed by the firmware inside it.

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.

Of course, I checked. But as I said earlier, there is no good reason why the firmware interface isn't completely publicly disclosed. (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.

That is an obvious truth. It doesn't address what _should be_, though.

Actually, I think Windows support almost comes with the territory. 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. 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. But you mentioned "RDI" and I haven't had a chance to research that, yet. So perhaps I'm wrong here.

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

Yes, I got that from you, already.

Yes, there is a separate, unrestricted gdb server that they provide at a fairly high cost.

I've already found some.

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.

Jon

Thanks for that.

What surprises me, generally here, is that ARM is the forte of the GNU GCC tools. It's probably the better vetted arena for those tools. There has been support for a long time, lots of folks supposedly using them, etc. It's a well-worn path, so to speak.

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.

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. That customers were struggling with the difficulties of using his software in the context of hardware JTAG debuggers he didn't control and this step of his was more a way to remedy that support problem than to market his own software or to further confuse the JTAG debugger situation. Which makes sense.

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 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 (as in the case of Segger) quite simply a step on the way to selling a high priced driver that finally opens up the features of the hardware you've bought into without expecting this bait and switch, so to speak.

Jon

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.

[Rest Snipped]

Regards Anton Erasmus

One do get independant JTAG Debuggers for ARM, which supports GDB, annd most/all of the commercial compilers. e.g. The JTAG debugger from Ronetix. However these tend to be priced from US$1500 upwards.

There is however an alternative in OpenOCD. This is an open source JTAG debugger backend which can be used with gcc. It is available for Windows and Linux. It supports the parallel port wigglers, and support for a few cheap USB based debuggers has also been added. At

schematics is available for a USB based debugger which is supported by OpenOCD.

Quite a few companies like olimex which supplies cheap ARM development boards have cheap JTAG hardware which are supported by OCD.

Regards Anton Erasmus

[86 lines removed]

[snip]

Please remove any parts of the previous messages you are not directly responding to. We do not want to have to skip past screen fulls of quoting on every message.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/

In article , Anton Erasmus writes

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