Here are the references I used.
pin mapping
Lora Shield v1.4 silkscreen
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.
Will be perfect for my diagrams!
, if I can now get the bugs fixed life should improve!
) do this in the real world and in my view should be able to in Fritzing too (although being able to do so from a code point of view may be too expensive to consider.)
