DxCore
DxCore copied to clipboard
SpenceKonde
DD-series pinout images
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.
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.
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
64dd28 devices will be going on sale shortly.... Still haven't gotten the small pincount parts.
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.
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
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.
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.
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.
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.
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]
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?
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?
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
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)
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
We've making great progress here in another thread now, removing "BLOCKED"
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)
The DD20 QFN variant is imho the entire point of the DD20. Certainly since the whole idea of the DD's is sort of as a budget option, and the SOIC packages are like a third more expensive than the QFNs and take up an acre* of board space. And the 64DD20 doesn't seem to be getting the QFN package... Which means that it will just be a curiosity, because the 64DD28 in TSSOP is cheaper than the 64DD28 in SOIC.
The point of the DD28 [V]QFN package is that it is very very cheap - 64DD28 is only 8 cents more per chip (w/out qty discounts) than the 64DD14... while the SOIC 64DD20 is... ... 31 cents more expensive than 64DD14.
At 32k the DD14 comes in at 99 cents, and 95 at 16k, while the DD20 is $1.08 and $0.98 in those sizes
* I don't know how widely used Acres are for measuring land area worldwide, or if it's just a US thing; that's the unit we use to measure land for non-farming purposes (farmers use a different unit, the hectare, which unsurprisingly is much bigger). A quarter acre lot is enough for a 4 bedroom house with living and dining rooms, plus whatever you do with the basement and third floor, while still having a yard large enough for kids to run around in. So it's a slight exaggeration to say that the wide SOIC20 takes up an acre of board space. But only a slight one >.>
You've done a great job with these diagrams, considering the complexity of the parts. The only thing I can't find is the Arduino pin numbers; or was that a conscious decision? One suggestion: they could go to the right of the pin number, in square brackets, in place of F6, F7, A0, A1 etc, which duplicates the black legend PIN_F6, PIN_F7, PIN_A0, PIN_A1 etc:
Hi technoblogy,
well the black names are the Arduino Pin Numbers. Just use e.g. digitalWrite(PIN_PD6, HIGH);
They are also compatible to the other cores from Spence and Hans. I use them every time. They are great! You can have a look in the datasheet and simply use PIN_ plus real port-pin. No lookup-table or translation sheet necessary.
@pcfreak1201 I know I can use those, but what I'm referring to are the numbers labelled "ARDUINO PIN" on the other pinout images such as:
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DA28.md
I intentionally removed the Arduino PIN numbers (which I had in an earlier version of these) as very strong encouragement to use the PIN_PxN macros, which are documented in the black boxes.
Arduino PIN numbers are inscrutable, create extremely non-portable code, and really should not be used directly.
It's just that anyone coming to DxCore from the standard Arduino range will be used to using them. For example:
https://www.arduino.cc/reference/en/language/functions/digital-io/digitalwrite/
At least add a note to that effect on the diagram?
@ObviousInRetrospect where did we leave this? I still don;t know where the QFN images that we had got off to...
And uh...
We need diagrams for the new EA-series that is now shipping in limited quantities and with onerous conditions too....
There's nothing particularly fancy about them - 28, 32, and 48 pins, PDIP/VQFN for 28, other two TQFP and VQFN (with the same pinout). Pin locations are the same as on the DA, except that all pins that had ADC input on DA or DD have ADC input on EA, there are two TCA's (TCA1 has pins 0-5 on PB or 4-6 on PC, PD, or PA, there's no TCD, 4 TCBs. USART 0/1 and SPI0/TWI0 got the absurd number of portmux options that DD got, nothing else other than the TCA got more, DAC is in the same place. All pins are fully async (can wake from powerdown sleep on rising/falling not just change or level.
@ObviousInRetrospect
Arduino PIN numbers are inscrutable, create extremely non-portable code, and really should not be used directly.
Whether or not you prefer using pin names like PIN_PD6 to Arduino pin numbers, this core is designed for use in the Arduino IDE ecosystem which is based on the idea of pin numbers, and just about every other core supports pin numbers. So it should support both.
It does support both. I just don't go out of my way to call attention to the numbers, because when people use the numbers, the overall result is more bugs, more difficulty using non-Arduino resources like official documentation, less compatibility, with no particular benefit. This is all discussed, and all the ways of referring to pins are listed, in the main readme file under the "ways to refer to pins.
We support "An" macros for analog pins too, but you sure won't see me putting those on pinout charts. I think the use of user-facing numeric literals as pin numbers, and the concept of an analog pin being presented as somehow different from other pins that belong to the subset of the pins that some specified peripheral can use are two of the biggest blunders that Arduino made. Following in their footsteps was what led people to design several incredibly perverse pinouts (the legacy pinouts on ATTinyCore for 861 and 167 come to mind, particularly the latter. I think they tried to make it "feel" like an uno, but what they actually made was . We don't give the PWM pins names like P0-P5, and we shouldn't call analog pins A0-An, and so on. There is a clear and logically coherent way to name pins: by using the same numbering scheme that the manufactutrer, and hence all other non-arduino resources, use. That is obviously the way to go, and so I am promoting it at every chance I get.