Martin, Easy to do with just one PIC i/o pin plus power if the i/o pin is a uart pin. Don't have a uart pin available? No problem. Use two i/o pins. Two pin method: PIC1 is the data SOURCE, and PIC2 the data DESTINATION. Each PIC has two dedicated i/o pins that connect to lines called CLOCK and DATA. CLOCK is bi-directional, and DATA is from PIC1 to PIC2. The CLOCK line has a pullup resistor to +5 V so it is held HIGH when both PIC1 and PIC2 have their CLOCK i/o pins set as INPUTS. (1k works well for me) One pin functions as a CLOCK and the other as DATA line. A bit is first placed on the DATA line. Then the CLOCK is pulsed HIGH. The receiving PIC generates an interrupt from the leading CLOCK edge and reads in a single bit on the DATA line. This repeats with each subsequent bit, and the receiving PIC builds up a received byte. It is useful to have a synch stream that you send prior to each set of data so your data is synchronized. By the way, in YOUR application you could get away with sending just 4 bit nibbles to indicate the bcd values. values from 0 to 9 would represent values to be displayed. Adding a fifth bit (msb) to each bit allows easy synchronization. When ALL 5 bits are HIGH, that is the synch character. Each set of numbers being sent to the remote box would begin with TWO of the 11111 synch characters. All regular characters would be in the form 0xxxx where xxxx represents the bcd code. At the receiving end, the input routine synchronizes by counting the run of 1's. Once it reaches 5 1's in a row it then ignores all subsequent 1's. The next 0 indicates the msb of a valid 5 bit sequence. Every valid 5 bit 'word' begins with a 0 in the msb, so the running count for 1's never gets past the value 5 for valid data words. (The running count is zeroed every time a 0 appears.) This method is very robust, as it re-synchronizes at the beginning of each valid data packet. The transmitting PIC must send data slow enough for the receiving PIC to receive and massage the data. This can be accomplished by having a timed delay of the sent data, or some hardware handshaking. I prefer handshaking, as it allows for the maximum transfer rate. HANDSHAKING MODE: The CLOCK line can actually be used as a one-wire two-way link. To do this the wire on the CLOCK line must be pulled high with a pullup resistor. Both PIC1 and PIC2 start out listening on the CLOCK line, so it is normally pulled HIGH. The CLOCK line is never driven by both PICs at once! To send a HIGH, each assigns it's CLOCK pin as an INPUT and the pullup resistor ensures that a HIGH appears on the CLOCK line. To send a LOW, the proper CLOCK bit is made to be an OUTPUT, and then the bit is cleared LOW with a BCF instruction. *****PIC1 POINT OF VIEW:***** When a bit is to be sent by PIC1, it watches the CLOCK line. If it sees a LOW, it knows that PIC2 is busy. If PIC2 is busy, then PIC1 waits (it may do something else useful while it waits). Once PIC1 sees that the CLOCK line is HIGH, it delays for about 5 NOPs (in case PIC2 just re-activated interrupts). PIC1 then places the desired data bit onto the DATA line. PIC1's CLOCK i/o pin is then SET to become an OUTPUT. The CLOCK bit is cleared LOW with a BCF instruction. A delay of a few NOPs ensures that the CLOCK line settles to a decent LOW state. Then PIC1 makes the CLOCK i/o pin an INPUT again. PIC1 delays for a few NOPs to ensure that the CLOCK line has returned HIGH. The rising edge of this CLOCK signal will generate an interrupt (or at least set the appropriate interrupt flag for polling) at PIC2, assuming that PIC2 was initialized for such a rising edge interrupt on the CLOCK pin. (So the CLOCK pin must be properly chosen on the PIC2 side to allow such an interrupt flag). PIC1 now watches the CLOCK line and waits until it sees an acknowleging LOW on the CLOCK line from PIC2. Once it sees that the CLOCK line is LOW, more DATA bits can be processed, or a return to other activity can ensue. ***** PIC2 POINT OF VIEW:***** When a LOW to HIGH transition occurs on the CLOCK line, then PIC2 enters into BIT RECEIVE MODE via interrupt or software polling of the interrupt flag. PIC2 immediately changes its CLOCK i/o pin to OUTPUT mode and makes the CLOCK line LOW. This acts as both an acknowledge and busy signal for PIC1. PIC2 reads the state of the DATA line and does whatever processing on that bit that may be required. Once it is finished, PIC2 sets it's CLOCK i/o to INPUT mode, delays for two NOPs, clears the CLOCK interrupt bit (that just got set as the CLOCK line went HIGH), then exits the interrupt. If using polling of the interrupt flag instead of interrupts, just set PIC2's CLOCK i/o to INPUT mode, delay for two NOPs, and clear the CLOCK interrupt bit (that just got set as the CLOCK line went HIGH). Note that the bit receive program needs to keep a bit counter that is reset whenever a 0 is received, and incremented whenever a 1 is received. Anytime the bit count value is greater than 4 then the system is receiving synch bits. When this occurs, the nibble bit counter should be cleared to 0. 5 bit nibbles are sent msb first, with the msb being 0 for normal bcd data and the entire 5 bit nibble 11111 when sending the two synch words that begin a full data packet. Fr. Tom McGahee ----- Original Message ----- From: "Martin McCormick" To: "Microchip PIC microcontroller discussion list." Sent: Saturday, August 28, 2004 9:03 AM Subject: [EE]: Display possibilities > I want to have a lighted display in a clock in which the > digits are in the general range of 2 to 4 inches high. If someone > makes individual digits like that then I will need to build a > controller for them, of course. > > If there is a display module that fits this general > description, then I need to be able to connect it using DIP headers or > something similar that I can accommodate with wire wrap technology. > > The idea is to make the clock work first and add the display > last such that the clock treats the display like a peripheral and > updates it but doesn't concern itself with lighting up this or that > segment. It would just send out BCD or ASCII digits to a second PIC > that managed the display itself. > > What I don't desire is what I have seen in some devices I have > salvaged in which there is a ribbon of 4 score and 7 tiny stranded > conductors wave soldered to the surface of both the display board and > the main board. That is not my idea of fun. I am sure it works fine > in a mass-production environment, but not here.:-) > > Thanks for any useful ideas. This is a one-of-a-kind project, > but one never knows where these things can lead. > > Martin McCormick WB5AGZ Stillwater, OK > OSU Information Technology Division Network Operations Group > _______________________________________________ > http://www.piclist.com > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist _______________________________________________ http://www.piclist.com View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist