Hi,
I try to investigate a program written by a former collegue.
An 8-bit dipswitch is connected to the microcontroller address/data bus. Two variables are declared in an assembler file: public DIPSWITCH and public _DIPSWITCH. The dipswitch value is read bij an assembler file from address DIPSWITCH (the real hardware address) and stored in _DIPSWITCH. (_DIPSWITCH is to be used as the startup dipswitch value and DIPSWITCH is used as the real actual value). In a .C file both DIPSWITCH and _DIPSWITCH are declared as 'extern xdata unsigned char'. If I evaluate the startup value _DIPSWITCH in that .C file I get the actual value of DIPSWITCH. If I create only two code-lines:
if ( _DIPSWITCH){ do something} if ( DIPSWITCH){ do something}
and then I compile that source with '#pragma src' and look in the listfile I see:
MOV DPTR,#_DIPSWITCH MOV DPTR,#_DIPSWITCH
So both different .C source lines compile to the same assembler code.
Can someone explain this?
Thanks
Henk
"That's not a program."
How can you say that? He hasn't posted any program for you to classify.
"What exactly do you think will happen if you connect a bank of switches, of all things, where a RAM chip is supposed to go?"
If the memory interface pins are also usable as generic I/O pins, then the OP probably expects to be able to read the DIP switch state.
"Can such a crazy piece of nonsense really behave like memory?"
It doesn't have R/W and strobe signals, but yes - it is a one-byte memory. Do you see any problem with connecting a 8-bit DIP-switch to a 8-pin interface on a microcontroller? The OP never said anything about expecting it to behave as a flash, EEPROM, RAM, ... memory.
All the OP has said, is that he wants to read the initial value of the DIP-switch and store in one value, and he wants the current value of the DIP-switch to be stored in the second variable. With a bit of optimization, he could of course skip the second variable and use his physical DIP-switch as a read-only memory variable ;)
He hasn't posted any program for you to classify.
He posted fragments of that program, and enough of a description of the rest of it, to allow that classification.
He's not treating it as generic I/O though.
The OP never said anything about expecting it to behave as a flash, EEPROM, RAM, ... memory.
You may want to re-read the OP. That code he was given quite clearly told the compiler that this is supposed to be memory (an unsigned char in xdata space, to be precise).
As-is, it's about as likely to kill the micro by short-circuiting unprotected output pins as it is to do anything useful.