27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

Ellen, You are thinking of the ports as a "single register", which will lead to confusion when you are splitting port functions. I'd suggest you re-read the section of the manual that describes the port logic. When dealing with ports that are configured for I/O, consider input bits to be "missing" from write operations and output bits to be "missing" from read cycles. It (used to be) good software practice to avoid "writing to inuts" or "reading from outputs" - either of which can cause problems in some circumstances. Calamity Jane __________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Thanks, you and Emmett made things more clear. However, I wasn't thinking of the ports as a single register. That's why i asked why the code tried to store a value (Ex: $EE)in the four most significant bits of PORTC when DDRC was initialized as $0f. I suppose the code just did that so as to save instructions since register B would already have the value i'm trying to compare with in PORTC. Now...just gotta figure out why the code in my book isn't working for me. Ugh....more questions later when i can pinpoint the problem, but my guess is my hardware. Eileen --- In , Calamity Jane <winnonad@y...> wrote: > Ellen, > > You are thinking of the ports as a "single register", > which will lead to confusion when you are splitting > port functions. I'd suggest you re-read the section of > the manual that describes the port logic. > > When dealing with ports that are configured for I/O, > consider input bits to be "missing" from write > operations and output bits to be "missing" from read > cycles. > > It (used to be) good software practice to avoid > "writing to inuts" or "reading from outputs" - either > of which can cause problems in some circumstances. > > Calamity Jane > __________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )