Simple serial port interface

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

I'm trying to build a simple computer controled led driver using sipo
shift registers. I have got it to work great using the parallel port
as I can control the input lines easily, however am having difficulty
understanding and implementing a version that would use the serial
port. I would prefer not to have to use a uC for this as I want to
keep it as cheap and easy to do and so that others, that don't have a
programmer, could make it. I am using latching shift registers so in
total I use 4 lines: input, clock, latch, and reset. Reset is kindof
optional but I prefer to be able to controll it from the program as
well.

I'm having a couple issues, 1) How do I generate the clock signal when
using a DB9 connector that doesn't have one suplied. 2) How and when
would the latch need to be triggered, i.e. when do I know all the data
has been recieved?

I could think that using a resonator could generate the clock signal
though I don't know how to do that exactly. I would think that a
counter (chained flip-flops or the like) would work for trigerring the
latch, however that would (I think) imply that you are constantly
sending data, ideally only changes would be sent.

Not that it matters, but this is intended for use on linux systems as a
visual indication of mythtv's recording schedule, disk usage, etc. But
the hardware for it should be generic enough that it could be used to
indicate virtually anything.

Any ideas would be great, if someone has created a microcontroller-less
serial peripheral I would really like to see the schematic or hear your
comments.

Thanks
-john



PRR

 

[Hawk]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

jhaskins@gmail.com wrote:
> I'm trying to build a simple computer controled led driver using sipo
> shift registers. I have got it to work great using the parallel port
> as I can control the input lines easily, however am having difficulty
> understanding and implementing a version that would use the serial
> port. I would prefer not to have to use a uC for this as I want to
> keep it as cheap and easy to do and so that others, that don't have a
> programmer, could make it. I am using latching shift registers so in
> total I use 4 lines: input, clock, latch, and reset. Reset is kindof
> optional but I prefer to be able to controll it from the program as
> well.
>
> I'm having a couple issues, 1) How do I generate the clock signal when
> using a DB9 connector that doesn't have one suplied. 2) How and when
> would the latch need to be triggered, i.e. when do I know all the data
> has been recieved?

You could bit bang it by manually controlling the DTR and RTS lines on
the port. You could use one of the lines as a data line, and one as the
clock.

You would set the data line to the correct boolean value (1 or 0), then
toggle the clock line to give you the 0-1-0 or 1-0-1 transition that you
need to clock the bit into the counter and have it ready to deliver the
next clock pulse.

Keep in mind that you will have to do a level shift to be compatible
with positive logic. The serial lines are at either -12V or 0V and need
to be shifted to positive logic for your counter. I would recommend
using a MAX232 IC which is designed specifically for this.

Good Luck,

