Re: Using (various stuff) to expand PIC outputs

Eeyore wrote:

"Peter S. May" wrote:

Eeyore wrote:
"Peter S. May" wrote:
Peter S. May wrote:
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?
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.

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 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.

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 ?

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.

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.

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
.

Relevant Pages

  • Re: ISE software bug???
    ... The design & report files attached below. ... TIMING REPORT ... Add Generic Clock Buffer: 8 ...
    (comp.arch.fpga)
  • Re: Coding style, wait statement, sensitivity list and synthesis.
    ... >> a double-edge sensitive register. ... >> which also allowed some pretty exotic scan/functional clock designs. ... >> this coding style: ... > In a design review, I require all multiple clock and clock ...
    (comp.lang.vhdl)
  • Re: Modulo-10 counter
    ... and would affect your design if you would play ... multipliers in your datapath without being bothered by clock skew ... The obvious thing to consider is the routing delay. ...
    (comp.arch.fpga)
  • Re: regarding the post PnR timing simulation.....
    ... Regarding the timing violation. ... quality of the clock is essential, for instance jitter, duty cycle, phase ... This is all what I can guess without knowing your design. ...
    (comp.arch.fpga)
  • Re: Virtex 4 FIFO16 blocks - Corruption ?
    ... So, even though I thought the extensive FIFO testing on V4, the problem with a test that passes is that a test is never the application. ... One minor difference for me may be that when I find unusual behavior and have it isolated to a functional portion of the design, I may check the knowledge database for any information relating to my problem area before spending a few more days to further isolate the cause. ... I have a floating point FFT design with a target clock rate of 400 MHz in an SX55-10 part... ... This is a real limitation to the FIFO16 design, and has cost me several weeks of debug and redesign time to find and work around it. ...
    (comp.arch.fpga)