New part—Arduino Pro Mini 3.3V (clone)

[UniquePete]

Arduino Pro Mini 3.3V (clone)

[mMerlin]

There are 3 Arduino Pro Mini parts currently in the parts database. The file in core are: Arduino-Pro-Mini_3.3v-v14.fzp Arduino-Pro-Mini_5v-v14.fzp Arduino-Pro-Mini-v13-a4+5.fzp

Is this functionally different? If not, just modify existing part files to include a blank part number, so that the source can be shown.

To make it easier to switch between variants, you should add matching properties to the fzp file here, and the existing parts. For starters, the voltage, and something to distinguish the clone part. Then inspector would switch between them without needing to find exactly the right on to initially place.

The existing parts have:

<property name='family'>microcontroller board (arduino)</property>
<property name='type'>Arduino Pro Mini (Rev14)</property>
<property name='type'>Arduino Pro Mini (Rev13)</property>
<property name='variant'>3.3V/8Mhz</property>
<property name='variant'>5V/16Mhz</property>

Either match (and extend) that, or change the existing parts to be consistent.

"Arduino Pro Mini 3.3V Clone" is not really a part number. I do not know which rev your clone is compable with. (v14 in the tag?) Maybe set the type property to "Arduino Pro Mini (clone)"? Or set the variant to "clone", but that needs the existing parts to be updated with a variant entry as well. What is that layer property for? What is the intent of the name=label property? Was that intended to be a label element instead? <label>Pro Mini</label>? Your existing label element is way too long. That is the prefix that gets used, with a sequence number appended, to show which of multiple copies of the same parts are being used.

Look at what elements, properties, tags are being used by the rest of the "microcontroller board (arduino)" family, and match as appropriate.

This was from a quick look at (only) the fzp file, plus a few searches of the part files currently in core.

The existing family:

Arduino_ADK_MEGA_2560-Rev3(fix).fzp
Arduino_ADK_MEGA_2560-Rev3(icsp).fzp
Arduino_bt07.fzp
Arduino_DUE_V02b.fzp
Arduino_Esplora.fzp
Arduino_Ethernet.fzp
Arduino-Fio-v22(fix)-bottom.fzp
Arduino-Fio-v22(fix).fzp
Arduino-Fio-v22(iscp+)-bottom.fzp
Arduino-Fio-v22(iscp+).fzp
Arduino_Leonardo_Rev3(fix).fzp
Arduino_MEGA_2560-Rev3(fix).fzp
Arduino_Micro_Rev03(fix).fzp
Arduino-Mini-v5.fzp
Arduino Nano3(fix).fzp
Arduino Nano3(icsp).fzp
Arduino_Pro.fzp
Arduino-Pro-Mini_3.3v-v14.fzp
Arduino-Pro-Mini_5v-v14.fzp
Arduino-Pro-Mini-v13-a4+5.fzp
arduino_Uno_Rev3(fix).fzp
arduino_uno(rev3)-icsp(1).fzp
arduino_uno(rev3)-icsp.fzp
arduino_Yun(rev1)_v1.fzp
HiFive1.fzp

[UniquePete]

The problem I have is that I'm really new to all this, so I almost don't know where to start with some of the suggestions you're making. I made this part in almost pure ignorance of all the things you've mentioned. I didn't even know about the internal file structure until @vanepp drew it to my attention. Up to that point, I thought all this stuff was managed through the Parts Editor. I didn't choose any of the descriptors for any other reason than that they seemed to be the sort of thing that I'd seen in other parts. I didn't realise there was that much structure in there.

So I'm happy for anyone to change anything they think isn't right, and I'll know for next time. If I have to make any changes, it'll take a little while for me to get across what I need to do.

I get what you're saying about there already being several versions in the core, but this one (the 'classical' Chinese clone) has a slightly different pin layout to any of them (that's the only reason I did it in the first place). But I don't know if that makes it a variant of one of the others or not.

So, where do I start...? Do you have a specific 'good' example that I could follow?

[mMerlin]

Good examples are hard to find. There have been too many people with varying knowledge doing the parts, and inappropriately doing copy/paste of pieces they did not understand. Some information can be found in the Make your own Fritzing Parts tutorial, near the end in the Metadata section. I disagree with their overly generic description of the value for "variant". Variants are variations, not sequential version numbers. Your clone, with different pins is a variant. And the text that is put in the field should reflect what that is, not just "variant 1", "variant 2". Variant is a catchall when something more specific is not really appropriate. Or pick one of the more specific fields, that should always have a value, and put it (consistently) in variant, just because some of the rules say a part should always have a variant property. I have no idea where that rule came from, or why.

As far as directly changing what you started, that is not likely a really good idea either. I do not know enough about the parts you are working with to choose the best values. I can see when some of the values should be different, because I researched what they are used for. But what the best values are is fairly open.

Almost anything that goes in the properties is going to show up as either a simple text display (if no other part in the same family also has that property name), or as a dropdown that can substitute the current part for one with the selected property value. Good name and good (range of) values makes getting the right version/variant/style/etc of the part a lot easier for users. Who often do not know what options are available. Different manufacturer part version and revisions are good candidates for properties. Things that make a specific part unique from others in the same family. Not just cosmetic labeling. That is in addition to what is put in the tags. What I saw in the tags in your part files looked reasonable. Possibly to be expanded based on what is discovered to be added to the properties.