(*>

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

jhaskins@gmail.com wrote:

> I'm trying to build a simple computer controled led driver using sipo
> shift registers. I have got it to work great using the parallel port
> as I can control the input lines easily, however am having difficulty
> understanding and implementing a version that would use the serial
> port. I would prefer not to have to use a uC for this as I want to
> keep it as cheap and easy to do and so that others, that don't have a
> programmer, could make it. I am using latching shift registers so in
> total I use 4 lines: input, clock, latch, and reset. Reset is kindof
> optional but I prefer to be able to controll it from the program as
> well.
>
> I'm having a couple issues, 1) How do I generate the clock signal when
> using a DB9 connector that doesn't have one suplied. 2) How and when
> would the latch need to be triggered, i.e. when do I know all the data
> has been recieved?

Serial is *a*synchronous. That's why the speed has to be manually set on
both ends (or an intelligence, as in the uProcessor you don't want, cycling
through the supported possibilities to see which one 'works', as modems do
at dial up).

The clocks on each end free run, with respect to each other, and the serial
data stream begins with a START bit. The receiving end monitors the serial
line for the START bit transition and then delays a half bit to set the
sample time. If the START bit is not still there then it's false start and
it goes back to waiting for one. If the START bit is still there then it's
'good' and there will be 7, or 8 (either 8 no parity or 7 with parity), or
9 (8 bit with parity), depending on the setting, data bits spaced equal
clock ticks from the half way point (to allow for bit jitter) in the START
bit. The STOP bit returns to the 'wait' state and is used as a final check
that synchronization occurred (stop should be there) or else the whole
block is discarded. Then parity checking is done if parity is set.

A START/STOP pair is sent for every 7, 8, or 9 data bits because the clocks
are not synchronized and, over time, would eventually drift apart. With a
START/STOP pair the two clocks just have to be close enough to keep within
1/2 bit, or so, over the 10, 11, or 12 bit time frame as they'll re-sync on
the next START.

> I could think that using a resonator could generate the clock signal
> though I don't know how to do that exactly. I would think that a
> counter (chained flip-flops or the like) would work for trigerring the
> latch, however that would (I think) imply that you are constantly
> sending data, ideally only changes would be sent.
>
> Not that it matters, but this is intended for use on linux systems as a
> visual indication of mythtv's recording schedule, disk usage, etc. But
> the hardware for it should be generic enough that it could be used to
> indicate virtually anything.
>
> Any ideas would be great, if someone has created a microcontroller-less
> serial peripheral I would really like to see the schematic or hear your
> comments.

Get a one chip UART that already does it and presents you with 8 bit
parallel out and a data strobe. Something like this (not that I'm
recommending this particular one, it's just an example)

http://focus.ti.com/docs/prod/folders/print/tl16c450.html

As the saying goes, "Don't reinvent the wheel."

>
> Thanks
> -john
>
>
>
> PRR
>

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

Why not use a HR-USBUART device and communicate with the PC with USB
then you get the 5V from the USB too and no annoying serial cables. The
device is tiny and the drivers work really well.
http://www.customidea.com/hr-usbuart.php

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

On 26 Jun 2005 16:03:29 -0700, jhaskins@gmail.com put finger to
keyboard and composed:

>I'm trying to build a simple computer controled led driver using sipo
>shift registers. I have got it to work great using the parallel port
>as I can control the input lines easily, however am having difficulty
>understanding and implementing a version that would use the serial
>port. I would prefer not to have to use a uC for this as I want to
>keep it as cheap and easy to do and so that others, that don't have a
>programmer, could make it.

Use a PICAXE (a PIC with on-chip BASIC). Program it from the serial
port with just an ordinary cable. No special programmer required. Pick
up your +5V power from a spare USB port. Cost is about AU$5-$15, which
is less than the cost of a UART and its associated support components.

See http://www.microzed.com.au/P02-18-PIN-PICAXE.htm


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

Thanks for all the replies, however I still don't think I have a
cost-efficient, viable solution, but then perhaps one doesn't exist,
not that big of a deal.

Hawk, I would love to bit-bang out the serial port, this would be the
best, however I need 3 or 4 lines, 1 for data, 1 for clock (as you
mentioned) 1 for latch and 1 for reset; reset I suppose I could leave
out which would leave 3. So would I be able to also use TX in bit bang
mode? Is there a fourth line I could use? Are there any examples of
this methodology in any language for linux? C/C++, TCL/TK, or Java
would be best but I can usually translate from most.

David, I understand how serial communication works though thank you for
the detailed explination. A UART is the obvious solution however I'm
just not sure it's appropriate for this project. The main issue is
cost, all that I have seen cost more than the rest of the project
combined, so it's virtually doubling the $, not that big a deal for
some but don't want to require it. Perhaps I'm make it more modular
and have a UART driven input module...

Franc, yes I could use a picAXE however that would require you to get
or make the programmer, download the programming software, me to write
and others to download the firmware, burn to the chip, etc.
Additionally it is just about the same $ as a UART... I mentioned that
i didn't want a uC in this project, a pic is a micro controller, if I
did I'd probably use something I'm very familiar with, and have spares
laying arround, such as an AVR that have built in UARTs. The thing is
I wouldn't be using them to their fullest extent and see it as a waste.
Thank you for the suggestion though.

picu..., I have considered making it usb, I like the idea but not sure
if it's worth the trouble. I did some looking yesterday and found an
ftdi chip that has drivers that can be used to do controlled 8 line
output without need for much else. The cost is still more than I
wanted for such a simple project but I may do this as an optional input
board. Have you or anyone else used any of the ftdi usb line of ics
specifically the FT245BM? How easy are they to work with both from the
hardware and the software perspectives? I'm a little concerned about
finding it on the bus, since it would likely have a factory set vendor
and product id, and use ftdi's standard driver...

Again, thanks for all the input.

-john

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

On 3 Jul 2005 10:58:56 -0700, "-john" <jhaskins@gmail.com> put finger
to keyboard and composed:

>Thanks for all the replies, however I still don't think I have a
>cost-efficient, viable solution, but then perhaps one doesn't exist,
>not that big of a deal.
>
>Hawk, I would love to bit-bang out the serial port, this would be the
>best, however I need 3 or 4 lines, 1 for data, 1 for clock (as you
>mentioned) 1 for latch and 1 for reset; reset I suppose I could leave
>out which would leave 3. So would I be able to also use TX in bit bang
>mode?

When not transmitting, Tx sits at -12V. When transmitting, the data
will be framed with start and stop bits. Try transmitting an all
zeroes byte (+12V) with space parity. This should generate a pulse
which you could use as your clock. Use RTS and DTR for data and latch.
Send a zero byte to reset your latch.

BTW, which latches/FIFOs are you using, and how are you translating
the signal levels?

>Is there a fourth line I could use? Are there any examples of
>this methodology in any language for linux? C/C++, TCL/TK, or Java
>would be best but I can usually translate from most.

>David, I understand how serial communication works though thank you for
>the detailed explination. A UART is the obvious solution however I'm
>just not sure it's appropriate for this project. The main issue is
>cost, all that I have seen cost more than the rest of the project
>combined, so it's virtually doubling the $, not that big a deal for
>some but don't want to require it. Perhaps I'm make it more modular
>and have a UART driven input module...

It's very difficult to even find a discrete UART these days, although
I have several I could give you should you wish to go that way.
Remember, though, that you will need a crystal and some level
translators, or an RS232 receiver IC. You will also need a buffer to
drive your LED(s).

>Franc, yes I could use a picAXE however that would require you to get
>or make the programmer, ...

It's just a resistor and a serial cable.

> ... download the programming software,

It's free.

> ... me to write
>and others to download the firmware,

The language is BASIC. A "program" to toggle some LED(s) would amount
to less than five lines of code, which is a *lot* easier than bit
banging a serial port.

The PICAXE is very popular amongst novices in secondary schools.

> ... burn to the chip, etc.

No more difficult than installing the "bit banging" software you would
still have to write.

>Additionally it is just about the same $ as a UART...

No, no, no!

>I mentioned that
>i didn't want a uC in this project, a pic is a micro controller, if I
>did I'd probably use something I'm very familiar with, and have spares
>laying arround, such as an AVR that have built in UARTs. The thing is
>I wouldn't be using them to their fullest extent and see it as a waste.
> Thank you for the suggestion though.

The PICAXE is a pre-programmed PIC. *All* the work is done for you.
You cannot beat it for versatility with a discrete solution. The
development time would be close to zero, and there are no additional
parts costs. IMHO, you are doing yourself a disservice by ignoring
uCs.

Consider reposting to sci.electronics.design for better ideas.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

[Frank Zabkar]
>When not transmitting, Tx sits at -12V. When transmitting, the data
>will be framed with start and stop bits. Try transmitting an all
>zeroes byte (+12V) with space parity. This should generate a pulse
>which you could use as your clock. Use RTS and DTR for data and latch.
>Send a zero byte to reset your latch.
>
>BTW, which latches/FIFOs are you using, and how are you translating
>the signal levels?

Still not sure how to control RTS and DTR but ,assuming I could do it,
that sounds like a fair way of implementing it. The shift register
with latch I'm using is just a 74HC595 (actually a number of them
chained together) as it's currently parallel port driven I'm not level
shifting. When and if I do a serial version, since it's only output
from the computer, no need to communicate the other way, will probably
just try to use some resistors for the level down-shifting.

[Frank Zabkar]
>It's very difficult to even find a discrete UART these days, although
>I have several I could give you should you wish to go that way.
>Remember, though, that you will need a crystal and some level
>translators, or an RS232 receiver IC. You will also need a buffer to
>drive your LED(s).

I appreciate the offer, I did manage to find a few that I could order,
not sure it's the way I'd like to go though.

>>Franc, yes I could use a picAXE however that would require you to get
>>or make the programmer, ...
>
>It's just a resistor and a serial cable.
>
>> ... download the programming software,
>
>It's free.
>
>> ... me to write
>>and others to download the firmware,
>
>The language is BASIC. A "program" to toggle some LED(s) would amount
>to less than five lines of code, which is a *lot* easier than bit
>banging a serial port.

Understandably it would be a simple small program, which is one of the
reasons for this project I'd like to stay away from microcontrollers,
they are overkill given the requirements.

>
>The PICAXE is very popular amongst novices in secondary schools.
>
>> ... burn to the chip, etc.
>
>No more difficult than installing the "bit banging" software you would
>still have to write.
>

still more for him/them to create and debug and at least one more thing
to go wrong... Don't get me wrong in general I agree with everything
you're saying, the issue here is that this is intended for use by a
friend of mine (at least one) that is not within easy driving distance,
so he would be doing it himself, and he's much more on the pc side of
techie... so not sure he would want to (if i were him i wouldn't) go
through the trouble of installing, configuring, troubleshooting the
software and building and troubleshooting the programming cable,
writing to the ic, all for a one time deal. I will perhaps try a
PICAXE for another project that is for myself, more electronically
savvy (or closer) friends.

>
>>Additionally it is just about the same $ as a UART...
>
>No, no, no!

okay I don't see a real price list or shopping cart on the site
provided, didn't see any other real concrete amounts elswhere ether,
but going off the impression I got from the site and assuming I would
use the cheapest they had available on the page that was sent it would
be $9-14, I saw another page there that had others and they might range
down to $3. So it might not be the same amount as a UART but it's
still a far cry from the $0.62 HC595 and $1+- perf-board that it is
currently.

[Frank Zabkar]
>The PICAXE is a pre-programmed PIC. *All* the work is done for you.
>You cannot beat it for versatility with a discrete solution. The
>development time would be close to zero, and there are no additional
>parts costs. IMHO, you are doing yourself a disservice by ignoring
>uCs.

I may be doing myself a disservice, but I'm just not convinced that for
this project it warrants a microController, if I actually needed to, or
would benefit from, putting some logic in firmware I'd consider using
a pixaxe, pic, or avr but when I can't get any real benefit I'd
rather try to figure out how to use all the lines on the serial port
directly, just leave it parallel, or do something a bit cooler like
usb.

>Consider reposting to sci.electronics.design for better ideas.

Been snooping around there for a while, didn't want to ask the same
question given that I'm sure more than just the two of us are looking
at both boards...

If you're interested, and promise not to laugh at it once you see it, I
could send you a link to the project after I get it posted. I think
once you see it you will agree, at least I hope you will, that using a
uC would be overkill.

-john

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
to keyboard and composed:

>[Frank Zabkar]
>>When not transmitting, Tx sits at -12V. When transmitting, the data
>>will be framed with start and stop bits. Try transmitting an all
>>zeroes byte (+12V) with space parity. This should generate a pulse
>>which you could use as your clock. Use RTS and DTR for data and latch.
>>Send a zero byte to reset your latch.
>>
>>BTW, which latches/FIFOs are you using, and how are you translating
>>the signal levels?
>
>Still not sure how to control RTS and DTR but ,assuming I could do it,
>that sounds like a fair way of implementing it.

PC COM ports are programmed in the same way as NS16450/16550 UARTs.

For programming info, study the datasheet for an NS16550A UART, eg
http://focus.ti.com/lit/ds/symlink/tl16c550b.pdf

The DTR and RTS pins can be controlled from bits 0 and 1 of the Modem
Control Register. For a serial port at COM1 (IO address x3F8), the MCR
is located at IO port 3FC. The MCR for COM2 is at port 2FC.

As an example, in real DOS mode you could use Debug to write to the
MCR at COM2 as follows:

debug
- o 2fc 3 (DTR and RTS on) o= oh, not zero
- o 2fc 1 (DTR on, RTS off)
- o 2fc 2 (DTR off, RTS on)
- o 2fc 0 (DTR and RTS off)
- q

I'm not a programmer, so I'm not familiar with the high level tools
available in a Windows or Linux environment. However, I *have* bit
banged the serial port using DOS and Qbasic. In fact I've written a
diagnostic program that flashes the RTS, DTR, and Tx pins at one
second intervals.

> The shift register
>with latch I'm using is just a 74HC595 (actually a number of them
>chained together) as it's currently parallel port driven I'm not level
>shifting. When and if I do a serial version, since it's only output
>from the computer, no need to communicate the other way, will probably
>just try to use some resistors for the level down-shifting.

At the very least you will need clamping diodes (eg 1N914 or 1N4148)
to protect your 74HC595s from destructive latchup. You may also need
an NPN transistor or two (eg BC548) for polarity reversal.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

Franc Zabkar wrote:

> On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
> to keyboard and composed:
>
>
>>[Frank Zabkar]
>>
>>>When not transmitting, Tx sits at -12V. When transmitting, the data
>>>will be framed with start and stop bits. Try transmitting an all
>>>zeroes byte (+12V) with space parity. This should generate a pulse
>>>which you could use as your clock. Use RTS and DTR for data and latch.
>>>Send a zero byte to reset your latch.
>>>
>>>BTW, which latches/FIFOs are you using, and how are you translating
>>>the signal levels?
>>
>>Still not sure how to control RTS and DTR but ,assuming I could do it,
>>that sounds like a fair way of implementing it.
>
>
> PC COM ports are programmed in the same way as NS16450/16550 UARTs.
>
> For programming info, study the datasheet for an NS16550A UART, eg
> http://focus.ti.com/lit/ds/symlink/tl16c550b.pdf
>
> The DTR and RTS pins can be controlled from bits 0 and 1 of the Modem
> Control Register. For a serial port at COM1 (IO address x3F8), the MCR
> is located at IO port 3FC. The MCR for COM2 is at port 2FC.
>
> As an example, in real DOS mode you could use Debug to write to the
> MCR at COM2 as follows:
>
> debug
> - o 2fc 3 (DTR and RTS on) o= oh, not zero
> - o 2fc 1 (DTR on, RTS off)
> - o 2fc 2 (DTR off, RTS on)
> - o 2fc 0 (DTR and RTS off)
> - q
>
> I'm not a programmer, so I'm not familiar with the high level tools
> available in a Windows or Linux environment. However, I *have* bit
> banged the serial port using DOS and Qbasic. In fact I've written a
> diagnostic program that flashes the RTS, DTR, and Tx pins at one
> second intervals.
>
>
>> The shift register
>>with latch I'm using is just a 74HC595 (actually a number of them
>>chained together) as it's currently parallel port driven I'm not level
>>shifting. When and if I do a serial version, since it's only output
>
>>from the computer, no need to communicate the other way, will probably
>
>>just try to use some resistors for the level down-shifting.
>
>
> At the very least you will need clamping diodes (eg 1N914 or 1N4148)
> to protect your 74HC595s from destructive latchup. You may also need
> an NPN transistor or two (eg BC548) for polarity reversal.
>

You wouldn't put diodes on the 74HC595s. You use the NPN transistor to
invert and level shift.

Input goes through current limit resistor to NPN base. 1N914 cathode to NPN
base and anode to emitter to shunt the negative. Include a leakage bleeder
from base to emitter as well. Output is from the collector-resistor junction.

The 74HC595 never sees anything but the 0-Vcc logic levels it expects.

Or just use a rs-232 level shifter IC.

> - Franc Zabkar

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

On Wed, 06 Jul 2005 09:55:44 -0500, David Maynard <nospam@private.net>
put finger to keyboard and composed:

>Franc Zabkar wrote:
>
>> On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
>> to keyboard and composed:

>>> The shift register
>>>with latch I'm using is just a 74HC595 (actually a number of them
>>>chained together) as it's currently parallel port driven I'm not level
>>>shifting. When and if I do a serial version, since it's only output
>>
>>>from the computer, no need to communicate the other way, will probably
>>
>>>just try to use some resistors for the level down-shifting.
>>
>>
>> At the very least you will need clamping diodes (eg 1N914 or 1N4148)
>> to protect your 74HC595s from destructive latchup. You may also need
>> an NPN transistor or two (eg BC548) for polarity reversal.
>>
>
>You wouldn't put diodes on the 74HC595s. You use the NPN transistor to
>invert and level shift.

You wouldn't need to invert RTS or DTR. A series resistor and two
clamping diodes are all that are required.

>Input goes through current limit resistor to NPN base. 1N914 cathode to NPN
>base and anode to emitter to shunt the negative. Include a leakage bleeder
>from base to emitter as well. Output is from the collector-resistor junction.
>
>The 74HC595 never sees anything but the 0-Vcc logic levels it expects.
>
>Or just use a rs-232 level shifter IC.

My understanding is that the OP wants an absolute minimum cost
solution. A transistor is an additional cost. I can't see how to avoid
using one for Tx, though, assuming Tx is to be used for clocking.

BTW, I realise that clamping diodes are not needed if a transistor is
used for level translation.

>> - Franc Zabkar


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

Franc Zabkar wrote:

> On Wed, 06 Jul 2005 09:55:44 -0500, David Maynard <nospam@private.net>
> put finger to keyboard and composed:
>
>
>>Franc Zabkar wrote:
>>
>>
>>>On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
>>>to keyboard and composed:
>
>
>
>>>>The shift register
>>>>with latch I'm using is just a 74HC595 (actually a number of them
>>>>chained together) as it's currently parallel port driven I'm not level
>>>>shifting. When and if I do a serial version, since it's only output
>>>
>>>>from the computer, no need to communicate the other way, will probably
>>>
>>>
>>>>just try to use some resistors for the level down-shifting.
>>>
>>>
>>>At the very least you will need clamping diodes (eg 1N914 or 1N4148)
>>>to protect your 74HC595s from destructive latchup. You may also need
>>>an NPN transistor or two (eg BC548) for polarity reversal.
>>>
>>
>>You wouldn't put diodes on the 74HC595s. You use the NPN transistor to
>>invert and level shift.
>
>
> You wouldn't need to invert RTS or DTR. A series resistor and two
> clamping diodes are all that are required.

