Using 74xx574 D FF to expand PIC outputs

/OE should be held low to enable the outputs. Looks like you've left it floating. If so, that is undoubtedly your problem. If you did actually wire it low somehow, keep reading.

Also, do you have a decoupling capacitor (~0.1uF) between power and ground physically close to each of the chips? Is your ground good and solid between the PIC and the latches? Proper supply voltage for each chip?

Sure would help if you did have a scope. :-\\

I just looked at your diagram again in a fixed font and I see you do have /OE grounded. Sorry 'bout that.

The ASCII schematic might have been slightly ambiguous, but the pluses are meant to indicate that GND and /OE are connected. (This was in fact the first mistake I corrected trying to fix this problem...)

Decoupling was something I was wondering about; I'm new to earnest applications of digital logic and never had to do it before. I have several 1uF tantalums that I attached to no avail, but first of all I didn't know whether 1uF was a decent capacitance (I don't have any 0.1uF on hand), and secondly I wasn't sure how far was too far. The leads are short on these things, so I wasn't able to make one straddle the chip. The closest I was able to get without changing the arrangement of the parts was to have one lead on the +V pin and one on the ground bus, or one lead on the GND pin and one on the +V bus. Would it help if I were to connect the capacitor to the breadboard row just north of 1 or just south of (pin count divided by two) and use short jumpers for both?

All of the ground pins are connected by jumpers to a bus on my breadboard, and all Vcc/Vdd are connected to another. The power supply is the +5V/GND wires from a floppy connector on a PSU lifted from an ATX computer case.

I believe it.

Thanks PSM

"Peter S. May" schreef in bericht news:QJidnX1HWsJSJQbbnZ2dnUVZ snipped-for-privacy@comcast.com...

That 74ABT574 is pretty fast a thing. To make it work reliably it requires good grounding, careful decoupled power supply and short, solid wiring. Wrong datatransfer is most of the times caused by glitches or disturbances on the clock lines. Dips on on the power pin may have the same effect. The glitches you see on the LEDS are most likely caused by unsufficient decoupling or wrong wiring of ground and/or power. When switching LEDs so fast, the wires are cannot be considered shorts. They will look like coils and capacitors and the circuit even may oscillate. (For very short times but nevertheless.) So you need the decoupling mentioned. You'd also not power the LEDs by the same (thin) conductor you use for the logic.

I did not check but maybe the rising edge from the PIC is not fast enough for the 74ABT574. Especially when you have long wires. You can check by placing pull up resistors of let's say 1k on the A-port outputs of the PIC.

Do not use a 2-to-4 decoder in the clock lines. This decoders are combinatorial logic that will have glitches on the outputs when one or more inputs change(s). Besides, you will always have at least one clock line high. A 1-to-4 demultiplexer may be usefull but it requires three lines from the PIC. (Two address lines and the clock.)

petrus bitbyter

Hello Peter,

No idea what the outputs have to do. However, check out serial to parallel converters such as the 74HC164. That's how I do that. There is also another variety that can update the outputs in a controlled fashion so you don't get glitches, and can be cascaded to a few miles of bits. But so far the HC164 was good enough for us.

[...]

--
Regards, Joerg

http://www.analogconsultants.com

Well, your bare-bones circuit is correct (but, as another poster mentioned, you're going to have trouble if you use a 2-4 decoder without an enable pulse - you _will_ get clock glitches). So, what's left (assuming your parts are good)?

1) Power/ground issues. Your ground from PIC to latches and LEDs needs to be substantial and low-impedance (short). Your +5 should also be reasonably substantial and short. And you need decoupling on every chip. And is your +5 really 5V? 2) Signal issues. Clock and data signals should be clean, with suitably fast edges and be well within the input voltage specs for the latches. It couldn't hurt to try the pullups mentioned, but I would not expect them to be necessary (however, I don't know the PIC output characteristics).

I think you need to set the comparator config register (CMCON) to 0x07 (00000111) to disable the comparators. The power on default is for the register is 0 which enables the comparators and configures A0-A3 analog inputs.

Mike C

If there is no absolute truth then nothing can be known.

...

...

...

Aren't these instructions read-modify-write? When the pin goes high-impedance to do the read, there could be a glitch. I'd just use the right byte, like for example (pseudocode):

lda 00000001b ; for bit 0 output A, portA lda 00000000b ; to make the strobe go away output A, portA

Of course, you've already written your data to port B.

If you're using port A for other stuff, keep a shadow copy in RAM.

Good Luck! Rich

