Added symbol for Nano RP2040 Connect.

[djpearman]

Hi,

I added a symbol for the Arduino Nano RP2040 Connect based on the Arduino_Nano_v2.x of the official Kicad MCU_module library. So it uses pin numbers and is compatible with the Arduino_Nano footprint of the Kicad library.

It passes the check of the check_symbol of the Kicad library utils.

Perhaps this is one small step towards #91 .

I use Kicad 7.0.7, which seems to have modified several properties of the other symbols in the library, hence why the commit is kinda large. The added content starts at line 6828.

Feedback welcome!

Best regards,
djpearman

[Alarm-Siren]

Hi djpearman, thank you for submitting this.

I've had a look at the changes and I have some thoughts; some are things that do need to be fixed (but not difficult to do so), others are not necesarily problems but I just raise them to clarify with you what the intent is. I will number my thoughts to make it easier for you to respond to them.

1. Pin 27, VUSB, should be set to Unconnected, as on these modules the VUSB/5V pin is in fact disconnected by default.
2. Pin 3, ~RESET, should be Open Collector. Admittedly the RESET pins on Arduinos are a bit weird and Open Collector isn't a perfect analog, but its better than Input which will get shirty if you leave the pin unconnected.
3. A6 and A7 should be inputs only.
4. Why is the REC pin named ~QSPI_CS?
5. REF, pin 18, should be called AREF and, if it is to be hidden, should have its connection point on the edge of symbol per KLC S4.6.2. However, I would also argue this pin should not be hidden.
6. Is A0, Pin 19, also in fact a DAC input? I don't recall reading that, but I may well have missed it...
7. I can see you've set the symbol's datasheet to the ABX00053 pdf. Whilst I agree this is technically more correct, I prefer to point to the relevant page on the docs.arduino.cc website (which has a link to the datasheet PDF at the bottom), as I find the datasheets, in general, are extremely variable in their quality whereas the docs pages are pretty good and - if the user wants the PDF, can get it from the link at the bottom. For consistency with the rest of the library its probably best to stick to the Docs pages, unless there is a specific reason you made this change?
8. Is there a particular reason you have preferred to use the Kicad default footprint - and created a new SMD footprint based on it - over the ones in this library? I don't wish to rely on anything in the Kicad default library, as that's just a recipe for disaster if they subsequently change or remove something underneath me. I also cannot vouch for the quality of their footprints. However, if there is a particular reason or use-case whereby the Kicad footprints have proven better/more useful to you, I would like to cater to that use-case in my library too.
9. No worries about the versioning issue. I intend that v5 of this library will drop support for Kicad 6, so this is as good an opportunity as any to upgrade the format.
10. I would seem that your intent here was to create a single symbol (Arduino_Nano_RP2040_Connect) that works with both the Socket and Tile footprint types, whereas in the library at the moment I have created seperate symbols for each footprint type. I understand your approach is more correct from the KLC's point of view, however I do not believe my method is forbidden and I have previously considered it more friendly to newbies in that they don't need to remember to select a correct footprint at a seperate stage of the process. However, I have toyed with switching to your approach for v5, and I would appreciate your thoughts on the matter. This is particularly relevant as this decision will determine what the new symbol will ultimately be named.

Kind Regards,
Alarm-Siren.

[djpearman]

Hi Alarm-Siren,

Thanks for your feedback! Here my thoughts and responses:

1. Pin 27, VUSB: This pin can be 'activated' by adding a solder bridge between two pads on the underside, so I figured it would useful to cover that use case by granting the ability to connect to it. While it is unconnected by default, setting the pin as such would forego that option. I have not used it myself, so I have no issue setting it as unconnected. Perhaps setting 'passive' would be most accurate?
2. Pin 3, ~RESET: I assume you are referring to this pin being connected to a pull up resistor as well as a pushbutton to ground and thus representing a sort of open collector output, though it is also an input to the RP2040. True, it is a bit of an oddity :) I will change the pin to OC.
3. A6, A7: Do you have a source for this? Neither the datasheet nor the pinout document declare them as input only. The latter gives their alternate function as GPIO, albeit on the NINA WS102. Is there a limitation in software that does not allow them to function as outputs? So far, I have not used these pins, so I have ignored them.
4. REC: I had originally labelled it ~QSPI_CSn/REC, but for some reason dropped the REC part. I'll rename it to REC in line with the datasheet.
5. Pin 18, REF: This pin is labelled REF in the datasheet and I go with datasheet content when there are inconsistencies (which was drilled into me at my last place of employment). Despite it being not connected, the pinouts still list it and call it AREF, so I have no qualms renaming it to that. As for visibility, upon reflection I agree that unhiding it is better.
6. Pin 19, A0: I just checked and there is no DAC on this pin. This seems to be a remnant from when I was using the Nano 33 BLE, so I will remove the DAC0 part.
7. Force of habit mainly, since the datasheet is linked for most components. The only real reason I have for linking the datasheet is to clarify the document used in the case of inconsistencies in the information provided (as for 5. for example). For modules like this, I tend to agree that it is better to link the product page, so I will change it.
8. No, I had not put much thought into which footprint to set as default other than it being in the official Kicad library making it more 'mainstream'. I agree that it would be better to set a footprint from this library as default, so I will do that.
9. Ok.
10. This is probably the point requiring most discussion and so I'll break it into separate aspects to ease discussion.
    10a. Symbol to Footprint linking: While I appreciate the newbie friendliness of your current approach and it is by no means forbidden, this does result in a lot of symbols. In my opinion, this makes it harder to use as well as maintain the library and does not scale well. For example, adding both tile and socket footprints without mounting holes (as is the case for the one I added) would bloat the library to four symbols per board. In addition, the in many cases already long names would become even harder to read. The two step process of selecting symbol then footprint slims the symbol library by decoupling the two choices and should not asking too much of someone attempting to design electronics. However, I only feel moderately strongly on this point :)
    10b. Pin designators: As far as I can tell, you have set pin numbers to be the same as their names. What is your rationale behind this? A consequence is footprints being specific to one or few symbols despite being potentially compatible to multiple, e.g. for the Arduino Nano series. While requiring a decent amount of effort, switching to pin numbers would slim down the number of essentially duplicate footprints and allow ones from the official library to be used as well if desired. In addition, adding footprints with small variations, such as without mounting holes, makes them available to all. On this aspect, I urge you quite strongly to consider switching.
    10c. Backwards compatibility: I am fully aware that these changes entail significant breakages to existing projects and will likely cause considerable dissatisfaction among users of your library. As such, I very much appreciate the gravity of these points and there will be no hard feelings whatsoever if you decide to stick with the current approach. On the other hand, I do think it would be beneficial to this library. No pain, no gain I guess :)

An additional more detailed observation:
11. Location of tile/SMD pads: In the Arduino Nano tile footprints that I checked, the pads are placed about 1mm farther out than in the one I have submitted. What is your reason for this placement? In my case, the pads also cover the circular THT part of the module pad and should in my estimation result in better soldering, but am open for other opinions on the matter. I have used this footprint in a design manufactured by a PCB contractor and it worked well.

I look forward to hearing your thoughts!

Best regards,
djpearman

[Alarm-Siren]

1. I think for consistency it should definitely be Unconnected. I did a comprehensive review of power pins and what they should be set to back in Review Power Input/Power Output pin modes for 3.3V, 5V and VIN pins #65 and I'm keeping to the methodology I employed there. Basically, every pin should be setup in the symbol as it is 'out of the box' for the module. Advanced users who want to modify their module to enable additional functionality, will also be sufficiently advanced to modify the symbol or footprint if need be. In any case, setting a pin to Unconnected doesn't actually stop you from connecting a net to it, it just means the DRC will moan, which I would argue is exactly the behaviour we want here. By default, it will moan at you for doing something you probably didn't mean to do - but if you really know what you're doing and have connected the VUSB bridge pads you can safely ignore the DRC warning.

2. You're quite right. On some of the other Nano modules A6 and A7 really are input only, I guess I just assumed it would be on this one too since it follows the same footprint layout. I've raised a seperate issue A6 and A7 on RP2040 should be Bidirectional #96 so that it doesn't get forgotten. I should probably review all the Nanos in case I've made the same mistake on others.

10a. Yes, I do see your logic on being able to support a greater variety of footprints per symbol. And adding footprints that lack the mounting holes would be a nice addition.

10b. Basically I used the "pin numbers" that Arduino themselves use; especially as for some of the footprints it isn't particularly obvious how they should be numbered if one were to use only numbers. On the Nano footprints, you can take the D0/D1 corner as 'pin 1' and number around as if it were a DIP chip, but for, say, the Arduino Uno or Mega? How on earth do you number those in a consistent manner? Any assignment of numbers would be completely arbitrary... so why not give the pins the names Arduino themselves use? I also found that it made it easier when cross-checking between footprints and symbols to make sure I've linked the right Symbol pins to the right Footprint pins. I'm open to the idea of using pin numbers, instead of pin names as now, I'm just not convinced that the change would add anything (except the ability to use the built-in footprints if desired, but as there's only three of them and I provide a complete set anyway, that doesn't seem like a huge advantage). On the issue of footprints being too specific, I always recycle footprints whenever possible, however the difference is usually not the pinouts but some other aspect. For example, the difference between the M0 Pro footprint and the Leonardo footprint is that the latter includes a courtyard area for the 2nd USB connector that isn't present on the Leonardo. The two footprints are otherwise identical, including pinouts. Similarly, I'm well aware that both KLC and IPC say that pin 1 should be the only square pad, and pin 1 should be marked in silkscreen, however because it wouldn't always be obvious what should be pin 1, I instead made an Executive Decision to set all GND pins to be square and mark Pin D0 in silkscreen as I feel they're both more universal reference points for orientation of these modules than whatever I might arbitrarily decide is pin 1.

10c. Indeed, but as previously mentioned, if one is going to make big changes v5 is the time to do them. Major version change and all that.

11. To be fair, I could ask the same of you! But in all seriousness, I based the SMD pad locations on the edge of the module, such that the inner semi-circle of the pad should exactly line up with the semi-circle on the module above it, but with some extra on the outer-side. My hope was that this would give sufficient space for easy hand soldering of the SMD pads, which I know can be difficult with small pads especially for a novice. However, if the suggestion in 10a is implemented I see no reason why one couldn't offer both variations - indeed, the Kicad standard library itself offers 'standard' and 'HandSoldering' variants of some SMD parts already, the latter having extended pads. I'm also not against extending the pads back toward the THT holes if this would give superior results.

[djpearman]

1. Done, changed VUSB to unconnected.

10b. Yes, I wholeheartedly agree that deciding on a numbering scheme for pins is not a straightforward task, especially with footprints that have no clear pin ordering in their footprints. At the end of the day, any choice is going to be somewhat arbitrary (and the Arduino Nano datasheets are unfortunately a case in point in terms of inconsistencies that may arise...). The approach of setting pin numbers to their assigned names may require less effort initially, but foregoing the benefits, where possible, of reusing identical footprints that assigning separate numbers and names to individual pins provides is likely to cause problems in future. While defining pin numbers may be a PITA for the likes of Uno or Mega boards, the comparative simplicity of MKR and Nano board makes it a lot easier and once a definition has been made, the addition of further boards using the same footprints becomes a matter of creating a symbol with appropriate footprint filters. Likewise, the addition of compatible footprints, e.g. without mounting holes, merely requires appropriate naming to become usable for all relevant modules. Of course, the outline differences you mention would have to be taken into consideration. Perhaps it would be acceptable to switch only boards with simple footprints and outlines and leave the other as they are. Admittedly, that basically limits it to the Nano boards and creates an inconsistency within the library, which isn't all that desirable.

11. The placement of the SMD pads in my case is chosen so that they cover the whole area below the castellated pad, so that it extends beneath the through hole portion, too. The castellated pads of the module make it quite easy to hand solder, since it flow nicely into the semi-circular portion, and not much pad area is needed outside it. In your case, the pads only cover the outer part, leaving the area under the through hole portion bare. While this is will work and shouldn't cause any immediate problems (unless someone places copper traces without solder mask in those areas), I think having pads cover the whole area beneath the boards pins is a cleaner design.

Ultimately, you are library owner and it is up to you to make the decisions. I am merely wishing to share some of the experience I have gained in designing electronics and hope to learn through having my thoughts scrutinzed.

[Alarm-Siren]

I am merely wishing to share some of the experience I have gained in designing electronics and hope to learn through having my thoughts scrutinzed.

And your thoughts and inputs are most welcome! In all the years I have maintained this library, I've never had anyone engage with me on this level, so it is valuable to me to have insight into how it can be improved by actual users.

[djpearman]

Just wondering if there is any further input required from my end on this PR after your approval? I am not able to merge since I don't have write access.

[Alarm-Siren]

No nothing needed from you, sorry I've just been busy. Its slightly complicated because I want to put out 4.2.1 first (to fix the #96 bug), update the library to the latest kicad version, then merge this into that to create the 5.0.0 baseline that I will then work on finishing #91 within. I just haven't had the time to do all that yet, especially as the release process for a kicad package is.... non-trivial.