Forums

ARM7 complete development tools?

Started by Jack May 17, 2004
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