I finally got home today, got out the pliers, and bent a 1uF capacitor's leads enough to straddle the PIC. The result appears to be a lot cleaner already! Thanks for helping a clueless boy track this down. However, I'm not going to call a single good test a success, so I want to talk it out.

For > > Well, your bare-bones circuit is correct (but, as another poster

Fortunately, I had the good sense to use a 2-to-4 _with_ an enable input. The outputs are inverted (HHHH when disabled, one output low when enabled), but the 574 is positive edge-triggered, so as long as all outputs stay high _except_ when in use, and then are not expected to register until the clock pulse from the processor _ends_, shouldn't that work? Anyway, I'm not going to re-introduce the decoder until I know everything works without it. That said, the decoder is necessary, because I'll need the extra two pins later. It's from the HC series, and I wouldn't guess it's altogether timing-incompatible. (But to make sure everything works with it, I'll be sure to add up the propagation delays and insert nops accordingly.)

Once I buy some capacitors, there will be one on every chip. The supply leads will be a more ideal length once I'm off the breadboard, I guess. The +5V from the supply has tended to range from 5.04 to 5.15, which I figured wasn't going to be a problem. (It's an ATX power supply, and I figure if it's good enough for the digital logic on a motherboard...but then, more obvious conclusions have been wrong.)

The ABT574's spec rates the governing minimum input edge (in this case, the clock input) at 100mV/ns. Unless I'm reading or calculating wrong, that means the up edge must take less than 50ns at 5V. A cursory glance at the spec for my PIC device rates the maximum I/O port output rise/fall at 40ns, 10ns typical, so that ought to be fine, right? If it weren't, what would I want to do? Perhaps run the pin out to some sort of bistable, or is it simpler than that? (My background in analog circuits is spotty.)

Speaking of these specs, when they speak of rise/fall times, are they talking about from GND to Vdd (e.g. 0 to 5V) or simply low to high (0.8 to 2.0V, as rated for the ABT574)?

Thanks for educating a guy who didn't have the good sense to do this as his major... PSM

I've evaluated shift registers for this design and found that for this application (which may end up having 128 outputs eventually) the bit banging involved would slow the refresh rate to nearly human-discernible levels. Farming it out to a parallel-in shift register outputting to serial-in shift registers has been another thought, but I plan to wait a while before exploring it.

Incidentally, the outputs are for driving a computer-controlled light display, so the outs on the DFFs will connect to transistor arrays that in turn drive several high-brightness LEDs each.

Thanks PSM

(00000111) to disable the comparators.

and configures A0-A3 analog

My copy of the 16F88 spec (rev C, page 15) says the POR value for CMCON is 00000111, not 0.

Thanks PSM

PORTA and PORTB, according to what I've read, are latched--I don't think they go hi-Z for a read. I could be wrong, but I'm having some degree of success with adding decoupling caps and shortening the ground lines, so I think that's more likely where the problem is.

Thanks PSM

The .1 ceramic are standard for each chip (more or less). The tantalums don't have as good frequency response, but they can be used on a per-board (not per-chip) basis.

You should be OK with an enable signal. Otherwise, due to different propagation delays within the chip, you may find unselected outputs getting a brief glitch. For example, switching from '0' to '2' you may find that e.g. '3' gets a brief glitch (but quick enough for the latch chip to respond). Use the enable pin to keep all outputs off (high) until the chip has settled. In practice this can just be the very next PIC instruction, since we're only talking ns or very low 10s of ns here.

The sheet I just looked at specified a max of 5ns/V, half of what you quote. Your PIC will probably work, but there's no margin. The reality is that you're using too fast a latch for the PIC. You never want to use a faster chip than you need - that's just a recipe for trouble, especially with sloppy breadboard wiring.

No problem. You're miles ahead of some of the stuff that gets asked. :-)

A little update: I hooked the fourth 574 back up and found that it was picking up the same noise as earlier, but jumping its ground directly to the PIC's ground and decoupling it (this time with a .47uF I happened to find in an older junk box) seems to have fixed it. I'm elated about this fact and I really think I'm a step closer to completing my next bill of materials for a Jameco order...

On the other hand, I think all of this means I absolutely cannot implement the final product the same way, since it involves breakout boxes potentially _feet_ away from the PIC, and keeping the ground-to-ground short is simply not an option. Would I be better off running the outs into a parallel-in shift register, then deserializing on the other end? Or perhaps going all-out RS-232? (I don't like that idea!) I guess just keeping the DFFs on the main board and running the outputs to the LED driver transistors could work. The human eye is conveniently non-timing-sensitive.

More follows; read > >> The ABT574's spec rates the governing minimum input edge (in this case,

I'll double-check that the sheet I have is for the manufacturer I've got. Unfortunately, I didn't know much about the difference between logic families _before_ I bought my last batch of stuff, and I certainly didn't suspect that there was a _minimum_ on the input rise; I just figured there was a threshold point unless there was a Schmitt trigger involved, and that newer series with pin compatibility could (in general) be used as drop-in replacements. I know better now, don't I? :-/ From what I'm hearing here, I'd be better off downgrading to, say, an HC-series? I don't like working without a margin. I'm already error-prone enough...

Noted!

Thanks a zillion PSM

That must be one slow uC. Imagine you would want to spring for, say, six IO lines for the light display. That would mean you'd have to update 32 serial bits on four lines, the 5th is clock and the 6th is for simultaneous loading in case you need that feature. Most modern uC could pipe out at several MHz no sweat. That would still be around or above

100kHz. Even if you restrict the data piping to 25% duty cycle you'd still be above audio. Definitely above the capabilities of the human eye.

Of course, in all this one must mind animals and their audio range. Even where they are normally not allowed guide dogs, for example, could still be present.

If there aren't any inductors involved audio noise is probably not going to matter much. Unless it electrically buzzes into a PA system or rock concert audio gear.

--
Regards, Joerg

http://www.analogconsultants.com

What's the maximum data rate you will need? How many bytes/sec? It really is starting to sound to me like you want a serial transfer mechanism. You should have no trouble running a UART to 115 kbaud over a few feet. That's 10kbytes/sec. You might be able to do quite a bit faster, perhaps using RS-485 drivers and receivers. But then you need a UART on the other end.

Or, you could do an SPI-type serial transfer, either with a built-in SPI module or by bit-banging. Simple MSI shift registers would be enough on the receiving end. Again, you might want to use RS-485 drivers and receivers. Making the decision really depends on how much data you have to write out, and also how much processing you need to do between data transmissions.

If you can avoid it, you do not want to be passing large high- frequency currents on your cabling. So you don't want to have your LED switching currents travelling along your cabling if you can package the LED power supply right at the LEDs.

I think something like HC would be a much better match.

(00000111) to disable the comparators.

and configures A0-A3 analog

"The scientist is possessed by the sense of universal causation...His religious feeling takes the form of rapturous amazement at the harmony of natural law, which reveals the intelligence of such superiority that, compared with it, systematic thinking and acting of human beings is an utterly insignificant reflection." Albert Einstein (theoretical physicist)

Oops, sorry. That was corrected in rev B of the datasheet and ofcourse I was looking at rev A.

Mike

"The scientist is possessed by the sense of universal causation...His religious feeling takes the form of rapturous amazement at the harmony of natural law, which reveals the intelligence of such superiority that, compared with it, systematic thinking and acting of human beings is an utterly insignificant reflection." Albert Einstein (theoretical physicist)

I'm afraid to make it too much more complicated than it already is...some dedicated shift registers could be suitable, but a micro on each breakout would be overkill. The output data rate isn't particularly extreme; it should be sufficient as long as it is architecturally capable of running 128 one-bit outputs at a refresh rate of about 60Hz--it's lights, after all. The _input_, actually, will be RS-232, because (at least in this incarnation) it's a computer-controlled LED lighting rig. I'm looking at running it with an

11.0592MHz crystal to keep the timing serial-compatible, and I already have the MAX232 on hand.

The 16F88 just happens to have a built-in SPI port. Are there any sort of "dumb-terminal"-style external registers that use something like this, or would I need another micro at the far end? (There are cheaper micros that could be exploited as dedicated bit-bangers for this purpose, but I'd like to avoid clunking it up like that...)

This can be done. What I'd planned to do is use some ULN2803A Darlington arrays to drive the lighting. I figured that in the worst case I could have just the array on the breakouts and everything else on the main board. This seemed like a good match, given that the 2803 interfaces directly with TTL-compatible levels and is rated at 1.35mA max input current (it appears to be more or less a high-current 7405 with two extra NOT gates). Then, I could use beefier supply cables to drive the lights themselves. The PSU is rated for 300W, and I know that ATX power ratings are for suckers, but at a pessimistic 40% estimate,

120W, it should still be a good deal more than necessary. (Cut this hubris off now, if you must!)

Thanks again; this project may be saved yet... PSM