Why don't more manufacturers provide their device pinouts (pin numbers
and names) as a spreadsheet or text file? It would make part creation
for PCB design packages *much* easier. Sometimes the data can be
extracted from the PDF file without too much trouble and then imported
directly into the PCB software, but in many cases this can't be done
because of the way the document is formatted. It's a real pain typing in
stuff like RA5/AN4/LVDIN over and over again for devices with 80 pins or
more.

Xilinx provides this info. for many of their newer chips; if enough
people complained to the other purveyors of silicon they might get the
message.

I've long had a similar complaint, except on the software side. The first
thing I (and most programmers) do when writing a driver is write a header
file that symbolically defines devices' register addresses and mask and
such. Imagine the resulting number of man-hours in duplicated effort.
Wouldn't it be a competative advantage for the chip manufacturers to
provide this information?

--
========================================================================
Michael Kesti | "And like, one and one don't make

Why? Are you two dim to click on "support" yourself? I
downloaded headers and example source for all the projects I've
done in the past 5-7 years. The last few were Samsung
ARM-based uCs and the Hitachi H8 series. Here's the link for
the Hitachi part I'm using now:

Maybe they should imbed the warnings into the flash on all of their
chips just to make sure the bad guys are adequately informed. Of course
this is something the lawyers thought up. The point is that it is*worthless*. Just because you provide support for your chips does not
make you liable for the illegal use of the information by others. Even
if you were somehow liable, posting a lame notice on a website will not
relieve your liability.

A very down-the-rabbit-hole approach, though. "We release this product
only to people who promise not to do bad things(*). If you do a bad
thing, we retroactively withdraw our offer of this code to you, and
therefore legally you never obtained it from us in the first place".

* The text originally quoted doesn't really specify do bad things WITH
THE RENESAS CODE. It basically says you're not allowed to download the
code if you're evil.

How are we supposed to know what chip he wants info for? He
was already told that most vendors supply header files. If he
wants one for a specific chip he's going to have to either go
looking for it or specify which one he wants. Instead of
either of those, he simply challenges the answer he's already
been given. Sorry if I was rude, but I thought his demand for
proof of the answer given was rude.

Did your doctor tell you to cut down on the caffeine? I'm not trying to
tick you off, but I think you are overreacting a bit. His request was
just to show him where you saw what you saw, it was not a chalenge or in
any way an indication that he doubted you. He just wanted to see for
himself.

I remember once when I was on vacation in Paris. I was in a little shop
that had handmade pens for sale. I was told that the refills were the
same as some other pen that I already had. Not that I doubted anyone,
but I wanted to see for myself and unscrewed the pen. When I exclaimed,
"Well it *is* the same", I was told that I was insulting her by
looking. I think she actually made some comment about rude Americans.
I didn't intend any rudeness, I just wanted to satisfy my curiosity.

In the same way, Michael did not mean any rudeness as far as I can
tell. He simply asked so he could see an example himself.

Besides just "wanting to see", an example can give someone information
on how to go about finding the information for himself. In this case,
using an example, he could probably determine how to find the info from
the vendor's web site, which would likely be helpful for finding similar
information for other parts.

I've used the AVR Studio (assembler/simulator/debugger) that's
freely downloadable from atmel.com. It comes with include files - the
one I've used is for the AT90S1200, but like most every such file I've
received for any microprocessor, I've modified it and added to it.

BTW, such files come with the assembler/compiler rather than just
"from the manufacturer" as, especially with assemblers, the file needs
to be written to fit the assembler's syntax and definitions. Thus it
wouldn't be quite as useful for a manufacturer to have a 'generic'
header file.
So, Michael, your complaint (or my complaint that such files are
inadequate) is with the tool suppliers rather than the manufacturers.

The original 1200 header file is 3k bytes, mine is 6k bytes. Here
are some snippets (FWIW, I see no copyright statement in the header
file):

The origial 1200def.inc:

;***** I/O Register Definitions

...

.equ MCUCR =$35
.equ TCCR0 =$33
.equ TCNT0 =$32

...

;***** Bit Definitions

...

.equ CS02 =2
.equ CS01 =1
.equ CS00 =0

.equ WDE =3
.equ WDP2 =2
.equ WDP1 =1
.equ WDP0 =0

.equ EEWE =1
.equ EERE =0

...

Here are three registers defined, and then some bits defined, I
know the four definitions starting with WDE are for the TCCRO
register, and EEWE and EERE I happen to remember are control bits for
the EE memory control register (not listed in the three register
definitions I quoted). So this thing has register definitions and bit
definitions, but you can't be sure which is for which without going to
the AT90S1200 user manual/PDF file.

I've put the bit definitions (as bitmaps for load-immediate and
logical instructions, but in some places also as bit numbers for bit
set and clear instructions) right under the register definitions, and
the bit definitions start with the register mnemonic. I also use
'macro' definitions so they reflect the FUNCTION done (such as setting
a prescale divider to a certain value), not just the name of some bit
position.
This takes going through the processor/controller manual and system
bitmap at the start, but it keeps me from having to go back to the
manual to answer silly questions.

So back to the original complaint:

So at least one manufacturer provides this, and I recall similar
files from several others that do give register and bit definitions,
but I've found the quality and usefulness of such files to be
questionable. Such a file (and the manual) does make a good starting
point.

I fully agree. One solution I have found is to use a OCR program to
get the text from the PDF document. Most OCR programs can read a PDF
file directly. It is converted to a image and then OCRd as any scanned
image. Then at least you get the data as formatted on the page
regardless of the internal PDF format. I have found FineReader OCR the
best OCR package on Windows.

I am happy when vendors make the PDF files text copyable. Some have it
locked out so you can't even select text in the document which I often
do for searches. Otherwise I find that I can often copy text to a file
with the clipboard. I often do this for tables (when they let me).