ARM7 complete development tools?

Hi Grant,

Grant Edwards wrote:
> On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
>> Hi Richard (and Grant),
>>
>> FreeRTOS info wrote:
>>> On 06/06/2010 17:10, Grant Edwards wrote:
>>>> On 2010-06-06, Michael Kellett <nospam@nospam.com> wrote:
>>>>
>>>>> Now for the bee in my bonnet !!!
>>>>>     Why do people buy development boards?
>>>> 1) They allow you to run benchmark code to compare different
>>>>    processors.
>> Nowadays, with most processors, I think you can get better
>> data from a simulator
> 
> Where do you get accurate simulators?

Have you *looked*?  Almost every ARM toolchain has one.
Microchip's MPLAB, Freescale products, many "legacy"
devices, etc.  *Look* and ye shall find.  :>

>> All it really gives you, here, is the ability to evaluate their
>> *hardware* debugging tools.  I.e., the quality of the code
>> generated doesn't vary whether you are running it on real
>> hardware or virtual hardware.
> 
> I've never found simulators for the vast majority of CPUs I've used.
> Do the correctly simulate timings of caches, bursting SDRAM and DMA
> controllers.  Bandwidth limitations on various busses, etc.?

That will vary based on your *final* hardware!  I.e., if I
replace that nice zero-wait state SRAM with a chunk of SDRAM,
you'll find all the timing data from your development board
suddenly invalid.

>>>> 3) They allow software development work to start long before the
>>>>    custom product boards are ready.
>> I've seen very few cases where this was truly necessary.
> 
> Of course it's not necessary.  Neither is a compiler or assembly. I've
> always been able to do a great deal of work with development boards.

Don't be pedantic.  Think about what I wrote.

I can count on a few fingers the number of projects in the past
three decades where I *needed* hardware early on in the project.
In each of those cases, the reason for the "need" was to test
some novel bit of I/O (for which a development board wouldn't
give me any advantage).  E.g., "I want to detect the presence
of a 10 microliter blood sample reliably using a detector that
doesn't require calibration, operates in EM/RF harsh environments
and doesn't cost more than a few pennies".  I surely wouldn't
worry about which *processor* I ran the code on to exercise
the I/O!

If you "need" hardware that early for your projects, I
suspect you've fallen into the "start writing code on day one"
mode instead of "start *designing* the software on day one".

>> Most of the time, people seem to start "Hello world"
>> instead of immediately diving down to some particular
>> aspect of the interaction between the interrupt
>> controller and the DMA controller, etc.  (i.e., *real*
>> hardware issues).
>>
>> Spehro's point (with the caveat s/hardware/silicon/) is
>> well made -- but, IME, you don't just stumble over bugs
>> in the silicon that quickly when using a development
>> board
> 
> Who said anything about bugs in the silicon?

That's a legitimate use for a development board!  Because
it lets you *find* bugs in the silicon (which aren't
often obvious -- or disclosed -- in data sheets).

My point was you rarely *stumble* on those quickly
(it's pretty unlikely that there is a bug in the
"ADD" opcode; but, possibly a bug when reloading a
DMA transfer count with "0xFFFF" *and* setting the
source address to "0x0002", etc.)

>>> 5) When your custom hardware comes back from the manufacturer and your
>>> software does not run on it - they allow you to very quickly determine
>>> if its (primarily) a software or hardware problem.
>> If your software is running in a simulator,
> 
> Where do you find all these simulators?  It's been decades since I
> worked with a CPU for which a useful simulator was available.

*Look*.  Google "ARM simulator", "Freescale simulator",
"open source simulator", "MPLAB simulator", etc.

>> Any place that I've worked has made it the hardware person's
>> responsibility to ensure the hardware is functional.
> 
> That's not the way it is most of the places I've worked.

So, the *software* person is responsible for ensuring
the hardware's functionality?  Is the *hardware* person
responsible for the correct functionality of the
*software*??  Wow, I'd love to be a software guy, there!!

>> A hardware designer can learn everything he needs to
>> know about a development board from its schematics
>> (usually published or readily available).  There's no
>> need to "touchy feely" the board.
> 
> In my experience, development boards are for use by software people,
> not hardware people.

A hardware designer will look at as many designs as he can
(reasonably) get his hands on before embarking on a given design.
Sometimes, something "unusual" will be present in a design
that will question his understanding of how the device
is supposed to work.  This might clarify some detail of
the datasheet -- or, alert him to a problem area that
the vendor is "working around" (so the vendor can be
questioned on the issue).

E.g., an external synchronizer on what *should* be an
asynchronous input is a strong clue that there is a
problem with the internal synchronizer *or* the "process"
(geometry issue?).

Likewise, a cap (gak!) on a "TC out" signal suggests the
output is glitchy and could benefit from some better
signal conditioning.

These are the sorts of things that the clueless software guy
will spend days/weeks scratching his head over because he's
not familiar with the non-ideal characteristics of the hardware
and wonders why "the motor stopped prematurely".

Hi Richard,

FreeRTOS info wrote:
> On 07/06/2010 15:29, Grant Edwards wrote:
>> On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
>>> Hi Richard (and Grant),
>>>
>>> FreeRTOS info wrote:
>>>> On 06/06/2010 17:10, Grant Edwards wrote:
>>>>> On 2010-06-06, Michael Kellett <nospam@nospam.com> wrote:
>>>>>
>>>>>> Now for the bee in my bonnet !!!
>>>>>>     Why do people buy development boards?
>>>>> 1) They allow you to run benchmark code to compare different
>>>>>    processors.
>>> Nowadays, with most processors, I think you can get better
>>> data from a simulator
>> Where do you get accurate simulators?
> 
> I think there is a little game playing going on here by Yuniskis ;o)

Not at all.  I do more than 90% of my (software) development
work in a simulator environment.  Often not even on the
same processor that I will use in the target.

> Here is a FreeRTOS support request scenario that is all too familiar:
> 
> Q: Your RTOS does not work.
> Me: Can you send me your project so I can investigate?
> 
> Q: Sure, here it is.
> Me: That is a strange project, what hardware is it configured for.
> 
> Q: We don't have hardware yet, its running in a simulator.
> Me: Ah, I see.  Ask again when you know it doesn't run on hardware.
> Simulators for this CPU don't generally run FreeRTOS projects because of
> x, y and z.

I suspect the problem you will encounter is not being able to
simulate asynchronous events.  E.g., I simulate ASR's in my OS's
by just breaking execution and "call-ing" the jiffy (or other
ASR).

But, I don't need to do this when simulating *task* level
code (all the libraries, etc.) as they are supposed to run
regardless of whether or not they are preempted, etc.

E.g.,

while (FOREVER) {
    lamp(ON);
    sleep(ON_TIME);
    lamp(OFF);
    sleep(OFF_TIME);
}

doesn't care what's running *under* it:

static boolean LED;
lamp(boolean state) {
    LED = state;
}

sleep(int time) {
    /* spin-wait proportional to "time" */
OR
    /* call OS hook with "time" */
OR
    /* print "We are now pausing for 'time' seconds" */
}

all approaches are equally valid and can be simulated
equally.

Even interactions between tasks can be simulated.   In fact,
it is often easier to find problems in the code by doing
this (instead of sitting back and wondering why they
aren't "playing nice together").

The hardest things I have found to simulate are "CAN'T HAPPEN"
conditions.  I.e. setting up an environment that your code
is designed to protect itself against in "the real world".

These are even *harder* to test for with real hardware
because the hardware is *supposed* to behave (and the
purpose of the test is to make sure that if the hardware
*misbehaves* your code will react gracefully instead of
crashing and burning).  In testing my memory allocator
recently, I had to resort to preparing test cases on
paper and "poking" values into memory ahead of the code
just to verify that it wouldn't stumble if it encountered
those (inappropriate) values during normal execution.

Dong this with "real hardware" would afford no benefit
(and, might even be prohibited -- misaligned data
accesses, etc.)

On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
> Hi Grant,
>
> Grant Edwards wrote:
>> On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
>>> Hi Richard (and Grant),
>>>
>>> FreeRTOS info wrote:
>>>> On 06/06/2010 17:10, Grant Edwards wrote:
>>>>> On 2010-06-06, Michael Kellett <nospam@nospam.com> wrote:
>>>>>
>>>>>> Now for the bee in my bonnet !!!
>>>>>>     Why do people buy development boards?
>>>>> 1) They allow you to run benchmark code to compare different
>>>>>    processors.
>>> Nowadays, with most processors, I think you can get better
>>> data from a simulator
>> 
>> Where do you get accurate simulators?
>
> Have you *looked*?  Almost every ARM toolchain has one.
> Microchip's MPLAB, Freescale products, many "legacy"
> devices, etc.  *Look* and ye shall find.  :>

