Prev: Bluetooth...where to start?
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010
From: Grant Edwards on 7 Jun 2010 10:29
On 2010-06-07, D Yuniskis <not.going.to.be(a)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(a)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!!
From: FreeRTOS info on 7 Jun 2010 10:49
On 07/06/2010 15:29, Grant Edwards wrote:
> On 2010-06-07, D Yuniskis <not.going.to.be(a)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(a)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)

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.

--

Regards,
Richard.

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

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.



From: D Yuniskis on 7 Jun 2010 10:56
Hi Grant,

Grant Edwards wrote:
> On 2010-06-07, D Yuniskis <not.going.to.be(a)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(a)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".
From: D Yuniskis on 7 Jun 2010 11:15
Hi Richard,

FreeRTOS info wrote:
> On 07/06/2010 15:29, Grant Edwards wrote:
>> On 2010-06-07, D Yuniskis <not.going.to.be(a)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(a)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.)
From: Grant Edwards on 7 Jun 2010 11:37
On 2010-06-07, D Yuniskis <not.going.to.be(a)seen.com> wrote:
> Hi Grant,
>
> Grant Edwards wrote:
>> On 2010-06-07, D Yuniskis <not.going.to.be(a)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(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Bluetooth...where to start?
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010