Because you figure on bit banging them the 'wrong' polarity?

>
>
>>Input goes through current limit resistor to NPN base. 1N914 cathode to NPN
>>base and anode to emitter to shunt the negative. Include a leakage bleeder
>
>>from base to emitter as well. Output is from the collector-resistor junction.
>
>>The 74HC595 never sees anything but the 0-Vcc logic levels it expects.
>>
>>Or just use a rs-232 level shifter IC.
>
>
> My understanding is that the OP wants an absolute minimum cost
> solution. A transistor is an additional cost. I can't see how to avoid
> using one for Tx, though, assuming Tx is to be used for clocking.

Yeah. Depends on how one measures 'cost'. If time and effort is 'free' then
discretes might be cheaper but, IMO, a UART is the way to go. You put it
down, it works, and it works the way everything else works so you don't
have to spend lord knows how long debugging a bit banger.

Actually, your suggestion of the micro is probably the cheapest since it
would do everything including drive the display. Especially if one bit the
bullet, used a plain jane one, and programmed it up in assembly (or compiled).

>
> BTW, I realise that clamping diodes are not needed if a transistor is
> used for level translation.

Depending on a discrete diode as a 'normal operation' voltage limiter to a
CMOS device can be problematic as it's a 'race' to see whether the external
diode or the CMOS substrate conducts first.

>
>
>>>- Franc Zabkar
>
>
>
> - Franc Zabkar

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

On Wed, 06 Jul 2005 23:19:31 -0500, David Maynard <nospam@private.net>
put finger to keyboard and composed:

>Franc Zabkar wrote:
>
>> On Wed, 06 Jul 2005 09:55:44 -0500, David Maynard <nospam@private.net>
>> put finger to keyboard and composed:
>>
>>
>>>Franc Zabkar wrote:
>>>
>>>
>>>>On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
>>>>to keyboard and composed:
>>
>>
>>
>>>>>The shift register
>>>>>with latch I'm using is just a 74HC595 (actually a number of them
>>>>>chained together) as it's currently parallel port driven I'm not level
>>>>>shifting. When and if I do a serial version, since it's only output
>>>>
>>>>>from the computer, no need to communicate the other way, will probably
>>>>
>>>>
>>>>>just try to use some resistors for the level down-shifting.
>>>>
>>>>
>>>>At the very least you will need clamping diodes (eg 1N914 or 1N4148)
>>>>to protect your 74HC595s from destructive latchup. You may also need
>>>>an NPN transistor or two (eg BC548) for polarity reversal.
>>>>
>>>
>>>You wouldn't put diodes on the 74HC595s. You use the NPN transistor to
>>>invert and level shift.
>>
>>
>> You wouldn't need to invert RTS or DTR. A series resistor and two
>> clamping diodes are all that are required.
>
>Because you figure on bit banging them the 'wrong' polarity?

Yes.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

 

[Guest]

Archived from groups: alt.comp.hardware.homebuilt (More info?)

Franc Zabkar wrote:
> On Wed, 06 Jul 2005 23:19:31 -0500, David Maynard <nospam@private.net>
> put finger to keyboard and composed:
>
>
>>Franc Zabkar wrote:
>>
>>
>>>On Wed, 06 Jul 2005 09:55:44 -0500, David Maynard <nospam@private.net>
>>>put finger to keyboard and composed:
>>>
>>>
>>>
>>>>Franc Zabkar wrote:
>>>>
>>>>
>>>>
>>>>>On 5 Jul 2005 01:19:41 -0700, "-john" <jhaskins@gmail.com> put finger
>>>>>to keyboard and composed:
>>>
>>>
>>>
>>>
>>>>>>The shift register
>>>>>>with latch I'm using is just a 74HC595 (actually a number of them
>>>>>>chained together) as it's currently parallel port driven I'm not level
>>>>>>shifting. When and if I do a serial version, since it's only output
>>>>>
>>>>>>from the computer, no need to communicate the other way, will probably
>>>>>
>>>>>
>>>>>
>>>>>>just try to use some resistors for the level down-shifting.
>>>>>
>>>>>
>>>>>At the very least you will need clamping diodes (eg 1N914 or 1N4148)
>>>>>to protect your 74HC595s from destructive latchup. You may also need
>>>>>an NPN transistor or two (eg BC548) for polarity reversal.
>>>>>
>>>>
>>>>You wouldn't put diodes on the 74HC595s. You use the NPN transistor to
>>>>invert and level shift.
>>>
>>>
>>>You wouldn't need to invert RTS or DTR. A series resistor and two
>>>clamping diodes are all that are required.
>>
>>Because you figure on bit banging them the 'wrong' polarity?
>
>
> Yes.
>
>
> - Franc Zabkar

ok