Right now, I'm working with an Atmel AT91SAM9G20.  Where can I find a
simulator for that?

It will need to provide reasonably accurate network throughput
results for various memory configurations.

>>> All it really gives you, here, is the ability to evaluate their
>>> *hardware* debugging tools.  I.e., the quality of the code
>>> generated doesn't vary whether you are running it on real
>>> hardware or virtual hardware.
>> 
>> I've never found simulators for the vast majority of CPUs I've used.
>> Do the correctly simulate timings of caches, bursting SDRAM and DMA
>> controllers.  Bandwidth limitations on various busses, etc.?
>
> That will vary based on your *final* hardware!

True, but I've always been able to get very representative results
from development boards.

> I.e., if I replace that nice zero-wait state SRAM with a chunk of
> SDRAM, you'll find all the timing data from your development board
> suddenly invalid.

Of course.  That's why one uses a development board with the same type
of memory that one is planning on using.

>> That's not the way it is most of the places I've worked.
>
> So, the *software* person is responsible for ensuring
> the hardware's functionality?

It's generally been the software persons reponsibility to test the
hardware and determine what works and what doesn't.

>> In my experience, development boards are for use by software people,
>> not hardware people.
>
> A hardware designer will look at as many designs as he can
> (reasonably) get his hands on before embarking on a given design.
> Sometimes, something "unusual" will be present in a design that will
> question his understanding of how the device is supposed to work.
> This might clarify some detail of the datasheet -- or, alert him to a
> problem area that the vendor is "working around" (so the vendor can
> be questioned on the issue).

But you don't need a board for that.  You just need the schematics.

> E.g., an external synchronizer on what *should* be an
> asynchronous input is a strong clue that there is a
> problem with the internal synchronizer *or* the "process"
> (geometry issue?).
>
> Likewise, a cap (gak!) on a "TC out" signal suggests the
> output is glitchy and could benefit from some better
> signal conditioning.

You don't need a development board for that.  All you need is a
schematic.

> These are the sorts of things that the clueless software guy
> will spend days/weeks scratching his head over because he's
> not familiar with the non-ideal characteristics of the hardware
> and wonders why "the motor stopped prematurely".


-- 
Grant Edwards               grant.b.edwards        Yow! Either CONFESS now or
                                  at               we go to "PEOPLE'S COURT"!!
                              gmail.com            

Hi Grant,

Grant Edwards wrote:
> On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
>> Hi Grant,
>>
>> Grant Edwards wrote:
>>> On 2010-06-07, D Yuniskis <not.going.to.be@seen.com> wrote:
>>>> Hi Richard (and Grant),
>>>>
>>>> FreeRTOS info wrote:
>>>>> On 06/06/2010 17:10, Grant Edwards wrote:
>>>>>> On 2010-06-06, Michael Kellett <nospam@nospam.com> wrote:
>>>>>>
>>>>>>> Now for the bee in my bonnet !!!
>>>>>>>     Why do people buy development boards?
>>>>>> 1) They allow you to run benchmark code to compare different
>>>>>>    processors.
>>>> Nowadays, with most processors, I think you can get better
>>>> data from a simulator
>>> Where do you get accurate simulators?
>> Have you *looked*?  Almost every ARM toolchain has one.
>> Microchip's MPLAB, Freescale products, many "legacy"
>> devices, etc.  *Look* and ye shall find.  :>
> 
> Right now, I'm working with an Atmel AT91SAM9G20.  Where can I find a
> simulator for that?

Maybe you should ask your vendor why they haven't provided one!

> It will need to provide reasonably accurate network throughput
> results for various memory configurations.

Gee, I'm working on a project with synchronized, distributed
system clocks (a variant of PTP) and *I* don't need hardware
until damn near *all* the code is written and debugged.
In fact, I can't *prove* the code works by having hardware
as creating a worst case network environment is tricky to
do in a repeatable way (especially since the code tries to
adapt to pathological cases it encounters).

I.e., getting everything right ON PAPER is essential to the
products working.

>>>> All it really gives you, here, is the ability to evaluate their
>>>> *hardware* debugging tools.  I.e., the quality of the code
>>>> generated doesn't vary whether you are running it on real
>>>> hardware or virtual hardware.
>>> I've never found simulators for the vast majority of CPUs I've used.
>>> Do the correctly simulate timings of caches, bursting SDRAM and DMA
>>> controllers.  Bandwidth limitations on various busses, etc.?
>> That will vary based on your *final* hardware!
> 
> True, but I've always been able to get very representative results
> from development boards.

And I get great results from simulations.

>> I.e., if I replace that nice zero-wait state SRAM with a chunk of
>> SDRAM, you'll find all the timing data from your development board
>> suddenly invalid.
> 
> Of course.  That's why one uses a development board with the same type
> of memory that one is planning on using.

And the same type of analog signal conditioning, timebases, etc. (?)

>>> That's not the way it is most of the places I've worked.
>> So, the *software* person is responsible for ensuring
>> the hardware's functionality?
> 
> It's generally been the software persons reponsibility to test the
> hardware and determine what works and what doesn't.

Ah, my sympathies.  Like the guy who puts the wheels on the
car deciding if the wheel wells are the right size  :-/

>>> In my experience, development boards are for use by software people,
>>> not hardware people.
>> A hardware designer will look at as many designs as he can
>> (reasonably) get his hands on before embarking on a given design.
>> Sometimes, something "unusual" will be present in a design that will
>> question his understanding of how the device is supposed to work.
>> This might clarify some detail of the datasheet -- or, alert him to a
>> problem area that the vendor is "working around" (so the vendor can
>> be questioned on the issue).
> 
> But you don't need a board for that.  You just need the schematics.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  <grin>


>> E.g., an external synchronizer on what *should* be an
>> asynchronous input is a strong clue that there is a
>> problem with the internal synchronizer *or* the "process"
>> (geometry issue?).
>>
>> Likewise, a cap (gak!) on a "TC out" signal suggests the
>> output is glitchy and could benefit from some better
>> signal conditioning.
> 
> You don't need a development board for that.  All you need is a
> schematic.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  <grin>

>> These are the sorts of things that the clueless software guy
>> will spend days/weeks scratching his head over because he's
>> not familiar with the non-ideal characteristics of the hardware
>> and wonders why "the motor stopped prematurely".

> Hello.
> We are in the beginning of development of new product with ARM7
> Can someone tell us what options we have for development tools? We
> need a list of available dev toolset, such as
> compiler+emulator+(RTOS)+(dev. board)+(processor) that work with each
> other. also, perhaps some comments on those tools.

> Thanks!!

> Jack

Very late to the party but my area of expertise:
Two very well tested options:

IAR + compiler
JLink (JTrace), + emulator
PowerPAC = embOS + RTOS
manyboards +
LPC2300/LPC2400/STR9/SAM7X or CortexM3 based LM3S/STM32/LPC1700
processor
For your LCD extension you can use emWin
http://www.iar.com
http://www.segger.com

Keil MDK + compiler
ULink2 + emulator
RL-ARM + RTOS
manyboards +
LPC2300/LPC2400/STR9/SAM7X or CortexM3 based LM3S/STM32/LPC1700
processor
For your LCD extension you can use emWin
http://www.keil.com
http://www.segger.com

Both are professional packages targeted at companies that are serious
with a short time to market and have a sizable tools budget
Total tools cost full blown for both option above > $10k

Alternative at much lower cost and with limitations:
Raisonance RIDE7 + IDE + Compiler
RLink PRO + emulator
circleOS + small free RTOS
Primer2 or REva or LPC1700 + Boards
STM32 or STR9 processor families
http://www.mcu-raisonance.com

Total tools cost full blown for option above > $1-2k

Limitations: CircleOS less powerful than RL-ARM or Powerpac/embOS
Limited to less choices with processors
Compilers from Keil and IAR might offer slightly more compact code
than a GNU based compiler

Some tools information:
http://www.lpc2000.com/tools

Cheers, An Schwob