Les Cargill wrote:
> Rich Webb wrote:
>> (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.
[...]
>> I'd just as soon go back to the book and do it myself.
> 
> Even the SDRAM controller?

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

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

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

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?
>>
>>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.

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.

> (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 ...

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...

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

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
                              gmail.com            become a VEGETARIAN ...

On 28/12/2011 10:54, Simon Clubley wrote:
> On 2011-12-28, David Brown<david@westcontrol.removethisbit.com>  wrote:
>> 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
>
> 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.
>

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.

>> 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.
>>
>
> 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.
>

On 2011-12-28, David Brown <david@westcontrol.removethisbit.com> wrote:
> 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 

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.

> 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.
>

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

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!

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

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

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

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

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