Searching \ for '[PIC] 16F877 Pinout Question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=16F
Search entire site for: '16F877 Pinout Question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F877 Pinout Question'
2019\08\23@092539 by Martin McCormick

flavicon
face
       As I have the data sheet for the PIC16F877 in the form of
the file 30292c.pdf, I am starting out with the same raw material
everybody else is probably using.

       Just this part of the knowledge acquisition process used
to be a royal pain for anybody who is blind since you first had
to obtain the paper copy and find somebody with the patience to
read it to you.  If they knew something about electronics, this
was a boon as they weren't confused as to what they were
reading and everything went along more smoothly.

       When one got to the pinout, the practice was usually to
read that in to a tape recorder and then the person needing the
information could write it down in Braille.  It usually ends up
in columns starting with a pin number followed by enough text to
identify the purpose of that pin.

       Nowadays, if one is lucky, the data sheet or book is a
portable document format or pdf file that is not a scanned image
but a file containing the actual text formatted so that a printer
will produce the book with all the pictures in the right spots
and everybody gets what they need.

       In this case, Microchip has really done a great job and
seems to have done everything one would hope so that we can wring
every drop of information out of the file and nothing is wasted.

       I have a notebook full of Braille pages full of pinouts
to various chips I have wire-wrapped over the years in to
projects so the first thing I will do to use the PIC16F877 is to
write such a chart for the 40-pin DIP packages I have.

       When I got to the pinout which is Table 1-2, I realized
there is a problem.

       The software we all use for reading PDF files may differ.
Some may be using Adobe Acrobat and I use something called
pdftotext which extracts ASCII text in reading order which is
actually the desired format most of the time as it makes the most
sense.

       Table 1-2 might not be a problem if there was only 1
40-pin package but there are 3 footprint styles and only one is
the traditional DIP package which, if you look from the bottom is
1-20 with 1 in the upper right and 20, lower right.  Pin 21 is
lower left and you count up to 40 which is across the chip from
1.

       I need to know it that way with the other 40 and 44-pin
footprints being a couple of surface-mount patterns that one
absolutely does not want to get mixed up with what is the correct
pattern in this case.  I don't know a better smoke generator than
wrong pin numbers which are about as good as AC line voltage on
the VCC pin.

       When you look at a proper screen rendering of Table 1-2,
how do you know for sure which Pin belongs to which footprint? Is
it color or do all the 40 pins for the DIP package show up in a
pattern resembling the solder side of the board?

       These markup languages like XML, html or others embed
codes that dictate the position on the page for every drop of ink
plus what color it should be.

       One can run pdf files through various filters that
perform different functions.  If I knew what is done to
differentiate all the 40-pin DIP listings from the one remaining
40-pin pattern and a 44-pin footprint, I might be able to sort
this out more easily.

       This practice is common to most of the PIC data sheets so
I want to see if it can be mechanized so one gets only the
pattern they need without accidentally including wrong pinouts
from other patterns.

       For those who mess around with text processing, perl is
great for writing helper programs for situations like this as
long as you know what it is you are looking for.

       On a general note, when it comes to making information
accessible to all, we generally have many more tools these days
than used to exist so what I just described is not a complaint as
much as it is a hunt for ideas to fix the problem.  Not being
able to get the information at all used to be the norm and there
were lots of complaints about that so we definitely do have
progress.

Martin McCormick
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2019\08\23@155514 by Martin McCormick

flavicon
face
Well, folks.  I wimped out and bought a BlackBox DB25/RS-232
converter.  It should be at our front door, porch pirates not
withstanding, in a couple of weeks.  Fourty years ago, I
interfaced a speech synthesizer board with the Syntronix
interface for an Apple II computer.  It took me several weeks to
get it working correctly.  The speech board had a Busy line data
flow stopper and the Apple II printer card needed the ACK signal
which is a pulse of about 500 nanoseconds.  I ended up taking the
Busy line from the speech board and it's trailing edge fired a
74-121 pulse generator chip.  I seem to recall that you can make
it fire on either the leading edge or trailing edge by wiring a
couple of pins differently.

       I learned a bunch of things in that project back in 1979,
one of them is to be paranoid about good grounding.  Some of the
noise on the ground wire from the data lines going up and down
looked a lot like ACK pulses so the speech was a bit skippy and
cleaned up a lot when there were no extra pulses that looked like
ACK's.

       Hopefully, this converter will let me sample the output
of the parallel port well enough to do the BIOS setups when
needed.

       I figure the extra dough which was not a terrible outlay
buys time that would just get otherwise wasted and I can get on
with other things.

Martin
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2019\08\23@233216 by Christopher Head

