Assember programming in Xpresso LPC43xx

[lpcware]

Content originally posted in LPCWare by acelink1 on Wed Feb 05 04:29:57 MST 2014
Hi Guys, I'm totally new here. I'm migrating from ATMEL 32bit MCU's to the LPC437x MPU 204Mhz Cortex M4 + M0 CPU's.

I have installed the latest ver of LPCXpresso and have built a few C projects which was quite easy to do :)

I have to say that I am not a C or C++ programmer. I am an Assembler programmer to which I have been programming Atmel MCU's in Assembler for years now.

I have ordered a LPC43xx board and it will be arriving in a few days.

What I would like to do is have everything ready so when my board arrives I can start Assembler programming in LPCXpresso.

I tried to create a new Assembler file In Expresso, So I chose NEW file and all it has listed there is new C or C++ file to be created.  I remember doing something like creating a .S file a few years back but can't quite remember.
Would that be the same way in Xpresso?

So can you guys please let me know how to create an Assembler file in Xpresso.

Thanks again guys for your support.

Pete :)

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Feb 14 05:36:56 MST 2014
Hi Acelink1.

Probably the most vital tip for anyone writing directly in assembler is to readup on the
ABI (Application Binary Interface) which specifies the register usage for parameter passing
and which registers are used for what; I.e which ones your code is allowed to change/use
and which ones must be preserved.

Second. Read about the 'lr' (link register -- r14). Forgetting to save/restore this on the stack
(r13) when calling other routines from you asm code is a very common pitfall. Only leaf
functions can save time and stack space by using it as is.

Third. Unlike many other embedded processors, the ARM cannot embed general
constants in the instruction stream. There are commonly used small constants (usually
up to 0xFF) that can be encoded in the opcodes,  and the Cortex M3 has 'movw' and 'movt'.
For general 32 bit constants, the assembler places the constant in flash nearby but outside
of the instruction stream and uses a PC relative addressing mode to load the value.
As this is verry messy and error prone due to editing, there are special assembler
pseudo opcodes for this. See section 13.5 of the gnu as manual.

Fourth. Many of the opcodes have a smaller encoding with the 's' postfix (if you do not
care that the status bits get updated). E.g. mov r0, 7 is 4 bytes and movs r0, 7 is 2 bytes.
The "ARMv7-M Architecture Reference Manual" is your bible.
Get it from the ARM-Info site [ARM DDI 0403D (ID021310)].

Buy yourself a copy of "The deinitive guide to the ARM Cortex-M3 /  Joseph Yiu" e.g. Amazon
For LPC17xx/LPC13xx/LPC43xx many other parts are Cortex M0 which has a much reduced instruction set!

Really hope that helps. Mike.

[lpcware]

Content originally posted in LPCWare by IanB on Wed Feb 12 15:23:32 MST 2014
I finally got it running. The linker caused the greatest consternation - after 30 years of writing absolute code, I've never needed a linker.
I just deleted everything I could until there was nothing left apart from the ResetISR entry and the start and end of the memory.

I can't complain about LPCXpresso - it's good value for money (it was free!) and I can run it on my Apple Mac, but its facilities for writing in assembler are lamentable, and the standard reply to any assembler questions from the support people is "search the fora for 'assembler'".

As for the Assmbler v. C war, it appears to me that there are some applications that can only be written in assembler, and some that can only sensibly be written in C (USB, Ethernet stacks as mentioned by RocketDawg), but the vast majority in the middle can be written in either depending on where one's greatest expertise lies; and I'm sure that one can write inscrutable code equality well in C or assembler! C and Assembler programmers are both equally likely to be too lazy to write proper comment lines.

[lpcware]

Content originally posted in LPCWare by acelink1 on Wed Feb 12 15:07:01 MST 2014
Hi Mike, thanks for that. I find LPCXpresso to be great. I'm only new to this IDE but it has and does everything I need. I've created a .S file for my assembly program and it builds it fine. Every programmer has their own way of writing their software and obviously your way is totally different than mine. All I need is to write Cortex M4 & M0 assembler code in the IDE, build it and download to flash. That's really all I need to do, so LPCXpresso is great for what I want.

Probably later I'll make my own libraries and scripts but at the moment I have no need to.

What specific pointers do you have for writing Assembler code that I should know about?

Pete :)

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Wed Feb 12 13:04:37 MST 2014
Hi. I write all my peripheral driver stuff, interrupt handlers, etc. in Cortex M3 assembler [once!] and only use "C" for the top level stuff that changes from project to project.

The LPCXpresso is not geared up (apparently) to do things that way and seems that I have to fight it every bloody step of the way.

That's ok the free(ish) java bloat product was desiged for a particular purpose which does not include much direct support for what I need/want to do.

It is no use complainng about that; I and the other three <g> assembler afficionados should not expect a hammer, for example, to be much use for sewing a coat.

So I do not use the IDE at all (except for the debuger). This approach needs to be learnt from the gnu manuals and quite a bit of experimentation, but if you want to go that route and can afford the fare, you can use the most flexible IDE which has been around since PC's first came on the scene -- DOS.

Learn to write your own make files and linker scripts, use a better editor that you feel fluent in and build with the gnu toolchain directly from the command line. [GNU lives in <install path>/lpcxpresso/tools/bin and there abouts.] You will only need the IDE for debugging and/or downloading to flash. However, see Flash Magic and read about the ISP mode of the processors. [Also, download a native GNU make -- the one in the IDE seems to be a bit too connected to Cygwin and I have had problems with it!]

However, apart from outright bugs that may appear in the tools, you will be mostly on your own as the main purpose of the IDE is to target C code that conforms to the conventions espoused by the wizards and the LPCOpen (formerly raw CMSIS) libraries etc.

