Anyone know of a good forum for ARM assembly language?

One that covers evaluating and setting up toolchains for assembly and debugging?

Reply to
Jim Stewart
Loading thread data ...

I did f1) They're mainly done in 'C'.

2) You'll need a board support package and a JTAG thingy to do board bringup in a reasonable amount of time. Hopefully, your board will be based largely on an existing reference design that has a BSP.

Just getting the PLLs set up to operate RAM can be daunting.

-- Les Cargill

Reply to
Les Cargill

Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do more than a pin-wiggler in straight assembly.

(Hijacking the thread, I suppose but...) I've not found BSPs to be all that useful. I find that I can spend more time trying to find just where they've hidden the, e.g., clock configuration stuff and what I need to tickle to get the various clocks setup how *I* want them, than the time it takes me to read the user manual sections and diddle the registers directly.

Your mileage may vary but when I run across things like:

// Setup CAN0 ... some code to init the CAN 0 peripheral ...

// Setup CAN0 [sic] .. some code to init the CAN 1 peripheral that was obviously a copy/paste from the CAN 0 block, with some but not all references pointing to the right peripheral ...

I'd just as soon go back to the book and do it myself.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

It depends on the processor and the OS. The last time I used a purchased BSP was when we used VxWorks with a board -- and the BSP was necessary for the OS far more than the hardware.

If you're used to "bare metal" programming, a BSP just gets in the way.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

It depends on local culture, I suppose. I've seen it both ways. Last BSP I ran into happened to be for Green Hills INTEGRITY.

The assumption where we might have gone wrong may have been: SFAIK, the register file that comes with the USB wiggler/JTAG thingy is part of the BSP. *That* is harder to do without.

-- Les Cargill

Reply to
Les Cargill

Lol! Yeah, there's that. Pretty easy to fix, usually.

Even the SDRAM controller? For a sufficiently advanced ARM, that's where the BSP and/or JTAG debugger-plus-register file came in really handy.

-- Les Cargill

Reply to
Les Cargill

The "little" ARM processors that I've used (mostly the TI/Luminary Cortex M3 ones) don't require any additional resources to use the JTAG debugger

-- it's all in the processor.

What processor were you using, whose debugger, and whose tool chain?

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

Same here. But there were other peripherals that had to be brought up.

DaVinci ( in one case ) - IOW, ARM9 with a weird multidrop JTAG interface, GreenHills/GreenHills.

-- Les Cargill

Reply to
Les Cargill

What's the scope of what you are trying to do ?

Is your main concern learning the language/architecture itself or learning how to setup and work with a toolchain ?

To learn ARM assembly language itself, I just used the ARM manuals available on the ARM website; I found them to be well written.

They also cover general architecture level issues such as handling interrupts and abort handlers.

As for a ARM toolchain, I just use a gcc based build called Yagarto. Although it's intended for Windows users, everything works just fine on Linux when building from source although I remember making some tweaks for personal preferences while building.

You still need to write (at least for traditional devices) the initial startup code as well as the interrupt/abort handlers in assembly language.

And yes, ARM assembly language is really elegant and expressive. The only real annoyance is with constants over 8 bits long that are not straight powers of 2, but that's just a small annoyance.

Sometimes the information isn't in the manual. For example, I'm currently playing with a LPC3131 based board which has 92 clocks and 24 fractional dividers.

While there's some example configuration information in the user manual, there isn't a full recommended default configuration, with the various relationships between the different clocks and dividers documented in the manual. For that information, you have to dig into the NXP example code.

If it's just a few clocks, it's easy enough to work out for yourself if a default mapping is not specifically documented in the manual. When you are talking about 92 clocks, that's slightly different... :-)

I've found that to be true in some manuals as well. :-)

(The LPC3131 user manual has clearly been built using the copy and paste approach...)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

In most cases, you can write startup code in C. It is perfectly possible to write C code before the initial C environment has been brought up. You need to take certain precautions - like avoiding anything that requires the stack until it is in place (you want to do that first thing), and being careful with memory and avoiding incorrect assumptions. You will also want to check the generated assembly code to be sure it is all safe. But there is no good reason for writing startup code in assembly - I have often replaced all or part of a toolchain's standard assembly startup code with better, clearer, faster and smaller code written in C.

And almost all toolchains will let you write your interrupt handlers in C. There may be a small amount of wrapper assembly, especially when you are using a common interrupt vector before farming out to specific interrupt functions, but the main work of the interrupt function can be in C.

I'm not against writing assembly when it makes sense - or even just for fun - but don't feel you /have/ to use assembly unless you really do!

Reply to
David Brown

Yes, that's what I do. However, the few lines of _initial_ startup code (the code that runs right out of reset) needs to be in assembly because you do need to load a temporary SP in order for your C routine to be able to use temporary stack variables (I'm not talking about anything in .data or .bss here, but things like loop counters) as well as setup the various processor modes permanent stack pointers and CPSRs once the main C startup code has finished.

I suppose you could use embedded assembly code within a C routine to do this, but I prefer to have a small outer layer assembly routine be in control of the startup which calls a couple of C routines (one before .data/.bss has been setup; one afterwards) to do the bulk of the startup.

In my defence, it was past midnight local time when I wrote that. :-)

Yes, I meant the interrupt wrapper, not the full interrupt handler; the main interrupt handlers are in C. My abort handlers are also a few lines of assembly (which dumps the register state and abort type to a .bss area) before calling a C level abort routine.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

I think we are on the same level here. I usually put such code in "asm" statements in a C file, since they are typically only a couple of instructions long. It's usually a good idea to have a basic stack in place before jumping to C - internal ram is very useful for that. I usually also do the clearing of .bss and copying of .data in C - let the compiler do its job of unrolling and optimising.

Reply to
David Brown

I wrote an IP checksum routine in ARM assembly once. It took several days of sweat to get it to the point where it was faster than the generic C routine in the NetBSD stack sources -- and doing so required some hints from an expert regarding some obscure features of the ARM ALU.

The sample code provided by most of the CPU vendors is the absolute worst. I don't know who they hire to write that stuff...

Sometimes "the book" is so badly done that finding some code that works is the only way to get started (I'm talking about you, Samsung).

--
Grant Edwards               grant.b.edwards        Yow! The FALAFEL SANDWICH
                                  at               lands on my HEAD and I
 Click to see the full signature
Reply to
Grant Edwards

[...]

Sure. (That was the last thing I did before chrismas holidays :-)

The BSP was really handy as an example: you need these units to set up clocks, these for SPI, and here finally you have the SDRAM.

But other than that, it was a big mess. Two u-boot derivatives stacked above each other, each initialising some part of the hardware, plus an operating system BSP initialising some other parts and reinitialising some of the original parts differently -- that's what I happily replace.

By four lines of assembly plus a few hundred lines of C, which compile to 3.5 k, I might add, for the other half of the thread: the compiler does a much better job at register-dancing than I do.

Stefan

Reply to
Stefan Reuther

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.