Pinout for VQFN packages (e.g. Attiny1616) #786
Replies: 8 comments 47 replies
-
|
I don't make the pinout images. I beg for pinout images, and I use whatever image format I get them in. That's why the images for my different cores all look different, like they were done by different people and there's no standard or template. It's because that's exactly what happened. It's very frustrating, but I don't have the graphics skills needed to do this, and I don't even know if software that's appropriate for this even exists anymore. Basically, some sort of graphics software more sophisticated than paint, but not as complicated to learn as a full CAD program like autocad. Something like Designer, which I used around when the company that made it went under 20 years ago) and I was less than 20 years old. When I have had to update DxCore files to reflect changes tio the core like the way on DxCore you can just set PORTMUX.TCAROUTEA and analogWrite() will know which pins it can be used on. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a SVG for the ATtiny1616 in QFN: The rest of the similar diagrams are here: https://github.com/ObviousInRetrospect/avr_pinout_diagrams/tree/main/svg - I provided the generated pincsv data as well which you can tweak and run through https://github.com/ObviousInRetrospect/GenPinoutSVG to generate SVGs (this is my fork with minor added features I depend on). @SpenceKonde I have my style of pinouts for every part supported by megaTinyCore and DxCore. These are all generated from the atpack xml data. There is an intermediate JSON text file you can edit if you want to add/remove stuff. Happy to make changes if needed but haven't gotten any suggestions. |
Beta Was this translation helpful? Give feedback.
-
|
I currently generate a rectangular image because I think its easier to read with the text all going the same direction. I can probably generate square ones if you think they are strongly preferred but have not been told they are. (and yes I should fix the dxcore reference on the tiny) |
Beta Was this translation helpful? Give feedback.
-
|
If the image does not reflect the actual shape of the QFN, whats the value of the image? How about putting the square chip at a 45 degrees angle and than fan out the pin functions horizontally from there? |
Beta Was this translation helpful? Give feedback.
-
|
The value of the image is to show what signals are on which pin and how to configure the core to match your hardware. In practice dev boards and breakout boards that use QFNs most commonly mount the QFN diagonally or otherwise route signals to two sides of the board and thus end up looking a lot like the above. For example: https://www.tindie.com/products/drazzy/attiny3217similar-breakout-board-bare-board/ and https://github.com/ObviousInRetrospect/avr_pinout_diagrams/blob/main/svg/ATtiny3217.svg seem to be a good match. |
Beta Was this translation helpful? Give feedback.
-
|
It's no more useful than the SOIC-20 pinout that we already have.... |
Beta Was this translation helpful? Give feedback.
-
|
And watch out or Il make it from that in microsoft paint! |
Beta Was this translation helpful? Give feedback.
-
|
ok, I'll generate square, had asked about that weeks ago and got no response. but I'd argue that having correct PIN numbers and order makes it more useful than the SOIC-20 pinout |
Beta Was this translation helpful? Give feedback.
-
|
And if you want to hand-edit and arrange stuff use Inkscape not paint. Personally if I generate by hand there will be too many errors. |
Beta Was this translation helpful? Give feedback.
-
|
This is a mock up. I took the rectangular layout you don't like and moved/rotated the pins to appropriate sides in Inkscape.
Is this what you are looking for? Are there changes you want? GenPinoutsSVG doesn't support this orientation [yet]. I want to get one of these looking exactly like you want using Inkscape. I will then hack support for that format into GenPinoutsSVG and generate everything again. Another question: there are some semi-undocumented signals like BREAK exposed in the atdf files. Do you want them or should they be hidden? I have open support cases with Microchip chasing down the discrepancies within the datasheets and between the datasheets and the atdfs. That is part of what the override configs are for. |
Beta Was this translation helpful? Give feedback.
-
|
So I must admit I'm quite good in Inkscape and I love Adafruit and what they do. So I found this guide on their website, The guy provides a pretty good template in the style of these diagrams BQ or Pighixxx did. |
Beta Was this translation helpful? Give feedback.
-
|
yeah so that is pretty but the manual arrangement is error-prone. Feel like re-arranging starting with my SVGs (which were programmatically generated from Microchip provided data)? Data is here: https://github.com/ObviousInRetrospect/avr_pinout_diagrams/tree/main/svg I'm better on the programming side than the aesthetics side so I am confident that someone else can figure out what pretty looks like and I can then probably make the generator generate whatever that is. That way we get accurate, pretty and consistent for all supported chips. If you want to play with color or similar tweaks I provided the GenPinoutSVG inputs. My fork of GenPinoutSVG is needed to support the generation of multiple boxes for the same column (separated by |). If we get one of them right I can probably generate everything else so don't spend a ton of time repeating work manually. |
Beta Was this translation helpful? Give feedback.
-
|
I think the SVG approach, since it gives a way to generate them without manual placement is probably going to be more scalable, and more maintainable, and doesn't require any exotic software. There would be features we would need to add though at the level of GenPinoutSVG if we were to also tackle the deplorable state of the DxCore diagrams after being butchered several times by me with microsoft paint, most notably that when you step into Dx land, suddenly you need to have a way to show "groups of pin functions" - ie, what I use those ugly purple boxes for over here. (really, they belong around the TCA0 labels, since that is what they refer to the grouping of) (see, on Dx-series and other full-size chips, TCA0 can be output on pins 0-5 of any port, but you can't mix and match pins from multiple ports) https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DB48.md |
Beta Was this translation helpful? Give feedback.
-
|
I already handle groups of signals in the Dx by suffixing alt positions with .n where N is the mux position. So MOSI, MOSI.1, MOSI.3 (and corrosponding MISO, MISO.1, MISO.3). This carries over to the tiny but on the tiny I just describe it as .1 is the alternate position. I think it generalizes better than the purple boxes. Especially for things like SPI on the DD where they went kinda crazy. (I wish they went crazy with UART mux positions - those I actually use. Their UART portmux options are pretty terrible.) Features can be added at a couple levels of the stack. GenPinoutSVG did a poor job separating concerns. It intermixes the logical signal definitions, styling, and physical layout. It also doesn't handle relative positions well which makes edits suck. Right now I have a pipeline that generates a json that concerns itself only with the logical (what signals in what groups are on each pin) + some software to generate that automagically from the atpacks and then a second stage that generates the GenPinoutCSV from the logical. Some things like rotated rectangles had to be hacked into GenPinoutSVG but I prefer to avoid hand writing inputs to that. From some of your other threads I don't know how you feel about JSON but I know you like CSV. If you don't like this sort of chip definition: I could easily do a bidirectional translation between the current json and a csv format where the columns are the things you see on the legend (signal groups) + the physical PIN number and the rows contain any boxes to be generated in the color corresponding to the column (with | separating cases where there are multiple signals on a pad in the signal group). This would look pretty similar to the IO multiplexing table in the datasheets except using more specific definitions for alternate positions and more consistent signal naming. I figure core-specific features get treated a lot like signals and are just extra columns. |
Beta Was this translation helpful? Give feedback.
-
|
@SpenceKonde I have a few variants to compare. Can you please pick among styles A-E and indicate whether the physical PIN number should be added as a small box right before PIN_Pxy or be part of the chip (it is currently part of the chip) and whether you want the semi-documented signals like break removed. (I can delete any signals we don't want. The PTC signals are another candidate. Right now I am including everything. Personally I sometimes generate a version that deletes the UART signals other than RX/TX as clutter). And identify any other changes you would like to see. Style A: (pins on 4 sides. text in two orientations)
Pros:
Cons:
Style B: (diagonal layout with staggered pins)
Pros:
Cons:
Style C: (diagonal chip without staggered pins)
Pros:
Style D: (style B with a duck by request)
Pros:
Cons:
Style E: rectangular layout (existing)
Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
-
|
BREAK/BREAK.1 are OCD signals that aren't really documented but are in the atpack. I can add a delete config to remove them if you don't want them. Yeah adding a key for the magenta boxes is planned I wanted to see if that was the version you liked before going further down the path. But first I need to get the diagonal stuff laying out properly. I finally figured out I needed to move the box down by the box size * (sqrt(2)-1)/2 to put it in the right spot across all chip sizes. I also just did a painful project to improve the line splitting since the pressure on it is higher with the diagonals and fix all the layouts in moving from A4 to Letter. I am also going to move from variable DPI to variable image dimensions above 32p (while keeping letter aspect ratio). The help text is minimal placeholder. I am torn in that I kind of like the svgs to be self-explanatory but the current text layout code sucks and requires me to manually line-break the text. It is sort of lower on the list I need to get the placement of everything right before I get a sense of how much space I have for text. If I can figure out how to ask the SVG library the dimensions of text I can make several things more elegant. I need to look into the signal error you flagged. It wouldn't be the first error in the atdf but I thought I checked it. On vref: in the datasheets it always shows up in the Special pin function column. The stuff from that column is grey. If you want to vary from the datasheet classification we can but it might be more confusing. I can look at coloring or maybe different borders for the unsupported stuff. But nothing about the cores prevents me from twiddling type b timer registers or using the output for my own purposes. So I am not super enthusiastic about hiding it I think being clear what the core is using for things like analog write and other similar places might be the better path (except for things like PTC that are just not usable). I think the colors are already doing enough work that desaturating them would be confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Datasheet agrees with you on XDIR0.1. In my defense: Microchip.ATtiny_DFP.3.0.151.atpack/atdf/ATtiny3227.atdf: <signal field="PORTMUX.USARTROUTEA.USART0"
function="USART0_ALT"
group="XDIR"
pad="PA7"/>Opened a case with microchip. I don't use that signal and have no way of testing where it actually is. For now I'll assume the datasheet is right: diff --git a/pinja/extra/ATtiny-2.json b/pinja/extra/ATtiny-2.json
index 01d6b20..46acb7e 100644
--- a/pinja/extra/ATtiny-2.json
+++ b/pinja/extra/ATtiny-2.json
@@ -5,6 +5,18 @@
"Special": [
"VREFA"
]
+ },
+ "PA4": {
+ "USART": [
+ "XDIR0.1"
+ ]
+ }
+ },
+ "del": {
+ "PA7": {
+ "USART": [
+ "XDIR0.1"
+ ]
}
},
"add_re_pad": { |
Beta Was this translation helpful? Give feedback.
-
|
dumb question: does the core actually support the use of XDIR or XCK? I sometimes generate personal use pinout images that omit what I regard as garbage signals and those 2 are at the top of my useless use of space clutter and distraction mostly because I often use every RX/TX. When I want synchronous serial I use SPI or i2c. re negative pins: is the best source footnote 3 in table 3.1 saying AIN[15:8] cannot be used as negative ADC input? Should we just steal that text? Any thoughts for this part of using an IO (purple) box with ± in it on the pins supporting negative input? looks like the atdf has: <value-group caption="Analog Channel Selection Bits" name="ADC_MUXNEG">
<value caption="ADC input pin 1" name="AIN1" value="0x01"/>
<value caption="ADC input pin 2" name="AIN2" value="0x02"/>
<value caption="ADC input pin 3" name="AIN3" value="0x03"/>
<value caption="ADC input pin 4" name="AIN4" value="0x04"/>
<value caption="ADC input pin 5" name="AIN5" value="0x05"/>
<value caption="ADC input pin 6" name="AIN6" value="0x06"/>
<value caption="ADC input pin 7" name="AIN7" value="0x07"/>
<value caption="Ground" name="GND" value="0x30"/>
<value caption="VDD/10" name="VDDDIV10" value="0x31"/>
<value caption="DACREF from AC0" name="DACREF0" value="0x33"/>
</value-group>and <value-group caption="Analog Channel Selection Bits" name="ADC_MUXPOS">
<value caption="ADC input pin 1" name="AIN1" value="0x01"/>
<value caption="ADC input pin 2" name="AIN2" value="0x02"/>
<value caption="ADC input pin 3" name="AIN3" value="0x03"/>
<value caption="ADC input pin 4" name="AIN4" value="0x04"/>
<value caption="ADC input pin 5" name="AIN5" value="0x05"/>
<value caption="ADC input pin 6" name="AIN6" value="0x06"/>
<value caption="ADC input pin 7" name="AIN7" value="0x07"/>
<value caption="ADC input pin 8" name="AIN8" value="0x08"/>
<value caption="ADC input pin 9" name="AIN9" value="0x09"/>
<value caption="ADC input pin 10" name="AIN10" value="0x0A"/>
<value caption="ADC input pin 11" name="AIN11" value="0x0B"/>
<value caption="ADC input pin 12" name="AIN12" value="0x0C"/>
<value caption="ADC input pin 13" name="AIN13" value="0x0D"/>
<value caption="ADC input pin 14" name="AIN14" value="0x0E"/>
<value caption="ADC input pin 15" name="AIN15" value="0x0F"/>
<value caption="Ground" name="GND" value="0x30"/>
<value caption="VDD/10" name="VDDDIV10" value="0x31"/>
<value caption="Temperature sensor" name="TEMPSENSE" value="0x32"/>
<value caption="DACREF from AC0" name="DACREF0" value="0x33"/>
</value-group>do these look right to you? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, have the generator putting pins in the right places (mostly) for square chips. Still needs a bunch of work (line limits correct per line, positioning and scaling optimizations, physical pin #s. I think screen readability is going to be better if I stick to 300DPI and add a multiplier to the paper size since the 64-pin is kinda too small on screen. Might be able to get up to 32 to work without it certainly 24. These are examples of the current outputs AND ARE OBVIOUSLY NOT DONE. But are now being produced without hand editing instead of the earlier mock ups.
|
Beta Was this translation helpful? Give feedback.
-
|
Now have things centered where they can be and no more text running off the page. I had to make the box widths variable based on the length of the contents to make some of the chips with lots of signals (DD) work at all. Any objections to using this style even when not strictly needed? (boxes that fit text rather than biggest possible thing in that group) I also had to intentionally decenter all of the square DD chips to accommodate PIN_PC2 which got all the functions. Still needs numbers and some other stuff but I'm now convinced the layout can be made to work for all parts of interest. These are still fully generated rather than hand edited. the QFN that was asked for originally:
|
Beta Was this translation helpful? Give feedback.
-
|
Damn, you're gonna scare the poor guy off. I know I'd be running for the hills. :D |
Beta Was this translation helpful? Give feedback.
-
|
nah the ability to do variants and changes efficiently is sort of the point in writing a generator. the above would scare me off if I were doing much by hand other than figuring out where things go |
Beta Was this translation helpful? Give feedback.
-
|
Json is a good format for this. I don't think csv matches the data as well
csv. I thibk the reason i appear to like csv is that i often use it as the
easiest bridge between text and excel when processing tabular data
generated by or pertaining to microcontrollers. I think json is probably
the most reasonable thing to use for this, as it has a hierarchical
structure
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Fri, Sep 2, 2022, 14:41 ObviousInRetrospect ***@***.***> wrote:
I already handle groups of signals in the Dx by suffixing alt positions
with .n where N is the mux position. So MOSI, MOSI.1, MOSI.3 (and
corrosponding MISO, MISO.1, MISO.3). This carries over to the tiny but on
the tiny I just describe it as .1 is the alternate position. I think it
generalizes better than the purple boxes. Especially for things like SPI on
the DD where they went kinda crazy. (I wish they went crazy with UART mux
positions - those I actually use. Their UART portmux options are pretty
terrible.)
Features can be added at a couple levels of the stack. GenPinoutSVG did a
poor job separating concerns. It intermixes the logical signal definitions,
styling, and physical layout. It also doesn't handle relative positions
well which makes edits suck. Right now I have a pipeline that generates a
json that concerns itself only with the logical (what signals in what
groups are on each pin) + some software to generate that automagically from
the atpacks and then a second stage that generates the GenPinoutCSV from
the logical. Some things like rotated rectangles had to be hacked into
GenPinoutSVG but I prefer to avoid hand writing inputs to that.
From some of your other threads I don't know how you feel about JSON but I
know you like CSV. If you don't like this sort of chip definition:
https://github.com/ObviousInRetrospect/avr_pinout_diagrams/blob/main/json/ATtiny1616-QFN.json
I could easily do a bidirectional translation between the current json and
a csv format where the columns are the things you see on the legend (signal
groups) + the physical PIN number and the rows contain any boxes to be
generated in the color corresponding to the column (with | separating cases
where there are multiple signals on a pad in the signal group). This would
look pretty similar to the IO multiplexing table in the datasheets except
using more specific definitions for alternate positions and more consistent
signal naming. I figure core-specific features get treated a lot like
signals and are just extra columns.
—
Reply to this email directly, view it on GitHub
<#786 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW4442H32YJFEIAFAYDV4JC5ZANCNFSM6AAAAAAQBFWMOE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
s.g. is the final example above good (the one with the pin1 O)? |
Beta Was this translation helpful? Give feedback.
-
|
I replied above to it - there's one pin function in the wrong place and two spurious alternate functions shown, I think people will get confused by the new I/O symbols unless we use the whole symbol, magenta box included, for that marking. and we still have the issue of the greying out / make-it-look-disabled option to mark the few functions that are not exposed by the core or an included library.See my post above for the deets.... oh and the color of the VREF marking. Should probably at least match the ADC, Gradients are even better if not hard to do in svg |
Beta Was this translation helpful? Give feedback.
-
|
Getting closer. Have numbers.
|
Beta Was this translation helpful? Give feedback.
-
|
full set of above style available at https://github.com/ObviousInRetrospect/avr_pinout_diagrams/tree/main/svg |
Beta Was this translation helpful? Give feedback.
-
|
@SpenceKonde added ± if the ADC module has a MUXNEG in the atdf modules section and the MUXNEG contains the signal. At the moment it is on the end of the signal name. Could also move it to a purple box if you prefer.
also: any preference between the above PIN number style (in the chip) and the old one (below):
Getting the PIN numbers in the box in the right place across all the sizes was a lot harder than expected and the spacing isn't perfect. The other style (on the pin) is easier to make perfect since the pin coordinate is known. |
Beta Was this translation helpful? Give feedback.
-
|
also any thoughts on a lime green border to indicate signals that are only available through register manipulation and not supported by the core (instead of desaturation which makes the colors too hard to match): I just marked TCB as an example. It will take some work to add proper support and proper legend support. Just demonstrating the concept here - don't want to plumb it through if it isn't viable. Can obviously pick other colors lime just stands out pretty well. |
Beta Was this translation helpful? Give feedback.
-
|
Aw yeah. My god, 64 pins sure is a lot of pins. Who the fuck needs that many pins on a microcontroller?! I'm glad we don't have 100-pin chips. (I suspect microchip is in no hurry to bring one out - the modern AVR architecture doesn't exactly make clear how they could have more than 56 I/O pins. (they had much the same problem on the ATmega2560, and though classic AVRs could have held it off longer if they didn't put other SFRs in the low I/O space, I think they only let the first 7 ports get first class treatment. The second class pins had to have control registers outside of the low I/O space (in fact, they weren't even in the high I/O space, they were extended I/O registers, using the same access procedure as SRAM). So they'd have to make a (dun dun dun) design decision about how to handle that here. Pondering all the possible ways, I think just declaring "VPORT registers are only available for ports A-G and parts with more pins must access them with the PORT registers". It would actually be a lot less painful than it was on the 2560, since modern AVRs have the atomic PORTx.OUTSET/CLR/TGL and PORTx.DIRSET/CLR/TGL registers, so you could still flip a pin with ldi, sts or std/st. So 1 clock to load the bitmask into a working register, 2 clocks to store to the register with sts, or 1 with std if you happened to have the Y or Z pointer pointing to the start of that port, or with st if you had any of the pointer registers pointing to that specific register. Way better than the non-atomic ld, andi/ori, st sequence like you needed on classic AVR, and which needed an extra 2 (If 100% certain interrupts will always be enabled when executing the code) or 3 (if you aren't) clocks to make interrupt safe. Those benign numbers, of course, ignore the fact that it has to hoodwink the optimizer into not reordering things such that they could be pulled out of the atomic block. There's no proper facility in gcc to say "executing this instruction should have the restrictions of write to a volatile variable" so the only way to get cli to not be reorderable is with the memory clobber, and that means everything in all the working registers is treated as invalid and must be reloaded (or... i guess they store local variables on the stack?) but anyway, as I understand it, that's a brutal extra penalty in some cases - between 0 and 87 clock cycles depending on register pressure). But i digress... 100 pins would be very hard to make a readable diagram for. We're definitely pushing the limits on readability with the 64 pin parts. We should consider switching the white text to black when the background color is light for parts with >64 pins. Right now I have to scoot my chair in and lean forward to read the text on opamps, evsys, ccl, etc. I almost wonder if the 64-pin parts wouldn't look better NOT rotated 45 degrees with the pin functions on top of the chip instead of outside of it, making for an image that was still tall, from the top and bottom pins info angled straight up and down, but it we could make things bigger so folks didn't have to squint. I see no problem with the +/- symbol being a symbol in a purple box to indicate negative ADC. Or maybe a green, ADC colored box next to the ADC function. The only sources for the restriction on negative pins are that footnote, and then in the ADC chapter, MUXNEG doesn't have as many valid options listed. The valid pins are PA1-PA7 on tinyAVR 2-series, PD0-PE7 on DA/DB, and all pins that support analog input on DD (Though the DD has a different caveat on some "new" ADC pins - the pins on PORTC can only be used as analog inputs if MVIO is turned off). Which reminds me, we need to mark the MVIO pins somehow..... shrug Just one thought on it. Oh, and according to the datasheets, the VDDIO2 voltage range is 1.62v - 5.5v, while the Vdd voltage needs to be 1.8-5.5 Considering the alignment issues, my only concern with physical pin numbers going outside the box is that it might force moving everything else further away, which doesn't matter for the tinies, but everything that makes the image wider hits like a knee to the groin on the 64-pin ones, because github downscales images so they fit column of text when it displays markdown files (seriously, this annoys the hell out of me. Half of the pixels on my screen are unused, big blank space on either side of the content..... (why? There's really no excuse for that, and I am struggling to not say really nasty things about github's design here). Does their office have a tradition of widescreen monitors turned vertically or something?). Might be better to put them above or below the dot instead of between the dot and the box. I'd even lobby in favor of a horizontal movement of the pins inwards to make the image narrower. They'll always downscale an image so it fits in the same frame as the rest of the .md file does. Anything that makes more downscaling is a bit of a kick in the eyeballs when you get up to the 64 pin diagrams - Every bit of added downscaling makes it that much less readable. About XCK/XDIR - Sorry man, we've actually got full support for using those pins... And I get asked frequently about RS485. I don't know who the f- these people using RS485 are or why. But a lot of people like RS485. That was a big part of the reason that the 2.4.x/2.5.x serial enhancements (see Ref_Serial.md). Serial lets you use the ports as not only UART or 1-wire half duplex UART with automatic control over direction for R485, or, but as a USRT (If a UART is universal async receiver transmitter, and USART is Universal Sync/Async Receiver Transmitter, then when sync mode was in use that'd have to make it a USRT right?) and as SPI master. There are actually very few hardware features that we don't support somehow - 2.6.0 will have autobaud (and also a way to see and clear cumulative error flags, so if you're getting invalid commands, you could see what kind of errors you were getting. USRT mode is quite different from SPI. For one thing, the clock comes out whether there's data or not from the master side, because slaves need to be able to send to it and how would they get a clock for that otherwise? (I wonder if common practice would be to switch data direction when they've got something to sent, wait until the end of the response then switch back to slave, so either of them could initiate a transfer and was free to do so as long as there wasn't already a clock on XCK.). More importantly, it still uses start and stop bits. and the selectable character size, not that anyone ever uses that feature even on normal UART. Aaaah interesting about the issue with the "greying out" thing. I wonder what the right way to show unambiguously (and in a way that people wouldn't have to be told what it means that is intuitively saying "this isn't really exposed for users, you'll have to do extra work to use it" A green outline seems to express the opposite, to me that would look like "You should use these pins in preference to others" There are no current or announced parts that allow you to remap the CCL input pins. Only the output. I don't think we want the IN0.1/IN1.1/IN2.1 markings. I don't expect such devices to ever exist, either. Whats with the third SPI mapping option then, you say you have a microchip case open about it? |
Beta Was this translation helpful? Give feedback.
-
|
I might have a solution to disabled signals. While the box color is doing a lot of work the text color isn't. Going from white to grey I think has the effect you were looking for: (not sure I actually disabled the right signals, more just trying to demonstrate the mechanism). Also replaced the bottom text with something mostly based on your version since I have plenty of room in the compact version. Also switched some signals to be black text. I am not sure it is an improvement on that front but if you have specific ones you want to see in white or black lmk.
|
Beta Was this translation helpful? Give feedback.
-
|
I think I have PWM correct on the ATTiny chips:
does this style of disable and marking both the IO and the specific signal with ∿ seem right? edit: noticed I forgot to add the include to the tiny-0 config. Added it and replaced the 1607 with one that has PWM. Tend to forget the forgettable. The T412 is failing because I don't know whether to mark WO0 or WO3 as being used on PA3 |
Beta Was this translation helpful? Give feedback.
-
|
I took a stab at PWM for all chips and marking other PWM signals as disabled. Haven't checked it carefully yet. Also cleaned up all the spacing and positioning of things like the o and the text. Removed the duplicative PIN numbers on the rectangular chips. Added proper text to all diagrams. Currently generating compact for everything except DD and spaced for DD. But it's a single line change to swap between them. Decided to generate style IO.3 until I hear otherwise because it is the most space efficient. Again, single line change to turn on a different option. https://github.com/ObviousInRetrospect/avr_pinout_diagrams/tree/main/svg has a full set of diagrams. Here is a DB32 so you can tell me my PWM logic is wrong.
Here is a DD32 since I have nothing to compare the PWM to and to illustrate the compact vs spaced rendering: The compact images allow me to make some of the smaller chips bigger to make things more readable (not done yet). In thinking through how GitHub's .MD display sucks though, I am thinking I should probably produce two sets of images. The first set will be printer-friendly with full information laid out on a single page per chip for distribution with the core and people to use standalone. The second set will be two cropped images for embedding in the .MD, one of just the chip. The other of just the legend. These would omit the bottom text which would move to the .md. By removing all whitespace from around the chip that should make GitHub stretch the image to the largest size possible |
Beta Was this translation helpful? Give feedback.
-
|
removed an obsolete series of posts below to try to make this more readable. The only thing they added was the explanation that the spaced version:
I am undecided whether this is a readability improvement or if the absence of whitespace hurts. |
Beta Was this translation helpful? Give feedback.
-
|
If you like the concept of generating a bare chip and legend without text to let GitHub stretch as non-horribly as possible: here are examples of a cropped svg: these were done manually by editing the viewport and size at the top of the svg but I know how to calculate the edits (and generate the appropriate pieces instead of the larger file with stuff that is cropped). the fonts being different all over the place is driving me somewhat crazy. I am working on figuring out how to embed a good font (menlo probably). I suspect you won't want them in the final diagrams but I populated a 4 in the IO box for pins present on the 3224 and a 6 for pins on the 3226 but not the 3224. This was because I was looking to develop my standard mux configuration for the 3227 and like to prioritize signals available lower down. The portmux for the ATtiny-2 series is highly disappointing. I suspect randomly assigning signals and alts to pins would have done a better job. UART0's default conflicts with the xtal. It's alt conflicts with UART1 (who the f#ck decided to put tx0.1/tx1 and rx0.1/rx1 on the same pins, when is that ever useful. If you are going to do that bs at least swap tx and rx on one of them) . UART0's alt conflicts with SPI0. UART1's alt conflicts with SPI1. So even on the 24-pin you can't get SPI + 2xUART + XTAL. Seriously unimpressed by the pins the 3227 adds to the 3226. |
Beta Was this translation helpful? Give feedback.
-
Hi,
i found the .gif files in the extras folder. If i can get a svg template I'm willing to do QFN pinout diagrams. Either side by side or as an extra .gif.
Btw. why gif? wouldn't png a more appropiate format?
Cu
David
Beta Was this translation helpful? Give feedback.
All reactions