One that covers evaluating and setting up toolchains for assembly and debugging?
Anyone know of a good forum for ARM assembly language?
Started by ●December 27, 2011
Reply by ●December 27, 20112011-12-27
Jim Stewart wrote:> One that covers evaluating and setting up > toolchains for assembly and debugging?I did find this: http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html That being said... 1) 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 by ●December 27, 20112011-12-27
On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill <lcargill99@comcast.com> wrote:>Jim Stewart wrote: >> One that covers evaluating and setting up >> toolchains for assembly and debugging? > >I did find this: >http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html > >That being said... > >1) They're mainly done in 'C'.Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do more than a pin-wiggler in straight assembly.> >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.(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 by ●December 27, 20112011-12-27
On Tue, 27 Dec 2011 15:16:35 -0500, Rich Webb wrote:> On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill <lcargill99@comcast.com> > wrote: > >>Jim Stewart wrote: >>> One that covers evaluating and setting up toolchains for assembly and >>> debugging? >> >>I did find this: >>http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >> >>That being said... >> >>1) They're mainly done in 'C'. > > Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do > more than a pin-wiggler in straight assembly. > > >>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. > > (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.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. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 27, 20112011-12-27
Tim Wescott wrote:> On Tue, 27 Dec 2011 15:16:35 -0500, Rich Webb wrote: > >> On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill<lcargill99@comcast.com> >> wrote: >> >>> Jim Stewart wrote: >>>> One that covers evaluating and setting up toolchains for assembly and >>>> debugging? >>> >>> I did find this: >>> http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >>> >>> That being said... >>> >>> 1) They're mainly done in 'C'. >> >> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do >> more than a pin-wiggler in straight assembly. >> >> >>> 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. >> >> (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. > > 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. >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 by ●December 27, 20112011-12-27
Rich Webb wrote:> On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill<lcargill99@comcast.com> > wrote: > >> Jim Stewart wrote: >>> One that covers evaluating and setting up >>> toolchains for assembly and debugging? >> >> I did find this: >> http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >> >> That being said... >> >> 1) They're mainly done in 'C'. > > Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do > more than a pin-wiggler in straight assembly. > >> >> 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. > > (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 ... >Lol! Yeah, there's that. Pretty easy to fix, usually.> I'd just as soon go back to the book and do it myself. >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 by ●December 27, 20112011-12-27
On Tue, 27 Dec 2011 15:49:06 -0600, Les Cargill wrote:> Tim Wescott wrote: >> On Tue, 27 Dec 2011 15:16:35 -0500, Rich Webb wrote: >> >>> On Tue, 27 Dec 2011 12:18:18 -0600, Les >>> Cargill<lcargill99@comcast.com> wrote: >>> >>>> Jim Stewart wrote: >>>>> One that covers evaluating and setting up toolchains for assembly >>>>> and debugging? >>>> >>>> I did find this: >>>> http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >>>> >>>> That being said... >>>> >>>> 1) They're mainly done in 'C'. >>> >>> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to >>> do more than a pin-wiggler in straight assembly. >>> >>> >>>> 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. >>> >>> (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. >> >> 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. >> >> > > 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.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. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 27, 20112011-12-27
Tim Wescott wrote:> On Tue, 27 Dec 2011 15:49:06 -0600, Les Cargill wrote: > >> Tim Wescott wrote: >>> On Tue, 27 Dec 2011 15:16:35 -0500, Rich Webb wrote: >>> >>>> On Tue, 27 Dec 2011 12:18:18 -0600, Les >>>> Cargill<lcargill99@comcast.com> wrote: >>>> >>>>> Jim Stewart wrote: >>>>>> One that covers evaluating and setting up toolchains for assembly >>>>>> and debugging? >>>>> >>>>> I did find this: >>>>> http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >>>>> >>>>> That being said... >>>>> >>>>> 1) They're mainly done in 'C'. >>>> >>>> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to >>>> do more than a pin-wiggler in straight assembly. >>>> >>>> >>>>> 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. >>>> >>>> (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. >>> >>> 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. >>> >>> >> >> 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. > > 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. >Same here. But there were other peripherals that had to be brought up.> What processor were you using, whose debugger, and whose tool chain? >DaVinci ( in one case ) - IOW, ARM9 with a weird multidrop JTAG interface, GreenHills/GreenHills. -- Les Cargill
Reply by ●December 27, 20112011-12-27
On 2011-12-27, Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:> On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill <lcargill99@comcast.com> > wrote: > >>Jim Stewart wrote: >>> One that covers evaluating and setting up >>> toolchains for assembly and debugging? >>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.>>I did find this: >>http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html >> >>That being said... >> >>1) They're mainly done in 'C'. > > Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do > more than a pin-wiggler in straight assembly. >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.>> >>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. > > (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. >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... :-)> 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. >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 by ●December 28, 20112011-12-28
On 28/12/2011 02:52, Simon Clubley wrote:> On 2011-12-27, Rich Webb<bbew.ar@mapson.nozirev.ten> wrote:>> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do >> more than a pin-wiggler in straight assembly. >> > > You still need to write (at least for traditional devices) the initial > startup code as well as the interrupt/abort handlers in assembly language. >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!
