I need pinouts of a couple hundred chips, without spending weeks trawling through datasheets. Any ideas?

[Anobium]

I need pinouts of a couple hundred chips, without spending weeks trawling through datasheets. Any ideas?

Where would you pull this data from?

[Peter]

I'd grab it from the xml files that MCC (and PPS tool) use

[Anobium]

PPS (XML) is a subset of the PICs.

:-(

I need the complete range.

[Chris Roper]

What Chips?

The PIC DIP devices have 6 in total of which only 4 are still in production divided across the entire range. Add in the SMP packages and it is about 12 in total.

If you are not referring to PIC Devices then we need more info to go on.

[Anobium]

@Chirs. Not sure what #6 refers to .

I am looking for PIC pinouts across the whole range.

[Chris Roper]

It means that for each package type 100's of devices have the same pin out.
Are you looking for PAD layout and dimensions.
Or the PIN Names or Peripheral Assignments?

All 8 Pin DIP MCU Packages are:
1,VDD
2,RA5
3,RA4
4,MCLR/VPP/RA3
5,RA2
6,RA1/ICSPCLK
7,RA0/ICSPDAT
8,VSS

All 20 Pin MCU Packages are:
1,VDD
2,RA5
3,RA4
4,MCLR/VPP/RA3
5,RC5
6,RC4
7,RC3
8,RC2
9,RC1
10,RC0
11,RA2
12,RA1
13,RA0
14,VSS
Those two alone cover 10’s if not 1000’s of devices.

The SOIC, MSOP and UDFN Package types follow the above pin outs too, I have not looked at other package types though.

But if that is not what you are looking for can you clarify the Ask?

edit: Duplicate paste error

[kent_twt4]

Not sure about Pics's but for AVR it would be in the xml style ATDF files. In short psuedo code style:

1. Extract package, pinposition, pads from ./pinouts/pinout, initialize and save in buffer/list for printout later
2. Extract pad usage name/signal group (e.g. m328p "TXD" for pad "PD1" from .signals/signal and add to pad buffer/list by iterating over .peripherals/module/instance/signals/signal. Assign (I/O), (I), (O) as required?
3. Printout package, pinposition. and pad data.

[Anobium]

8bit PIC initially then all PIC architectures.

Cheers Kent.

[kent_twt4]

Here is item 1 for m328p from my code. Further development pad functions.

[Pins-TQFP32]
1,PD3(I/O)
2,PD4(I/O)
3,GND
4,VCC
5,GND
6,VCC
7,PB6(I/O)
8,PB7(I/O)
9,PD5(I/O)
10,PD6(I/O)
11,PD7(I/O)
12,PB0(I/O)
13,PB1(I/O)
14,PB2(I/O)
15,PB3(I/O)
16,PB4(I/O)
17,PB5(I/O)
18,AVCC
19,ADC6(I/O)
20,AREF
21,GND
22,ADC7(I/O)
23,PC0(I/O)
24,PC1(I/O)
25,PC2(I/O)
26,PC3(I/O)
27,PC4(I/O)
28,PC5(I/O)
29,PC6(I/O)
30,PD0(I/O)
31,PD1(I/O)
32,PD2(I/O)

[Pins-QFN32]
1,PD3(I/O)
2,PD4(I/O)
3,GND
4,VCC
5,GND
6,VCC
7,PB6(I/O)
8,PB7(I/O)
9,PD5(I/O)
10,PD6(I/O)
11,PD7(I/O)
12,PB0(I/O)
13,PB1(I/O)
14,PB2(I/O)
15,PB3(I/O)
16,PB4(I/O)
17,PB5(I/O)
18,AVCC
19,ADC6(I/O)
20,AREF
21,GND
22,ADC7(I/O)
23,PC0(I/O)
24,PC1(I/O)
25,PC2(I/O)
26,PC3(I/O)
27,PC4(I/O)
28,PC5(I/O)
29,PC6(I/O)
30,PD0(I/O)
31,PD1(I/O)
32,PD2(I/O)

[Pins-QFN28]
1,PD3(I/O)
2,PD4(I/O)
3,VCC
4,GND
5,PB6(I/O)
6,PB7(I/O)
7,PD5(I/O)
8,PD6(I/O)
9,PD7(I/O)
10,PB0(I/O)
11,PB1(I/O)
12,PB2(I/O)
13,PB3(I/O)
14,PB4(I/O)
15,PB5(I/O)
16,AVCC
17,AREF
18,GND
19,PC0(I/O)
20,PC1(I/O)
21,PC2(I/O)
22,PC3(I/O)
23,PC4(I/O)
24,PC5(I/O)
25,PC6(I/O)
26,PD0(I/O)
27,PD1(I/O)
28,PD2(I/O)

[Pins-PDIP28]
1,PC6(I/O)
2,PD0(I/O)
3,PD1(I/O)
4,PD2(I/O)
5,PD3(I/O)
6,PD4(I/O)
7,VCC
8,GND
9,PB6(I/O)
10,PB7(I/O)
11,PD5(I/O)
12,PD6(I/O)
13,PD7(I/O)
14,PB0(I/O)
15,PB1(I/O)
16,PB2(I/O)
17,PB3(I/O)
18,PB4(I/O)
19,PB5(I/O)
20,AVCC
21,AREF
22,GND
23,PC0(I/O)
24,PC1(I/O)
25,PC2(I/O)
26,PC3(I/O)
27,PC4(I/O)
28,PC5(I/O)

[Anobium]

@Chris. While this is usually true, it is not always true. The 16f145x being a real case.

I would still need to check every datasheet by hand to see if it matches the rule. And, this would take too much time.

What I need is some kind of data dump of all the chips with their pinouts, like you find illustrated near the top of datasheets, except as data rather than an image

[Chris Roper]

Well to the best of my knowledge the 16f145x is the only case as it is the only PIC16 device with USB support. It was a one off covering 2 devices, 1 x 20 pin and 1x 14 pin and has not been repeated in a decade.

Personally I would accept it as an anomaly and follow the common rule ignoring the one exception in over 1000 parts. But as you have not stated the use case we can only make suggestions, the risk assessment depends on the final project and so is your decision.

Have you asked Microchip?

[kent_twt4]

Progress for AVR, specifically for the m328p family. This is formatting gymnastics (Hell?). Let me know if on right path.

[kent_twt4]

More AVR prototypes, including ATtiny85 and ATtiny1617.

If anyone bothers looking; Microchip is still putting out a bogus datasheet. If you see a 1616/1617 sheet, run, it shows pin22 or what should be PC5 not connected. Instead opt for the 1616/3216 or 1617/3217 datasheets instead.

[Anobium]

Making some progress but many parts are missing.

Key information show below is missing.

VDD "GND
 VSS"   "MCLR
 VPP"   "ICSPDAT
 DAT
 PGD"   "ICSPCLK
 CLK
 PGC"

Where can I source this data? You?

The URL has direct access to the file. Look in the VDD to PGC columns - lots of data missing.

https://docs.google.com/spreadsheets/d/1jitADCFupsRZs0kqjevWsUQf6FDz2QhPiQ0LFpu267I/edit?usp=sharing

Please, please help.

[Peter]

I have added a few in red.
I've sent you an email with a tool which will help for some of them.

[Anobium]

Thank you. I get on the job to extract the data.

[kent_twt4]

On with the megas, and a prototype that looks good with the mega1609 at least? Lots more work to do, especially when I have to start using best guess on device's with no package/pin info.

Too much info for IDE pins?