Searching \ for 'Orcad Library' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=orcad+library
Search entire site for: 'Orcad Library'.

Truncated match.
PICList Thread
'Orcad Library'
1998\07\08@152329 by Barry Baldwin

flavicon
face
Hi,

I was wondering if anybody knows where I can get an Orcad
library file for the PIC parts?  Specifically the PIC 16C74.

Thanks,

Barry

1998\07\08@162422 by er

flavicon
face
Making the Schematic Library part is only a 5 minute job,
and has the benefit of letting you arrange the
pins.  For example all the inputs on the left
and the outputs on the right often makes the
most understandable schematic.

-----Original Message-----
From:   Barry Baldwin [SMTP:spam_OUTbbaldwinTakeThisOuTspamINDYME.COM]
Sent:   Wednesday, July 08, 1998 1:29 PM
To:     .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject:        Orcad Library

Hi,

I was wondering if anybody knows where I can get an Orcad
library file for the PIC parts?  Specifically the PIC 16C74.

Thanks,

Barry

1998\07\08@164522 by David VanHorn

flavicon
face
>Making the Schematic Library part is only a 5 minute job,
>and has the benefit of letting you arrange the
>pins.  For example all the inputs on the left
>and the outputs on the right often makes the
>most understandable schematic.


For anything larger than simple gates, I always libedit my own.
The thing is, a schematic (unlike most you've seen) isn't just a
rats nest of wires designed to confuse the hell out of you.

It's supposed to be a logical flow of information designed to
take you quickly to the part of the circuit you're interested in,
and to tell you what signals are involved in that portion of the
circuit, and where they come from, and go to.

Using canned parts leads to spaghetti wires.  =:-P

Start with something, even if you make it, but after the design
solidifies, go back and re-organize the signals so they make
sense, juggle the parts and sheets, it's amazing how much
nicer they are to read when you put a little effort into it.

1998\07\09@040334 by Frank Tamminga

flavicon
face
Barry Baldwin wrote:

> Hi,
>
> I was wondering if anybody knows where I can get an Orcad
> library file for the PIC parts?  Specifically the PIC 16C74.


Hi Barry,

Why don't you edit it yourselves (witch is very easy with the libedit
function). You can make the lib to suit your project. (pins at the right
places etc.)

Frank    (p.f.tammingaspamKILLspamhgt.nl)

1998\07\09@054103 by Peter L. Peres

picon face
On Wed, 8 Jul 1998, David VanHorn wrote:

> >Making the Schematic Library part is only a 5 minute job,
> >and has the benefit of letting you arrange the
> >pins.  For example all the inputs on the left
> >and the outputs on the right often makes the
> >most understandable schematic.

Yes.

> For anything larger than simple gates, I always libedit my own.
> The thing is, a schematic (unlike most you've seen) isn't just a
> rats nest of wires designed to confuse the hell out of you.
>
> It's supposed to be a logical flow of information designed to
> take you quickly to the part of the circuit you're interested in,
> and to tell you what signals are involved in that portion of the
> circuit, and where they come from, and go to.

I *stronly* prefer the kind of schematic that matches the layout or at
least physical pin-out. It makes troubleshooting on the physical thing
much faster. For this, I have to redo the libraries for most gates in
Orcad for example.

In fact, I think that the logical functionality of a unit should emerge
from a block diagram, not from the schematic. That one is for other
purposes (such as manufacturing and troubleshooting).

Peter

1998\07\09@072543 by Caisson

flavicon
face
> Van: Barry Baldwin <.....bbaldwinKILLspamspam.....INDYME.COM>
> Aan: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Orcad Library
> Datum: woensdag 8 juli 1998 19:28
>
> Hi,
>
> I was wondering if anybody knows where I can get an Orcad
> library file for the PIC parts?  Specifically the PIC 16C74.

AFAIK you can draw your own symbols and stuff them into a library.
(My 'home' layout stuff is Orcad & Layo.  On my work I have to wrestle with
Ulti-Cap / Ulti-Board)

Greetz,
 Rudy Wieser

1998\07\09@125115 by David VanHorn

flavicon
face
>> >Making the Schematic Library part is only a 5 minute job,
>> >and has the benefit of letting you arrange the
>> >pins.  For example all the inputs on the left
>> >and the outputs on the right often makes the
>> >most understandable schematic.
>
>Yes.


In simple systems I'd agree with you, but strictly adhering to
that rule will make a mess in larger systems.


{Quote hidden}

IMHO, this results in a mess, since the mfgrs aren't usually kind enough
to put the pins for a given section of the chip in the same place.
Power pins are on opposite sides or ends, which would mean that
the bypass cap has to leap across many other signals, giving the
impression that lead length isn't important. (!)

I move power and ground together, such that the CAP NP just fits,
and then the schematic strongly suggests that this is a critical connection.

The osc pins move near the ground pin(s) for the same reason.

Everything else is grouped by function, so that I have, at a glance, every
signal needed for a given function called out.

If my repair techs can't remember how to count pins, then they need to
find a new job.  I also include dupes of the datasheets on anything that
has more than two legs, so they really have all the info that's needed.

What I'm after is to quickly convey to them, if a given section of the
product isn't working, what signals does that section need to function,
and what signals (if any) does it need to produce.  Once they've got
that info, they find what's missing, and then the sub-sheets detail where
any given signal comes from.

Schematics aren't terribly useful in pulling out manufacturing defects
anyway, since you can get shorts between entirely unrelated sections
of the board simply because the two tracks routed through the same
area.

>In fact, I think that the logical functionality of a unit should emerge
>from a block diagram, not from the schematic. That one is for other
>purposes (such as manufacturing and troubleshooting).


The top level sheet of all my schematics is a block diagram, but I want
to carry that concept all the way through. There's a lot more information
to be conveyed than "This hooks up to that".

Doing it the other way leaves you with these big bricks that have no clear
relationship with each other, and it's not obvious where a signal goes, once
it leaves chip A..

1998\07\10@115912 by Peter L. Peres

picon face
On Thu, 9 Jul 1998, David VanHorn wrote:

> >> >Making the Schematic Library part is only a 5 minute job,
> >> >and has the benefit of letting you arrange the
> >> >pins.  For example all the inputs on the left
> >> >and the outputs on the right often makes the
> >> >most understandable schematic.
> >
> >Yes.
>
> In simple systems I'd agree with you, but strictly adhering to
> that rule will make a mess in larger systems.

My normal job is camcorder and professional video equipment repair, which
is ALL of it component level SMD troubleshooting and repair in, well,
large systems packed very tightly ;) (shall I say folded ?). I've been at
this for nearly seven years now, and I'm supposed to be the foreman here.

In the process I have seen service manuals and manufacturing manuals from
major Japanses and other manufacturers, more of them than I care to
remember (not just camcorders, also professional video equipment, mixers,
TBCs, Betacams, the works)  and I have to say that in my mind they are
clearly classified.

#1 There are one-color 'spaghetti' diagrams, with block diagrams that
indicate functional blocks one by one (3 dozen of them), in the manner
some here like: each module with inputs from left and outputs to the
right. Now, these are the worst. By the time you nail down the sub-unit
that is suspect in the block diagram, and do the analysis on the
functional diagrams, and reach the detailed spaghetti (pardon, schematic),
to poke a probe at the signal, you feel like you have read the phone-book
backwards 3 times. imho, the only place where these should be, is in
schools, for teaching, where they get the message through better by
removing the complexity. Maybe also in new product/technology
presentation/courses.

#2 And, there are 2-color (red+black, sometimes also blue and green)
detailed schematic diagrams with a clear block diagram, with the
schematics drawn to match the pin-outs of the chips as seen on the board,
and with major signals neatly bussed and with essential signal flows
outlined in the 2nd color over the black wire trace, in dashed or dotted
lines. These are a pleasure to work with, and you get the job done with an
average of only three lookups: open the block diagram to locate a module,
open the module schematic, and that's it, just poke a probe at it. I
regard it as significant, that these manuals are 'working' manuals and are
accompanied by 'instruction manuals' which have schematics drawn as under
#1 (small functional blocks). The instruction manuals are not normally
used, except for instruction ;).

Nearly all the technicians I've had to do with on this clearly prefer the
#2 kind of manuals and many a time get lost in the #1 type, sometimes with
disastrous results (you can only make this many mistakes in a SMD unit
that is not terribly over-engineered). I consider this significant.

Engineers on the other hand, read the instruction manuals first, from
cover to cover, then use (and prefer) the #2 type manuals throughout, but
the #1 type instruction manual reading gives them all the understanding of
the unit that the technicians don't really care about ;) So, there, I've
said it all.

> IMHO, this results in a mess, since the mfgrs aren't usually kind enough
> to put the pins for a given section of the chip in the same place.
> Power pins are on opposite sides or ends, which would mean that
> the bypass cap has to leap across many other signals, giving the
> impression that lead length isn't important. (!)

Nobody really, really, cares about sections when doing a troubleshooting
check-out following a table of measured voltages ordered by pins on a
100-pin SQFP, when the pins in the schematic are ordered 'functionally'.
Having the pins drawn in numerical order will remove one step from the
work (the lookup of the wire in the schematic). With 100 pins and maybe 25
significant signals to check out, this is 25 lookups less, and that can be
from 5 minutes to 1/2 hour of work time, depending on instrument settings
etc. This means dollars, not cents.

In my projects I always have my drawings for functional/design and
another drawing of the same schematic for the booklet, manufacture, and
troubleshooting. Of course I do not withhold the functional-ordered
drawing.

> If my repair techs can't remember how to count pins, then they need to
> find a new job.  I also include dupes of the datasheets on anything that
> has more than two legs, so they really have all the info that's needed.

Paying people for pin-counting is not so good imho. Of course they have to
know how to do that, but that should not be a mainstream paid occupation
at the workplace imho. Especially since I've been there.

I agree about the data sheets, or at least internal block diagrams. They
are very helpful. #2 type manuals always include them.

> Schematics aren't terribly useful in pulling out manufacturing defects
> anyway, since you can get shorts between entirely unrelated sections
> of the board simply because the two tracks routed through the same
> area.

Correct, it's just a matter of lookup speed. Anyway, when I spot a solder
bridge or corrosion spot between 2 pins in a chip, I want to be able to
look at a schematic that immediately shows me the wires from those pins,
to give me a clear idea of what else has been smoked or fried. The #2 type
schematic will do that for me, the #1 is better when an engineer is doing
some design modifications to the system.

> >In fact, I think that the logical functionality of a unit should emerge
> >from a block diagram, not from the schematic. That one is for other
> >purposes (such as manufacturing and troubleshooting).
>
> The top level sheet of all my schematics is a block diagram, but I want
> to carry that concept all the way through. There's a lot more information
> to be conveyed than "This hooks up to that".

The question is, does the Joe who pokes scopes into it really care about
the functionality, and can you afford to teach him to understand it (or to
hire people who can do that already). And how long a time are you willing
to allot for his finding any troubles, if not.

> Doing it the other way leaves you with these big bricks that have no clear
> relationship with each other, and it's not obvious where a signal goes, once
> it leaves chip A..

Colored arrows printed on the significant (black) tracks help a lot...
they are a part of the #2 type diagrams... and one can always peek at the
block diagram when moving from edge connector to edge connector...

Peter

PS: For a check-out of a good example of a #2 type schematic, take a look
at a schematic of a Sony CCD-F or CCD-TR-V series service manual at the
next occasion.

1998\07\10@124914 by David VanHorn

flavicon
face
>> IMHO, this results in a mess, since the mfgrs aren't usually kind enough
>> to put the pins for a given section of the chip in the same place.
>> Power pins are on opposite sides or ends, which would mean that
>> the bypass cap has to leap across many other signals, giving the
>> impression that lead length isn't important. (!)
>
>Nobody really, really, cares about sections when doing a troubleshooting
>check-out following a table of measured voltages ordered by pins on a
>100-pin SQFP, when the pins in the schematic are ordered 'functionally'.
>Having the pins drawn in numerical order will remove one step from the
>work (the lookup of the wire in the schematic). With 100 pins and maybe 25
>significant signals to check out, this is 25 lookups less, and that can be
>from 5 minutes to 1/2 hour of work time, depending on instrument settings
>etc. This means dollars, not cents.


So if motor A dosen't spin, you're going to read every voltage on every
pin of all the chips and hope this points you at something that makes sense?

When I do a schematic, motor A is in a block with all the circuitry that is
required to drive it. If you check the input signals to that page, and they
are correct, then the fault WILL be on that page. No spaghetti.  At most,
you'll have maybe a dozen nodes to look at, and that presumes a fairly
complicated circuit.

IMHO, those measured voltage tables are about useless, since they don't
allow for dynamic conditions.  Anything on the schematic that can be counted
on to have a stable voltage is so labeled.

It is apparent though, that we are talking about radically different levels
of
complexity. My systems are small one or two board devices, with maybe
20 chips on a board.  For things like a VCR, I'd use a completely different
approach.

>> The top level sheet of all my schematics is a block diagram, but I want
>> to carry that concept all the way through. There's a lot more information
>> to be conveyed than "This hooks up to that".
>
>The question is, does the Joe who pokes scopes into it really care about
>the functionality, and can you afford to teach him to understand it (or to
>hire people who can do that already). And how long a time are you willing
>to allot for his finding any troubles, if not.


Can and do. I won't have people repairing products who do not understand
the circuitry. I don't ask them to be able to design it, but they should be
able
to tell me outputs of logic gates given known inputs, figure out current in
a
circuit from voltage readings, and identify possible problems from comparing
normal waveforms to abnormal waveforms.

We train where needed, and hire people who either are already there, or
seem trainable.  I've only had to dismiss one person in the last 7 years.
Our turnover rate has been nil.  Average repair time is about 10 mins,
though some get into many hours. (Some have taken ME days to diagnose.)
Nothing gets tossed without first understanding why it croaked.

I've even trained our accountant to repair our products. (he asked for it!)
:)

>Colored arrows printed on the significant (black) tracks help a lot...
>they are a part of the #2 type diagrams... and one can always peek at the
>block diagram when moving from edge connector to edge connector...


I do that on anything above simple gates or ram/rom chips, and always
where the pin is software assignable. I don't expect anyone to guess
wether an I/O pin is in, out, or tri-state.

>PS: For a check-out of a good example of a #2 type schematic, take a look
>at a schematic of a Sony CCD-F or CCD-TR-V series service manual at the
>next occasion.

I'll do that. I'm always willing to learn :)

1998\07\10@132404 by Roberto Marchini

flavicon
face
>I was wondering if anybody knows where I can get an Orcad
>library file for the PIC parts?  Specifically the PIC 16C74.
>Barry

Hi Barry,
I've got some libraries founds on WWW, there are for new and old ORCAD
version.
If you want, I send you.
Best regards

Roberto Marchini

PS send your answer to my work address: rmarchinispamspam_OUTfacet.it
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1998\07\10@154140 by Peter L. Peres

picon face
On Fri, 10 Jul 1998, David VanHorn wrote:

> So if motor A dosen't spin, you're going to read every voltage on every
> pin of all the chips and hope this points you at something that makes sense?

In systems of that complexity (camcorders for example), things are so
tightly entwined that you simply cannot separate functional blocks. We
have one hell of a lot of trouble with some of these, as, for example,
disconnecting the EVF in certain models, required to gain access with a
probe, removes the HD and VD pulses required by the OSD chip to display
setup data on screen, and additionally place the system timing in total
disarray (you get 'hiccuping' servos, disfunctional zoom and many other
goodies), by virtue of the designers using the VD signal from the EVF as
master clock 'tick' in the LAN. This is the kind of thing you spend a few
days on, after trying to repair something that isn't broken, and then
smack your head on the nearest wall when you understand what's up (by
accident) <G>. Needless to say, no service manual mentions the bomb, and
the extender cable recommended by the manufacturer for the EVF cord is too
expensive to purchase.

> When I do a schematic, motor A is in a block with all the circuitry that is
> required to drive it. If you check the input signals to that page, and they
> are correct, then the fault WILL be on that page. No spaghetti.  At most,
> you'll have maybe a dozen nodes to look at, and that presumes a fairly
> complicated circuit.

> IMHO, those measured voltage tables are about useless, since they don't
> allow for dynamic conditions.  Anything on the schematic that can be counted
> on to have a stable voltage is so labeled.

Good tables have a little star or dash instead of DC voltage at positions
where AC is present, or are supplemented by oscillograms as appropriate.

The tables are very useful, because they give a probing technician the
occasion to confirm his suspicion with regard to certain signals.

The DC voltages measured, even in a digital circuit, or analog with Ac
super-imposed, are fairly accurate for orientation, as even AC signals
cause repetitive waveforms in the circuits I have to do with, and thus
correspond to certain duty cycles, i.e. the DC measurement is meaningful.
If one is off by more than 5% then it's time to check deeper. (5% is 0.25
V at Vcc = 5V, and 0.15 V at Vcc = 3V).

> It is apparent though, that we are talking about radically different
> levels of complexity. My systems are small one or two board devices,
> with maybe 20 chips on a board.  For things like a VCR, I'd use a
> completely different approach.

I hope so. Every major firm that I know of (not that it means much) uses
the #2 type diagram, or else every technician I know curses their good
name quite freely on occasion... <G>

Note that for small designs and for training/engineering purposes, the
type #1 schematic is better. I agree on that. You seem to be using the
right approach for your type of activity. However, many a man learns the
#1 type drafting in school (where it should be used), goes into business,
grows, and stays with #1 type out of habitude when he should switch to #2
type drafting, as the people in his business get more specialized, and
engineering moves farther away from the troubleshooters. Apparently no-one
teaches these subtle small details in school...

{Quote hidden}

Asking even a good TV/VCR technician to understand all the circuits he is
asked to adjust and repair is asking for him to have at least a practical
engineer's degree. If he had one, he wouldn't be doing that. Plus, some
things advance so fast, that a graduate of a trade school from 2 years ago
is outdated today. I guess it's like the piano: if you don't play it every
weekend you forget it (I don't play the piano, but I'm told it's like
that).

> We train where needed, and hire people who either are already there, or
> seem trainable.  I've only had to dismiss one person in the last 7 years.
> Our turnover rate has been nil.  Average repair time is about 10 mins,
> though some get into many hours. (Some have taken ME days to diagnose.)
> Nothing gets tossed without first understanding why it croaked.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is most laudable. I know places where the engineering section is so
far away (not physically) from the plant that they just figure in the loss
percentage and smash the bad boards without further looking. Actually,
every major electronics consumer product factory seems to work like that.
In this case, it is the accountants <G> who decide.

> I've even trained our accountant to repair our products. (he asked for it!)
> :)

Uh. Whatever made hime do that ? Accountants make more money than
technicians here. If they fancy technology then they seem to bend more
towards software...

> >Colored arrows printed on the significant (black) tracks help a lot...
> >they are a part of the #2 type diagrams... and one can always peek at the
> >block diagram when moving from edge connector to edge connector...
>
> I do that on anything above simple gates or ram/rom chips, and always
> where the pin is software assignable. I don't expect anyone to guess
> wether an I/O pin is in, out, or tri-state.

OnT: I have an old DOS version of Orcad, and I have never gotten around to
make it print the arrows although I set them right when declaring pins.
Anyone know how to make them at least print ?

thx,

       Peter

1998\07\10@182030 by William Chops Westfield

face picon face
> Power pins are on opposite sides or ends, which would mean that
> the bypass cap has to leap across many other signals, giving the
> impression that lead length isn't important. (!)

FWIW, all the schematics done here (these are BIG boards, folks - LOTS
of pages, 300+ pin BGAs and fine pitch ASICs out the wazuu) have ALL the
bypass caps on a separate page (frequently several pages) at the end of
the (functionally group) pages showing more interesting stuff.  They're
hell to follow in a general sense - hopefully there are block diagrams
elsewhere...

BillW

1998\07\10@193408 by David VanHorn

flavicon
face
>> Nothing gets tossed without first understanding why it croaked.
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>That is most laudable. I know places where the engineering section is so
>far away (not physically) from the plant that they just figure in the loss
>percentage and smash the bad boards without further looking. Actually,
>every major electronics consumer product factory seems to work like that.
>In this case, it is the accountants <G> who decide.


In first production, I fix every board until I'm satisfied that it's stable
and
everything's going well. Once that's in place, then I turn it over to
repair.
That way I know EXACTLY what's going wrong, and why.  It's also SOP
for me to go over the returns with a microscope to check for dirt from the
assembly process, and anything the customers might have added.

I tracked one all the way back to a particular operator screening PCBs
in Taiwan, who wasn't wearing a hair net. 22 opens on one board!


>> I've even trained our accountant to repair our products. (he asked for
it!)
>> :)
>
>Uh. Whatever made hime do that ? Accountants make more money than
>technicians here. If they fancy technology then they seem to bend more
>towards software...


Personal growth? I donno.. :)  He does it kind of as a hobby. Who am I to
turn away a motivated student?


>OnT: I have an old DOS version of Orcad, and I have never gotten around to
>make it print the arrows although I set them right when declaring pins.
>Anyone know how to make them at least print ?


I put a text ">" on the pin.  I don't think it differentiates pins that way
as part of the
different pin types (in, out, I/O..)  Plus it's easier during the design
process to change
the little >s than to edit the part pins.

1998\07\10@195453 by David VanHorn

flavicon
face
>> Power pins are on opposite sides or ends, which would mean that
>> the bypass cap has to leap across many other signals, giving the
>> impression that lead length isn't important. (!)
>
>FWIW, all the schematics done here (these are BIG boards, folks - LOTS
>of pages, 300+ pin BGAs and fine pitch ASICs out the wazuu) have ALL the
>bypass caps on a separate page (frequently several pages) at the end of
>the (functionally group) pages showing more interesting stuff.  They're
>hell to follow in a general sense - hopefully there are block diagrams
>elsewhere...


I understand that on a huge schematic, but mine don't get that big, and I
really want that information conveyed that the power comes to the cap
FIRST, and then to the part. If they're on another sheet, then the
impression
is that they don't matter so much..

I try to make mine convey a lot of information without being a spaghetti
bowl.
My larger parts might go through 5 or 10 versions with different pin
positions
as the design evolves. In the end, you know exactly what's needed for a
given
section to function, and it's a fast process of elimination to find the
guilty part.

1998\07\13@112316 by er

flavicon
face
-----Original Message-----
From:   Peter L. Peres [SMTP:@spam@plpKILLspamspamACTCOM.CO.IL]
Sent:   Friday, July 10, 1998 9:28 AM
To:     KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Subject:        Re: Orcad Library

On Thu, 9 Jul 1998, David VanHorn wrote:

{Quote hidden}

My normal job is camcorder and professional video equipment repair, which
is ALL of it component level SMD troubleshooting and repair in, well,
large systems packed very tightly ;) (shall I say folded ?). I've been at
this for nearly seven years now, and I'm supposed to be the foreman here.
[snip]
--------------

As the originator of the "5 minute job" quotation, I stand by it, except
in the case of extremely large ASICs, such as found in late model
cameras.  I have spent several years modifying the Sony TR5500
camera to fit into little torpedos for the National Geographic Societies
"Critter Cam" series, and find Son'ys documentation first class.  I agree
with every observation you make on the subject.  But for typical PIC jobs,
with a max of 40 or 44 pins, and more simple in/out, it seems to me that
schematics could be made much more understandable by judiciously
grouping the pins in relevant manner according to functionality, with
regard to signal flow.  The case with schematics as complex as cameras
the task of so doing is overwhelming, and concession to pragmatism
wins out.

John Shreffler

1998\07\13@132247 by David VanHorn

flavicon
face
>As the originator of the "5 minute job" quotation, I stand by it, except
>in the case of extremely large ASICs, such as found in late model
>cameras.  I have spent several years modifying the Sony TR5500
>camera to fit into little torpedos for the National Geographic Societies
>"Critter Cam" series, and find Son'ys documentation first class.  I agree
>with every observation you make on the subject.  But for typical PIC jobs,
>with a max of 40 or 44 pins, and more simple in/out, it seems to me that
>schematics could be made much more understandable by judiciously
>grouping the pins in relevant manner according to functionality, with
>regard to signal flow.  The case with schematics as complex as cameras
>the task of so doing is overwhelming, and concession to pragmatism
>wins out.
>
>John Shreffler


That's the art of it.  Picking the right approach for the job at hand.
Once we realized the difference in scale between our environments, I
think we're pretty much in agreement.

My systems consist of small functional blocks, and so my schematics
reflect this.

1998\07\13@132838 by Peter L. Peres

picon face
On Mon, 13 Jul 1998, John Shreffler wrote:

> As the originator of the "5 minute job" quotation, I stand by it, except
> in the case of extremely large ASICs, such as found in late model
> cameras.  I have spent several years modifying the Sony TR5500
> camera to fit into little torpedos for the National Geographic Societies
> "Critter Cam" series, and find Son'ys documentation first class.  I agree
> with every observation you make on the subject.  But for typical PIC jobs,
> with a max of 40 or 44 pins, and more simple in/out, it seems to me that
> schematics could be made much more understandable by judiciously
> grouping the pins in relevant manner according to functionality, with
> regard to signal flow.  The case with schematics as complex as cameras
> the task of so doing is overwhelming, and concession to pragmatism
> wins out.
>
> John Shreffler

Again, I was NOT talking about 'understandable'. I was talking about
'usable' (as in production, layout re-design etc). I have learned long ago
not to try to re-design a layout of something complex before you draw the
whole mess on a single sheet in 'physical' style and spend some time
thinking hard.

For understandability, it has to be functional and rather cleanly laid
out.

Peter


'Orcad Library'
1999\07\15@201628 by Onil Germain
flavicon
face
Hello, I'm searching for the complete set of library of pic working with
OrCAD design tool.
Please, if some can tell me where I can find it, let's me know.
(I search in Orcad web and I don't find it)
Thank

1999\07\15@202039 by Antonio L Benci

flavicon
picon face
Which version of ORCAD ???

Onil Germain wrote:
>
> Hello, I'm searching for the complete set of library of pic working with
> OrCAD design tool.
> Please, if some can tell me where I can find it, let's me know.
> (I search in Orcad web and I don't find it)
> Thank

Nino.
--
******************************************************
* Antonio (Nino) Benci                               *
* Professional Officer / Electronic Services Manager *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL    - 61 3 9905 3649, FAX - 61 3 9905 3637      *
* Mobile - 0414 764 763 (private and ah only)        *
* EMAIL  - RemoveMEnino.benciTakeThisOuTspamsci.monash.edu.au (work)       *
*        - spamBeGonefleatechspamBeGonespamexcite.com (private)             *
* WWW    - http://www.physics.monash.edu.au/                *
******************************************************

1999\07\15@202451 by Onil Germain

flavicon
face
Hello Antonio,
The version I use are 7.2.170
Thank
Antonio L Benci wrote:

{Quote hidden}

1999\07\15@210810 by Antonio L Benci

flavicon
picon face
I've got a SDT source library of Microchip parts. Is this acceptable.

Onil Germain wrote:
>
> Hello Antonio,
> The version I use are 7.2.170
> Thank
> Antonio L Benci wrote:
>
> > Which version of ORCAD ???
> >

Nino.
--
******************************************************
* Antonio (Nino) Benci                               *
* Professional Officer / Electronic Services Manager *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL    - 61 3 9905 3649, FAX - 61 3 9905 3637      *
* Mobile - 0414 764 763 (private and ah only)        *
* EMAIL  - nino.benciEraseMEspam.....sci.monash.edu.au (work)       *
*        - EraseMEfleatechspamexcite.com (private)             *
* WWW    - http://www.physics.monash.edu.au/                *
******************************************************

1999\07\16@081914 by Dan Tye

flavicon
face
On a related note.... Does anyone know where I can get uchip 17CXX
libraries for ACCEL?

-----Original Message-----
From: Antonio L Benci [RemoveMENino.BenciEraseMEspamEraseMESCI.MONASH.EDU.AU]
Sent: Thursday, July 15, 1999 9:07 PM
To: RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU
Subject: Re: Orcad Library


I've got a SDT source library of Microchip parts. Is this acceptable.

Onil Germain wrote:
>
> Hello Antonio,
> The version I use are 7.2.170
> Thank
> Antonio L Benci wrote:
>
> > Which version of ORCAD ???
> >

Nino.
--
******************************************************
* Antonio (Nino) Benci                               *
* Professional Officer / Electronic Services Manager *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL    - 61 3 9905 3649, FAX - 61 3 9905 3637      *
* Mobile - 0414 764 763 (private and ah only)        *
* EMAIL  - RemoveMEnino.benciTakeThisOuTspamspamsci.monash.edu.au (work)       *
*        - EraseMEfleatechspamspamspamBeGoneexcite.com (private)             *
* WWW    - http://www.physics.monash.edu.au/                *
******************************************************

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...