[rescue] Parallel ports [was Re: Slightly OT: ?Bad Cap Saga]

[Curious George]

--- On Thu, 8/21/08, der Mouse <mouse at Rodents-Montreal.ORG> wrote:

> > I believe the ATtiny2313 might be exactly what you'd want (hardware
> > UART, external clock not required, DIP package).
> 
> That certainly makes it sound good.  ...google...  Tempting.  It's not
> _exactly_ what I'd want; it demands something very much like a PROM
> pogrammer to get code into it.

Most (many?) modern devices are now flash based.  Programming
is often done via funky serial algorithms and/or just cramming
data onto pins of the chip, etc.  (which means you need a
parallel port on a PC...  <wink> )

> I also can't help wondering how you can have three general-purpose
> 8-bit I/O registers in a device with fewer than 24 pins;
> there must be something I'm missing, but then, I haven't read the
> whole doc file.

You'll find that not all the bits are available externally.
You may also find that if you want to use the UART, you
have to "sacrifice" two (or more) of the I/O pins (i.e.,
to implement RxD and TxD).

The biggest "issue" with picking a decent MCU for a particular
task is sorting out which "features" you can use together and
what that *costs* you.

E.g., using a programmable timer may cost you an I/O pin.
Or, it may prevent you from using the UART -- since there
may be only *one* timer in the device.  Solution:  program
your timer to run at whatever baud rate you need and NOT
as a more generic "jiffy" interrupt.

Much of the work in using these devices is sorting out how
to configure all the I/O's after startup.  You'll find the
datasheets invariable here as you can just go through
and make notes about how you want to set each of the
configuration registers and what the ramifications of each
of those settings are in terms of hardware pins, etc.

> > A good 232->uC that can go faster is likely to be trouble some,
> > unless you have one of the really high speed serial cards for a Sun
> > (or other machine).
> 
> I have a Magma SBus serial-port card that can be set to run
> as fast as megabit speeds.  I don't know how reliable it is at
> such speeds, as I've nothing for it to talk to at that kind of speed.

I think I have one in the garage -- I'd have to check to see what
sort of level translators they have on the Tx outputs.  E.g.,
the EIA232 spec originally required the outputs to be slew rate
limited to ~30V/us. As such, toggling a line at 500KHz would
be a limiting factor.
 
> I might try to build something of my own for it to talk to, but I
> have had little
> success with logic circuits involving signals approaching
> the megahertz
> range (no experience -> no successes -> still no experience).
> 
> > For a some amount more cash spent on the project, you could build
> > something network capable and a lot faster.  To me, that would be the
> > write way to do it.  It seems to me that ethernet isn't expensive if
> > you can built it yourself, but it is pretty expensive to buy premade
> > modules.
> 
> But then you need a computer on the far side of it, and you're right
> back to getting the bits off a computer.  At least, I can't really
> iamgine how you're going to do any kind of network protocol without
> _some_ kind of computer to implement it.  Or were you thinking of doing
> that in silicon?

It's been done in some products.  But, no, you typically write
your own stack -- or port an existing one (this can be a real
chore for smaller processors which don't have much horsepower).
You'll find many such devices just cheat and do everything UDP
instead of trying to support TCP/IP.

<shrug>  Why not?  You could always layer a protocol on top
of UDP to give you whatever error checking you needed, etc.
Far less costly than implementing the complete TCP/IP
suite.  (on many smaller processors, just the checksum
computation can be a bottleneck!!)

This is what, IMO, makes embedded products so much more fun
to design than desktop applications.  You really have to think
*hard* about what you are trying to do instead of just "doing
the obvious"  :>