Pinout data grumble

Yeh, it didn't work on flight sim did it?

On 2004-01-19, Ralph Malph <noone@yahoo.com> wrote:
> Grant Edwards wrote:
>> 
>> In article <400B16B7.298B8105@gv.net>, Michael R. Kesti wrote:
>> > CBarn24050 wrote:
>> >
>> >>most chip makers do
>> >
>>> Can you provide any examples, especially of such information
>>> that is freely downloadable via the Internet?
>> 
>> Why?  Are you two dim to click on "support" yourself?  
>
> Is there a reason that you feel the need to be rude?  Clearly
> this guy has not seen any such info and asked a ligit
> question.  If you don't like the question, then don't answer.

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.

-- 
Grant Edwards                   grante             Yow!  I know things about
                                  at               TROY DONAHUE that can't
                               visi.com            even be PRINTED!!

CBarn24050 wrote:
> 
> Yeh, it didn't work on flight sim did it?

What didn't work?

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In comp.arch.embedded, "Michael R. Kesti" <mkesti@gv.net> wrote:

>CBarn24050 wrote:
>
>>most chip makers do
>
>Can you provide any examples, especially of such information that is
>freely downloadable via the Internet?

   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.


   A snippet of my header file:

.equ	D0	=1
.equ	D1	=2
.equ	D2	=4
.equ	D3	=8

.equ	D4	=16
.equ	D5	=32
.equ	D6	=64
.equ	D7	=128

.equ	B_D0	=0
.equ	B_D1	=1
.equ	B_D2	=2
.equ	B_D3	=3

.equ	B_D4	=4
.equ	B_D5	=5
.equ	B_D6	=6
.equ	B_D7	=7

...

;***** I/O Register Definitions

.equ	MCUCR	=$35
.equ	MCUCR_SE	=D5	;Sleep Enable
.equ	MCUCR_SM	=D4	;Sleep Mode
.equ	MCUCR_LEVEL_LOW	=0		;INT0 level low generates int
.equ	MCUCR_FALL_EDGE	=D2		;falling edge of INT0
generates int
.equ	MCUCR_RISE_EDGE	=D2+D1	;falling edge of INT0 generates int

;***** Timer/Counter

.equ	TCCR0		=$33
.equ	TCCR0_STOP	=0
.equ	TCCR0_CK	=D0
.equ	TCCR0_CK8	=D1	;clock / 8
.equ	TCCR0_CK64	=D1+D0
.equ	TCCR0_CK256	=D2
.equ	TCCR0_CK1024	=D2+D0
.equ	TCCR0_EXT_RISE	=D2+D1
.equ	TCCR0_EXT_FALL	=D2+D1+D0

.equ	TCNT0	=$32		;the actual timer/counter register

;***** Watchdog Timer

.equ	WDTCR	=$21		;Watchdog Timer Control Register
.equ	WDTCR_WDE	=D3	;Watchdog Enable

.equ	WDTCR_16k	=0	;Watchdog timer prescale select
				;16k cycles=15mS at 5V, 47mS at 3V
.equ	WDTCR_32k	=D0
.equ	WDTCR_64k	=D1
.equ	WDTCR_128k	=D1+D0
.equ	WDTCR_256k	=D2
.equ	WDTCR_512k	=D2+D0
.equ	WDTCR_1024k	=D2+D1
.equ	WDTCR_2048k	=D2+D1+D0

   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:

>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?

   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.

-----
http://mindspring.com/~benbradley

> It's not supposed to.  I imagine it's there so that Renesas can disclaim any
> responsibility if some bad guy *does* use the data in a bad way.

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.

On Sun, 18 Jan 2004 19:58:39 +0000, Leon Heller <aqzf13@dsl.pipex.com>
wrote:

>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 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.

Regards
   Anton Erasmus

Grant Edwards wrote:
> 
> On 2004-01-19, Ralph Malph <noone@yahoo.com> wrote:
> > Grant Edwards wrote:
> >>
> >> In article <400B16B7.298B8105@gv.net>, Michael R. Kesti wrote:
> >> > CBarn24050 wrote:
> >> >
> >> >>most chip makers do
> >> >
> >>> Can you provide any examples, especially of such information
> >>> that is freely downloadable via the Internet?
> >>
> >> Why?  Are you two dim to click on "support" yourself?
> >
> > Is there a reason that you feel the need to be rude?  Clearly
> > this guy has not seen any such info and asked a ligit
> > question.  If you don't like the question, then don't answer.
> 
> 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.

Anton Erasmus wrote:
> 
> On Sun, 18 Jan 2004 19:58:39 +0000, Leon Heller <aqzf13@dsl.pipex.com>
> wrote:
> 
> >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 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).

Ralph Malph wrote:
> 
> Grant Edwards wrote:
> >
> > On 2004-01-19, Ralph Malph <noone@yahoo.com> wrote:
> > > Grant Edwards wrote:
> > >>
> > >> In article <400B16B7.298B8105@gv.net>, Michael R. Kesti wrote:
> > >> > CBarn24050 wrote:
> > >> >
> > >> >>most chip makers do
> > >> >
> > >>> Can you provide any examples, especially of such information
> > >>> that is freely downloadable via the Internet?
> > >>
> > >> Why?  Are you two dim to click on "support" yourself?
> > >
> > > Is there a reason that you feel the need to be rude? 
>>
> > How are we supposed to know what chip he wants info for?  He
> > was already told that most vendors supply header files.
> > [...]  Sorry if I was rude, but I thought his demand for
> > proof of the answer given was rude.
> 
> 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.

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.

Thad