Good day to all. We are in the process of adding ModBus communications to a mature=20 product. This is a box that lives in a hazardous location (explosive=20 atmosphere) and the certification process is fairly onerous. This=20 certification process has to be repeated any time that anything=20 within the box changes. I mention this to explain why I'm trying to avoid changes to the=20 existing PC board. The unit uses a 16F77 and does not currently make use of the on-board=20 USART. Because we always try to look to the future, the serial RX &=20 TX lines as well as several Port D pins were brought to a header,=20 along with power and Gnd. The unit spends most of time asleep so as to minimize current=20 consumption. It wakes once per second to update its clock and will=20 wake immediately should any user button be pressed, as well as when=20 any external sensors trip. It works pretty well. Sleep current is somewhere 150uA - mostly=20 analog stuff that is always working. It will run without sunlight -=20 and drive its output solenoids - for a least two months and still=20 leave the battery charge sufficiently high to avoid freezing down to=20 -40C or so. Now the customer wants to add ModBus capability to the unit. Aside=20 from the continuous current consumption that the RS-485 chip=20 requires, its pretty straight ahead kind of stuff. FWIW - we are=20 using LTC1483 as our RS-485 interface - it was the lowest-current=20 device we could find (Idd =3D 500uA worst case). I'd be happy to hear=20 of any lower-current parts, though. We are implementing the ModBus interface on a little add-on card that=20 connects to the main card via ribbon cable. Yeah - we have to go=20 through the whole certification process again but the certifying=20 authority tells us that the cost will be significantly less if we=20 don't change the existing PC board and just add on the new board,=20 connected with a cable. Anyway, the last hurdle to overcome was how to wake our unit from=20 sleep when a RS-485 transmission occurs. The idea was to wake up,=20 wait for the next transmission to occur (the packet that woke the=20 device would have been lost), see if the slave address matches, then=20 go back to sleep if it doesn't. The people who are writing the=20 ModBus stuff at the control end are OK with having to send a dummy=20 packet to wake our box. But: how to wake the unit from sleep? We could patch the existing PCB to allow something from the ModBus=20 interface board to generate an interrupt. That is actually fairly=20 easy - there is an existing node that will wake the PIC anytime=20 current flows out of that node (normally HI; current flow towards Gnd=20 wakes the PIC). But: we don't want to modify the PC board. We came up with a solution that I haven't previously seen and I=20 thought I'd share it with the PIClist. The USART on-board the 16F77 can be configured for either Synchronous=20 or Asynchronous operation. The data sheet says that Synchronous=20 operation can be used communicating with external eeproms or a/d or=20 d/a converters - something we have never needed. But: there it is. It turns out that the USART can generate an interrupt that will wake=20 the PIC if is configured for Synchronous Slave mode and then receives=20 a character. Even better: the USART TX pin is the clock input for=20 Synchronous Slave mode. That means that pin is already part of our=20 expansion header. All we had to do was place a resistor (4k7) between the USART TX and=20 RX pins, then configure the USART to be in Synchronous Slave mode=20 before going to sleep. The resistor does not affect normal operation=20 of the USART when talking or listening to the RS-485 buss. It works like a charm. The incoming data is treated as if it were a=20 clock signal - we wind up with garbage in the USART receive buffer=20 but we don't care. When 9 or more data edges are seen, the PIC=20 wakes. We then set the USART into Async mode, flush the receive=20 buffer, then wait for a new packet to begin. Hope this is helpful to someone. dwayne --=20 Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .