The first item in the list should be to measure the key system voltages and currents. Verifying the correct voltages can quickly solve some really odd behavior at first turn-on. Knowing the correct currents can quickly alert you to a problem by just glancing at your lab power supply.
@clia: The Hackware technique is something I developed - I have not seen it written up anywhere. (I haven't been looking for it though.) Maybe I ought to write a book, "Hackware for Dummies." :-) In the absence of such sources, send me an email (my email is on the first slide) with questions, comments, etc., and we can talk more about it.
Wow, that is horrible. And, sorry to say, but an excellent poster child example for sufficient pre-release, in-house testing. Thanks, Gary, for another great presentation. And, thank you for answering the question about the books yesterday. In the absence of books, is there another source that you would reccomend for learning more about hackware?
@clia: I'm fuzzy on the details. Maybe it was supposed to alert the staff but didn't. Maybe it was more than just a monitor. But the end result was that a patient died needlessly because it hadn't been tested on older people.
@GStringham – Concerning H/W vs S/W, I once did a H/W design of a capacitive keyboard many years ago. Capacitive keyboards were a bit novel at the time. The board worked fine after I fully tested it with my own test firmware. I handed it over to the S/W group and it worked fine for them. After the S/W folks were done with it, it was handed over to the folks that do the exhaustive testing before final release. It was about this time I had submitted my resignation because I had accepted a job offer at another company. During my 2-week notice time, I was presented with a problem with my design. The keyboard didn't work reliably when more than key was pressed at one time. It wasn't written into the requirements, so the capability wasn't designed in. Neither the S/W folks nor I tested this because nobody knew until the H/W was done and the drivers were written. I never had an opportunity to complete the correction of the flaw before I was gone. :.(
@danlafleur: I've seen some impressive virtual prototype demonstrations at trade shows. The Design West show in San Jose next week that Alex mentioned will have many such demos. They can make, for example, a virtual cell phone which you can manipulate with the mouse that gives a very good hands-on feel to the product.
@MazianLab: Yes prototypes are expensive. Exactly what there is or not depends on what you are dealing with. Can the prototype be cheaper if you add three weeks to the schedule and have it buildt overseas? Can you make emulator hw that looks like the real thing to the CPU?
@Ann R. Thryft: What types of simulations work better? That could be a class for itself. It depends on the situation. What components are complete vs partially done? What simulation models are available? How much time/money is in the budget? What is the object of the testing? Hw or sw?
@GStringham – Thanks Gary.All I'm referring to is getting a newly designed/built board, checking it out in baby steps (as you said today) and loading some self-design firmware to exercise the board.Additionally, after checking out RAM, lights, switches, etc., go ahead and do some firmware and exercise all the I/O.Of course this doesn't tell us anything about whether the H/W design can keep up with timing needs or other specifics of their development.The only way to determine that is to hand it over to the S/W team.There are still other H/W efforts to be made after the handover such as environmental testing and other H/W stress tests.
@luizcosta: When I was there, HP used LynxOS from LinuxWorks as their OS in the LaserJet printers. LynxOS is very unix-like. But I think they are using something different now. I know that ThreadX is used in some InkJet printers (at least that's what the ThreadX company claims.)
@Ran: Ideally the sw team has only fully-debugged circuits to work with. But they would have to wait a while to get it. But by giving them something earlier, even though it is not perfect, they can at least do their job. It wasn't the sw engineers job to test the hw, sort of... The hw team did what testing they normally do with simulations, etc., but you can't really thoroughly test the hw without having the full sw code running on it. So they wanted sw to run their normal stuff and tell hw if they saw any problems. It did create a difference of opinion.
@Ds26: Does Big Bang turn-on work? Hum... If it's a mature product, it could because most of the components are already well-known. The new features might create problems. Or a replacment part that is assumed to be identical may cause problems. For new, first-generation products, Big Bang is iffy.
I would say quality in a small startup is probably lacking because they don't have the funds to staff a test team. But an organization of about 100 people, whether a division in a big company or whether that is the company, should have the resources to have dedicated quality engineers. I think a large part is the culture of the company. In the old days, HP was known for it's very high quality. HP engineers that left and started up their own companies tended to carry that quality culture with them. Other companies don't have the stringent quality culture.
@Syakovac – It's like Gary said: There's never time to do it right the first time, but there's always time to do it over again to fix it. There always seems to be a manager somewhere who hasn't gotten this memo.
Gary, I developed my design skills at a time when simulation software didn't affordably exist. It was done on paper and then you built a prototype. The process was more intuitive and incremental. Has simulation software been able to maintain a "hands-on" feel for development?
@Syakovac – The H/W and S/W teams can usually get started independently for the sake of project timing.As such, there is usually an opportunity to get the H/W built in alpha form and out in the lab.Of course the earlier boards have to be debugged anyway.If it has a uP or uC, then debug code has to be written to check it out.That's the time to write the test code for ALL the upcoming H/W + interface I/O.Many times the best time to write such code is when the Gerber files have been sent to the board house and you're waiting on the board to come back.Not until you have a built board can you work on it anyway.
@GStringham – Concerning testing hardware and testing software, I've been a member of both development teams.But, when doing the H/W, I never put the testing onto the S/W folks.I created my own software/firmware that exercised/tested all my hardware.The software folks always got a fully debugged circuit on which to do their development.
@slk, yes working at -40 means pushhing to see where the limit is for everything, reliability, stability and failsafe operation. timing does change quite a bit too, so we use our temperature chamber a lot for testing new circuit designs.
@slk -- Yes. I would.... Sort of. I used a lot of VPI to be able to use some models from Verilog VPI and glue that to SystemC and some custom models using native threads to run fast. That was a lot of stuff to glue together. Verilog has improved vastly and I think more could be done with native Verilog and DPI to create the same effect but not have to create my own multi-thread controls.
Depending on your browser, there are a number of ways to refresh. IE is kind of goofy with its cache, so try F5, Refresh button, and also, highlight the URL and hit Enter. I've had to do each of these some days in order to get audio.
As per testing, when I think the system is ready, I get an operator (with the required basic knowledge) have then run through the operation and to see if the controls are intuitive and easy to follow and are following a basic visual management protocol.
cwinn61: The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.