It is not going to apply very well to your parts, but I recently created a family of parts for LED Matrix displays. 4 different sizes, 2 polarities (common cathode or common anode), 2 different pcb footprints, which makes 16 different part files that can be switched between by values in the inspector dropdowns. The files are "8x8_dot_matrix.fzp in core, and can be found in the parts library by searching for "8x8". There was only one existing part that matched. I used the family name from that, then obsoleted it, since one of my 16 matched it, but I had changed the schematic representation to match the standard 0.1 in pin spacing. (the original was at 0.2in). I created properties that corresponded to the features of the different parts. Including some doubled up. The properties have an entry for the size (dimension in mm or in) of the display, and another for the size of the individual dots. Those are 1 to 1. A single physical size always has the same dot size. But that lets the use select using either value. My "variant" in that was the polarity. The label on the old part was "DISP", and I saw no reason to change that. Label is short. The basic components of resistor, capacitor, transistor, chip have labels of R, C, Q, U. J gets used for headers and connectors. S for switch, T for temperature sensor.

For other elements, pick an example part, and compare what inspector, or rendered representation in each of the views show compared to what is in the fzp file. That will usually narrow down what is appropriate to use. Even a micro controller board does not need a label that is longer than the board is wide, when the important part is the final digit. The label could be reduced to "uC" or "mC", then uC1, uC2 is going to make more sense on the schematic. Just because I like to push things to the limits, "µC" :) The is the greek mu character, which is the "proper" prefix for "micro". "µA", "µF". Not really a good idea though, because too many pieces of code will not handle full utf-8.

