DD-series pinout images

[SpenceKonde]

Note the crap I added to the the existing diagrams. While the 28 and 32 pin ones are essentiallly the same as the DB only without OPAMPS, with only one ZCD and AC, analog onalmost every pin, and way morepin mapping options for USART0 and SPI1. The markings around pins 0-5 of each port are there to deliniate the groups of pins that can have PWM that port is selected. I

Need to think about how to represent the TCD pin groups best, since they will get the same sort of behavior (where if the portmux is set, analogWrite recognizes it andwill use it), since the DD is almost guaranteed to have that bug fixed. (and that will need to end up on te other diagrams if the fix is ever backported.

[SpenceKonde]

This is a priority, new version of core is shipping this week to catch the first DD's that people have in their hands.

If the charts are not ready, we will ship without a chart and nobody will know what's on which pin.

[SpenceKonde]

I will also be shipping 32DD14's on breakout boards as soon as I get the parts,. which are supposed to ship today. via fedex and arrive by end of week

[SpenceKonde]

64dd28 devices will be going on sale shortly.... Still haven't gotten the small pincount parts.

[SpenceKonde]

We're ah, gonna need some pinout images here.

[SpenceKonde]

28 and 32 are copies of the DB only with more USART0, USART1. SPI0 and the TCD portmux. The 14 and 20 pin versions can be made by taking a 28-pin version and deleting PC0, PD1-3. and PF0-1 and the Vdd/Avdd pair to get the 20 pin version and PA2-PA7 in addition to that for the 14-pin ones

Core defaults:
14 pin: TCA0 PWM on PC1-PC3 (other options being PA0-1. and PD4-5) TCD on PD4, PD5 no TCB PWM.
20 pin: TCA PWM on PA0-5. TCD PWM on PA4.PA5, PD4, PD5. (other options are TCA PWM on PC1-PC3, or PD4, PD5) (TCB PWM on PA2,.3 if user has changed portmux)
28-pin: TCA PWM on PD1-5, TCD PWM on PA4-PA7 (other options are TCA PWM on PC1-PC3 PA0-5 TCD on PF0-1.
32-pin: TCA PWM on PD1-5, TCD PWM on PF0-PF3 (other options are TCA PWM on PC1-PC3 PA0-5 PF0-5 and TCD on PD4, PD5 or PA4/PA5, PD4/PD5. TCB PWM on PF4/5 (TCB2 PWM can come out of PC0 on 28/32, but I'm strongly encouraging people to0 use that timer for millis.

HF or 32k xtal on PA0/1 for pins < 28, else 32kHz xtal pins on PF0/F1, HF XTAL remains on PA0/1

and while we only have 1 AC, it has like a million pins.

Whoever takes up this challenge should take a look at the DA/DB diagrams which I added all TCA mux options to. This needs to be done for TCA0 and TCD0 because both of those now support runtime switching of PWM output pins on the basis of PORTMUX and unless I get a very unpleasant surprise, I believe the TCD portmux works now! (now, c'mon microchip, backport to DA/DB? plx)

Oh, and on DA, DD, and DB (respectively, in datasheet, datasheet, datasheet clarification) that TCB singleshot mode (incredibly useful mode), the edge bit =0 starts on positive edge, while EDGE = 1.

ADC start s where PD0 would be, running to end of PD then on on parts with PORTF, up to PF0-PF5 have ADC, then it wraps around and PA2-7 have it. The 3 or 4 PC pins have it if and only if MVIO is disabled.

USART0 and SPI0 have like a million mux options, and USART1 has gained an extra one. and TWI 0 got one gained an extra one.

I'm working on Azduino5 toolchain with ATPACK updates. Unfortunately they renamed a shitton of _bp and _bm macros. My band-aid for it, and I am going to have it emit warnings if the old names are used to push people to update, since this seem to be getting applied to every it runs to 4000 lines (obviously automatically generated) Azduino5 has all the non-xmega ATpacks. in all their latest versions (ATAutomotive, ATmega, ATtiny, Dx, Ex. Oh, and they renamed RTC_CLKSEL _XOSC to RTC_CLKSEL_XTAL

Need to do the same bullshit over on megaTinyCore to deal with all the renaming (I pull the diff from the most compresnice

@MCUdude Probably of interest to you.

[SpenceKonde]

No word on availability of pinout diagrams, so 1.5.0 will probably be released without the pinout charts. This sucks, but I lack the graphics skills

[MCUdude]

I may be able to take a look at this by the end of the summer

[ObviousInRetrospect]

I dislike these being things that are created by hand in a graphics editor. I did a very rough draft of a diagram for the AVRxxDD14 using GenPinoutSVG.py. I extracted the pinmux table from the datasheet and tried hard to just import it mostly as-is.

The big empty text box is for whatever verbiage you want for the chips.

If you like the concept, I might go ahead and write something that merges a csv pinmux table with the variant's pins_arduino.h (to get the digital PIN numbers and the swap indices) and produces a version of this automagically.

Warning, engineer done art, engineer chosen color scheme. Happy to insert the colors of your choice from: https://upload.wikimedia.org/wikipedia/commons/2/2b/SVG_Recognized_color_keyword_names.svg into this line:

LABELS,DEFAULT,TYPE,GROUP,Name,Special,ADC0,AC0,DAC0,ZCD3,USARTn,SPI0,SPI0B,TWI0,TCA0,TCBn,TCD0,EVYS,CCL-LUT
FILL COLOR, white, white, white, white, deepskyblue, lime, greenyellow, green, olivedrab, cornflowerblue, yellow, yellow, orange, lavender, magenta, darkorchid, red, gold

[edit: figured out a dirty hack for how to solve the 3 SPI options on PC1]
[edit: cleaned up the text box, added some sample text, and added arduino PIN numbers (as much as I wish people would stop using them)]

I checked the input file in here: https://github.com/ObviousInRetrospect/DxCore/blob/master/megaavr/extras/GenPinoutSVG/AVRxxDD14.csv if you want to play with it. The tool is here https://github.com/stevenj/GenPinoutSVG Also happy to make any requested changes and let you spend the time on getting 1.5.0 out.

[SpenceKonde]

Hmmm. There are a few things here that are not ideal:
Compare https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DB48.md
with that image added into https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DD14.md.

The boxes around the pins are larger, but the text is smaller, and I have trouble making out all the markings without zooming in.
The features and notes section is unreadable due to text size.
DxCore supports moving TCA and TCD pins to alternate pin groups (if you set the PORTMUX register, analogWrite and digitalWrite will know about it); so analogWrite(PIN_PA0,150) will instruct TCA0 to generate waveform output on WO0 and set PA0 output, if and only if PORTMUX.TCAROUTEA == 0. I think somehow in the charts those the groups should be shown - a much bigger problem for the larger parts - though I was planning to use the DB 28 and DB 32 images with removed opamps and added mux options) - but all the outputs have to get moved at once. That fact needs to be shown somehow. On the DB48 (where the errata renders the TCD PORTMUX useless) I only had to do this for TCA,, and it was done with those ugly purple boxes, but it does't look to have been done at all here.

Frankly, I'd be happiest regarding arduino pin numbers if we just showed the PIN_Pxn notation, on the charts as a way of pushing people away from using them. I sort of regret having them on the charts at all, but I wasn't as fully convinced of that notation when the pinout charts were first created, and all I can do to them is what I can do in Microsoft Paint.

[ObviousInRetrospect]

oh font size scale etc are trivial to change. I was forcing it down to letter size I can generate any scale.

I started with PIN_Pxn but thought you wanted the numbers, I'll revert that later.

I took a look at the python and hacked it so I don't have to only have one box per type which makes it more readable. For now I didn't fix C1/C2 because they are too long & I need to overall rework the size.

Here is a quick rev, but yeah let me think how to represent what you said above. I think it involves showing the swap() index.

[ObviousInRetrospect]

I'll play around with making it equivalently readable and looking better embedded in the md if you are ok with a change in format in principle.

[ObviousInRetrospect]

I took another stab at increasing readability. I settled on the notation signal.swap_pos such as TX0 / TX0.3 / TX0.4 with a note that you need to choose the same swap position for all related signals. I think this works for PWM as well although, see the latest version:

at this point I think the readability deficit of this approach is mostly font choices and tuning, do you know off hand the exact font used in your other diagrams?

I'm undecided whether I like the signal names inside the chip rectangle - thoughts?

With respect to the relative space efficiency of this vs the other style I'm less concerned. The DD14 is a somewhat pathological case in that it only has 7 rows. I can tune the spacing easily enough once I generate the larger ones. As an example I shrunk the key down a bit.

https://github.com/ObviousInRetrospect/DxCore/blob/master/megaavr/extras/DD14.md shows it in context

If you decide to play with changes you will need to use my fork of GenPinoutSVG which supports a pipe to split a field into multiple boxes: https://github.com/ObviousInRetrospect/GenPinoutSVG as trying to stack the signals was totally unreadable.

[many edits: google fonts + GitHub = fail, local preview looks different]

[SpenceKonde]

Now that's more like it!

[MCUdude]

Sorry, I've been quite busy lately and I'm late to the party. @SpenceKonde do you want me to make pinout pics for the DDs, or are you keeping @ObviousInRetrospect's?

[ObviousInRetrospect]

If you end up doing them you might want to use the .alt notation as in the DD14 (so RxD0.1 is the Serial.swap(1)) as some of these have many positions.

Also FYI the datasheets are a mess and there are things in the IO Multiplexing table that have no corresponding settings in the relevant ROUTE register. I have a case with Microchip to figure out which is right. Here are the ones I know of:

14/20:
pin present in iomux and not in pinmux: 4 PA0 SPI0 ['MOSI']
pin present in iomux and not in pinmux: 5 PA1 SPI0 ['MISO']
pin present in iomux and not in pinmux: 6 PC1 SPI0 ['SS']
pin present in iomux and not in pinmux: 7 PC2 EVSYS ['EVOUTC']

32:
pin present in iomux and not in pinmux: 20 PF0 CCL ['3,IN0']
pin present in iomux and not in pinmux: 21 PF1 CCL ['3,IN1']
pin present in iomux and not in pinmux: 22 PF2 CCL ['3,IN2']
pin present in iomux and not in pinmux: 23 PF3 CCL ['3,OUT']
pin present in iomux and not in pinmux: 6 PC0 TCBn ['WO2']
pin present in iomux and not in pinmux: 8 PC2 EVSYS ['EVOUTC']

I was testing the consistency of my IOMUX parser and my PORTMUX parser as a way of finding any bugs. All the discrepancies were in the source material.

My suggestion would be to give me until Sunday and then decide if the new generated ones are sufficient or if you want to do a fresh set. Assuming I get the generation done the images I produce also might be easier to clean up.

@MCUdude what fonts are you using in yours?

[ObviousInRetrospect]

This is the output of the mostly-automated generator. Still need to add the legend & text to the auto and the auto-splitting of long lines needs a bit of work. Do we care about uniform spacing or should I add some whitespace when a line gets doubled - on the DD20 it looks like it needs more separation.

this is the auto version of the 14 for comparison. Looks like the biggest difference I see is more completeness when alternate positions duplicate the defaults.

[edit: the original 14 was just an old 20]

will work on getting the auto-splitting spacing to not need manual adjustment and then generate the rest. I have data parsed for all DDs

the other unknown is 4-sided chips might need more work. I was going to generate two-sided chips for everything first and then figure out how to convert

[ObviousInRetrospect]

Here is a full set with the spacing improved a bit. They no longer require any hand edits.

On to restoring the legend + figuring out how to make square chips square (although part of me is tempted to render them as a very narrow diamond and keep all the text right side up. this is probably because I usually rotate them 45 degrees on the pcb and so the rectangle looks fine to me)

[ObviousInRetrospect]

legends:

[ObviousInRetrospect]

I think #331 is pretty close. Any suggestions?

[ObviousInRetrospect]

Improved images viewable in context here. If I didn't know @SpenceKonde liked the DD20-QFN variant I might have omitted that diagram (along with the 28 QFN, not sure why you would use that over the 32)

:
https://github.com/ObviousInRetrospect/DxCore/blob/dd-pinouts-all-rev1/megaavr/extras/DD14.md
https://github.com/ObviousInRetrospect/DxCore/blob/dd-pinouts-all-rev1/megaavr/extras/DD20.md
https://github.com/ObviousInRetrospect/DxCore/blob/dd-pinouts-all-rev1/megaavr/extras/DD28.md
https://github.com/ObviousInRetrospect/DxCore/blob/dd-pinouts-all-rev1/megaavr/extras/DD32.md

[SpenceKonde]

We've making great progress here in another thread now, removing "BLOCKED"

[SpenceKonde]

I thought I was accommodating them ;-)

Anyway @ObviousInRetrospect or anyone else, where the heck did those new images get off to for the DD series??

[SpenceKonde]

Anyone? Please?

And we now need EA charts too. x_x

[MCUdude]

I wrote this back in August and didn't get a response.

Sorry, I've been quite busy lately and late to the party. @SpenceKonde do you want me to make pinout pics for the DDs, or are you keeping @ObviousInRetrospect's?

If there is a pinout generator that's free to use, why not use this if you're happy with the result?

[SpenceKonde]

My plan has always been to use his generator. You're busy, and I want to be able to adjust and create pinouts as needed myself without having to beg for help

Why have I not done so? Why are we nearly 7 patch versions later without new pinout images?

because I forgot where it was stored and cannot locate it

[MCUdude]

How about @ObviousInRetrospect's fork?

If you decide to play with changes you will need to use my fork of GenPinoutSVG which supports a pipe to split a field into multiple boxes: https://github.com/ObviousInRetrospect/GenPinoutSVG as trying to stack the signals was totally unreadable.

[SpenceKonde]

I don't think that;'s the complete version, and anyway, I reemember seeing fully rendered QFNs that were square. Looked great, was finally going to add them and coldn't find them.

Sigh... And now we need diagrams for the EA.

And before you know it we'll need them for the DU (at least all that is needed for those is already known, unlike the EB, whose new timers and hence what to mark as a PWM pin will likely be unknown until we have hardware in our hands.

[SpenceKonde]

Still no luck locating the tools,. We are now two generations behind, and sufficient information is availavble to create a diagram for the future DU-series! And I feel totally powerless here. I don't have any knowledge or experience with graphics.

[coburnw]

Ive been playing with automating svg generation using Tengo10's pinout-overview with fair success so far.

Ive been using tabula to extract the pin function table from the microchip pdf, but cant seem to pull out the table header, im guessing because of the rotated text.

Are you aware of another, more parsable, source for the pin function data?

[pcfreak1201]

Well, I don't think the PDF is a good source for automatic generation of pin assignments. I tried PDF2TXT and got this output:
HTML-Output
May be the variants are more likely a point to start at?
e.g. https://github.com/SpenceKonde/DxCore/blob/master/megaavr/variants/20pin-ebseries/pins_arduino.h

[coburnw]

Now that makes sense. I found this old SO on header file parsers for python so its not starting from scratch, but it still looks like quite a project. You up for it?

the code im using to extract the data from the data sheet and generate the yaml pins file for pinout-overview is here along with a generated svg.

[SpenceKonde]

If I can provide to you a list of pins and their functions to you in JSON, XML, CSV or other structured text, just let me know which one! I can do that easy peasy. I have already extracted the data seven ways to sunday! I just don't know jack fuckall about this graphics shit!

Oh - one exception to text formats - I have tried multiple times to achieve basic fluency in yaml. I have been largely unsuccessful. So I do not believe that I could prepare a document in yaml format if that format could even be used to communicate the possible functions of pins (I have no idea what it can and can't do, nothing makes sense to me. I've reached out to people who who work at G/A/Fb/and so on and swore on their mothers grave that they knew that stuff like the back of their hand, slowly back away and look defeated when I ask what I think are simple question saying things like they've never seen anything like that before... (you just said you work with yaml all the time. ) cannot comprehend yaml nor find any explanation of it that makes the basic syntax clear to me, so I can't provide anything in yaml. I have tried to learn! I ask people who swear on their mothers grave that they work with yaml all day and know it like the back of their hand, and I ask them what ought to be a simple question and they look at me like I just grew two extra heads, change the topic and scurry away.

I have yet to see evidence that anyone other than our big-tech overlords understand yaml

[pcfreak1201]

Now that makes sense. I found this old SO on header file parsers for python so its not starting from scratch, but it still looks like quite a project. You up for it?

the code im using to extract the data from the data sheet and generate the yaml pins file for pinout-overview is here along with a generated svg.

Wow, I like the result(s). (Unless I personal don't prefer all possible combinations in one picture, but I understand it is only me). The SVG is quite good readable, isn't it?

[coburnw]

I really like the how the orthogonal pinout breaks the page into four text regions. but no joy yet... So for now, just text quadrants with markdown which you can see an example of here.

How do you build your list of pins and functions, do you use the master/variant/pins.h file as pcfreak1201 suggested? in python by any chance? I guess what im getting at is do you think it is possible to get from header to yaml?

Assuming it might be possible, how likely do you think that each variants will correctly convert without hand edits because of oddities and differences between header file? Said another way, how many exceptions are we going to have to add to the conversion program?

If you had a variant header parser in python to share, i'd be interested.

Do you have a map of function to color and their color hex codes for continuity with your previous svgs? Nevermind. Looks like gimp has an eyedropper mode that allows html color code extraction.

[coburnw]

@SpenceKonde, so what im thinking is rolling pinout-overview into a library. You can fill the variant dictionaries with whatever data you like, from whatever source you like. At least for now, leave the template data in yaml files as they seem easy to read and edit by hand. As a library, you will be able to wedge it into your tree and flow any way you like. Maybe even a github action if you were so inclined.

If what you have seen so far is of interest, then pinoutOverview/pins.py contains a stripped down main that you can use to explore creating the necessary variant dicts and seeing the results.

I think this project can be structured such that the community/assignee can maintain the images assuming the ATPack can be parsed without needing too much hand editing.

[SpenceKonde]

As I said above, any formula except yaml.

No yaml allowed unless a gun is being held your head, or the software is being held at gunpoint. In the case of github actions , this is the case - no github actions = no more core.

YAML should be a last resort because I have spent days trying to figure out the basics and all the resources seem to disagree any I am get lost in a fog of confusion and eaten by a grue.

If a document describes yaml as completely as json.org describes json, please please link me to it because I cannot find an authoritative and complete specification for that format and don't know how to parse it by machine and it takes for several tries to make changes in github actions most of the time, with the rest failing with a syntax error, and then I read what it says is missing and try to figure out how to fix it. But sometimes I can't and I just have to remove testing I had thought I'd had ready becaues I can't make the yaml work without errors.

And there is NOBODY TO ASK!

Everyone lies and says they know yaml, then you ask them a question and it's like you told them to spin straw into gold! I don't even know if YAML is actually a one format, or dozens of different formats.

All my processing is semi-automated - I am not quite that good. What I was proposing was "Well I'll generate tables of things to be shown per pin some combination of manually and semi automated means in any format except yaml

So unless one of you has a very strong opinion on yaml being the correct choice here, you know where I live, and are willing to drive over here and threaten me with firearms, I don't want to use yaml in this pin generator.

Let's stick to languages we can all understand. Just like I wouldn't accept a pullrequest if all the comments were in comments in klingon, and would be disappointed if the part diagrams were marked in ancient egyptian heiroglyphics, and why I don't write the documentation in pig latin.

[pcfreak1201]

Year, there are lot too much scripting languages and formats out there ;-)
But if I understand it correctly, yaml is kinda based on json - so when Spence can provide .json and coburn needs .yaml how about this: https://github.com/drbild/json2yaml
It could transfer in both directions and/but is written in python (what's my kryptonite :-). So converting the sample file back in json could give Spence an idea how to format/fill the json and converted back it could feed the Pinout Generator?!

[coburnw]

And with all that selection we can never find the perfect one, right? oh well.

But the real problem is that some cant resist an open box. They cant move on until every item has be prodded, inspected and fiddled with. Spence wanted that box opened, so now here we are.

I foolishly allowed myself a diversion to discover what a grue is and found myself with another open box. After much study I think i would gladly walk into the pitch darkness than to spend a lifetime thinking about the color grue and The New Riddle of Induction.

But I am making headway.

[SpenceKonde]

I didn't want the box opened! Microchip opened the box and emptied it onto the floor by releasing all these new parts and all these pin mapping options. But yeah like, if I knew what information we needed (I feel like if I tried to guess, I would miss things or make life harder than it needed to be).... the list is quite easy to generate for AVR DA and DB due to symmetries.

[SpenceKonde]

I'm close to having lists of the pins and physical pin numbers for each pin mapping in json.

[coburnw]

I have some json dicts and lists pretty well refined and working. How about you hold on another day or two till i get them posted? Im working thru some pretty serious snow blindness. You know the kind where all the code merges into one giant line, with non existent indentation. I spent the last two days splitting cordwood and am starting to see normal again. And still have all my toes.

Oh. And thanks for the nudge.

[SpenceKonde]

This is what the products of my generating are coming out looking like now

{  "DD14":{  
    "shape":0,
    "partfamily":"DD14",
    "negadcpins" :"All",
    "notes": ["All pins are fully async and can wake from powerdown sleep on rising/falling edge", 
      "DxCore's PWM system is *PORTMUX aware* for both TCA and TCD; just set PORTMUX, and analogWrite/digitalWrite() will react appropriately", 
      "TCA and TCD must be set as a group, they cannot be set individually. ",
      "Errata/Clarif: TCD and TCA override the port direction on these parts."
    ],
  "pins":[
    {"PIN":"PA0", "USART0":["TX"], "SPI0":["MOSI_ALT1"], "TWI0":["SDA_ALT2 (MS)"], "TCA0":["TCA_A"], "CCL":["0IN0"], "CLOCK":["CLKIN", "XTAL1"]},
    {"PIN":"PA1", "USART0":["RX"], "SPI0":["MISO_ALT1"], "TWI0":["SDA_ALT2 (MS)"], "TCA0":["TCA_A"], "CCL":["0IN1"], "CLOCK":["CLKIN", "XTAL1"]},
    {"PIN":"PC1", "AIN":[29], "USART0":["TX_ALT4"], "USART1":["RX"], "SPI0":["MISO_ALT1", "MOSI_ALT6", "SS_ALT3"], "TCA0":["TCA_C"], "CCL":["1IN1"]},
    {"PIN":"PC2", "AIN":[30], "AC":["IN_N3"], "ZCD":["IN3"], "USART0":["RX_ALT4"], "USART1":["XCK"], "SPI0":["SCK_ALT1", "MISO_ALT6"], "TWI0":["SDA (S)", "SDA_ALT2 (MS)"], "TCA0":["TCA_C"], "CCL":["1IN2"], "EVSYS":["EVOUTC"]},
    {"PIN":"PC3", "AIN":[31], "AC":["IN_P4"], "USART0":["XCK_ALT4"], "USART1":["XDIR"], "SPI0":["SS_ALT1", "SCK_ALT6"], "TWI0":["SCL (S)", "SCL_ALT2 (MS)"], "TCA0":["TCA_C"], "CCL":["1OUT"]}
    {"PIN":"VDDIO2"},
    {"PIN":"PD4", "AIN":[4], "USART0":["TX_ALT3"], "SPI0":["MOSI_ALT4"], "TCA0":["TCA_D"], "TCD0":["TCD_C_ALT4"]},
    {"PIN":"PD5", "AIN":[5], "USART0":["RX_ALT3"], "SPI0":["MISO_ALT4"], "TCA0":["TCA_D"], "TCD0":["TCD_D_ALT4"]},
    {"PIN":"PD6", "AIN":[6], "AC":["IN_P3"], "USART0":["XCK_ALT4"], "USART1":["TX_ALT2"], "SPI0":["SCK_ALT4"], "EVSYS":["EVOUTD_ALT"]},
    {"PIN":"PD7", "AIN":[7], "AC":["IN_N2"], "USART0":["XDIR_ALT4"], "USART1":["RX_ALT2"], "SPI0":["SS_ALT4"], "CCL":["2OUT_ALT"], "OTHER":["VREFA"]},
    {"PIN":"PF6", "OTHER":["RESET"]}
    {"PIN":"PF7", "SPI0":["SS_ALT6"], "EVSYS":["EVOUTF_ALT"], "OTHER":["UPDI"]},
    {"PIN":"VDD"}, 
    {"GND":"GND"}
  ]
}

Note: That was after hand editing (and no small amount of it), I can't get that direct from the spreadsheet yet - but I do have a spreadsheet for all the parts - it's just getting the formatting to come out right using only a few regexes at most. The comments I would expect to enter manually.

[coburnw]

Have a look at the dxcore branch of my fork of tengo10's pinout-overview. extract_variants.py is used to generate the follwing config files from a pdf. This project is very much work in progress. Please try to see thru that.

• DD20.json contains the variant specific data including a map of pin-numbers to port-names
• dd14_20.json contains portname to functions list relationships
• and dxcore_functions.json that contains the styling for the various function labels. Note the skip option to turn on and off functions with styling.

I never looked into the atpacks as you suggested. The table in the datasheets is conducive to having an intermediate family file. Perhaps that doesnt work with the atpacks. I dont know. Regardless we can make it work either way.

I enjoy building tools and will be happy to maintain something like this if it is helpful to you, but you should know, there is very little chance i will be your future goto guy for making new drawings without significant duress. At least at this point, i really think the graphics can be as easy as minor edits of a template file or two. As for the parsing, i only toyed with parsing a pdf datasheet and sense it will be quite problematic. I guess you will know shortly about the atpacks.

Im open to structural changes. Please dont take any of the above comments as demands...

[coburnw]

I made some minor changes to your json file and got it to display. I chose to add a pinmap but simply appending the pins in the right order would work fine too. Do you think you can extract the pin numbers from the atpack?

[SpenceKonde]

Ooooh! I like the looks of that. The dashed border for alt pins is good. I wonder if it would look better to lighten the fill color too?

The legend is super long - I think we probably want to have a list of entries for the legend, or something, and some way of specifying which color they get. I think... - maybe two new json fields? One which will list the peripheral classes,

Sooner or later they're gonna come up with new peripherals. In fact they seem to come up with around 1 new one per family on average. (DD got no new ones, but EB is adding 2 kinds of timer. EA just brought in the ADC from tiny2, but they made the last two changes to the event system that they should have made before releasing the first parts with an event system, so we finally got a proper event system (we're just lacking one basic thing in CCL/EVSYS which might as well be the same thing... better late than never? So maybe I should provide an entry in the table named "legend" to list entries in the legend (eg, "legend":[{"name":"PWM", "color":(wtf format do I use here?), "caption" PWM (analogWrite()) pins"},{"name":"EV/CCL","color":???, "caption":"Event System (EVSYS) and Custom Logic (CCL)"},....] or something like that? In the order to be displayed

And `"colors":{"AC":???, "ADC":???,....} - I don't know how you would want color specified that would be easy to ingest

One question is whether the different serial interface types get different colors. On yours they do, but you were starting to run out of colors (yaknow, birds have a fourth type of cone cell! We got ripped off with only 3. You get 3+3+1+1 = 8 colors from 3 (RGB, CMY, White, Black). With 4 cone cells, we could see 4+(3+2+1) +4+1+1 = 16 colors (R, G, B, U, 2color: C, M, Y, UR, UG, UB, 3color URG, UGB, URB, RGB (no longer white), new white (all 4), and black). Imagine how much easier color coding would be! Though blacklight parties would be way less fun I suppose... and I'll bet arc lighting would have stayed for a lot longer than it did, since arcs emit into UV but it's mighty hard to get much UV out of a incandescent lamp. I think the bird one is also very near UV)
I think putting different colors for the serial interfaces is nice, but not something we should do if we don't need to.

The labels for the SDA/SCL overflow the box, because there are two types of SCL and SDA - full function SCL + SDA that can be either master, slave or both ("multimaster" busses) in non-dual mode, or master in dual mode, and the dual mode slave only pins

I would favor making all kinds of timer the same color (basically that color means "this pin has (or could have) PWM.

I guess we need some check for whether a pin is on PORTC on boards with MVIO, so we can mark them (maybe different background color on the pin number or pin name.

Times New Roman is not flattering. Maybe like, something sans serif for the notes?

The clock pins are not being rendered correctly - PA0 is CLKIN. There is only one CLKIN,

I think most of these aren't terribly troublesome. But there's another issue - we need some way to differentiate peripheral instances from pinmappings: Look at what happened to the serial pins, for example: you can't tell which is Serial and which is Serial1.
Showing the mapping number on there is a very good thing - it's frequently not done (I mean, lord knows microchip doesn't), and one of the next two AVR families they release will have only one USART... with yet another pinmapping option. PA01, PA45, PA23, PD45, PC12, and PF76. Notice that the reset/updi pin one is backwards since reset is input only. That means that the Serial.pins() function won't work, because it relies on a function that, internally, relies on the fact the TX+1 = RX. However other than that Serial will work as is, despite the fact that it thinks RX is on the pin after PF7, instead of the one before it. PF6 can never be an output, so it doesn't matter that we didn't set RX input. And what got set input instead? Nothing - the pinMode() failed! The UPDI pin, if it can be made IO, is always assigned the last arduino pin number, so PIN_PF7+1 is never a valid pin, so instead of setting a pin that's always input input, which it doesn't need to do, it sets something that doesn't exist to be an input, which it can't do. (I wonder i

CCL looks good. You can't put number at the end like one "ought" (because that's how Microchip does it) to do with the instance number since the inputs end in a number, and that's also Microchip;s notation. But technically these aren't instances of the CCL, anyway! That CCL has multiple "logic blocks" (unofficial term, but I think the Microchip term ("LUT") is likely to cause confusion) in it. But the registers are all CCL.TRUTH0 and CCL.TRUTH1, not CCL0.TRUTH, CCL1.TRUTH)

The fukin DB OPAMPS are like that too. I think in both cases for the same reason, that they're not quite independent - a couple of things are set globally. But I think they'll be one "column"

This is awkward for the AC pins, because they're only sort of alt pins, I'm inclined towards ACnIN1 (since they will have the same background color as all the other analog stuff) (though out is OUT and OUT_ALT so that is normal and wellbehaved.

The TCBs work like the CCL as far as portmux, except possibly not on the DU, so we need to be able to handle a multiple ALT TCB. I think it's safe to say that if the options are passed from the json as ALT we don't show numbers, and if it's ALT1, or ALT2

With everything else, we need to do something to make the numbers look visually distinct from the peripheral instance number. My first thought is maybe

^pTCAn

so pin on the third mux option of TCA1 would be like

³TCA1

(is that going to display in github?)

The logic behind that being that whenever we show the name of an instance of a peripheral, it's number should go after the letters, especially if it's the Microchip abbreviation (eg, TCA). Probably should only be shown if there's more than 1 TCA on the part

I'm not parsing atdf's for that data.

That is generated by a combination of excel (workbook with 1 sheet per family. So I fill in the fields (most, copy/paste them from the existing ones, because a lot of things stay the same. The format I get out of excel then goes through some brief processing in sublime with regexes to get the json. But every peripheral or pin mapping got entered by hand. It's looked easier that trying to parse that mess, andI'm pretty sure itis

[coburnw]

Tengo10 did a nice job keeping the style separated from the mechanisms. Many of your concerns can be fixed by simple style edits

The basic style including color for all possible function type labels is defined in dxcore_functions.json while dd14_20.json would be an example of a specific variants concrete function list. Please feel free to add whatever fields you like to the variant function list. If you give me some hints on how you would like to see those fields modify label styling we can see what we can do

Ill work on divorcing the color codes from the function label types to make the colors readable to anyone wishing to edit the styling of the function type labels.

An unresolved is the font for the notes fields. I havent found a mechanism in SVG to easily display a block of text in a defined region so i am exploring how to go about that myself. Currently the ugly font you see is displayed by your browser, ie it is not rendered inside the svg file as the other text is. I suspect i could get the browser to apply a proper css to it, but i worry that it may not render properly in, say, a pdf. We will see.

Ill add a use-counter to the function labels so the legend only contains the functions you reference.

How the various definition files are handled internally by the library has gotten convoluted and opaque. that needs a serious rework.

I quite frankly cant imagine building those spreadsheets. better you than me, Gunga Din.

[SpenceKonde]

Huh, interesting.

Oh they're not that bad to crank through...

It would be dreadful if these parts were still made by Atmel, because they sometimes seemed to be making decisions by coin flip. Microchip, on the other hand, makes microchips, and have about as much creativity as their name and line of business suggest. They don't seem to have such a need to change stuff for change's sake.

[SpenceKonde]

Here's a spin on the DA-series to try to find more stress cases.

Implementation notes:
* I realized that the "notes" section was duplicated across the whole part family, with only a few exceptions, while going through the DA-series
  so the files become more managable if we get notes by combining pinmap["DA"]["Notes"] and pinmap["DA"]["DA28"]["Notes"] 
  (all of the part-specific notes fields are empty except for DA64 - but this won't be true on all series).
* Same for "Legend", except that parts don't have special part specific legend entries.  
* There are cases where the default pin mapping for TCA, TCB, or TCD, or any other peripheral to be different from the default. 
  Hence the default_mux property. For timers (peripherals starting with "TC" - there's only TCA, TCB and TCD now, but we'll have parts with a TCE and TCF 
  (that'll be in the EB-series), and all the pinout info is already known. 
  portmux selection is not the default (TCA_A) 
* In the case of "SPECIAL", the default portmux depends on something else (this is the case for USART0). If that's specified for a peripheral, there's a note explaining it
  and all of it's pins should get a border different from either the "default" or "non-default" values (in the case of USART0, it depends on the clock source, 
  since external clock sources take the default TX pin (and on later series that support a crystal, the RX pin as well)
* I realized that "shape" was trying to encode two pieces of data in a single value, which doesn't work, it was renamed to package for the names of the packages, and
  to "shape" for the one that specifies how the pins would be arranged - "rect_2sides" is for standard SOIC/SSOP/DIP packages, with parts down the left and up the right.
  "square" is a square package with the part aligned with edges parallel to the frame of the image, "square45" if it is to be rotated 45 degrees to fit better. Finally, *I*
  have a strong desire to be able to make a "rect_3sides" pinout - down left, up the right, then the last 5 pins of the pinmap along the bottom edge of the rectangle between the rows. 
  so I can make nice pinout charts for my Azduino Nano DB/DB+/DA/etc boards that I'm producing and planning to start selling once I've finished up the documentation, which is 
  taking FOREVER. (hardware has been waiting over a year for me to catch up and have docs written so I can list it people might actually buy it. 

Annoying that they don't let you upload a .json...
pinsdx.txt

[coburnw]

So your stress tester is functional in a watertight sandbox. I made some minor tweaks to your json file to fix a couple typos and make the features work. oh, and some coding... As it is now, all the function label style and ledger style is pulled from dxcore_functions.py. The legend section of your json file is completely ignored at this point.

Im still in the process of wrapping my head around special pins. Would mvio pins be considered special? Were you thinking along the lines of how the mvio pins are displayin in this dd14.svg image?

I added some footnote bubbles that can be added to any function label. They are configured with a '[n]' in the json file. In hindsight perhaps '(n)' would stand out in the middle of the json better and would make hand editing a lot easier. The DA28 is a good example of the footnotes.

For now, im going to pretend you never mentioned three sided parts.

[coburnw]

If you are still interested, please see all the updates here https://github.com/coburnw/dx-pinouts
I did what you suggested a long time ago, and wrote a parser for the atpacks. Maybe now i can get some forward movement.