In a fairly short time I've accumulated hundreds of sketches, text/PDF files, screenshots, circuit diagrams, datasheets, etc. And dozens of my own finished and unfinished projects, plus many other users' projects. Fast, logical access is becoming an issue
I'm interested to know how others (especially electronics hobbyists) organise their files please?
In particular I'm debating over sketch organisation. For instance, to keep within 'projects' or in subfolders of one large SKETCHES folder.
I just use names that represent a logical iteration of any project and thus I am able to go back and forward as needed. I save many sketches for each project which will often be named like this;
Project is for a 12volt I2c switch module with led indicators
I2C12VLEDSM_buttons
I2C12VLEDSM_buttons2
I2C12VLEDSM_LEDs
I2C12VLEDSM_LEDs2
I2C12VLEDSM_button_LEDs
I2C12VLEDSM_button_LEDs_arrays
I2C12VLEDSM_button_LEDs_bitarrays
So naming strategy is project name_subsection_iteration
This also allows me to find specific code for a part of the project to use in subsequent projects. You can see I work on one but at a time for major components but then drop into code optimisation once I have the major components working. I will occasionally drop back and start labelling subsections with code optimisation if I feel that it better achieves an encapsulated bit of code.
The date is also included as standard
I use the same naming strategy with my schematics
Thanks, that's helpful for sketch naming. But what about all associated files like those I mentioned? If I'm developing a project I'll probably accumulate many, culminating hopefully in photos and final circuits and sketches of the cased project.
In earlier years (decades!) the very large parent folder called
C:\Users\terry\Dropbox\Electronics\CIRCUITS\MY FINISHED CIRCUITS\ was satisfactory for everything. Much of it built with legacy components (from transistors to TTL to CMOS). No MCUs, no code.
But having switched to Arduino for much of my work a large proportion of all 'associated files' are INO sketches.
I'm not terribly "organized", but I keep all related files within the Arduino file hierarchy for the project. For example,
Thing\ has pdfs of all devices, sketches, user notes, limitations notes, etc.
thing\R0 has all bits to do with the R0 release,
thing\R0\iterations has all important sub versions of R0
thing\R0\iterations\basic
thing\R0\iterations\I2Cworking
thing\R0\iterations\LCDworking
The problem I still have is, of course, all the CAD files in Eagle aren't stored with the Arduino hierarchy. So far, that's not been a problem, I just have a folder set in the Eagle project subdir like
thing
thing\R0
thing\R1
As long as I keep the name "thing" the same in both hierarchies, I'll be ok.
I have not got to a stage where I feel creating a master filing system is required. I may upload a project online when finished with all associated parts. In general I find using the naming system satisfactory as since I use the same system in all areas the associated files are easy to find. So eg I will have a file in my pictures folder named I2C12VLEDSM which contains any pictures associated with the project. I will have my arduino files in the ide default spot, my schematics in the kicad or easyeda default spot etc
If I want to aggregate it is simply a matter of going to the associated program and downloading the latest iteration to a file.
I can also just search the base name and all files in all associated folders will be visible
If you look at most modern computer systems it is the naming that matters now rather than where you put stuff. In the old days you would have loads of desktop files containing stuff. Now search is so fast you just need standard names and everything appears in your “search file”. I don’t bother saving stuff to anywhere but the default now.
Thanks both, much appreciated.
My current structure is something of a hybrid of yours. Bit of a mess really. I think one cause is that when creating or downloading a file (sketch, text tip, PDF, JPG etc) it could be in connection with a current or imminent project. But often it might not. In the former case I'm sold on that sound idea of more careful (consistent) naming. In the latter the file might go for example to a 'sundry'. folder. If I'm browsing to solve an issue with the DF Robot MP3 module it would at present be:
C:\Users\terry\Dropbox\Electronics\Arduino\Arduino (Sundry)\DFR Sundry & Unassigned
Step 1: throw away anything you don't need. It leads to confusion later.
Step 2: I have a standard project folder structure
PROJECT NAME
\FIRMWARE -- code goes here
\DOCS - pdfs, notes, other documentation
\CAD - schematics, wiring diagrams, PCB files
Sometimes I add
\INTERNAL
This is for paid projects where I keep my cost estimates, bids, milestones, receipts etc. that aren't shared with the customer. Everything else goes into a private repo on Github.
Thanks. Step 1 has been on my Must Do list for a month or so. It's the 'will I neeed that?' that takes the time!
Step 2: So '\FIRMWARE' contains all sketches relating to a specific project? BTW, why not named '\SKETCHES'?
Don't do what I do:
I rely heavily on my own memory and a handful of Unix tools to find things in *.ino files wherever they might be all over my Documents folders.
And to see if and why things are different.
Srsly I'd be lost if you took away find, grep and diff, and just enough Unix/CLI to work them.
Too late for me.
And don't get me started on the virtual crap-ton of wokwi simulations I've spewed out, which seem to be without the capability of managing themselves in any way.
Best thing I read on this thread: throw away stuff you don't need anymore. I still have email from the 20th century. 
a7
I set up an engineering document management system with code, CAD, parts, and assemblies. Every part data sheet is saved in /PARTS under the pn in the inventory database. If two parts are connected it becomes an assembly drawing with a standardized parts list location.
The parts lists are extracted from the drawings so a project BOM and cost data can be extracted.
All the drawings and parts are in .PDF format and are cross linked so you can chase down sub assemblies.
All of the supporting docs are in .HTML format so it can b easily viewed with an embedded, targeted, browser so the program has the docs available in a browser window.
From this we were able to check parts availability and order needed supplies just by selecting an assembly, etc.
The cad .DXF files were also used to drive the CNC system. Draw it, export it, convert to gcode, and go wait for your parts to be cut by a low skill operator loading the CNC. This allowed our small 5 man shop to operate like we were a big corp.
At the end of the project everything was printed, bound, and supplied to the customer with the machine.
Most all the code driving the system was PHP/MYSQL on a cheap LAMP server.
Yes.
" I still have email from the 20th century. "
Me too.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
