Cortex R4 Tools and Processors

This is related to my "D'oh post" regarding the Cortex M4 floating point size.

According to ARM, the Cortex R4 supports double-precision floating point, and it looks like it's maybe more amenable to embedding than the Cortex Ax cores. I really want to find a chip that I can just lick the back of and stick onto a board, rather than something that'll become the CPU in a built-up computer with external memory and all that razz-matazz.

TI has a Cortex R4 part, but I've used the predecessor part and the only tools available for it were from Keil -- I dislike single-sourcing, and I'd much prefer using Gnu tools if there are such for the R4.

So, has anyone used the R4? Do you happen to know if the Gnu tools support it well? Can you recommend any off the shelf embedded processors that use it? (TI included -- just because the SM470R1B1M was hard to work with doesn't mean that TI hasn't solved those problems with their Cortex version).

Thanks much.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

Both Rowley

formatting link
and Imagecraft
formatting link
seem to support TI TMS570 series processors. I've used both compilers but not that series (or other R4) processors so I'm not absolutely sure that's what you're looking for.

Rowley is GNU-based, Imagecraft is independent. I've used both for commercial embedded products. There's probably a pure GNU solution out there, but I'm in a situation where (L)GPL issues arise.

Reply to
Rich Webb

TI also supply their own compiler and Eclipse based IDE in their Code Composer Studio (CCS) download.

Regards, Richard.

  • formatting link
    Designed for microcontrollers. More than 103000 downloads in 2012.
  • formatting link
    Trace, safety certification, FAT FS, TCP/IP, training, and more...
Reply to
FreeRTOS info

The documentation at least claims it does. OpenOCD should also support it as well.

-a

Reply to
Anders.Montonen

We just worked on a TMS570 (R4) port for uCOS-II using IAR EWARM 6.5. Worked great. Scott

Reply to
NotReallyMe

The GPL nature of gcc does not affect you unless you are trying to run the compiler on the microcontroller. Any sane toolchain will have libraries that can be linked with your code without any license restrictions - but if you use additional third-party libraries or code, you obviously need to check the licence (whether commercial or open source).

Reply to
David Brown

Besides which, as far as I know Rowley provide their own (not open source) optimised libraries when you purchase their tools. Only the compiler is GPL.

Regards, Richard.

  • formatting link
    Designed for microcontrollers. More than 103000 downloads in 2012.

  • formatting link
    Trace, safety certification, FAT FS, TCP/IP, training, and more...

Reply to
FreeRTOS info

Correct. Rowley, for example, does use a gcc compiler and, of course, the generated code itself isn't GPL-burdened. They also (being a sane toolchain ;-) provide their own non-LGPL libraries.

In the "check the license" vein, however, using C++ RTTI or exceptions does link in GPL-licensed code (not just LGPL). I've been puzzled about why that's the case but since I stay away from C++ in embedded work I haven't worried about (or investigated) that too much.

Reply to
Rich Webb

The GCC C++ library license contains an exception allowing its use in proprietary software:

-a

Reply to
Anders.Montonen

Interesting. Thanks!

Reply to
Rich Webb

Rowley provide their own libraries - that's one of the reasons people might pay for an otherwise free compiler (along with things like support, the IDE, the debugger, etc.). But they like Rowley's libraries because they are small and fast, not because there is any practical difference in the licences compared to newlib or (for examle) Code Sourcery's libraries' licences. My point is merely that there are no GPL or LGPL issues to worry about with gcc or commonly used free libraries targeted at static linking.

There are a number of code snippets that come with gcc itself (as distinct from the libraries), and are copied verbatim from the gcc source into temporary files which end up complied and linked with your code. There are also library files that are distributed as part of gcc itself (such as support for floating point and integer arithmetic which require library routines rather than code segments). The code generators arguably also involve verbatim copying of assembly-language source code from gcc files into your own code.

But while the original gcc author (Richard Stallman) is well-known for his fanaticism for free software, fortunately the other authors realised that keeping these parts under a strict GPL would make the compiler "free" but useless outside of the GNU project. So there is an explicit exception in the licence that covers all such code, letting you use it an link it with any other code that you want, under any licence.