flavicon
face
part 1 1079 bytes content-type:text/plain; charset="utf-8" (decoded base64)

On Fri, 23 Aug 2019 08:25:33 -0500
"Martin McCormick" <spam_OUTmartin.mTakeThisOuTspamsuddenlink.net> wrote:

>        When you look at a proper screen rendering of Table 1-2,
> how do you know for sure which Pin belongs to which footprint? Is
> it color or do all the 40 pins for the DIP package show up in a
> pattern resembling the solder side of the board?

Hi Martin,
I’m not at all familiar with most of your software, but I can certainly
answer this: table 1-2 has column headers for “pin name,” “DIP pin#,”
“PLCC pin#,” “QFP pin#,” “I/O/P Type,” “Buffer Type,” and
“Description.” Each pin is one row in the table. So if you’re using the
DIP package, you’d consider the numbers in the “DIP pin#” column (the
second column, right after the pin name). For example, the first row is
for OSC1/CLKIN, and the DIP pin# column has the number 13 in that row.
With the exception of some NC pins, all the pins are present on all the
packages, just in different places.

Hope this is helpful,
--
Christopher Head

part 2 197 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2019\08\24@004756 by James Cameron

flavicon
face
Martin McCormick wrote:
> When you look at a proper screen rendering of Table 1-2,
> how do you know for sure which Pin belongs to which footprint? Is
> it color or do all the 40 pins for the DIP package show up in a
> pattern resembling the solder side of the board?

It is not colour.

I agree with Christopher.  I also use a slightly different method to
find pins on this PDIP package; using the pin diagram on the first
page of the datasheet, top right.  Sometimes I cut it out and
enlarge.  It has a border.

I work down the either side of the pin diagram looking for the letters
of the pin name.  I learn the meaning of the arrows between the pin
name and the package.  I learn the localisation of the pin names; how
RB is mostly top right, how RC is embedded inside RD, how OSC is
usually mid-chip.

I'm using document DS30292A though, and haven't checked if DS30292C
has the same diagram, but I expect it does.

-- James Cameron
http://quozl.netrek.org/
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2019\08\25@225221 by Martin McCormick

flavicon
face

Christopher Head <.....cheadKILLspamspam@spam@chead.ca> writes:
> I’m not at all familiar with most of your software, but I can certainly
> answer this: table 1-2 has column headers for “pin name,” “DIP
> pin#,”
> “PLCC pin#,” “QFP pin#,” “I/O/P Type,” “Buffer Type,” and
> “Description.” Each pin is one row in the table. So if you’re using
> the
> DIP package, you’d consider the numbers in the “DIP pin#” column
> (the
> second column, right after the pin name). For example, the first row is
> for OSC1/CLKIN, and the DIP pin# column has the number 13 in that row.
> With the exception of some NC pins, all the pins are present on all the
> packages, just in different places.

James Cameron <quozlspamKILLspamlaptop.org> writes:
{Quote hidden}

       This is a great help as both of you confirmed that if I
can get the columns to display as they actually were meant to,
then the output will make sense.

       You might ask "Why don't I just run the PDF engine that
way?

       The answer is that it all depends on what kind of
information one is reading at any given time.  The text
describing what the various modules or subassemblies in the chip
do and what signal levels to expect to provide and or read is
best read as linear text, the way you'd read a news story or
instructions on how to do about anything in which one needs clear
prose written in logical order.

       The pdftotext manual has a passage saying:

      -layout
             Maintain (as best as possible) the original physical  layout  of
             the  text.   The  default is to ´undo' physical layout (columns,
             hyphenation, etc.) and output the text in reading order.

      -fixed number
             Assume fixed-pitch (or tabular) text, with the specified charac
             ter width (in points).  This forces physical layout mode.

      -raw   Keep the text in content stream order.  This is a hack which of
             ten "undoes" column formatting, etc.  Use  of  raw  mode  is  no
             longer recommended.

      -htmlmeta
             Generate  a  simple  HTML  file, including the meta information.
             This simply wraps the text in <pre> and </pre> and prepends  the
             meta headers.

      -bbox  Generate  an  XHTML file containing bounding box information for
             each word in the file.

      -bbox-layout
             Generate an XHTML file containing bounding box  information  for
             each block, line, and word in the file.
end of quote

       Now that I know that color or type style is not used, I
should be able to experiment with some of those flags and
virtually cut out which table to use.

       Other Microchip data sheets appear to use similar display
styles so maybe I can come up with a mechanical filter that can
be trusted.:-)

       Thanks again as this is probably more useful to know than
just getting the pinout  for a given IC.

Martin   WB5AGZ

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

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