This post was flagged by the community and is temporarily hidden.
The main problem is that the bus configuration in the fzp file is incorrect, a number of the pins don’t exist (which may mean that others are bused in correctly). The svgs are not at the correct scale. Breadboard is missing connectors for the IoRef connector and that connector is missing from pcb. Things that aren’t quite right but won’t break things: connectors should start from pin 0 not pin1 and be contiguous (this does break things in pin number display, I didn’t look closely enough to see if the pins are contiguous or not). In schematic I generally prefer the layout match the pinout in breadboard so the connection is obvious but it is your choice. The PCB hole sizes are a little large (.1 headers are usually 0.038in holes, yours are a bit bigger than 0.04). When I finish some other part creation I can correct what I see is wrong or you can do it as you choose. There is information on scaling and documentation in the dht11 humidity sensor post I just replied to so I won’t repeat it here.
Many thanks for your feedback and the references. I found the https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format extremely helpful.
I am a newbie in Fritzing and not sure if I correctly understood all your points:
Re: “The main problem is that the bus configuration in the fzp file is incorrect, a number of the pins don’t exist (which may mean that others are bused incorrectly).”
For HiFive1 part creation, I used the arduino_Uno_Rev3.fzp as the reference file. The only differences between the two fzp files are the removed twelve pins belonging to the ICSP1 and ICSP2 connectors that are not needed for the HiFive board. The buses sections are identical between two files. What am I missing?
Re: ”The svgs are not at the correct scale.”
I have derived the HiFive1 svgs from the arduino_Uno_Rev3 svgs. Could it be that the Arduino UNO svgs are also not at the correct scale?
Re: “Breadboard is missing connectors for the IoRef connector and that connector is missing from pcb.”
Correct, not really needed it. It is a jumper selecting 5V vs 3.3V that can be specified in the notes. It is just a picture with no holes under it in the PCB. Will see if I can fix it easily.
The reason I created this part was to use it for connection diagrams in HiFive1 tutorials and it serves this purpose very well. While the Breadboard and Schematics views are very useful, the PCB view is not really needed. I am wondering what is the reason of having the PCB view for board parts like Arduino UNO board?
Welcome aboard, I’ll try and not scare you off from parts creation
The Arduinos have a number of issues, such as non contiguous connectors. At some point I hope to clean them up, but haven’t gotten there yet. At the bottom of the fpz in the section marked bus, there is a list of pins that are internally connected together. When I ran the fzp file through my part checking python script (available on github), it complains that some of the bus connectors don’t exist:
<buses> <bus id="+5v"> <nodeMember connectorId="connector40"/> <nodeMember connectorId="connector46"/> <nodeMember connectorId="connector87"/> </bus> ...
This indicates that connectors 40 46 and 87 all connect together internally (clicking on one will light up all the others in yellow to show an internal connection). The check script doesn’t think that pin 40 exists. This may imply (I’d need to look more closely that I did initially to be sure) that there are pins that shouldn’t be bused together.
Error 53: File
At line 536
Bus nodeMember connector40 does’t exist
Error 53: File
At line 537
Bus nodeMember connector46 does’t exist
Error 53: File
At line 541
Bus nodeMember connector44 does’t exist
I see this morning that I also missed some complaints about pcb having ellipses rather than circles (which causes no hole to be generated in the gerber output):
Error 65: File
At line 2259
Connector connector2pad is an ellipse not a circle, (gerber generation will break.)
Error 74: File
At line 2259
Connector connector2pad has no radius no hole will be generated
Error 65: File
At line 2267
Connector connector3pad is an ellipse not a circle, (gerber generation will break.)
Error 74: File
At line 2267
Connector connector3pad has no radius no hole will be generated
Yes, many parts even in core are not the correct scale. In practice it doesn’t hurt anything, Fritzing will adjust to what ever scale is used. It does interfere with the check script being able to check part alignment though. Again long term I hope to correct the parts in core.
If the part suits you then that is really all that is important. The reason for pcb view is that people do make boards that a Arduino is soldered in to as part of a larger project. I expect that same will be true of this board so it is desirable to have an accurate pcb layout so that can be done. It doesn’t always make sense to do that, in which case there are a variety of ways to surpress pcb view. I’m just about finished making a part for the Arduino MKR Vidor 4000 FPGA board, once that is done I’ll have a closer look at this part and perhaps fix up some of its issues. Unfortunately much of parts creation isn’t (yet) documented, so it tends to be passed along in posts here (that’s how I learned to make parts ).
OK below is how I would make the part if someone had asked for it. Please use it as a base (if you don’t like some of the changes I made) as it is internally a better part. Changes to breadboard are: I converted the names to be the same as the picture of the pcb on the web site so they match the physical board (you may want to change them back if there is a reason they were different in your part). I changed all the pins from female to male except the ioref pins. Male is the normal connector type in breadboard and will automatically connect to the breadboard if placed on top of it. The 3 ioref pins however would short if inserted in a breadboard, so they are set female so they will not automatically connect, you need to attach a wire to them to get a connection. Icon: I changed to the standard copy of the breadboard file, but I see that your original had a custom logo file instead, just copy the original icon file in to the icon file in the fzpz file if you would like to keep the original icon. Schematic has changed substantially. I favor a schematic which matches the layout of breadboard and pcb as it makes debugging easier so I changed to that format. As well space in schematic is at a premium so I reduced the size of the part as small as it would go given the text on the pins. I also added the ioref pins (as being easier than supressing the pins). I also shortened the pins a bit. PCB got worked over as well. I added the 3 ioref connectors because if someone wants to mount the board on a larger PCB (which is done with UNOs) the ioref pins will be hidden. I changed the pad sizes to be the standard 20thou width and 0.038 hole suitable for .1 header connectors. I removed all the printing and changed the outline path to have no fill because the Fritznig gerber processing was giving a solid color for silkscreen with no connector outline of mounting hole circles. I also corrected the bus definitions so the the grounds, 3.3V and 5V pins are bused. If you click on a bused pin in any view it and all the other members of the bus will light up yellow. If there are any other shared pins they should be bused as well, but I didn’t see any.
HiFive1_improved.fzpz (48.6 KB)
WOW, it was really fast! Will check your version shortly.
Meanwhile, I also did some progress with the part addressing the issues you pointed in the first place and some of the fixes you mentioned in your last post including the addition of new buses.
Yesterday, I submitted a pull request with the fixed version of the part into fritzing-parts GitHub (pull request #167).
Also attaching it here for convenience.
HiFive1.fzpz (64.7 KB)
Once you get over the learning curve (which is fairly steep) , parts creation is fairly easy. That is why I tend to make parts for folks that ask, its easy for me, but not necessarily for them.
Some comments after reviewing the HiFive1_improved.fzpz part:
I am wondering why one would like to do this in Fritzing if it cannot be done with a real board?
The intention is to stick to the Arduino UNO Rev3 part style as much as possible in terms of look and feel. This was the reason for deriving this part from the Arduino UNO Rev3 part.
The UNO uses female pins and it works great for people currently using it. Our board is very similar in design and so we want to build our part as close as possible to their general design.
I used the breadboard image in the first drafts but finally prefered the SiFive’s logo to mimic the Arduino UNO board icon style.
In the schematics component, the multiple physical pins like GND, VDD and similar are usually represented by a single “logical” connection. This also reduces the number of connection points of the component (in our case by 7) allowing shrinking its size even more. For example, having several 3.3V connections to the component in the schematics view could be misleading making one think that these connections were separated intentionally since perhaps are originated from different power sources with different current capabilities… For this reason, I think it would be better to stick to the Arduino UNO schematics view layout.
Yes, I did it as well in the pull request. (the site does not allow to post a link to the pull request, sorry).
Sure, there are additional buses - SCL, SDA, IOREF as can be seen in the fzp file in the pull request.
I think we should continue this collaboration on the Fritzing parts GitHub.
While I wasn’t here in the early days of fritzing, I think the idea is that it does match the real world. When you push a part in to the breadboard it connects in the real world, you can’t push in Fritzing so this does the same thing. The reason for female pins is that when you have a perpendicular row of pins, if the autoconnect rule applies the pins will short (because of the breadboard strip connecting vertically) which is unexpected by new users. If you wish to leave the pins female it is not a big deal (your part, your rules ) either way will work. It is just more common to use male pins and only use female when there is a reason to.
Again no big deal, just copy your original icon file across (or leave it alone if it is already there) .
Again this is more a style issue, both ways are in use. I prefer to have all the pins in breadboard or pcb represented in schematic so the three views are identical, but there are lots of parts that do it the other way. Using the original schematic is fine if you wish.
You should be able to just copy the github url in to the message like this one from my parts check repo:
or am I missing something (github still confuses me most of the time ).
This is a case where Fritzing terms are unfortunate. In Fritzing a bus is a collection of pins that connect together internally, where as in most EDA packages it is a group of pins (such as a data bus) that are treated as one. So what I meant here is if there are any more shared pins (in the Uno, a4 and a5 are shared with scl and sda I think and are thus in the Fritzing sense bussed together). I think the gnd, 3.3V and 5V pins are the only ones with internal connections but if there are others they should be bused in ths Fritzing sense as well.
We can do that, although I read this forum more than github usually. However I would prefer to continue here, as this is as much about education for other users as anything else, and more users read this forum than github (especially new users).
As I wrote earlier, there are 3 additional busses. The pin 18 is shared with sda pin and the pin 19 with scl pin. The same is right for two ioref pins of the power and ioref connectors. You can see all the busses in my part, either in the breadboard view or in the HiFive1.fzp file.
<buses> <bus id="5v"> <nodeMember connectorId="connector87"/> <nodeMember connectorId="connector92"/> </bus> <bus id="gnd"> <nodeMember connectorId="connector57"/> <nodeMember connectorId="connector88"/> <nodeMember connectorId="connector89"/> </bus> <bus id="18/sda"> <nodeMember connectorId="connector4"/> <nodeMember connectorId="connector59"/> </bus> <bus id="19/scl"> <nodeMember connectorId="connector5"/> <nodeMember connectorId="connector60"/> </bus> <bus id="3v3"> <nodeMember connectorId="connector86"/> <nodeMember connectorId="connector94"/> </bus> <bus id="iref"> <nodeMember connectorId="connector84"/> <nodeMember connectorId="connector93"/> </bus> </buses>
Ah, good I’m just used to people not understanding what a bus in Fritzing really means but you look to be on top of it!