[Eeyore]

Though it's not for a "light show" per se, it will be attached to (and
controlled by) a PC that is also producing sound, and the roadies I
imagine you're talking about are really just home PC users (equally
clueless about EMI), so this is in fact something that will probably
require consideration...

As will complying with EMC requirements since we're on the subject.

Graham

 

[Eeyore]

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.

That sounds to me like tackling the symptoms instead of the cause.

Why are you using an ABT part here ?

Graham

 

[Eeyore]

I agree here too - whenever I use a protoboard

'ABT speed parts on a protoboard ! ??????

Graham

 

[Peter S. May]

Yes. I've done exactly the same thing, both for inputs and outputs.

I've found out that my PIC can't use SPI and USART at the same time.
I'll probably use a parallel-in shift register instead, in the interest
of the possibility of adding a little more functionality (such as input
from SPST buttons, perhaps collected from another shift register) to the
device later.

That's why I suggested using RS-485 drivers at the PIC end and
receivers at the breakout end - very noise-resistant. That along with
a slower logic family and all the usual anti-noise precautions.

I'm going to investigate RS-485 as far as possible with my current
intellectual means, now that you're not the only one to have suggested
it. But, in the meantime...

I'm so far under the impression that it's similar to what RS-232 would
be if it used differential signaling. Is it possible to keep the TX
lines of RS-485 and discard the rest; i.e., can/would I use RS-485
drivers without implementing the whole of RS-485? Would I have one TX
line each for signal, shift clock, and latch clock?

The remainder of this project is going to be pretty much exclusively
HC-based. What a haunting fresh-meat mistake...

What do you mean by a "breakout"? One 8-bit register, or an entire
128-bit device, or something in between? I'm assuming the latter.

Something in between. In particular, there will probably be two to four
separate 8-bit breakouts, plus the possibility of adding a 50-to-100 LED
bar graph with animation effects (hence the importance of 60Hz minimum
refresh rate). (Theoretically I ought to be able to replace the LEDs on
any given breakout with some sort of relay or lamp, but, having in mind
the necessity for protection diodes and electrical isolation, LEDs
seemed less troublesome than lightbulbs for this application.)

Anyway, I'd put the shift registers on the same board as the devices
they are driving. That is to say, where you have dozens of data bits
passing between chips, keep those chips on the same board (or at the
very least, in the same box).

One (or possibly all) of the 8-bit breakouts is going to run
high-current Darlington drivers (my tentative BOM specifies a ULN2083A
per 8 bits), because each of the bits thereon represents the light of 9
to 10 LEDs at 20mA each. (I'd better check the ULN2083A sheet again; I
might need two of them for that particular breakout.) Those LEDs won't
even be _on_ a board, but at that point we're past the logic components
and signal integrity isn't going to be that critical...I think.

If you wanted to drive multiple 128-bit breakouts, you could do it by
daisy-chaining but that would be a very brittle arrangement, since any
time your breakout configuration changed you'd have to alter the
entire data-transmission sequence. Much better to (similar to what
you were trying originally) use a star configuration with the same
serial clock and data (and reset?) signal being fed to each breakout,
but a separate latch strobe to each breakout.

I didn't wanna daisy-chain it anyway... Sounds like more trouble than
Christmas lights! But then, I kind of hope it doesn't get to the point
where I actually have to _solder_ more than 128 bits worth of output...
(Then again, I could use the practice; my natural soldering ability
leaves much to be desired.)

My mashing "GO" on the next Jameco order is in T-15 days, and I seem to
be on schedule.

Thanks for your continued input!
PSM

 

[Peter S. May]

I'm going to investigate RS-485 as far as possible with my current
intellectual means, now that you're not the only one to have suggested
it. But, in the meantime...

I'm so far under the impression that it's similar to what RS-232 would
be if it used differential signaling. Is it possible to keep the TX
lines of RS-485 and discard the rest; i.e., can/would I use RS-485
drivers without implementing the whole of RS-485? Would I have one TX
line each for signal, shift clock, and latch clock?

Follow-up on this: Would it be reasonable to use RS-422 instead? The
data sheets seem to be easier to understand and the receivers and
drivers appear to be quite a bit less expensive. Thoughts?

 

[Eeyore]

Follow-up on this: Would it be reasonable to use RS-422 instead? The
data sheets seem to be easier to understand and the receivers and
drivers appear to be quite a bit less expensive. Thoughts?

How far and how fast does your expansion need to be ? Does it need to interface
to any 'foreign' equipment ?

So far I only see ppl suggesting what may be excessively complex and expensive
solutions.

Graham

 

[Peter S. May]

How far and how fast does your expansion need to be ? Does it need to interface
to any 'foreign' equipment ?

The only 'foreign' interface is an RS-232 connection to a computer,
maintained separately.

The distance could be anywhere from 1m to 3m. The output refresh rate,
in toto, needs to be 60Hz or faster (making the maximum clock around
100us, not much of a requirement) but a potential later expansion for
input needs to be much faster than that (my ballpark figure is 20kHz
refresh rate, but I'm sure it could be much slower and still work, and
there will be far fewer inputs than outputs).

So far I only see ppl suggesting what may be excessively complex and expensive
solutions.

I have to agree, at least concerning RS-485. But the RS-422 devices
seem to be less imposing in terms of complexity, being nominally
TTL-to-differential converters, and are quite a bit cheaper. The 485
stuff runs over $1 per device, as far as my searching has gone, and 422
stuff is about half that. Half of a dollar per breakout shouldn't be a
crippling expense. Hopefully they're as simple as I assume they are.

Anyway, it's okay if this project is _slightly_ more complex than it
could be, because it's partly an educational experience on my part and
knowing how to run longer, higher-speed data lines in later projects
would be beneficial. However, I didn't want it to become unwieldy. The
idea of, for example, implementing RTS/CTS for something so simple seems
profoundly ridiculous. But then, I'm not terribly familiar with any
RS-nnn spec, and there aren't Cliffs Notes to point out which parts are
actually important. Perhaps one can get away with a lot less than the
whole thing.

Thanks
PSM

 

[Eeyore]

The only 'foreign' interface is an RS-232 connection to a computer,
maintained separately.

Right, so we can ignore that (put it to one side) from the perspective of this
specific requirement.

The distance could be anywhere from 1m to 3m.

That's 'no distance at all' to my mind. Obviously not suitable for the 'CPU bus'
itself but not a mega-issue.

The output refresh rate,
in toto, needs to be 60Hz or faster (making the maximum clock around
100us, not much of a requirement) but a potential later expansion for
input needs to be much faster than that (my ballpark figure is 20kHz
refresh rate, but I'm sure it could be much slower and still work, and
there will be far fewer inputs than outputs).

And how much data needs to be refreshed during that period ?

60Hz is VERY different to 20kHz (as in 300 times different) so you ought to define
your spec NOW or you'll likely get bitten in the ass.

I have to agree, at least concerning RS-485. But the RS-422 devices
seem to be less imposing in terms of complexity, being nominally
TTL-to-differential converters, and are quite a bit cheaper.

Yes..... but RS232 has all that voltage translation if done properly. Arguably RS485
is simpler.

I'm sorry, but it's effing *INSANE* to use RS-232 or RS-485 to go 1 metre ! or even 2
metres. What is everyone thinking of ?

You need to stop and think hard and *define* your required maximum data rate. Trying
to design kit without a defined spec is a mug's game. Potentially a soon to be
unemployed mug's game.

Graham

 

[Peter S. May]

Right, so we can ignore that (put it to one side) from the perspective of this
specific requirement.



That's 'no distance at all' to my mind. Obviously not suitable for the 'CPU bus'
itself but not a mega-issue.

The reason I've been calling it an issue is that the first incarnation
of this didn't work with the output latch on the same _board_ as the
input micro. I found that the problems were that (a) as a newbie
mistake, I ordered ABT-series parts that ended up being more
noise-sensitive, (b) as another newbie mistake, having never had to
decouple logic ICs before, I wasn't aware I'd have to this time, and (c)
the line from the micro's ground to the latches' ground wasn't short
enough. Since the ground connection will supposedly be even longer in
the product, I figured some sort of denoisifying interface might be in
order. That, and using shift registers and HC-series logic.

And how much data needs to be refreshed during that period ?

The output capability is supposed to be 128 bits. I figure that amounts
to one signal cycle and one clock cycle for each bit, plus a latch clock
every 8 (or more). The input (if and when added) would likely be 16 or
32 bits.

60Hz is VERY different to 20kHz (as in 300 times different) so you ought to define
your spec NOW or you'll likely get bitten in the ass.

This is a hobbyist's experiment, and I don't feel the need to do a great
deal of design in advance. I'm just making inquisitions about it now so
that I can order all the parts I'll _probably_ need at once and know
what sort of hard physical limits I'm looking at.

I'm aware that 60Hz and 20kHz are different! This is a human interface
device. The outputs are visual, and 60Hz should cover persistence of
vision. On the other hand, the ideas I have for inputs include
high-resolution rotary encoders, and I wanted to safely overshoot how
fast a human is capable of turning a wheel without the aid of a motor.
Still, I admit 20kHz just might be overkill.

