CODEWITHSUNDEEP
gitgithubhardwarefirmwarekicad
Claudio
Claudio

Reputation: 2217

While using git to control the source code of firmware from a hardware project, is it a good idea having the KiCAD schematic/PCB in the same repo?

I already use git as a VCS to control software and firmware I develop. Having done some work lately on the hardware side and coming to the conclusion that it is viable to control KiCAD schematic and PCB files also in git (please take a look at https://jnavila.github.io/plotkicadsch), I was wondering having the firmware and the hardware schematics in the same git repo - and maybe referenced by the same github project and issue tracker - might be very interesting and productive, since hardware and firmware are so closely related.

A lot of times a new functionality in firmware requires you to modify the circuit board, and the opposite is very much true as well, so initially it makes sense to me that both could be controlled together in the same git repository, maybe having a subdir scheme like:

project (in git)
   - kicad
   - firmware

where the subdir kicad would have all the schematic and PCB files and firmware would hold the source code for the firmware which should run on the hardware designed in KiCAD.

That would leverage the issue tracker for the project for solving bugs or setting milestones, which generally would require actions on both firmware and hardware, making it easier to develop and maintain a product with consistent modifications, with different branches for testing new features and so on.

Have you ever tried or thought about that? Can you foresee any "showstoppers" or something that would strongly advise against doing it this way?

Upvotes: 1

Views: 501

Answers (1)

Kache
Kache

Reputation: 16727

From your link:

Kicad is the only electronics CAD that I know to use a nice text format for managing all the data.

If the schematic and PCB files are text files, it's probably a good idea and there are little to no downsides.

Binary Files

However, if instead they're binary files, then it kind of depends. Off the top of my head, the "worst case" files for git are all of:

  • large in size
  • high-entropy (a small logical change causes large changes to file, e.g. compression/encryption)
  • frequently changing

If your file type is all three of those, then git's going to lose a ton of efficiency. Otherwise, git generally handles binary files just fine.

Team Workflow

The article you linked also talks about a few extras to handle rough edges:

  • configuring gitignore
  • clean/smudge to ignore non-logical project file save_at dates
  • schematic diffability

All these things involve various configuration/customization that you'll want to have sync'd across your team. Git has a lot of powerful built-in ways to customize behavior (e.g. commit/push hooks). Perhaps you could commit a shared script that can initialize these custom configurations for the repo.

Spending this effort now mean automating workflow and preventing future headaches -- you'll have to weight the benefit/costs.

Upvotes: 1

Related Questions