So don't worry - you can use C++ exceptions in your embedded code if you want, with no licensing issues. You might have trouble convincing yourself and others of the reliability of code using hidden and unexpected jumps (which is what exceptions are), but the licences will be fine :-)

Reply to
David Brown

I think you may be a bit inaccurate in your "no LGPL worries" statement, at least with the open-source code.

The libraries that come with the gnu compiler are LGPL which frees you from having to release your code, but it doesn't free you from having the license notices and code availability for the libraries themselves.

If Rowley (or Mentor/CodeSourcery) ships their "real" product with libraries that have been written to get around that -- cool.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Thanks. I do try to Do The Right Thing on licensing issues just on GP but I hadn't read up much on V3 -- more familiar with the older LGPL terms and conditions. Still not tempted by exceptions, though ...

Reply to
Rich Webb

I use C++, but I don't use exceptions -- I have yet to work on any system where any conceivable result from an exception is better than just hitting an assert that hangs the processor.

(Which means that once the code gets into production, any such bugs are Really Bad News anyway, so one should make damned sure that they never happen!)

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

/All/ licences (except perhaps the "beer licence") are full of exceptions, small print, and legalise.

It's not always easy to do the right thing on licensing - whether open source or commercial. It's not always clear what the legal situation is, or what the author (or copyright holders) intend. There are plenty of licences (commercial and open) that are not valid in all countries, and there are plenty of cases where the legal situation is very different from the author's intentions (I've seen code with notices like "I'm releasing this with the GPL, so that you can use it any way you want along with your own code").

But the licences for gcc and the included gcc libraries are very clear - the tool is under the GPL (now GPLv3), with the exception and intention that it imposes no restrictions whatsoever on code generated with the tool and linked with the included libraries.

Similarly, any library that comes with serious embedded tools is going to be fine to use with embedded code.

Reply to
David Brown

No, there are no standard gcc libraries that are LGPL. There are standard C libraries (like glibc) that are LGPL - and you /do/ need to release your source or linkable object files if you want to statically link to LGPL libraries. LGPL libraries are almost exclusively used with dynamic linking.

The libraries included with gcc itself are GPL with an exception, because they are targeted at static linking but have an exception to avoid enforcing the GPL on the rest of the code.

It is quite possible to distribute a gcc for embedded targets along with a pure LGPL library, but I have never heard of such a beast (it would be of very limited value).

A common free library used with embedded gcc is newlib, which has no "LGPL worries" - it is mostly BSD (with some public domain licensing, and a few GPL bits for linking to specific bits of the Linux kernel - if you use these parts, you code would be GPL anyway by linkage to the kernel).

It does, I suppose, have a "BSD worry" - you need to include the library copyright notice in documentation. This is frequently omitted, or relegated to the least read technical manuals - the newlib copyright owners have never been known to complain about missing copyright notices.

Rowley and CodeSourcery (and probably also Code Red, though I don't know them as well) wrote libraries designed to be more efficient in embedded systems, to have features more suited to embedded systems, and to be more tightly targeted to the processors in question (newlib is so portable that it's code is illegible). That has always been the main reason for having these libraries. The lack of a copyright clause on the binary is a minor issue.

Reply to
David Brown

I meant the throw..catch exceptions didn't tempt me but, yes, a hearty "Roger that" for minding the small print. ;-)

Thanks. IANAL etc. and this thread has cleared up some things.

Reply to
Rich Webb

OK, I see what you mean now. (I also disable exceptions when playing around with C++, at least on embedded systems. They are handy in Python for PC programming, but not for embedded stuff.)

IANAL either, and I sometimes get things wrong concerning licenses. I know more than most people, but certainly not everything. So if my free advice is helpful, that's great - it's worth every penny - but if you can envisage lawsuits down the line, then get a second opinion too :-)

Reply to
David Brown

There are different styles of exception use. In some exceptions are the basic error reporting mechanism - you certainly wouldn't (usually) want to hang the processor because:

Socket ConnectToHostTCP("someservice.example.com", 12345)'

threw a SocketExcepetion(HostNotFound)!

Reply to
Robert Wessel

True. I generally deal with that sort of thing through milder mechanisms.

But then, if it has a user input of more than two buttons and a user output of more than two blinking lights, then it's getting into "excruciatingly fancy UI" territory for me.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.