ARM7 complete development tools?

On 6/6/2010 8:53 AM, Michael Kellett wrote:
>
> Now for the bee in my bonnet !!!
>      Why do people buy development boards ?
>
> Michael Kellett

Now for the bee in your bonnet !!!

Why do people complain about thing they can not change.

With the number of development boards out in the world, there must be 
some kind of a demand, but that would require thinking past your own 
little world.

hamilton

Am 06.06.2010 16:53, schrieb Michael Kellett:

> Now for the bee in my bonnet !!!
>      Why do people buy development boards ?

I use them as a known-good starting point for my own tests. I've 
recently bought an MSP430 board made by Olimex in order to get used to 
this new (for me) architecture, the tools, software etc. These board are 
even more useful as fewer and fewer parts are available in a 
breadboardable package. The chip on the Olimex board was an F1611, my 
own board used an F2274. There were some differences, but they were not 
so big, and the transision was done in an hour or so.

-- 
Mit freundlichen Gr��en

Frank-Christian Kr�gel

On 06/06/2010 17:10, Grant Edwards wrote:
> On 2010-06-06, Michael Kellett <nospam@nospam.com> wrote:
>=20
>> Now for the bee in my bonnet !!!
>>     Why do people buy development boards?
>=20
> 1) They allow you to run benchmark code to compare different
>    processors.
>=20
> 2) They allow you to evaluate toolchains and other infrastructure.
>=20
> 3) They allow software development work to start long before the
>    custom product boards are ready.
>=20
> 4) They're free: you often don't buy them -- you borrow them from the
>    CPU distributor.
>=20


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.

They are so inexpensive (normally) why would you not have one?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T=DCV as meeting the requirements for safety related systems=
=2E

Hi Rocky,

RockyG wrote:
>> Hi Michael,
>>
>> Michael Kellett wrote:
>>> Why do people buy development boards ? They either have no hardware 
>>> (like the Silabs ones) so you need to make a board with your own stuff
> on to 
>>> get your project going or they have loads of stuff on them (like the ST
> 
>>> ones) but it's never what you want, so you need to make a board with
>>> your own stuff on to get your project going.
>> Yes!  I simply cannot understand this huge waste of effort.
>> You are *going* to design a board *anyway*.  Do it and at least
>> get started on the path to nailing down all the "gotchas" that
>> *will* come up in the design.
>>
>> Years ago, I could *almost* understand the rationale that "it
>> lets the programmers get started" (yet another self-delusion!).
>> But, nowadays, you can write and debug *lots* of code without
>> ever needing real hardware.  For most projects, you don't even
>> need to use the actual tools for the targeted platform for
>> much (most?) of the code!
>>
> I find them useful from the POV that you can use them as a sanity check.
> I.E. Have I installed the tool-suite correctly or is it my hardware that
> has a problem?

Understood.  I'm in the position where if the hardware doesn't
work, it's *still* "my problem"  :>

> Once the 1st project is done, the usefulness falls away as you have
> reasonable confidence that the h/w is OK.	   

I much prefer the "freedom" to not get tied down to a particular
hardware implementation until I absolutely *must*.  Especially
nowadays with new devices appearing "daily" -- and, old devices
*disappearing* just as frequently!

If you insist on having hardware before you can write code,
then you put that in the critical path, force people to
make decisions about that hardware (which you will have to
buy into!) and then you end up as the "wagged tail".  :<

Even with lots of experience, its still hard to come up
with realistic estimates for time and space on hardware
requirements.  And, if you are in a market where cost is
a criteria, you can't afford to err on the high side
(since it gives your competitors an advantage) *or* on
the low side (since it can greatly complicate your
design).

For most designs, the "processor+I/O" is usually pretty
simple to throw together.  Layout is a breeze with modern
tools (no more cutting rubilyth!).  And, there are *so*
many quick-turn houses out there that you can get a first
pass of your *final* board in a month or two (start of
design to first copper).

Spend the energy better learning your tools so you can
leverage their effectiveness.  I'd much prefer examining
symbolic variables and looking through trace buffers
than sitting with a scope probe wondering why a signal
is at 37% duty cycle instead of 52%, etc.

