Post by thread:Conceptual Question

Friends...I'm a little new at this but, please bear with me. I've got a project where I'm creating an I2C network of "smart" components - displays, sensors, switches, etc. I'm trying to figure out the best way to implement the switches. So far I have a 4 switch assembly that uses a PIC16C62A (so I don't have to do too much I2C in software - I could software and switch to smaller SOICs to reduce the size) to determine what button has been pressed. There will be multiple 4 switch assemblies and it is possible to have 2 switches pressed at one time. Since this is an I2C bus implementation, I thought this would work with a minimum number of components and give me more options if the switch logic has to change. Basically, I use a PIC17C756 as the master and all it has to do is ping the switch regularly and check the status of the switches and then drive relays or other circuits accordingly. I'm off here or am I blinded by the light of PICs so I can't see other ICs that could be used instead? BTW - the bus is actually 3 wire - SCL, SDA and 5v to power the other PICs. David Olson

{Quote hidden}> > Friends...I'm a little new at this but, please bear with me. > > I've got a project where I'm creating an I2C network of "smart" components - > displays, sensors, switches, etc. I'm trying to figure out the best way to > implement the switches. So far I have a 4 switch assembly that uses a > PIC16C62A (so I don't have to do too much I2C in software - I could software > and switch to smaller SOICs to reduce the size) to determine what button has > been pressed. There will be multiple 4 switch assemblies and it is possible > to have 2 switches pressed at one time. > > Since this is an I2C bus implementation, I thought this would work with a > minimum number of components and give me more options if the switch logic > has to change. Basically, I use a PIC17C756 as the master and all it has to > do is ping the switch regularly and check the status of the switches and > then drive relays or other circuits accordingly. > > I'm off here or am I blinded by the light of PICs so I can't see other ICs > that could be used instead? > > BTW - the bus is actually 3 wire - SCL, SDA and 5v to power the other PICs. > > David Olson > Philips makes two devices which could be used as switch nodes. PCF8574 Remote 8-bit I/O expander for I2C-bus PCF8575 Remote 16-bit I/O expander for I2C-bus If I have read the datasheet correctly you they would be a single device solution for this app. Kevin Dale Kirmse

[Original message snipped...] Sheesh. I thought I snooped around there. I'll have to dig through it again. Once your on a mission with this stuff, everything runs together after a while. I glanced at the expander before and just assumed it was the same as their other I/O expander - the operative word here being "remote". I also don't think a MUX/DeMUX is a good answer since I'd have to add all the I2C stuff to it. Also, the A/D approach seems problematic with the multiple switch theory. My software bias (instead of hardware) makes me believe that flying around the bus and reading status bits is a bit easier. Thanks Kevin. [Kevin wrote...] > Philips makes two devices which could be used as switch nodes. > PCF8574 Remote 8-bit I/O expander for I2C-bus > PCF8575 Remote 16-bit I/O expander for I2C-bus > If I have read the datasheet correctly you they > would be a single device solution for this app. > Kevin Dale Kirmse

Kevin, I'm adding a bit to my previous reply (since I've had some off-line conversations)... I re-read the I2C spec as well as the 8574 data sheet and I do believe that this would work. But, I have an uncomfortable feeling about the switch debouncing. If I were to use the PIC as the slave, I could debounce in software at the switch module before the master calls up for a status. If I debounce in the master, I'm afraid that I'd run into timing problems when other modules on the bus need more time to do their thing. Seems to me that 8574 being only I/O, that without some smarts - like "I'm busy debouncing switches, please wait", I may get some inconsistencies. Then again, the slow speed of the bus may naturally debounce for me. I could also debounce through hardware but, now I'm adding more stuff to the board that would probably equal the PIC-as-slave approach. Since I've got 4 switches on the board, it could start to add up. I've got some 8574's on the way, the wife and kids are away, there's a chip burnin' party at my house. Thanks again Kevin for finding this. [Then Kevin wrote] > PCF8574 Remote 8-bit I/O expander for I2C-bus > PF8575 Remote 16-bit I/O expander for I2C-bus > If I have read the datasheet correctly you they > would be a single device solution for this app. > Kevin Dale Kirmse

David Olson wrote: > Kevin, I'm adding a bit to my previous reply (since I've had some off-line > conversations)... > > I re-read the I2C spec as well as the 8574 data sheet and I do believe that > this would work. But, I have an uncomfortable feeling about the switch > debouncing. If I were to use the PIC as the slave, I could debounce in > software at the switch module before the master calls up for a status. If I > debounce in the master, I'm afraid that I'd run into timing problems when > other modules on the bus need more time to do their thing. Seems to me that > 8574 being only I/O, that without some smarts - like "I'm busy debouncing > switches, please wait", I may get some inconsistencies. Then again, the slow > speed of the bus may naturally debounce for me. > > I could also debounce through hardware but, now I'm adding more stuff to the > board that would probably equal the PIC-as-slave approach. Since I've got 4 > switches on the board, it could start to add up. If you are getting inputs by polling then switch bounce would be a problem only if you poll too often. > > > I've got some 8574's on the way, the wife and kids are away, there's a chip > burnin' party at my house. > Have fun. --------------------------------------------------------------------- | Dr. Kevin Dale Kirmse, PhD EE | Portable System Design, High Speed Serial Links | FPGA Design, Video Hardware, Graphics Hardware | | King of Prussia, PA 19406 | spam_OUTkirmseTakeThisOuTnetaxs.com ---------------------------------------------------------------------