Native ARM assembly on Stellaris Launchpad

Hi David,

you can use whatever IDE you prefer to have assembly only or mixed source (i.e. C with inline assembly commands). I'm using TIs Code Composer Studio (CCStudio: http://www.ti.com/tool/ccstudio&DCMP=dsp_ccs_v4&HQS=Other+OT+ccs) and Crossworks for ARM (http://www.rowley.co.uk/arm/index.htm).

Well, which IDE you want to use is a matter of taste and money! CCStudio is for TI products only and sells for $445 (https://estore.ti.com/TMDSCCS-ALLN01D-Code-Composer-Studio-IDE-Platinum-Node-Locked-Single-User-N01D-Download-Only-NO-DVDs-P1691.aspx), Crossowrks can be used for all manufacturers, but a license cost s $1500 (http://www.rowley.co.uk/crossworks/Licensing.htm).

There are a lot of other IDE's out there. It depends on the time you want to spend to get them up 'n running (if you don't want to spend money buying a license).

EDIT: Forgot to mention the programming device! For code debugging you should use a JTAG debugger; in case of simple downloading you can use LMFlash programmer (http://www.ti.com/tool/lmflashprogrammer).

Rgds
aBUGSworstnightmare 

Thanks!

I'm using the Stellaris Launchpad dev board so I thought CCS was free to use with it? What are the limitations of the eval version?

Hi David,

you didn't mention what platform/tools you were using ;-)!

Yes, you're right! CCS is free and unlimited when used with the Stellaris Launchpad (bundled  license). You can use it to write production code.

Find some more info on CCS licensing here: http://processors.wiki.ti.com/images/8/8d/Code_composer_studio_v5_1_software_license_agreement.pdf

Rgds
aBUGSworstnightmare 

Great!

What compiler does CCS use?

Can I just use __asm__ or asm() like in gcc?

While "free" is appealing - you are locking yourself into a single source. 

Multiple vendors produce ARM MCUs - each with a different mix of product peripherals, pricing, and product stocking @ disty.  Freedom of selection is an important criteria...

I have a suggestion.

Before you go to all that effort -- learn the differences by working the examples and workshops using standard vanilla C or C++. I will be astounded if you actually need assembly for the speed -- not that you cannot do it.

You are dealing with an 80MHz 32 bit MCU -- you are used to what -- 16MHz 8 bit?

Even an ADC conversion can be limited to a few microseconds on these boards -- plus you have an FPU for the tough math. The I2C and SSI are built in and managed...

Watch the videos and lessons on the interrupts and tail chaining and the timers.

Now maybe you can find a use for assembly language -- but I don't see it.

And yes -- load up Code Composer studio -- C, C++ and assy -- one package -- complete with Docs.

Forgot to mention -- it is the DInkum compiler out of Australia -- good enough for RAD studio and the Microsoft team...

Dave Robinson said:

good enough for RAD studio and the Microsoft team

While I have distant recall of one such use - are you implying that multiple other IDEs (such as Keil, IAR) are not also in use w/in these "hallowed" halls?

Keil/IAR - with their exacting focus upon small, embedded MCUs - produce performance benchmarks beyond that of the far newer player, CCS.  And of course - they both are MCU maker agnostic - which may grow in importance as the Feb end "deadline" approaches... 

Even a casual search of, "Requests for Help" shows that CCS perplexes users far more than IAR & Keil.  In addition - both Keil/IAR produce/provide "real" JTAG/SWD probes - which are far faster, more robust, and infinitely easier to set-up and maintain than the "bulk" of FTDI-based devices - so common w/in CCS. 

Your serious code analysis further benefits from SWO/Trace - which has not found itself into the CCS "bag of tricks" - pity for RAD & the MS team...

I was only pointing out that the Dinkum compiler is in widespread use. Embarcadero (RAD Studio) is using the C++ 11 version in their latest RAD studio, and they are now offering ARM compilation as well. MS I gather will be using at least the C++ 11 compiler for their latest VS.

Beyond that I offer no opinion.

I have IAR -- it is a nice smooth experience -- it's just the $2500 -- $10K it would cost me just to cover my TI efforts -- forget anything else. It's just the $$$...

CCS is not great -- but I have been happy with the latest 5.2 release and am waiting for the latest.

I use Eclipse for my Android and GCC efforts so I can cope.

I rarely use debugging mode on the IDE and the compilers.When I do use the debugger the built in link to ICDI for the eval/demo boards seems adequate, When I get to putting chips into my own board designs I will get the most appropriate full JTAG for the programming -- but hopefully I will not use de-bugging mode much more. (I could use my LM3S811 as a JTAG -- but it's not worth the effort....)

Writing correct well defined code from a decent design is more efficient to me. Some people spend less time on design -- more time on debugging -- I prefer more time on design less on debugging. It's what works for me. In several decades of design work I have never had ECOs issued or design changes made to bugs in my software or firmware -- upgrades and new features to software yes -- no hardware fixes. I just put the effort in a different direction than most. Many shops are so rushed this is not a practical approach for everyone -- I admit that.

Anyway -- it means that I can accept a lower grade of tools in return for effort placed in a different area. It would be nice to have IAR or Keil -- but I will get the Rolls polished twice a week before I spend those buck$... ;-)  OK, Ok it's actually a Vauxhall -- but still...

Each to their own...

Dave Robinson said:

I can accept a lower grade of tools in return for effort placed in a different area

Should not "one" of those "different" areas be (at least) the simple review of the methodical efforts of similar MCU vendors offerings?  One would think that - in combination - that the "ROW" (rest of the world) could at least get something right!  How can one design/develop the best/brightest with such "closed dock" mentality?

Locking oneself into single sourced devices/systems may be problematic even when there are NO issues of NR/ND - and exclusive delivery of LX rather than LM...

aBUGSworstnightmare said:

...Crossworks for ARM (http://www.rowley.co.uk/arm/index.htm) ...

... well, I need to say it again: Have a look at Crossworks for ARM! You can get a Personal License (for non-commercial use only!) for $150 and you will have support for nearly every Manufacturers ARM products  (NXP, STM, TI, ... only to mention a few).

Add a CrossConnect for ARM for another 300 bucks (+ $20 ww shipping) and you have all you need. Crossworks is the product of choice when you need an IDE which natively runs on Mac OS X.

aBUGSworstnightmare

As I said -- I have IAR and CCS V5.2 and GCC.

So yes I do agree. I did my evaluation and this is where I ended up.

As far as the "non-availability" of parts -- we have discussed that in private. TI has made its decisions and will stand or fall on them.

Thanks to everyone for your comments.

I'm just a hobbyist and I don't really need to worry about other MCUs etc. I can always just port my code over to something else. @cb1: Free *is* appealing :)

I think CCS should be sufficient for my needs.

@Dave Robinson

Yes, I've mostly been using 16MHz 8-bit MCUs. However, it's not about the speed in certain applications I need it for. The speed of this MCU is one of the reasons I chose it but I still need cycle-perfect calculations for some of my applications (or near enough to it).

For e.g. one of my plans it to use this to drive 800x600 VGA signals. I need to count 40MHz cycles for that.

I could always code it in C, compile it and then disassemble that and just tweak to make sure that I fit in the number of cycles that I need to but it's just as much effort coding it by hand. I'm used to assembly. :)

I watched the videos and it seams exceptionally easy to set up timers/interrupts etc. I guess i'll code that in C using the library APIs and then call a ASM-coded handler when the timer triggers after a specified number of cycles.

At the moment I'm having trouble downloading CCS from TI. It says it needs 'manual approval' or something because of US export regulations. I wonder how long that takes...

David Kaplan said:

I can always just port my code over to something else.

But David - that was exactly my point - w/CCS you cannot!  (only 1 vendor supported)

I have done such a VGA port as you've described.  (I come from display industry)  We found that ARM MCU and FPGA - in tandem - produced the best results.  FPGA is far better suited for the high-frequency, repetitive demands - whereas the MCU can add "selective" intelligence. 

While videos provide some guidance - even simple scan thru this/other ARM Forums will review that, "devil is in fine detail" - which usually fell to "cutting room" floor during video production.   Good luck...

CB:

Good point about the FPGAs.

EETimes ran a seminar on the FPGA -- run by Max Maxfield -- see:   university.eetimes.com/lecture-calendar.asp

You will have to create a user name and login -- but it will get you past the basics if you have never used an FPGA. It will give you some idea of the tools involved.

EETimes in particular have been hosting some seminars on TI MCUs and specialty components if it interests you -- check their archives.

Monsieur Robinson,

You provide a great, instructive source for such clarifying detail.  Such effort/time may explain why snow drifts/banks "blanket" your arctic doorstep...

I'm an EE by training so I've done some time with FPGAs. :)

I agree that for a proper display implementation a combination of FPGA and some sort of processing unit would be great. But I don't want to bother with an FPGA when this MCU can handle 800x600 VGA without breaking a sweat (both the VGA cycles and drawing/processing). It's all I need for my simple application.

I have a number of Altera Cyclone dev boards and I have VGA modules for them that I don't even need to bother writing; but it's just overkill for what I need. ;)

Some guy on the net did a pretty decent 640x480 implementation (albeit only 256 px) on a 20MHz-clocked 8-bit AVR using the front/back porch cycles for the drawing logic.

I'm planning on doing something similar but I' should be able to easily draw more pixels with this 80MHz MCU.

Well -- if you have installed CCS you should find the assembler docs (pdf's) inside the c:\ti directory -- just do a search. They explain how to do inline code and also how to integrate "xx.obj" files.

I did my years of bit flipping as a math processor designer -- ain't doin' it no more if it can be avoided.