Yes..... but RS232 has all that voltage translation if done properly. Arguably RS485
is simpler.

From what I've read, though, RS-422 can be run with just a 5V supply
with no need for such conversion, instead getting the noise immunity
from differential signaling, which would adapt well to the profusion of
CAT-5 I have available for the task anyway.

I'm sorry, but it's effing *INSANE* to use RS-232 or RS-485 to go 1 metre ! or even 2
metres. What is everyone thinking of ?

The aforementioned signal concerns, conservative design, and a potential
learning experience.

You need to stop and think hard and *define* your required maximum data rate. Trying
to design kit without a defined spec is a mug's game. Potentially a soon to be
unemployed mug's game.

Fortunately for my income, I do something almost entirely unrelated to
electronics for a living! This is a hobby, a new one at that, and the
project I'm on is an exploratory exercise to the point that an actual
working product is almost secondary as a goal. If I go overkill on a
few of the specs, I figure it may help with a later project that
actually requires the higher speed. I'm only trying to get a feel for
what I might need so that I can buy a few parts that might be helpful,
as opposed to the entire catalog, and hopefully not to have to wait on
another order because I missed something.


Thanks
PSM

 

[Joerg]

Joerg wrote:




Yup, they work OK.

Also see PCF8574 ( I2C interface).

But not for mass production. Way too expensive IMHO. Also, it's got only
two sources and I'd prefer a chip with 5-10 sources since they are
available.

I'm curious too why an ABT574 is being used.

Me too ;-)

 

[Peter S. May]

Me too ;-)

Newbie buying error. It's the kind of mistake one makes when one
assumes pin-compatible = compatible.

I know better now, thanks to sci.electronics.design...

 

[Mike Silva]

I've just realized a dumb mistake: The PIC shares its SPI pins with its
USART pins, so the intended output would be mutually exclusive with the
intended input! :-(
Ouch!

I suppose this means I should resort to bit banging...though, with the
easiest method of doing so being loading one of the 8-bit out registers
and rrfing the value eight times, shouldn't I just be using a
parallel-in/serial-out shift register for this part instead?

Ech, I don't know. Just frustrated at the moment.

You could use a parallel-in/serial-out SR. The tradeoff is another
part and using more of your PIC i/o pins, vs. a little bit faster
software (your software will only need to bit-bang the clock signal,
not serialize the output data between each clock pulse). My gut
reaction is that adding the SR doesn't buy you enough to make it worth
doing (I'm assuming here that it's no big deal to shift out a byte on
the PIC).

BTW, I read that app-note on the Schmitt trigger buffers. The idea
was that for a relatively slow rising/falling clock, different shift
registers may clock the data at different points on the clock edge,
potentially causing mis-shifts between chips. This is another case of
having problems when you mis-match the speed of different chips in a
system. If you use some sort of line driver and receiver (such as the
RS-485 I mentioned), they will speed up your clock edges enough that I
don't think it would be an issue. And again, don't use a faster logic
family than you need (which means in your case, a very slow logic
family will do). If you wanted to give yourself extra margin you
could also add a (slow) non-inverting buffer between each SR output-to-
input path. This will help insure that one SR doesn't shift out new
data before the following SR has shifted in the old data, by delaying
the data from one SR to the next.

 

[Joerg]

Newbie buying error. It's the kind of mistake one makes when one
assumes pin-compatible = compatible.

That's normal, been there myself. He who does not try will not win ;-)

I know better now, thanks to sci.electronics.design...

As a friend of mine (SW engineer) once put it, we are here to serve.

 

[Mike Silva]

Follow-up on this: Would it be reasonable to use RS-422 instead? The
data sheets seem to be easier to understand and the receivers and
drivers appear to be quite a bit less expensive. Thoughts?

Yes, RS-422 is (sorta) RS-485 without the ability to turn off the
driver. In your case you don't seem to have any need to turn off the
driver so 422 chips would be fine. Here's a little more info:
http://www.maxim-ic.com/appnotes.cfm/appnote_number/723/

As to why these drivers (another poster was questioning their
recommendation), I'm basing it on your distance (3m, which I doubled
because this is real life and what I gather to be your data rate (a
few hundred kbaud, to keep your bit-banging transmission time down to
around 10% of your 16ms refresh rate). If somebody else has a better
idea on how to send (worst-case estimate) 250kbaud over 6m, I would
genuinely like to know it myself.