"Michael Kellett" <nospam@nospam.com> wrote in message 
news:jd6dnb-iQYr4K5bRnZ2dnUVZ8kqdnZ2d@bt.com...
>
> Now for the bee in my bonnet !!!
>    Why do people buy development boards ?

Think of it another way. Ask yourself why do they also buy development 
software written by others and you might answer your own question.

P.S. We write our own development software ;-)

--
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com

"hamilton" <hamilton@nothere.com> wrote in message 
news:hugmju$j7b$1@news.eternal-september.org...
> On 6/6/2010 8:53 AM, Michael Kellett wrote:
>>
>> Now for the bee in my bonnet !!!
>>      Why do people buy development boards ?
>>
>> Michael Kellett
>
> Now for the bee in your bonnet !!!
>
> Why do people complain about thing they can not change.
>
> With the number of development boards out in the world, there must be some 
> kind of a demand, but that would require thinking past your own little 
> world.
>
> hamilton

Oh Hamilton - why must you insult that which you have mostly missed the 
point of.

I asked the question  - with I thought, sufficient pointers to suggest that 
it was a matter for philosophical discussion - so I would have thought my 
willingness to think "past" .. my .. "own little world" was clear enough.

Actually there have been some interesting points made.

I am surprised to learn that some engineers have the time and resources to 
actually test several different processors physically rather than comparing 
on paper. I've never found it to be necessary but then I quite like reading 
data sheets.

Another poster suggested that development boards are frequently not bought 
(and I did ask why people buy them) but given and indeed I have quite a few 
lying around that I was given.

I do often look at development board schematics but I don't need the 
phyisical board to get the benefit of them in my own designs.

It's also fair to say that most of my work is for designs which will be made 
in small numbers - as few as one and rarely more than a few thousand. Saving 
a little on the cost of the processor chip is not often an issue.

However for mass production designs there is huge value in getting real 
hardware early in the project.

Thanks for all the comments (and I hope the OP got something out of it too 
!)

Michael Kellett

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 -- since getting it from real hardware
usually means erecting some test scaffolding to set up
the test cases and "signal" the actual measuring instrument
(e.g., scope loops, etc.)

The simulator approach is also a lot easier to instrument
and do post-mortems ("OK, your code on this processor seems
to run slower... *where* is the bottleneck?" requires you
to build a new test case instead of just reexamining the
simulator traces)

>> 2) They allow you to evaluate toolchains and other infrastructure.

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.

>> 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.
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 (or, if so, those bugs are already well known and
a few minutes with google would turn them up!).  You
also have to be sure the silicon on the board isn't
"stale" and agrees with the silicon that you are likely
to be using in production (else you work around problems
that might not really exist; and, miss *new* problems
that have arisen in newer mask revisions)

>> 4) They're free: you often don't buy them -- you borrow them from the
>>    CPU distributor.

Unless you're an independant contractor and/or need/want a
variety of different processors  :<

> 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, you *know* the
problem is in the hardware -- or, your assumptions about the
hardware.   You are assuming that the "development board"
is a standard against which to measure your software's
functionality.  Why isn't the simulator/toolchain given
the same level of credibility?

Any place that I've worked has made it the hardware person's
responsibility to ensure the hardware is functional.  Years
ago, that often required the cooperation of the software person
to create simple test routines (exercise memory, scope loops
to test decoding logic, etc.).  Nowadays, if a hardware guy
can't write enough code to exercise his hardware, he probably
shouldn't be *designing* that hardware as he obviously is
clueless as to its use/role.

> They are so inexpensive (normally) why would you not have one?

