----- Original Message ----- From: "Bob Axtell" To: Sent: Wednesday, June 23, 2004 2:24 PM Subject: [PIC]:Bob's 1-Pin Diagnostic Signal (Was: The Read / Modify / Write stuff) > Something seems to be wrong with the PICLIST. I hace received 13 > messages in 3 days. I'm resending this. If anybody gets it, send me an > enmail privately. > > > -- > > I'ts uploaded as an RTF file. It also contains a simple TP5 DOS Pascal > file that can be easily ported over to Delphi (if you can unlock the > parallel port IO using Winsoft's IOPORT component). Needs just ONE > active pin on the parallel port, but I once wrote a program that > monitored 8 PIC products at a time by picking up all 8 products' > diagnostic pins. > > -- > > The PIC is pumping out a simple diagnostic signal on a single pin. It is > sent slowly so that any host (PC, PDA, or PIC) can be used to pick it up > without missing a bit through Windows overhead. I usually set it up to > send a bit every 4-5ms, but have have set it as fast as 50uS > (PIC-to-PIC) and as long as 20ms per bit (very long diagnostic cable), > and it works just fine. > > The PIC is setup to send a 48-bit bit stream, which is 6 8-bit bytes. > This is usually enough data to identify local faults. Data is sent Bit7 > first. After the 48 bits are sent, another zero bit is sent as a > dummy**. After I send 49 bits, I turn off the transmitter for about > 16bits, so that the receiver has processed the last 6-byte frame and > stored it, and is waiting for the beginning of the next frame. > > A bit is the period between two RISING EDGES. A bit begins as a 1, which > drops to 0 before the next bit starts. If the width of that ONE pulse is > more than half the distance to the next bit edge, that bit is a ONE, > otherwise that bit is a ZERO. That's all there is folks. > > ** Why? because a bit is defined as the duration from the BEGINNING of > this bit to the BEGINNING of the next one. In order to have a next one, > a dummy 48th bit is required (and its data ignored). > > The receiver simply times (1) the interval between bits and (2) the > length of time the pulse stays HIGH, and captures the decision by > shifting into registers. If you are doing long-term burnin tests, you > should capture the data on a log file that you can examine later. > > Normally, I use the 1-pin diagnostic by holding a point low on powerup, > and when the PIC sees that stick, it hangs until that point is clear, > then the diagnostic program is entered. > > USES > > Best use of this is in identifying stuck pins. Just manipulate the pins > so that the results are read; stucj pins will not provide an appropriate > response, which you can interpret with a failure code. Hopefully the > stuck pin ISN'T your diagnostic pin! > > Next-best use of this is in ADC calibration. Example: suppose the PIC is > supposed to make a battery charge judgement ('Level 1 to 10'). On a test > fixture, you could apply a "battery" of a very precise voltage for each > "battery level" decision. Since the PIC's ADC and the components are not > overly accurate in combination, the converted value could be sent out > over the diagnostic channel, and these values installed into the EEROM > for use by the program later (you could reprogram the PIC with those > values installed directly into the EEROM), making the battery meter VERY > accurate. Build a lookup table for the battery levels. > > My clients, always looking to prevent losses due to "warranty repair > abuse" (people swap a good card with a bad card and send it back under > "warranty"), use it with a simple PDA at incoming inspection to > determine the date of manufacture (written into the chip on the day it > was first programmed). No I didn't write the PDA program, sorry. > > Finally, it is a great program debugging tool, especially if the > debugger runs all the time in the background. For this application, I > like to drive PA4, which is usually open collector (no wasted current, > PC Host has pullups on the parallel port). When debugging, place the > several bytes in strategic paths, and send a copy out the debugger. > > I'm including two versions, one that is mainline code (no interrupts), > and one that is background (called from a 1-2ms interrupt.) > > --Bob > > Charles Linquist wrote: > > I would like a copy of your routine. > > > > > > Charles Linquist > > > > -----Original Message----- > > From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU] On > > Behalf Of Bob Axtell > > Sent: Saturday, June 19, 2004 1:19 PM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: [PIC]: The Read / Modify / Write stuff > > > > Actually, the way Microchip handles the READ/MODIFY/WRITE is the correct > > one. For one thing it allows the PIC to know when a bit is stuck. 99% of > > manufacturing faults on PCBs are shorts to other signals, to GND or to > > VCC. Doing an xor of a port and NOT getting back the correct data is a > > great, quick way to testing for shorts. > > > > On powerup, the PIC can execute a tiny routine to test its own signals > > and greatly assist the production tech. I do this by dedicating one PIC > > pin (usually either the PGM DATA or PGM CLK pin) to sending a manchester > > mark diagnostic signal (usually about 48 bits of info). > > > > Anybody wants the routine, I'd be glad to email it or even post it. > > > > --Bob > > > > -- > > > > Replier: Most attachments rejected > > -------------- > > Bob Axtell > > PIC Hardware & Firmware Dev > > http://beam.to/baxtell > > 1-520-219-2363 > > > > -- > > http://www.piclist.com hint: To leave the PICList > > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > > > -- > > http://www.piclist.com hint: To leave the PICList > > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > > > > -- > > Replier: Most attachments rejected > -------------- > Bob Axtell > PIC Hardware & Firmware Dev > http://beam.to/baxtell > 1-520-219-2363 > > > > > -- > > Replier: Most attachments rejected > -------------- > Bob Axtell > PIC Hardware & Firmware Dev > http://beam.to/baxtell > 1-520-219-2363 > > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > > -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu