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:
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
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.
Understood. I'm in the position where if the hardware doesn't work, it's *still* "my problem" :>
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.
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
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
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)
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 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)
Unless you're an independant contractor and/or need/want a variety of different processors :<
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.
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.
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
Where do you get accurate simulators?
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.?
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.
Who said anything about bugs in the silicon?
Where do you find all these simulators? It's been decades since I worked with a CPU for which a useful simulator was available.
That's not the way it is most of the places I've worked.
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!!
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.
Have you *looked*? Almost every ARM toolchain has one. Microchip's MPLAB, Freescale products, many "legacy" devices, etc. *Look* and ye shall find. :>
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.
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".
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.)
*Look*. Google "ARM simulator", "Freescale simulator", "open source simulator", "MPLAB simulator", etc.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 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".
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.
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.)
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.
True, but I've always been able to get very representative results from development boards.
Of course. That's why one uses a development board with the same type of memory that one is planning on using.
It's generally been the software persons reponsibility to test the hardware and determine what works and what doesn't.
But you don't need a board for that. You just need the schematics.
You don't need a development board for that. All you need is a schematic.
--
Grant Edwards grant.b.edwards Yow! Either CONFESS now or
at we go to "PEOPLE'S COURT"!!
gmail.com
Maybe you should ask your vendor why they haven't provided one!
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.
And I get great results from simulations.
And the same type of analog signal conditioning, timebases, etc. (?)
Ah, my sympathies. Like the guy who puts the wheels on the car deciding if the wheel wells are the right size :-/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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
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
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:
Cheers, An Schwob
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.