--- In , Stramkb9mrm@a... wrote: ... > You think their might be internal propagation delays for the '589? > What if I tried this in code: > PD5 = LOW > PD5 = HIGH > add a few NOP's > PD5 = LOW > instead of the L-H-L-H-L ? Having looked at the message I posted earlier, and re-thinking over the procedure I suggested, my comment about prop. delay was probably not relevant. Sorry for the confusion. What I'm about to add here might clarify things, or might simply add to the confusion. I hope it's the former ;) Here's a simplified illustration of the internal logic of the '589 for one input: Input --->[D] Latch [Q]--->[D] Shift Reg The internal latch is edge-sensitive (rising edge of RCK) clocked, whereas the shift register is a 'transparent' latch with a level- sensitive latch enable (-SLOAD). A rising edge on RCK transfers the state of the input(s) to the internal latch. -SLOAD is a level- sensitive input that forces the state of the shift register to reflect the Q-outputs of the internal latch. If RCK and -SLOAD are tied together to one output port pin, and -OE is tied to a different output, then the loading of the shift register will require two pulses on the RCK/-SLOAD pin. Here's the sequence of events: RCK/-SLOAD = HIGH -OE = HIGH Idle state RCK/-SLOAD = LOW Latch -> Shift Reg (value in latch is the OLD state of the inputs the last time you read it, not current!) RCK/-SLOAD = HIGH RCK sees rising edge, Inputs -> Latch. The internal latch now has the current input state, but the shift register does not. RCK/-SLOAD = LOW Latch -> Shift Reg. Shift reg now has 'current' state of inputs. RCK/-SLOAD = HIGH -SLOAD high, so Shift Reg can shift. -OE = LOW Ready to transfer The above procedure follows Darren's timing diagram In my prior message, I suggested a means by which you could use a SINGLE output port pin to control all three '589 control inputs (RCK, -SLOAD and -OE) by connecting RCK and -OE directly to the output, and -SLOAD thru an inverting stage. A better arrangement would be to route the un-inverted output to -OE, and the inverted state to RCK and -SLOAD. The table below illustrates the sequence of events for this configuration: Port RCK -SLD -OE Event ---- ---- ---- ---- ------------ HIGH LOW LOW HIGH Idle state (SR = Latch, cannot shift) LOW HIGH HIGH LOW Inputs transferred to internal latch HIGH LOW LOW HIGH Internal latch transferred to shift register LOW HIGH HIGH LOW Output enabled, ready to transfer (initiate SPI transfer at this point) HIGH LOW LOW HIGH Return to idle state after xfer complete The above arrangement has the advantage of requiring only ONE output to control the '589, but requires the addition of the inverter. If you are using a large number of '589's (or '594/5's) in your design, Darren's approach may be the better way to go, as ALL the devices can share a common 'latch control' output, and the state of all the inputs can be read using multiple consecutive SPI transfers without intervening code to change output states. Darren's approach is the most time- and code-efficient for multiple devices, but it is not as 'selective' as the approach I outlined. Darren's method is the most time-efficient if you want to read/update everything at once EVERY time you want to read or change something. My approach would incur less overhead if you I/Os are grouped in such a way that you typically only need to read (or update) one group of 8 inputs or outputs at a given time. The 'double buffered' organization of the '589 and '594/5 lend themselves to quite a few different control configurations, each with their own pros and cons. There are doubtless many other ways that one could wire these up; I can envision a setup that would use a combination of the methodology I discussed along with Darren's method; for example, creating two 16-bit input (or output) ports. I'll go into this in more detail if interested. > I normally program in "C", but I am getting better at assembly. > I figured out how to control the SPI port in assembly. Once you > set up the registers correctly, the rest was easy. I just put my > data into a variable, call my subroutine, and I am done. There *are* several compilers on the market (most, unfortunately, quite expensive) that will generate HC11 code. I believe there is even a version of the gnu/gcc compiler available that will generate HC11/HC12 code. Most compilers that are targeted to microcontrollers provide some sort of mechanisim to specify an absolute address in a variable declaration, so it is possible to do something like this: PORTA |= 0x40; SPIData = SPDR; ...etc... > I am going to use the '595 and '589 because of the tri-state > ability of the chips. Some of my I/O lines will be bi-directional. > I might end up using 2 seperate pins to control the /OE lines so I > can tri-state the devices at specific times. As I noted above, the '589 and '594/5 are quite versatile devices. > The end point to this is a small mobile robot. It is just a hobby, > and I wanted to try building one. Most of the electronics and code > are complete. I ran into needing a few more I/O. I think that is > always the case with microcontrollers. The SPI port looked like my > best bet. I have just started working on a project that is I/O-intensive, and I am taking a somewhat different approach. I happen to have on hand quite a few 68HC711E20's that were used in development, all of which have their ROMs already 'burned' and thus not useful for ordinary single-chip work. However, one can still run code out of the internal EEPROM if the device is started up in bootstrap mode. I have written a small (< 512-byte) "slave controller" program that will allow me to read/modify/write data to any HC11 memory location using simple commands sent to the SPI or SCI, as well as execute small programs loaded into the internal RAM. In effect, this small program turns the HC11 into a semi-intelligent I/O controller. Once I have the code fully debugged, I will be making it available to anyone who wants it - I will probably upload it to the files section of this group. |