If you want to see what values are currently used, and are on a linux (or mac) system, grep "<label>" core/*.fzp will dump everything. Do the same on obsolete folder for older entries. There are some other long names in that list that I do not think are appropriate. To see what is unique, without context, a start would be

grep -h "<label>" core/* | sort | uniq

That is not perfect, because leading spaces on some entries make them show up multiple times. Using sort without uniq will give a better picture of what is used more often.

For this case, the existing pro mini parts are a place to start, expanding to others in the same family for reference information. Same for the radio and wireless families. Use the existing parts for ideas, and what already exists, looking for opportunities to "do it better"™.

[mMerlin]

A more official source of information for the metadata is the Fritzing app wiki. Part file format has a section for the FZP format, but there are not a lot of details, the page has not been modified since 2017, and the fzp format content has changed very little since 2014. Which really just says that nothing has changed. The description of the property information could be a useful base. Notice that there is NO variant property in that example.

[UniquePete]

Thanks, that's all very helpful. What you say makes perfect sense. I simply didn't know/realise how that stuff was being used. I probably started with a bad example—it may have been a part that wasn't even in the core (which I knew nothing about at the time) to begin with (and so hadn't been through this level of scrutiny).

So, if I start with the "variant" issue (the others I think I can probably get a handle on based on your discussion above), how do I decide what "variant" the clone part might be? Actually, having had a look at the other Pro Mini parts, the clone is as different as the Rev.13 vs Rev.14 parts are to each other. That fact notwithstanding, I do see all the variants within the Rev.14 part but, to be honest, some of them seem totally irrelevant... The 3.3V/8MHz and 5V/16MHz variants are entirely logical (this is almost only a labelling difference—the board layout, I believe, is identical), but I can't see why the 'Modified pico' or 'rev 1' variants got singled out from all of the other Arduino boards as variants of the Rev.14 Pro Mini.

If I were to try to relate my 'clone' to the Rev.14 part, what variant would the clone become? There are actually 3.3V/8MHz and 5V/16MHz variants of the clone board too, so do these variants of the clone board become variants of one of the Rev.14 variants...? In reality, the clone board is more closely related to the current Rev.13 part, although the Rev.13 part currently has no variants... and the clone board has three extra pins on it...

If, then, the clone board is considered different enough to be another part, what would it then be called? I'm not sure that it's an actual copy of any particular revision of the original [open source] hardware. In fact, I have no idea where the Rev.13 and Rev.14 names came from. It may be prefectly reasonable for the clone board to be named Rev.15, but without knowing how the other Revs were determined, that might be being a little presumptuous. It's more like a branch off the original tree, but we've no real way of knowing where that might end up at this point in time. The Rev.14 board added two more pins to the Rev.13 board. The clone moved those two pins to a different physical location on the board and added an extra pin (and changed the physical appearance of a few other components).

I understand the problem with the proliferation of similar parts that should logically be grouped, but if it's reasonable for the Rev.13 and Rev.14 parts to be distinct parts (I can see argnuments both ways), I think it would be reasonable for the clone part to also exist in its own right. If the separation of the Rev.13 and Rev.14 parts is not in the spirit of the Fritzing universe, how do I choose which of these parts should be the base for the clone? And if the clone is to stand alone, is the "clone" suffix appropriate and/or sufficient to distinguish it from the other similar parts (given that it will have its own 3.3V/8MHz and 5V/16MHz variants)?

Maybe this is not a good example to be trying to learn from... in which case I'm still a bit lost. Once again, I get everything you're saying, I'm just struggling to find a logical structure (in this little corner of the Fritzing universe) to work with.

[vanepp]

"If I were to try to relate my 'clone' to the Rev.14 part, what variant would the clone become? There are actually 3.3V/8MHz and 5V/16MHz variants of the clone board too, so do these variants of the clone board become variants of one of the Rev.14 variants...? In reality, the clone board is more closely related to the current Rev.13 part, although the Rev.13 part currently has no variants... and the clone board has three extra pins on it..."

The last part of this is the important one. The board having 3 extra pins, indicates it should be a new part (IMHO at least) as the swap mechanism will try and swap it for a part with less pins and cause a red square in other views because of undefined pins. The speed variants aren't significant to Fritzing, the pin outs and operation are the same for all speeds so one part serves for all. We only need a variant if there are different pins or number of pins. Unfortunately documentation (and of late times people with experience making parts which is how we used to learn) are both lacking. I've made a stab at some documentation in this tutorial series in the forums, but we really need better documentation and even more so someone capable of and willing to spend the time needed to write it, and probably examination of the source code to figure out what it should say.

https://forum.fritzing.org/t/part-creation-howto-part-1-breadboard-and-pcb/7692/2

there are 9 parts to this currently and feedback on anything (which may be most things) that aren't clear would be welcome and I'll try and make it clearer.

[mMerlin]

Here is a cleaner way to see the existing labels. Add a pipe to filter the white space. Add | uniq to get only one line per label value.

grep -h "<label>" core/* | awk '{$1=$1}1' | sort

To gather information about the existing parts, create a new folder, cd into it, then

find path/to/fritzing-parts/core -type f -exec grep -q " name.*family.*microcontroller board (arduino)" {} \; -exec cp -t ./ {} +

will get a copy of all of the parts in that family. Then some more grep, awk, sort, uniq can collect all of the used property information.

Summary / suggestion for your part

• do not include a label element or layer property.

<property name="family">microcontroller board (arduino)</property>
<property name="type">Arduino Pro Mini</property>
<property name="part number"></property>
<property name="pins">35</property>
<property name="vcc">3.3</property>
<property name="clock">8MHz</property>
<property name="revision">Rev14+</property>
<tag>arduino</tag>
<tag>pro mini</tag>
<tag>rev14</tag>
<tag>ATmega328</tag>

Anything that is electrically different needs to be a unique part in Fritzing. Except for things like resistors that are generated from the 'factory'. That means different supply voltage, different pins, different placement (especially for pcb footprint) need separate fzp files. Changing the labeling on a pin, without changing its location or functionality does not need a new part. A different manufacturer that is fully electrically compatible does not need a new part. That can be handled by just using a blank part number property that can be filled in after the part is placed. Different positioning of the (sub) parts on the board do not need different Fritzing parts, if that does not change the electrical properties and connections. That is just cosmetic, as far as Fritzing is concerned. Depending what the differences are, those separate parts can use common icon, breadboard, schematic, and pcb view images. Even ALL of them, when the only difference is something like supply voltage. Which should be a different part, because it is electrically different. Each separate part needs a completely unique SET of properties. No 2 parts should have the exact same combination.

So, reasoning. Your description says this is almost a Rev14, with 2 pins moved and one added. There is no 'industry standard' for that case (that I know of), so I just added a "+" to indicate the extra pin. As mentioned, different manufacturer does not matter to Fritzing, so "clone" has no real functional meaning. Probably means it was made in China, but nothing functional. If details are useful, the information can be included in the description. I do not see a need for a variant property. What could go there, I suggested separate vcc and clock properties instead. If the existing part metadata was cleaned up (see below), the Rev14+ and pins count would each keep this part unique in the family.

The tags shown are a base set. I did not research details of your part, but I assume the chip is a ATmega328.

properties are used to differentiate between parts in the same family. Tags are used during searching, so can be the same in multiple parts, multiple families.

How I got there.

grep -h "<property.*name" *.fzp | awk '{$1=$1}1' | sort | uniq

Shows all of the unique property name values. Actually not quite unique, because using single and double quotes show as separate lines. The slightly (manually) filtered output from that is:

<property name="family">microcontroller board (arduino)</property>
<property name="layer"></property>
<property name="part number">HiFive1</property>
<property name="part number"></property>
<property name='type'>Arduino BT (Bluetooth)</property>
<property name="type">Arduino Due</property>
<property name="type">Arduino Esplora</property>
<property name="type">Arduino Ethernet Board</property>
<property name='type'>Arduino Fio (v22)(iscp)</property>
<property name='type'>Arduino Fio (v22)</property>
<property name="type">Arduino Leonardo (Rev3)</property>
<property name="type">Arduino MEGA 2560 (Rev3)</property>
<property name="type">Arduino MEGA ADK (Rev3) (icsp)</property>
<property name="type">Arduino MEGA ADK (Rev3)</property>
<property name='type'>Arduino Micro (Rev3)</property>
<property name='type'>Arduino Mini (Rev5)</property>
<property name='type'>Arduino Nano (3.0) ICSP</property>
<property name='type'>Arduino Nano (3.0)</property>
<property name='type'>Arduino Pro Mini (Rev13)</property>
<property name='type'>Arduino Pro Mini (Rev14)</property>
<property name="type">Arduino Pro</property>
<property name="type">Arduino UNO (Rev3) - ICSP</property>
<property name="type">Arduino UNO (Rev3) - ICSP (w/o icsp2)</property>
<property name="type">Arduino UNO (Rev3)</property>
<property name="type">Arduino Yun</property>
<property name="type">HiFive1 board</property>
<property name='variant'>3.3V/8Mhz</property>
<property name='variant'>5V/16Mhz</property>
<property name="variant">rev 1</property>
<property name="variant">variant 6</property>
<property name='view'>bottom-view</property>
<property name='view'>top-view</property>

A more specific search is needed to find out which parts are using a specific value.

grep -i "name.*layer" *

Finds 4 of these files have a layer property, all blank. I say, just leave it off.

grep -i "label" *

Shows that only 2 of those actually have a label. One is "Arduino", the other is "U". From memory of symptoms, I think that no label means that "Part" will be used (IE "Part1", "Part2"). The label does not need to be unique for (to) a family. Multiple part families can use the same label. That is very common for things like "U". I say, just leave it off.

The "view" properities are for (only) the Fio boards. Without more research, I do not know what the purpose of these are. Maybe separate top and bottom connection pins? Usually that is handled by 'x-ray' pins, so they can be connected to. Should only apply to the breadboard view. PCB view, you can already place parts on top or bottom of the board. You do not need this.

Looking over the details shown in the type and variant fields, this looks like it (existing) could be cleaned up a lot. Tags that are being included in the type field should be moved out into separate properties, reducing the number of unique type values. I am thinking: vcc (3.3, 5), clock (8MHz, 16MHz), revision (Rev3, Rev13, Rev14, v22), icsp (none, ICSP, «no»ICSP2). That would cover most of the cases I see, without digging into exact details, and the unique types dropping to BT (Bluetooth), Due, Esplora, Ethernet, FIO, Leonardo, Mega 2560, Mega ADK, Micro, Mini, Nano (3.0), Pro Mini, Uno, Yun, HiFive.

grep -h "<tag>" * | awk '{$1=$1}1' | sort | uniq

<tag>adk mega</tag>
<tag>Arduino Board Ethernet</tag>
<tag>arduino due</tag>
<tag>Arduino Esplora</tag>
<tag>Arduino Fio</tag>
<tag>arduino leonardo</tag>
<tag>Arduino Mega 2560</tag>
<tag>Arduino Micro</tag>
<tag>Arduino Nano</tag>
<tag>Arduino Pro</tag>
<tag>Arduino</tag>
<tag>arduino</tag>
<tag>Arduino UNO</tag>
<tag>ATmega168</tag>
<tag> ATmega 2560</tag>
<tag>ATmega2560</tag>
<tag>ATmega328</tag>
<tag>ATmega328V</tag>
<tag>Atmega32U4 AVR</tag>
<tag>ATmega32u4</tag>
<tag>ATmega3uU4</tag>
<tag>Atmel SAM3X8E ARM Cortex-M3</tag>
<tag>Bluegiga WT11</tag>
<tag>Bluetooth</tag>
<tag>BT</tag>
<tag>Eth-Board</tag>
<tag>HiFive1</tag>
<tag>icsp</tag>
<tag>microcontrollerboard</tag>
<tag>mini</tag>
<tag>pro mini v13</tag>
<tag>pro mini v14</tag>
<tag>REV 3</tag>
<tag>REV3</tag>
<tag>rev3</tag>
<tag>RISC-V</tag>
<tag>riscv</tag>
<tag>RJ45</tag>
<tag>uno</tag>
<tag>V1.0</tag>
<tag>Yun</tag>

grep -h "<tag>" Arduino-Pro-Mini* | awk '{$1=$1}1' | sort | uniq

<tag>arduino</tag>
<tag>ATmega168</tag>
<tag>ATmega328</tag>
<tag>pro mini v13</tag>
<tag>pro mini v14</tag>

[mMerlin]

The speed variants aren't significant to Fritzing, the pin outs and operation are the same for all speeds so one part serves for all. We only need a variant if there are different pins or number of pins.

Fritzing does not (currently) care about speed (and voltage) variants. The user can care though, since mixing voltages, or speed mismatches can cause problems. Which can all be handled by the part number field.

The currently above, is because of the spice element. If circuit simulation ever gets integrated/interfaced, the speed and voltage become important.

Whether that needs a separate Fritzing part is open for discussion. Something I would like to see in Fritzing, would say a single part is correct, but needs an enhancement to the properties information to specify attributes and possible values. So a single part, but be able to select vcc of 3.3 or 5. Only the metadata changes, so a single part with a range or selection of values for one attribute (or some attributes) handles both the physical and electrical information.

Electrolytic Capacitors are a simple example. The actual parts used better have a high enough voltage to work with the circuit being built. But the physical size, pin position, pcb footprint, schematic symbols do not change for a wide range of voltage values. At the same time, it is good to be able to show the intended voltage of the component in the schematic. Based on component properties settable in inspector. Instead of adding "16V" text string parts. Capacitor is one of the factory components. It does have a voltage property with values selectable in the Parts Inspector. Other (non-factory) parts should have the same capability.

[UniquePete]

So, to be clear, are you suggesting that I should amend the .fzp file to replace the initial elements with the following?:

<title>Arduino Pro Mini</title>
<date>Fri Mar 6 2020</date>
<tags>
    <tag>Arduino</tag>
    <tag>Pro Mini</tag>
    <tag>Rev14</tag>
    <tag>ATmega328</tag>
</tags>
<properties>
    <property name="family">Microcontroller Board (Arduino)</property>
    <property name="type">Arduino Pro Mini</property>
    <property name="part number"></property>
    <property name="pins">35</property>
    <property name="vcc">3.3V</property>
    <property name="clock">8MHz</property>
    <property name="revision">Rev14+</property>
</properties>
<taxonomy>part.devmod.35.pins</taxonomy>
<description>he Arduino Pro Mini is a microcontroller board based on the ATmega328. 
It has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, an on-board resonator, a reset button, and holes for mounting pin headers. A six pin header can be connected to an FTDI cable to provide USB power and communication to the board. There are two version of the Pro Mini—3.3V/8MHz and 5V/16MHz.</description>

Are the title and taxonomy elements correct (I'm assuming that everytihng else is OK)? And do I just then submit an appropriate pull request to have this update included in the part that was previously submitted, although I will presumably also change the names of the part files to remove the reference to "clone" (and 3.3V?—so should I just end up with files based on the name "Arduino Pro Mini"?)? Or am I supposed to be modifying the Rev.14 part in some way, in which case how do the relevant breadboard and pub files get included?

Thanks for all your help. The first one is always the most difficult...

And thanks @vanepp, I'm working my way through your tutorials.

[mMerlin]

Pretty close. @vanepp might have some input. He has been creating parts for longer. The description has a typo. "he Arduino" should be "The Arduino" That looks like the generic pro mini description. Somewhere in there should be some information about the pin differences from the standard pro mini for this part.

My information is that the title is the place to be a bit more unique. The existing pro mini part titles are:

<title>Arduino Pro Mini (3.3V)</title>
<title>Arduino Pro Mini (5V)</title>
<title>Arduino Pro Mini v13</title>

Might as well follow along for this case. If the voltage is in the tags and properties, it should probably be in the title too.

Taxonomy I have not yet gotten good information on, about how it is intended to be structured and used. Anything I say there is just guessing.

No new pull request should be needed. Just make the changes, commit, and push to your github repository branch. The existing pull request will see the changes and recheck. The part file name has to stay unique, clone in the name there is fine. Or at least a valid option. For future reference, there are some guidelines for naming the image files. See on "4. File Naming Conventions" (almost) at the end of Fritzing Graphic Standards page. The part file name has to stay unique across all parts, all families. Which means combining enough details to keep the file name different from any other similar part. Being descriptive makes finding part files to look at easier, without needing the kind of content searches I demonstrated above. Don't trust that the file names are reasonable though. Cross check with searches for at least family once you think you found the interesting part files.

With those 3 pins being different from rev 14, you will need unique image files (except icon could have been the same), which need their own names. Which could have started as copies of the existing images. If those were "clean", the changes would have been small. If the same images could have been used, just need to point to them in the image attribute of the appropriate view.

For this case, I have seen a lot of way worse image file names. Since the images images are the same regardless of the voltage, the "3V3" part of the names are not needed. The same image works for 5V. Whether that is actually a separate part, with different metadata, or not. Some reference to the difference from rev14 should be in the image name, since rev13, rev14, and this all need different images. From the existing pro mini parts, the image names are:

<layers image='breadboard/Arduino-Pro-Mini_breadboard.svg'>
<layers image='breadboard/Arduino-Pro-Mini-v13_breadboard.svg'>
<layers image='pcb/Arduino-Pro-Mini_pcb.svg'>
<layers image='pcb/Arduino-Pro-Mini-v13-a4+5_pcb.svg'>
<layers image='schematic/Arduino-Pro-Mini_schematic.svg'>
<layers image='schematic/Arduino-Pro-Mini-v13_schematic.svg'>

There is no icon image in that list, because the breadboard image was also used for the icon. A design choice. Again, future reference, search for similar/related existing parts, and see what was done there. Right or wrong. Don't just use what was done before, if that is not following the rules, but unless there is a good reason, try to be consistent.

If the existing is bad enough, consider cleaning that up along with adding your own part. Force some consistency in that group. Though that might mean working through what is needed to obsolete a part. That would depend on what sort of fix is needed. Which is being/has been discussed recently, but not really finalized.

[UniquePete]

OK, got all that, I think...

Typo corrected, and description augmented to include the difference between this and other parts:

<description>The Arduino Pro Mini is a microcontroller board based on the ATmega328. It has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, an on-board resonator, a reset button, and holes for mounting pin headers. A six pin header can be connected to an FTDI cable to provide USB power and communication to the board. There are two versions of the Pro Mini: 3.3V/8MHz and 5V/16MHz. The present variant differs slightly from the original Pro Mini in that the A6 and A7 pins, together with an additional ground pin, have been moved to the edge of the PCB adjacent to the reset button.</description>

How about "Arduino_Pro_Mini_Clone.fzp" for the name, although if you think it's worth creating two different parts, pointing to the same image files, for 3V3 and 5V versions, they could be "Arduino_Pro_Mini_Clone_3V3.fzp" and "Arduino_Pro_Mini_Clone_5V.fzp". Yes?

Then the .svg files (they are different to anything there at the moment—that was the motivation for this exercise in the first place) could simply be prefixed with "Arduino_Pro_Mini_Clone". I originally did as you suggested and looked at existing names. I vacillated between spaces, no spaces, underscores and hyphens, because all are variously used. I know the other Pro Mini modules seem to use hyphens, but after flipping and flopping and considering all the parts I was creating, I ended up with underscores... If there is a preferred method of dealing with 'spaces', and it's not using underscores, please let me know and I'll fix all of my parts accordingly.

[mMerlin]

Arduino_Pro_Mini_Clone.fzp, Arduino_Pro_Mini_Clone_3V3.fzp, Arduino_Pro_Mini_Clone_5V.fzp, Yes?

Yes.

The naming conventions page I referenced uses underscores. Which I like, but mostly because of what some tools I use consider to be word boundaries. No real strong personal preference.

[KjellMorgenstern]

How about an excel sheet to see if we can get to a classification that makes sense?

The currenct Microcontroller Board classification in Fritzing is not very clean. Example: "Arduino1" has "variant", which can be "3.3V/8Mhz", "5.5V/16Mhz", "Modified pico", "rev1" and "variant6". What a mess :-) I think it can be cleaned up without having to obsolete/replace them.

I think the suggestion from Pete is already much better:

<property name="family">microcontroller board (arduino)</property>
<property name="type">Arduino Pro Mini</property>
<property name="part number"></property>
<property name="pins">35</property>
<property name="vcc">3.3</property>
<property name="clock">8MHz</property>
<property name="revision">Rev14+</property>

And yes, the title should be more unique. It should be the criteria by which users can order it from shops.

In theory, all the above mentioned properties could be combined:

vcc	clock	revision	form factor/type
3.3V	8M	rev14	pro mini
5.5V	8M	rev14	pro mini
3.3V	16M	rev14	pro mini
5.5V	16M	rev14	pro mini
3.3V	8M	rev14+	pro mini
5.5V	8M	rev14+	pro mini
3.3V	16M	rev14+	pro mini
5.5V	16M	rev14+	pro mini

I am not sure what "revisions" refer to, I'd have guessed that are hardware revisions from Arduino.cc. The number of PIN criteria makes sense, and maybe instead of rev14+, try to find some reference to the manufacturer or pcb desing used. What do you intend the "part number" to refer to?

[mMerlin]

I think it can be cleaned up without having to obsolete/replace them. I think the suggestion from Pete is already much better:

Actually my suggestion that Pete was confirming. Glad you liked it. I like that form factor property. For some of the revision distinctions, the pin count is useful. Normally the revision implies the pins and vice versa, but being explicit doesn't hurt. Going "overboard" we could add analog, pwm, digital, (pin count) property names, to include details normally only seen in the description.

Looking over the details shown in the type and variant fields, this looks like it (existing) could be cleaned up a lot. Tags that are being included in the type field should be moved out into separate properties, reducing the number of unique type values. I am thinking: vcc (3.3, 5), clock (8MHz, 16MHz), revision (Rev3, Rev13, Rev14, v22), icsp (none, ICSP, «no»ICSP2). That would cover most of the cases I see, without digging into exact details, and the unique types dropping to BT (Bluetooth), Due, Esplora, Ethernet, FIO, Leonardo, Mega 2560, Mega ADK, Micro, Mini, Nano (3.0), Pro Mini, Uno, Yun, HiFive.

:) Mostly covered by my thought stream in the earlier comment. And yes, the "rev" is an arduino hardware revision number, when pin counts changed a little. Adding in rev13 to the table you showed for pro mini. Need to add more if expanding to include more of the parts in the existing "microcontroller board (arduino)" family. The rev number (sequence) is unique to the base form factor, so in theory, 2 different form factors could have the same rev number. Typically not though.

As far as changing the existing parts, without obsoleting, I think it should work, and not be against any of the current rules. This is metadata only changes, so the only thing that will notice it is the inspector. Assuming not changing label, or anything else that would affect the views.

That said, the existing functionality DOES allow property values to be displayed in the part labels. So any property that gets removed or modified in the cleanup can potentially change existing sketches. Which would imply the use of obsolete. If only adding properties, no impact to existing sketches. Unfortunately, the "type" property is in that list, so any change to that leads to sketch changes. IF anyone has been using that feature, with that property name. Reversing my thought above, I think this will need to assume obsoleting most of the part files, but not the image files.

And it would suddenly become useful to have the obsoleting "replacedBy" attribute apply to the properties. So property names could be changed, and values follow along to the new name.

Part number is just a general place to put an identifier, when a compatible part can be ordered from different vendors, that may use different identifier numbers. Happens even when the part is from the same manufacturer, but sourced through different outlets. The outlets often have a part number that is not the same as the manufacturer.

[UniquePete]

Not actually wanting to make this any more complicated than it is, a quick 'net search reveals at least two more 'clone' configurations out there, one with 36 pins (from 'Sumozade') and another with 40 pins (from 'Deek_Robot'). The one my part is modelled on is branded 'The Simple', so they all have differentiating branding. But if I were to consider how we'd extend the 'Rev14+' approach to revisioning, I'm not sure I could come up with a satisfactory solution—Rev14++ and Rev14+++?

Would it work to simply use the branding as the revision? 'The Simple'/'Sumozade'/'Deek_Robot'? Or use something other than revision (manufacturer, as suggested earlier, would obviously work in this case) to differentiate the different configurations? I'm not offering to create all of those parts at this point in time, but it would obviously be good if we could accommodate known variants in whatever we decide now.

Would the following work?

  <title>Arduino Pro Mini Clone (3V3)</title>
  <date>Fri Mar 6 2020</date>
  <tags>
    <tag>The Simple</tag>
    <tag>Arduino</tag>
    <tag>Pro Mini</tag>
    <tag>ATmega328</tag>
  </tags>
  <properties>
    <property name="family">Microcontroller Board (Arduino)</property>
    <property name="type">Arduino Pro Mini</property>
    <property name="manufacturer">The Simple</property>
    <property name="part number"></property>
    <property name="pins">35</property>
    <property name="vcc">3.3V</property>
    <property name="clock">8MHz</property>
  </properties>

with file names:

Arduino_Pro_Mini_Clone_3V3.fzp
Arduino_Pro_Mini_Clone_icon.svg
Arduino_Pro_Mini_Clone_schematic.svg
Arduino_Pro_Mini_Clone_breadboard.svg
Arduino_Pro_Mini_Clone_pcb.svg

The 5V/16MHz variant (the voltage and processor speed are 'coupled') would then be differentiated by:

  <title>Arduino Pro Mini Clone (3V3)</title>

    <property name="vcc">5V</property>
    <property name="clock">16MHz</property>

and use the metadate file:

Arduino_Pro_Mini_Clone_5V.fzp

which would point to the same image files.

But as I type all that, I ask myself "What would we then name the other clones, which also come in 3V3 and 5V variants?"... Maybe we need to include the number of pins (I'm sure that was also suggested in one of the conversations we've been having today)...

Arduino_Pro_Mini_35pin_Clone_3V3.fzp

Then, would he moduleId also have to include the pin count?

moduleId="Arduino_Pro_Mini_35pin_Clone_3V3"

[vanepp]

@mMerlin " Notice that there is NO variant property in that example."

I think the lack of variant in the part file format is an oversight and/or document didn't get updated (which we probably should correct). My sense is that the docs haven't been updated in a long time, even when they should have been, but I also wasn't around when development was still going (I arrived in 2016 just after the 0.9.3b release when development had effectively stopped.) Parts editor will not let you save a part without a variant field, which implies to me that the variant is a required field by something in the code:

Here I replaced the "variant 1" with a blank and parts editor complains (same happens with lack of a family). We would need to check the source (which isn't likely to be easy) to be sure, search for the error message and try and figure out what can trip the message is my usual plan, but I expect that warning is there for a reason and something will break if it isn't present. Could be Inspector, or could be the swapping mechanism (which I don't understand very much at all.) that substitutes parts, sometimes unexpectedly, I have seen messages of the form "exact part match not found, closest part substituted" on parts that should be complete and present. I have never found the time to dig in to the source to figure out why there wasn't a match as it seems to work (I get the part I expect.) I think documenting what the various options do or were supposed to do (i.e. Taxonomy, which I also have never understood nor heard explained by any of the more experienced folks when they were still posting) would be a good bet. My grand plan when I started the part check script all those years ago was (and still is) to then do a clean up of core parts to make them match the standards. Many parts in core are just plain broken in various ways and some of them are way more complex than they need to be. That task got delayed by me trying (unsuccessfully) to restart development, since without development there isn't much point in a parts cleanup as Fritzing was going to die of bit rot as libraries got out of date. Development has been successfully restarted, so I'm back to trying to clean up and improve the check script before considering starting to clean up core parts (since I think core parts will need to be cleaned up to put the parts check script in to the part submission chain.) That is going slow I've been in operations all my working life and development is new to me.

@mMerlin :

"See on "4. File Naming Conventions" (almost) at the end of Fritzing Graphic Standards page. The part file name has to stay unique across all parts, all families. Which means combining enough details to keep the file name different from any other similar part."

This one I know the reason for. The issue is the parts repository. The various files (fzp, and the 4 svgs) need to be unique in the repository directories (and have a unique moduleId although that is elsewhere). One enhancement for the parts script is to check the current repository for an existing file conflict. That of course is complicated by needing to be able to update an existing part by obsoleting the current file and I haven't yet gotten to figuring out how to do that. As well I want to be able to take a .fzpz file as input and write it (translating the file names on the way by between the two formats) to the repository to make submitting a part to core easier.

@KjellMorgenstern : "And yes, the title should be more unique. It should be the criteria by which users can order it from shops."

I prefer to use the url field for this purpose, although it isn't perfect (the url may die over the life of the part, or the ebay listing may expire.) I tend to use the url of where the part was built from as many of the ebay generic parts have multiple formats all called the same, at least with a url you may be able to tell where to order the one that this part describes. Otherwise you need to look at the parts til you find a part that matches what you have. As well I would prefer for the part to have a label field (the default "part1" is ugly in my view), for modules I tend to use "Mod". This isn't prefect because the numbering appears to start from the first of this particular part. So if I have a standard 1/4watt resistor it becomes "R1", but if I also have a 5W power resistor (which is a different part but also has label R) it will also start as "R1", giving two R1s in the same sketch. I expect this would need to be addressed by a code change of some kind, to either keep a "next value" for a label (independent of what part it is part of) or something I haven't though of yet .

[KjellMorgenstern]

I have filed an issue about that “So if I have a standard 1/4watt resistor it becomes "R1" in fritzing-app

[UniquePete]

I was going to suggest something similar in relation to the label, since I never really liked seeing everything labelled as 'Part', but where are we then on the variant?

From my simplistic 'outside looking in' position, and acknowleding all the discussion so far, it would seem to me that the most logical variant descriptor in this case, assuming one is required, would be the voltage/clock speed—note that the two are coupled, so there would be a 3.3V/8MHz variant and a 5V/16MHz variant, and these variants would exist for most 'pin configurations' (original and clones) that I've seen to date. My boards also seem to have a check-box (on the silk screen) for a 20MHz processor, but I've never encountered one of them in my limited exposure to the Pro Mini.

And one more question on properties, what is the purpose of an 'empty' property (in this case, the "part number")? I do have part numbers for some of my parts, but not for this one. Is this just a place holder, in case one appears at csome later date? That seems reasonable to me, but I wondered if there was some other reason—like something requires a 'part number' property somewhere along the line.

[mMerlin]

@UniquePete Including a blank part number property provides a box in Inspector where a part number can be filled in. Which can then (optionally) be included in the labels displayed in the view. Some Fritzing parts could have multiple different part numbers, depending on the manufacturer, or sometimes on the outlet it is purchased from. In those cases, it is not appropriate to fill in an actual part number, because the (Fritzing) part can be used with other (electronic) part numbers. Supplying an actual part number in the properties allows it to be displayed in the view labels, but it can not be changed. Well, not changed without making a new copy of the Fritzing part. If a compatible / direct replacement part, with a different part number, could be used, a blank part number is the way to go, because that can be edited when used. If the Fritzing part will only matched a single physical part, with no clones, no direct substitutions, then the matching part number can be filled in. Those LED matrix parts I have mentioned a few time were based on a part that was a red led matrix, with a specific part number. However the Fritzing part does not care if the red, yellow, green, blue, etc matrix is used, so the part number is blank. Fill it in to match what you are actually using for the project. Schematic and PCB footprint are the same. Potentially, the breadboard and icon images could be different, to show the colour, but that is purely cosmetic. I just built it with 'white' dots.

For variant, I have built and testing parts locally without a variant property. They worked fine for as far as I took them. I have not used the Parts editor since initial attempts ran into too many limitations for what I was trying to do. I just build the fzz (xml) with combinations of manual editing, copy + paste, and occasionally scripted templates. So I do not know if variant is really needed, under what conditions, or if that rule is just hanging around in the parts editor code, but is no longer appropriate.

With this part, staying safe and keeping a variant property, "I" like variant as "The Simple". In the context of what 'variant' means, that seems closest. The voltage and speed are used for variant in a few other existing parts, so it makes a good choice for consistency. Until the whole set of families is cleaned up make them match better. But since that is not defined yet, 3.3V/8MHz makes a good variant today.

You have a property name 'manufacturer' with a value of 'The Simple'. Isn't "The Simple" closer to a model than a manufacturer? Just going by what I have been reading in other posts here. Here, again "I", like revision, because that is really an alternative to the rev13 or rev14 of the original? core? base? pro mini boards. Instead of the rev14+ I initially suggested, but was pointed to run into issues with other similar but different variations.

[UniquePete]

Yes, model would probably be better I think, whether or not it also happened to be the manufacturer. I think there's probably a bit more flexibility there.

All up then, that seems to leave us with:

<module fritzingVersion="0.9.4" referenceFile="Arduino_Pro_Mini_35pin_Clone_3V3.fzp" moduleId="Arduino_Pro_Mini_35pin_Clone_3V3">
  <version>1</version>
  <title>Arduino Pro Mini 35pin Clone (3V3)</title>
  <label>Mod</label>
  <tags>
    <tag>The Simple</tag>
    <tag>Arduino</tag>
    <tag>Pro Mini</tag>
    <tag>ATmega328</tag>
  </tags>
  <properties>
    <property name="family">Microcontroller Board (Arduino)</property>
    <property name="type">Arduino Pro Mini</property>
    <property name="model">The Simple</property>
    <property name="part number"></property>
    <property name="pins">35</property>
    <property name="variant">3.3V/8MHz</property>
  </properties>
  <taxonomy>part.devmod.35.pins</taxonomy>
  <description>The Arduino Pro Mini is a microcontroller board based on the ATmega328 and originally produced by Sparkfun in two versions: 3.3V/8MHz and 5V/16MHz. The Pro Mini is an open hardware platform with variants made by several manufacturers. The present, 35-pin variant differs slightly from the original Pro Mini in that the A6 and A7 pins, together with an additional ground pin, have been moved to the edge of the PCB adjacent to the reset button.</description>

Will this work?

[vanepp]

@UniquePete : "Will this work?"

Yes, it looks like a good solution to me. Note the variant field needs to be unique among all the parts in the family. I also don't know if variant is actually required for anything, it is entirely possible that it was "required" for a future function not yet implemented in parts editor, but having one in the part should not hurt and will prevent confusion if someone tries to edit the part with the new parts editor at a later date and doesn't know what variant to add to get parts editor to accept the new part.

[UniquePete]

@vanepp, the variant in this case, 3.3V/8MHz, would only be unique for this model/pin configuration. Most of the Pro Mini boards that I've seen come in 3.3V/8MHz and 5V/16MHz variants, so any particular model or pin configuration would likely come in these two variants, but they would all be part of the same "Microcontroller Board (Arduino)" family. Will that be a problem?

[mMerlin]

When I did the display parts, I was asked to remove the referenceFile attribute. Apparently it only applies to custom parts, not parts that are being added to the library.

If variant really needs to be unique across the family, then I am not sure what to suggest there. @vanepp Why does variant need to be unique? It is not unique in the "matrix display" family I did. I used the polarity, "column cathode" and "row cathode" for the variants, and there are 8 of each in the family. For those parts, unique is only found by combining 3 of the properties. matrix size + pcb pad + variant. So far, no issues have been found with that. So, is it variant that needs to be unique, or the whole combined set of properties? I have always thought it was the whole set. Maybe variant needs to be unique only if it is the only property with an expilict value, other than family (explicit to ignore blank part number fields). title needs to be (or at least should be) unique.

[vanepp]

@mMerlin "Why does variant need to be unique? "

As usual that is an assumption (possibly wrong) on my part. The usual reason for a variant is to have a selector field in Inspector to select between parts in the same family. Obviously two parts with the same variant field won't select in the pull down menu (although I admit to not having tried it to see what will happen, but I don't think you will be able to select one or the other) so I have always assumed it needs to be unique even if that isn't checked for. It is also possible that one of the experienced part makers told me that it needs to be unique when I first started making parts and they were still around to answer questions. This is another of the many things where we need to read the source (which is hard!) to figure out what is and is not safe to do. I expect the original developers knew from experience what to do and not do, but the knowledge has now died due to no more original developers and no more experienced parts makers posting in the forums to correct us with why not to do that (which is what used to happen when I first came to Fritzing), that is how I learned most of what I know, and why I have made the tutorials so at least it is written (if poorly) somewhere if I go as so many others have. I'm old, I could fail to wake up tomorrow.

[mMerlin]

The usual reason for a variant is to have a selector field in Inspector to select between parts in the same family

The combination of selections from all of the properties shown in Inspector are what determine the specific part. If variant is the only selector, then yes it needs to be unique. If there are multiple selectors, then there needs to be a unique combination. Which is how the matrix display family works. As long as no 2 parts (in one family), have the same combination of dropdown selectors (property name value pairs), then the part can always be differentiated, and selected, from other parts. You just need to select the right value from every selector.

Actually, a value from each selector that makes up that unique combination. Once a unique combination is selected, any other property fields will be filled in to match. So if pcb pad, variant, and matrix size values are selected, dot size will be filled (based on matrix size). If pcb pad, variant, and dot size values are selected, matrix size will be filled (based on dot size).