puzzled about port initializations

I’m trying to figure out how to configure my RCM4400W to have all PortA & PortB pins as outputs, initialized to all 1’s. PortA is easy, per the RCM44xxW.LIB file:

WrPortI(PADR, &PADRShadow, 0x00); //set to output all low
WrPortI(SPCR, &SPCRShadow, 0x84); //sets all bits to output

And I know PortB bits 0&1 are used for something and I shouldn’t try to drive those. That same lib file:

WrPortI(PBDR, &PBDRShadow, (PBDRShadow & 0xCF) | 0xCC); // set outputs to high
WrPortI(PBDDR, &PBDDRShadow, (PBDDRShadow & 0xCF) | 0xCC);// set inputs and outputs

If it’s really bits 0 and 1 I should “leave untouched”, then why the 0xCF instead of 0xFC? Are the nibbles reversed?

thx…-BobC

The RCM44xxW.lib is a library specifically written for the development board and core together. If you look at the top of the file where it is describing port usage, you will see that on Port B, bits 4 & 5 are tied to switch inputs from the dev board. Therefore the code you quoted is preserving the current settings on PB0 & 1 (that’s why 0xCF not 0xCC) and forcing PB4 & 5 as inputs and the other four bits as outputs. Both PB0 & 1 get used internally so should be avoided, although PB0 can be salvaged with proper coding (see note about sock_init in same port usage comments at top of library). You can also use PB4 & 5 as outputs if you desire, just understand that on the dev board they have an external pull up on them and pressing switches 2 or 3 will ground them.

Many thanks for the reply, Bill Sprouse. Combining your inputs with the documentation, I’ve zeroed in on my real problem. To wit: I need Port A to come up from a hard reset as anything but “all outputs, data = 0x00”. My init code writes the shadow reg to 0xff and then sets all Port A bits to output. Which works, but before that happens, my logic analyzer tells me that the Rabbit chip is setting Port A to outputs and data = 0x00 for about 760 uS after reset. I really wish it would not do that. The documentation says that the SMODE pins are sampled on reset, but I’m unclear on what these two bits are by default (00, judging by the RCM4400W schematic) or why that mode should cause Port A to be an output. Should I install a jumper that ties SMODE to something other than 00? What? Thanks for any help.

Are you calling the standard brdInit and then doing your own initialization afterwords, or have you edited the RCM44xx library file?

I edited the library file. And to convince myself that I edited the right file, I put a “walking zeroes” series of writes to PADR into the lib file, where the usual pair of WrPortI calls go, and this worked perfectly and looked real pretty on my logic analyzer. Except for the 760 uS of port A = 0’s that preceded it. :frowning:

Could you try putting some weak (say 100K) pull ups on port A and see what happens?

What I’ve got hanging off port A is one relay per bit. Each relay is driven by a PNP transistor with its emitter tied to +5V, its collector connected to the relay coil, and the other end of the coil is grounded. The transistor’s base has a 56K resistor in series with it, and the other end of the 56K is connected to one of the Port A outputs. I also have a 10K pullup on each bit of the Port A outputs. So if Port A were tri-stated or driven high, those PNPs would be turned off. Any Port A bit that drives a logic low out will turn on that PNP and energize the relay. (That’s why having the whole port drive 0’s is a problem – 760uS isn’t long enough to energize a relay, but I still want to know why it’s doing this, just in case.)

Port B is not doing what Port A is doing, by the way. What I’m seeing on Port B is bits [5:0] are high and stay high, but bits 6 & 7 are low for the 760uS period, and then they follow the brdInit() setting. The docs say the Port B bit 6/7 behavior is legacy compatibility back to Rabbit 2000.

Has anyone succeeded at using Port B on the RCM4400W for general purpose outputs? The example init code in RCM44xxW.lib says to leave PB0 and PB1 untouched but seems to suggest I can use the other 6 as outputs. They don’t seem to be working that way though. My modified RCM44xxW.lib file says

WrPortI(PBDR, &PBDRShadow, (PBDRShadow & 0xff) | 0xfc);
WrPortI(PBDDR, &PBDDRShadow, (PBDDRShadow & 0xff) | 0xfc);

My intention was for the first of these two to set the PBDR reg to all ones (except bits 0 & 1), and the second WrPortI to set the high 6 bits to outputs. My scope says they’re outputs all right, but the write to PBDR doesn’t seem to have any effect.

Ideas? thanks…-BobC