PLEASE NOTE that I am NOT criticising the IDE -- It is great for newcommers and those that do not really care what goes on under the hood, or need to crank out a solution quickly etc. etc. If you want complete control, you have to completely control everything in your projects. And that take hard learning.

Here be dragons!


Happy hunting, Mike

[lpcware]

Content originally posted in LPCWare by acelink1 on Wed Feb 05 15:43:37 MST 2014
Hi Ian, I was a 6502 Assembler programmer as well. I still have my 6502 Atari 800XL 1.79Mhz, 64k ram, 256 colours and 4 sound channels :)  and a faster disk drive than the Commodore64 :) hehehehe.  Then I bought an Amiga 500, a 68000 8Mhz based CPU, 4096 colours, 8bit digital sound -> WHAT A FANTASTIC MACHINE <-  ( Which I still use today ). From their I went to the ACORN RiscPC600 (32Mhz ARM Based CPU) and that was fun too. Then to Amiga 1200 with 68030 40Mhz accelerator. I programmed all in Assembler and BASIC. Then moved on to ATMEL Microcontrollers and finally NXP LPC437 microcontroller which I have just started. 204Mhz with Cortex M4 & M0 Processors. NICE !!!!

I have never been interested in C as I could do everything I wanted in fast Assembler or BASIC but I find nothing wrong with the C language. It's just the SYNTAX is difficult to read but all languages do the same thing, it's just that the syntax is different. Some compiled code is larger than others and some not. It's really up to the individual which language suits them.

Is this like the old days where I say that My Atari 800XL is better than your Commodore64 or Apple IIe ? hehehehehe

Anyway so all is cool. :)

Pete

[lpcware]

Content originally posted in LPCWare by acelink1 on Wed Feb 05 15:28:25 MST 2014
Thank you LPCXpresso support for the info. hehe No, I am not starting a war between C and Assembler. 
My project is for VGA video generation and I need to count every clock cycle and you can't do that in C.

I see nothing wrong with the C language, it's the same as any other language except for the syntax.
They all do the same thing, moving data and setting bits here and there.

Thank you again for the info and I'll read up on the links you suggested.

Pete :)

[lpcware]

Content originally posted in LPCWare by rocketdawg on Wed Feb 05 10:04:18 MST 2014

---

Quote: IanB

"Maybe moving to a new MCU would be a good time to consider starting to improve your C" is a very irritating reply - presumably from someone who can't write assembler and wishes he could.

---

Now, now, no need to get nasty.  You just flamed a NXP support person.
You think nasty is going to encourage him/her to help you all the more, or help you in the future?

Your development processes are your own concern.  If you want to use assembly, go right ahead.  We seldom do, and only for timing critical optimizations.
But, engineers are notorious for NOT knowing what part of the code should be optimized by using assembly, so there must be profiling proof.

Most of us cannot use assembly, because we need modern design processes, like clean code, peer review, unit tests, constant integration, regression tests, RTOS, design patterns, Safety critical, ...
We often work in teams were cut and paste is frowned upon because it transmits defects to other areas of the code, instead of a library function (that is what the linker is for) where one can fix the defect once.
We also do not want to "marry" the code.  Such as, this code is mine, no one knows how it works, and if something is wrong, only I can fix it, because I am the only one that codes in asm.
you might think that leads to job security, but it really leads to a stale career.  Pigeon holed.
Even a collage intern can maintain C code, but they do not really teach assembly in collage any more.


besides, I'd rather not write a peripheral stack (USB, Ethernet, SD/Fat) in assembly, when NXP goes to all the trouble to provide one in C.

[lpcware]

Content originally posted in LPCWare by IanB on Wed Feb 05 09:15:53 MST 2014
I'm looking for the same information as Pete - how to set up an assembler program. I have been programming in assembler since the 6502 was around, and I like to think that I'm pretty good at it by now. All I want to do is write code in a text editor, compile it, load it into the processor and debug it.  I write all my code in ONE file. If I want to include code I've written before - that's what "cut and paste" on the text editor is for. It remains a mystery to me what a linker does.

"Maybe moving to a new MCU would be a good time to consider starting to improve your C" is a very irritating reply - presumably from someone who can't write assembler and wishes he could. Why should anyone who has years of experience in assembler be asked to jettison all that expertise? Writing in assembler is essentially quite a simple procedure and I have my suspicions that many "software development environments" are designed to make it appear much more complex than it really is, in order to persuade uses down the C route.

As many replies have suggested I have examined the output of the C compiler, and in most cases was appalled to find out how inefficient it was. In one case, having examined 32 lines of assembler to see what it was doing, I found it was something I could have done in four assembly instructions. With that performance, who needs a 50MHz processor?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Feb 05 05:03:31 MST 2014
Personally, and without wanting to start an "ASM vs C" war, I would strongly recommend that you reconsider your decision to use assembler. Maybe moving to a new MCU would be a good time to consider starting to improve your C  :)

But if you really still want to do this, then I would suggest that you use the forum search option (on the right of the page) to find previous threads with "assembly" or "assembler" in them, for example:

http://www.lpcware.com/content/forum/how-to-compile-assembly-instructions-i-lpcxpresso-ide
[Note that this particular thread was imported from an old forum system to LPCware, and some of the links are no longer live.]

With regards to creating an assembler file, just ensure that the source file that you create has a .s file extension, and it should get assembled rather than compiled.

And if you are targeting LPC43, I would suggest that you also do some reading, starting with the FAQ at:

http://www.lpcware.com/content/faq/lpcxpresso/lpc18-lpc43-support

and download an appropriate LPCOpen driver/examples package from:

http://www.lpcware.com/content/nxpfile/lpcopen-software-development-platform-lpc43xx-packages

Regards,
LPCXpresso Support