Forums

ARM7 complete development tools?

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