Prev: Bluetooth...where to start?
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010
From: D Yuniskis on 7 Jun 2010 14:13
Hi Grant,

Grant Edwards wrote:
> 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?

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".
From: An Schwob in the USA on 8 Jun 2010 15:28
> 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
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Bluetooth...where to start?
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010