Reply by An Schwob in the USA●June 8, 20102010-06-08
> 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.comhttp://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.comhttp://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
Reply by D Yuniskis●June 7, 20102010-06-07
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.
>> 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".
Reply by Grant Edwards●June 7, 20102010-06-07
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
Reply by D Yuniskis●June 7, 20102010-06-07
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.)
Reply by D Yuniskis●June 7, 20102010-06-07
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".
Reply by FreeRTOS info●June 7, 20102010-06-07
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
Reply by Grant Edwards●June 7, 20102010-06-07
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!!
Reply by Grant Edwards●June 7, 20102010-06-07
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
Reply by D Yuniskis●June 7, 20102010-06-07
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.
Reply by Michael Kellett●June 7, 20102010-06-07
"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