Since my link is currently up, I have grabbed copies to look over when the link is down and will reply when I can …
Peter
Since the link has staggered up again, here are my initial comments (I’ll drag down the LoRa data to check some details, link willing …):
Issues:
Mod1 (the arduino) shows up in pcb with an outline and label (but label can be hidden so not a big deal.)
Rats nest lines are showing in pcb on the jumpers even though there aren’t connections in breadboard or schematic and they are not correct (they short the two outside jumper positions which is wrong, one or the other should short to center.) Don’t yet know why. This however turned up a bug in FritzingCheckPart.py comment processing as it tries to process the comment. I need to fix that first and see if FritzingCheckPart finds anything. Fixed and now reports no errors, so I don’t know at this point. I’ll poke further.
The factory default jumper positions should be shown with the alternate position indicated somehow (how is currently unclear.)
It is probably preferable to have only one cs connection in schematic so that only one of the options can be used (although the other two will connect if you install wires.) At present you can short D4/D5/D10 by connecting all three jumpers which you can’t (at least easily) in real life.
icsp2 should be on the other side of the arduino to allow a shield to use it if desired as should reset and aref (in order to make the arduino universal and not specific to this particular shield.)
3.3V on the Dragino isn’t connected to 3.3V on the Arduino (there is an internal regulator from 5V on the Dragino I believe, but I need to verify that when my Internet link is up.)
LoRa reset needs a new name to not conflict with Arduido reset as the two are not the same.
I’m not sure what R9-R11 are about, need to look at the dragino schematic I expect. I’m not clear why they have connections although I may have missed a configuration option when doing the origianl.
Selecting one of the other arduinos in Inspector loses the shield entry in the selector and is thus not reversable (probably due to the accepted values being hard coded, which wouid need a code change to fix.) This should be an enhancement request to change the code to export an api that will remove the hard coding of the various options so parts can be added to core and selected in Inspector without a code change required.
The current icsp connection requires the user to know where to connect the ICSP wires, it may be a better bet to do that connection internally in the LoRa shield (without connectors being defined? May not be possible as they are defined in breadboard and pcb)
I’d prefer to find a way to put the pins in all three views as the last iten in the svg with no group so a python script can find and renumber them automatically (with only the requirement to identify connector0pin in the svg.) As it makes creating connectors much less time consuming (the script will properly number and move them if required.) This is more general than just this board.
I’d probably unique the name field by @pin number rather than 1, 2 etc. Probably external pin number (i.e. connector number + 1)
Peter
Here are the references I used.
I did not do anything with the Uno PCB view. Due to some other discoveries around the way bus connections currently work (and don’t work), I think the pcb view may need to have the connectors defined, even though logically they serve little purpose. Symptoms say that a connector must exist in the current view before the physical connections specified by the bus are used to determine what is actually connected already. And need to have the shield to host board connections available to get started.
The ratsnest line shorting outside jumpers is actually correct, given that the uno has bus entries tieing the ICSP1 headers with D11, D12, D13. With that, it does not really matter which side the jumpers are configured to. D13 is the same as ICSP1 SCK. The Uno board has them tied together. I assume that some other Arduino board has them separated (or different), or there would be no purpose in the jumpers on the shield. The sample sketch I provided shows that on the schematic view. The explicit wires I added for the ICSP1 pins to the schematic view hide the same symptom there. Delete the explicit wire to ICSP1 SCK, and a ratsnest shows up shorting between the ICSP1 SCK and D13 connections internal to the shield. The shortest wire to make the connection.
Actually you can (in real life). Those are the R9, R10, R11 SMD resistor in the breadboard view. It is quite possible to physically install them all. Not a good plan generally. But the schematic mirrors what I understand of the physical shield properties.
That was a deliberate choice. Maybe incorrect. I did not expect many shields to use the ICSP2 header. Or the AREF and reset pins. A shield can still use that, but the schematic wires would need routing, instead of the straight accross lines for the standard shield pin connections. A trade off, to keep the schematic layout simpler for what I expected to be the usual case.
Are you saying that that the 3V3 pin on the shield, which obviously connects to the 3V3 pin on the Uno, is not actually connected internally on the shield? If so, I need to treat that like the other unused (eg analog) Uno pins. A label, but no connection pin. My assumption from the reading, was that the shield uses either the 5V or 3V3 power source from the uno (host board), based on what is at IOREF.
There is no other reset line on the shield. Yes that is a reset for the shield itself, but with no Arduino board reset shown on the schematic view (of the shield), there should not be a conflict. Like the analog, and some other pins, those are not shown as getting to the shield. They are (assumed to be) pass through, with no connection to the shield electronics. It is not really possible to have totally unique names for every part. In this case, the LoRa SCK, MISO, MOSI are more of a concern. Those exist twice on the shield. Once as connections to the Arduino board, and again for the LoRa internal connection. I did put the big bar and “Arduino” label on the left, bracketing all of the pins (except power and ground) that connect directly to the ‘host’ board.
As above, R9-11, are the 0 ohm jumpers from D4,D4,D10 to CS.
I suspect it is not the hard-coding. My guess is that inspector does not look for substitution parts in the temp bin. I’d say it is a bug, not enhancement, if that is the reason it is not shown. A partial test for that scenario, would be 2 different fzpz parts, with the same family, different types, plus other not matching property names, in a single sketch. See if inspector can toggle between them.
My quick test here found a different bug. After swapping to a different uno, “undo” brought back the previous part, but lost the schematic connection between the 3.3V power symbol and the Arduino. Although it did keep the ratsnest from 3.3V to the shield.
A mouse down on the ICSP1 pins shows where they are connected. And the ratsnest starts between the shield internal ICSP1 and data pins. That is the shortest connection for it to draw. Delete the wires I placed to the ICSP1 shield pins to see that. A different Arduino board, with separate data and ICSP1 pins, would have extra pins to match ICSP1 on the shield. That is, if they were really separate, not just going to different data pins.
The pins need to be at least in the correct layer group. They also need to be at the correct coordinates for the view, so the user/designer needs to have already correctly linked them (by id) to the fzp connector definitions. With that much in place, a script should be able to renumber them without needing them at the end of the svg file, or outside of other groups. I did something similar manually with my text editor. It has the capability to do global edits across multiple files. Just need to specify the substitutions carefully, so that changing “connector1” to “connector22” does not also change “connector11” to “connector221”, and that the target of a change does not already exist, where it would end up getting caught in the next change during renumbering. I handle the 2nd problem by doing things in 2 steps: First change all of the “connector(n)” entries to “konnector(n)”, then the individual “konnector(n)” to “connector(new n)”. That way there is never an overlap during the renames. For the first case, make sure that an entry being changed never has a digit after the part that matched. Depending on the context, including the trailing quote character or “pin”, “terminal”, “pad”, “leg” in the search covers it, but may need 3 or 4 substitutions to do a single renumber. Scripts can use a bit more complex (regex) patterns to do it all at once.
Which leads to a different question … what is a reasonable / standard pin number sequence for a module/board like an arduino? Most discrete components have a well defined sequence, but the layout of the pins on an Arduino do not have an obvious progression order. Each header has pin numbers starting at zero, as defined for that block. But I know of no consistent way to sequence between the headers. Plus some of those headers block numbers run in opposite directions (I think A0 and VIN are both pin 0 in those headers).
A code enhancement might avoid the issue, for this context. The number suffix is only being used to keep the name unique internally. The user typically does not care. Have the code truncate that uniqueness suffix before displaying the name. Just do not display anything after the marker (“@” here). So GND@n just shows as GND, which is all that is normally needed. If more is important for a specific case, the descriptions can be different, or use GND_n instead.
As is, using that external pin number for the suffix would have simplified what I did. I had to keep back tracking, to see what number I should use. A trick I added for some places, was to add the suffix only for the 2nd and later cases. The first / main case was unique, because it was the only one without the suffix. A user invisible suffix would mean that it could always be added, without concern about whether it is needed, or what the users would understand it to mean.
Of course, having the name not NEED to be unique would also fix this just fine. With the id being unique, I see no real (functional) reason that the name also needs to be.
I found a solution to the issues I was having with bused connectors. The hybrid connectors section of the part file format information on the wiki has been updated. Now, going back and cleaning these parts up is on my todo list. Still can not totally hide parts in pcb view, but that is a minor quibble.
I opened an issue for rejecting connections in the SCH view when having part-to-part connections in the BB view. That is the issue in the Incorrect-connections-by-overlay-shield-on-arduino-Sketch.fzz (52.8 KB)