??? 11/20/11 14:06 Read: times |
#184831 - What I Do and Not Do Responding to: ???'s previous message |
For serial port UARTs I always code them up to use interrupts. I setup according to the data sheet and then check the resulting baud rate with an oscilloscope.
I do not vary crystal freq, temperature, baud rate, cable length and voltages to check limits. I do run the end application through a bank of functional tests that are designed to stress the hardware / software beyond the expected normal operational load. Usually this is in the form of a diagnostic testing program on a PC that used as a combination development tool, functional exerciser and pre-production testing program. Sometimes when production volumes are not exceeding 100's I will also morph this same testing program into use for production functional test. Note that it is not uncommon that my testing program is different software from that used with the product in its normal usage. The embedded 8051 software (which I like to call firmware) is the same though. There have been some products that are only tested at production with my exerciser program and not the regular usage software. There have been several cases where the embedded product is normally used standalone with its firmware and the interface with my functional test exerciser was put in place solely for the purpose of testing. I recall one line of medical products that had quite a few parameters that the user could set. During the product validation cycle, after the user interface is checked and the ability of the operator to navigate the UI to set parameter values is verified then a remote PC interface from my exerciser program is put into use to do the "full matrix check". This is where the product is checked for proper operation through the full range of all of its settable parameters. Michael Karas |
Topic | Author | Date |
NXP Promises ARM Cortex-M0 in DIL Package! | 01/01/70 00:00 | |
Amazing! I thought DIL was DEAD. | 01/01/70 00:00 | |
Me too! | 01/01/70 00:00 | |
Hmm.. | 01/01/70 00:00 | |
maybe | 01/01/70 00:00 | |
dsPIC is a waste of time | 01/01/70 00:00 | |
We Await The Results... | 01/01/70 00:00 | |
Which one(s)? | 01/01/70 00:00 | |
two | 01/01/70 00:00 | |
Why so long? | 01/01/70 00:00 | |
Well | 01/01/70 00:00 | |
Two years | 01/01/70 00:00 | |
Answers | 01/01/70 00:00 | |
But what delays did you try before original release? | 01/01/70 00:00 | |
shorter delays | 01/01/70 00:00 | |
good thinking | 01/01/70 00:00 | |
Can't get the error | 01/01/70 00:00 | |
What changed? | 01/01/70 00:00 | |
Seems a little harsh | 01/01/70 00:00 | |
Never blame manufacturer without proofs | 01/01/70 00:00 | |
Proven Product Syndrome | 01/01/70 00:00 | |
My response ... | 01/01/70 00:00 | |
No Offense | 01/01/70 00:00 | |
What I Do and Not Do | 01/01/70 00:00 | |
NXP are mistaken | 01/01/70 00:00 |