Arduino Due Schematic Part - No 3.3V

[davidperrenoud]

From tks...@gmail.com on November 01, 2013 04:43:08

I am new to fritzing. I am using fritzing 0.8.3 on Windows 7. While making a circuit for Arduino Due I found the following,

(1) In Arduino Due Schematic Part there is no 3.3V pin.

(2) In Arduino Due PCB Part there is no SPI pins (6 pin header) near the processor.

Are they not provided deliberately or mistakes?

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2771

[davidperrenoud]

From irasc...@gmail.com on November 01, 2013 04:48:00

Owner: bluearc....@gmail.com

[davidperrenoud]

From tks...@gmail.com on November 01, 2013 07:17:23

Also see their is no SPI pins shown in schematic part of Arduino Due.

[bcraigie]

Yes, the 3.3v pin is incorrectly labelled as IOREF and consequently is routed incorrectly. Can nobody fix this?

[TheDevilOnLine]

I'd really love to see the SPI pins added. As there are no documents describing the measurements from the sides of the Arduino Due of where the pins are located, it's close to impossible to place those pins yourself when creating a PCB.

[KjellMorgenstern]

@TheDevilOnLine
I fixed the 3V3 pin and added it SIP / ICSP headers . I manually calculated the header postions, though, which might be wrong. I don't have a DUE to verify.
Can you checkout the https://github.com/fritzing/fritzing-parts/tree/arduino_due_icsp branch and print the pcb on paper to verify it matches the DUE ?

[TheDevilOnLine]

@KjellMorgenstern can you help me out a bit on how to get the new part into my fritzing application. I'm using the Windows version. I already downloaded the fritzing-parts github and extracted those into the fritzing-parts folder of my fritzing installation, but the ICSP version of the Due doesn't show up, and the original one is still lacking the ports.

For now I just replaced the existing Due files with the new Due ICSP files, so I could at least print them, I added some ink to the bottom of my Arduino Due and put it on the paper, so I could check if the pins alligned with the drawing. The dots allign perfectly with the printed PCB, so as far as I can see, it is correct!

Thanks for the quick solve!

[mMerlin]

I'm using the Windows version.

@TheDevilOnLine Which release of the windows version? 0.9.4b is the latest (directly) downloadable.

The Fritzing Forum is a better place to ask operational questions.

From Kjell's comment, the fixed files are only in the "arduino_due_icsp" branch of the repo so far. He wanted some external verification that the changes were correct before moving them into the "production" parts library.

Once they are in the repo branch that Fritzing expects to use, with 0.9.4, (start with) on the Help menu, "Check for updates". That will (attempt to) update it to the latest changes in the github repository. You could have permission problems (to the parts library folder), which would cause the update to fail. To do it manually, with the git application installed, from the folder for the parts library, with administrator access git pull will get the updates. A manual update needs to be followed with: start Fritzing app, go to Breadboard (or other view except welcome), Part menu, "Regenerate parts database".

Your download and extract was about equivalent to the git pull. The local repository now looks like it has been modified though, and future updates (by Fritzing) will likely fail. The regenerate should make the updated parts available. Also, depending what you moved into the fritzing parts folder, you may not have gotten everything. A change like this moves some of the original files into an obsolete folder, so Fritzing has a reference to lookup old parts in existing sketches, and can offer to update them to the new version. If you know how to use git, there are ways to cleanup. A possible (untested, I use git instead) way, would be to download the full repository, unpack it, then replaced the complete fritzing-parts folder with the download. Cleanup to be done after the parts have been moved to the final git branch.

With Friting 0.9.3b, the internal update will fail, due to changes in the github 'rules' about downloading from a remote repository. The manual work around should still work.

With either Fritzing version, a last resort fix is to reinstall the app. After (possibly) saving and cleaning up custom parts information. If a simple install over the existing app works, all done.

If cleanup and reinstall is needed, see FAQ: Fritzing Freezes on Start. The details are the same as needed here. Be sure to backup your sketch files, and any fzpz files needed to reload the custom parts.

A detail I am not clear on for the git updates. A message I see using "Check for updates" says it is expecting the "master" branch of the repository, but the recent fixes I have seen in the merged pull requests have only (so far) been put in the "develop" branch. I use manual (git) updates, and have the local repository pointing to the develop branch. But that is me, and for other reasons. So report back if none of the options suggested here work for you.

@KjellMorgenstern Can you checkout the…

Was your intent to merge that branch into a local develop branch to do the testing? Or change to that branch? Not everyone here lives in git every day. Should I look at creating a (maybe wiki) document to describe options to test changes sitting in an issue branch, then get back to normal afterward?

[KjellMorgenstern]

@TheDevilOnLine Thanks for verifying :-) That was what I had hopped for. I will fix some remaining issues, also the variant without SIP. Once that is done, it will be merged to the development branch.

@mMerlin You are right, when Fritzing notices that the parts folder was modified, it will not apply any further modifications, to not mess up with the users changes. Using git checkout would be a clean way to switch back and forth. Deleteing a git repo to fix things is close to never necessary, but it is of course a quick way to set the Fritzing parts to original state.

There is a huge number of really good Q&A, tutorials, articles and books of how to use git. I think we could instead see if we can get Fritzing more robust. It should simply work after switching from master to develop by using 'git checkout develop', and give more helpful hints instead of the 'something was modified, good luck' type error messages. That could be: Dialog that shows current folder location and branch. List parts which differ from HEAD. Show upstream url.

[KjellMorgenstern]

@TheDevilOnLine My recommendation about checking out the branch would be, even on Windows, to use the command line version of git. In the shell, you go to the parts folder, run get fetch --all to get the latest updates, then git checkout arduino_due_icsp . When finished testing, run git checkout master to go back to the release version or git checkout develop if you prefer that version

[mMerlin]

@KjellMorgenstern
It should simply work after switching from master to develop by using 'git checkout develop'

That looks optimal. Probably also needs a regenerate parts database, which could possibly be automatic when a different repo branch is detected on startup. Also a configuration setting that tells the app which repo branch(s) it can do updates from.

I think we could instead see if we can get Fritzing more robust.

Sure. But a little documentation to indicate that a standard git repo is used for the core parts library, and a few links to those git learning resources would help for situations like this. The only thing that should be needed in addition to that, is any common pointers for the fritzing parts specific case. Which would seem to be … not much at all for general use. A couple hints for branch management and PRs for those serious about helping out with part updates (but are not "conventional" developers that already know about git and other source control). Those I think are covered in some of the other docs, but people arriving here (parts issues) likely do not know to look for that.

@TheDevilOnLine

then git checkout arduino_due_icsp

git checkout for a different branch will also fail if existing files have been modified compared to the source (previously checked out) repository branch. Those changes would need to be "undone" before the checkout would work. See some of that 'huge number' of resources for git.

[KjellMorgenstern]

I don't see the issue here. In the flow described, the checkout will work fine. Even if not, git will tell you that it can't switch branch because files are modified, git will just list the files in question, and that it can not switch because the files would be overwritten. At that point, the user has to decide what to do with the changes, no tutorial will tell you?

[mMerlin]

I included that because the previous description of the testing done showed the local repo getting out of sync (modified files). The repo content is already modified, so checkout will not work, so going forward from the current state, the first thing that needs to be done is handle that. The tutorials will provide information about HOW to deal with the reported changes, once the decision is made to revert or save them outside of the repo. Usually a google search for the messages from git status (or the checkout attempt) will provide options.