The problem with development boards (and COTS to a similar
extent) lies in the inertia they impart to a project.  If
this inertia is *exactly* along the same vector that the
project is intending to take *anyway*, great!  (IME, that is
rarely the case:  "Let's design a product that someone has
already made")

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.

With the variety of multipurpose pins on today's MCU's,
a development board is stressed to give the designer the
same flexibility that the *chip* itself offers.  I.e.,
if the development board opts to connect a serial FLASH
to pins 1 and 2 BECAUSE IT WAS MOST COMPATIBLE WITH THE
DEVELOPMENT BOARD'S GOALS, then it has implicitly made
that choice for the hardware developer -- as the software
developer will have already (subconciously?) adapted his
code to that precondition (instead of leaving that
"open for discussion").  This often has repurcussions on
what peripherals are later available for the application
(the vendor may have wanted to emphasize one particular
peripheral over another -- e.g., "Wow!  Look at how many
A/D inputs we support!!!" -- which seldom exactly agrees
with the way you would ideally want to use the device)

The vendor choses some components for use on the board.
Will *you* end up using the same components?  E.g., will
you be using that serial FLASH chip?  Or, some other?
Will any firmware that the vendor has graciously provided
to make your use of that peripheral device be portable
to some *other* equivalent device?  Or, will there be
pressure on the hardware design to "just use the same
component (even if it is a bad choice for the job)?

E.g., when I look at most MCU's, the first functionality
that I discard is usually that of any A/D inputs.  I can
usually get the information I need in other ways without
relying on them (since they are often noisy, "practically"
8 bits, etc.).  OTOH, I *cherish* counter/timer signals
as they are more versatile.

Most vendor designs are pretty uninspired.  They do everything
the way you would *expect* it to be done.  There is little
value in this approach, usually.  If you are looking to
get extra performance/efficiency/cost savings from *your*
design, chances are you will be doing things differently.
Will the efforts spent on supporting the development board
benefit that effort?

Energies are diverted to supporting the development
board that could, instead, be spent on getting the *real*
board done sooner.  "Can you rig up a motor driver
interface to this 'expansion port' connector for me so
I can start working on the motor software?"  Any work
done in that light adds more inertia to the "bastard"
design (explain to your boss/client why you need to have
the software guy rewrite "working code" because the
*real* design is slightly different than the "bastard").

The design of the development board is not intended (is
often *disclaimed*!) to work in a production environment.
Often, things only work "typically".  Their manifestation
in a tangible board gives them undeserved credibility.
I.e., are you *sure* this circuit and configuration will
REALLY work in production?  Maybe you would spot some
key flaw if you had to design that same functionality
"from scratch" instead of falling prey to scheduling
pressures and "well, it's worked SO FAR on the bench..."

The hundred(s) of dollars spent on the development board
are inconsequential when compared to the other, less
tangible costs that it *infers* -- in much the same
way that the costs of a particular toolchain are
insignificant when contrasted with their impact on the
actual software (or hardware!) development effort.

A development board's role is to get you *committed* to
a device quickly.  The vendor has no interest in whether
or not that is the *right* choice for you or your project.

On 2010-06-07, Michael Kellett <nospam@nospam.com> wrote:
>
> "hamilton" <hamilton@nothere.com> wrote in message 
> news:hugmju$j7b$1@news.eternal-september.org...
>> On 6/6/2010 8:53 AM, Michael Kellett wrote:
>>>
>>> Now for the bee in my bonnet !!!
>>>      Why do people buy development boards ?
>>>
>>> Michael Kellett
>>
>> Now for the bee in your bonnet !!!
>>
>> Why do people complain about thing they can not change.
>>
>> With the number of development boards out in the world, there must be some 
>> kind of a demand, but that would require thinking past your own little 
>> world.
>>
>> hamilton
>
> Oh Hamilton - why must you insult that which you have mostly missed the 
> point of.
>
> I asked the question  - with I thought, sufficient pointers to suggest that 
> it was a matter for philosophical discussion - so I would have thought my 
> willingness to think "past" .. my .. "own little world" was clear enough.
>
> Actually there have been some interesting points made.
>
> I am surprised to learn that some engineers have the time and resources to 
> actually test several different processors physically rather than comparing 
> on paper. I've never found it to be necessary but then I quite like reading 
> data sheets.

Odd.  None of the datasheets I've ever seen contained useful
throughput data.

-- 
Grant Edwards               grant.b.edwards        Yow! Am I in GRADUATE
                                  at               SCHOOL yet?
                              gmail.com            

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?

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

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

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

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

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

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

-- 
Grant Edwards               grant.b.edwards        Yow! I just heard the
                                  at               SEVENTIES were over!!  And
                              gmail.com            I was just getting in touch
                                                   with my LEISURE SUIT!!

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
>=20
> Where do you get accurate simulators?
>=20

I think there is a little game playing going on here by Yuniskis ;o)

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.

--=20

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T=DCV as meeting the requirements for safety related systems=
=2E