2 photons, particle workbench, git - how do I store the code for each photon and develop a library locally

Developer Tools Particle Workbench
#1

I had 1 Photon - super fun - it’s recording temperatures, tracking the gerbil wheel speed, restarting the Ring doorbell via IFTTT and an IOT plug when it goes offline…the whole point was to monitor for water in the basement and I got very sidetracked.

I use the Particle Workbench. I have the code in a Github repository. (I’m a developer by day - we use TFS at the office so Git is pretty new for me).

I finally got a second Photon. So now I need to organize the code better I think.

Should I have a repository for each device since they’ll do different things?

And now to share the code between the devices I’m assuming I’ll make a library…in its own repository?

While I’m developing the library how do I include it in my project so I can test/reference it?

Say I have a function RecordTempToGoogleSheet(…)

I’ll want to call that from both devices. I create a new repository for a library, make a library with the cli (particle library create), add the files to the repository.

Then go to a project for one of the Photons and… how do I link that library in under /lib/ since I’m assuming they’ll be in different repositories (and also assuming they’ll be in separate folders on disk…)?

There must be a convenient way to do local development on a library w/o having to upload the library to as a private library and then re-get it to get changes… maybe a config setting telling the compiler where to find libraries on disk instead of just in …/lib/ ?

Thanks in advance - Peter

This was a great help:

#2

@paraih You don’t need to have a code repository for each device and actually you don’t need to use github. I wonder if you are confusing device and project?

And now to share the code between the devices I’m assuming I’ll make a library…in its own repository?

While I’m developing the library how do I include it in my project so I can test/reference it?

If you are using Particle Workbench then you can create a new project for each different requirement and target the build with Configure for Device setting the device OS and device name (optional).

The compiled binary can be targeted to any device if the device name has been omitted.

I assume you understand that a new project creates a local repo with a directory structure on your PC.

Under the Create New Project there is Install Library for Particle Community libraries which go under the lib folder.

For your own ‘library’ or common functions you can either create it like the imported libraries or you can put the .h and .cpp files in the src folder for the project. A simple way to then clone your libraries between projects is to copy and paste the files under /lib/my_library or under src into the project file structure you want and use #include in the .ino.

#3

In order to reuse local libraries across multiple projects I usually go with creating a junction link to that library in the project’s lib folder.

There are other options like customizing the MAKE file or absolute references, but I find a junction the easiest to use.

It would be nice if Workbench would offer a dedicated workflow/task for that to keep the nitty gritty details of how to do that with your respective host OS from the user - @m_m how about this? Or any better way to allow for personal/local library repositories to be used across Workbench projects?

1 Like
#4

@armor I’m sure I’m confusing a lot of things…

GitHub - I’m just used to keeping all my code in a remote code/source repository somewhere - since I have access to GitHub seems like a place to keep my code - I won’t touch this for a few months after it’s working, PCs come and go…so it’s just a good backup plan if nothing else…

Regarding “I assume you understand that a new project creates a local repo with a directory structure on your PC.” ah ha, I didn’t. But I poked around - I can create a local repo or create a new project and publish to git hub…slick.

So each project should be in its own GitHub repository…? I’m not familiar enough with GitHub at the moment, but that seems to be the way to organize it… the alternative would be to have multiple projects in one GitHub repository which seems like that’s not how it is intended to be used.

And I’ll probably have a project (and GitHub repo) for each device. And a project (and GitHub repo) for each library.

I appreciate your options for sharing code between devices/projects.

Thanks - Peter

#5

@ScruffR Thanks - “Junction link”? I just learned something. Had never heard of that in windows before. Looks like VS code will send the content behind the link to GitHub (not surprising really…) so I’d have to add an ignore flag to the git config for the project… easy enough…

It does mean if I got a fresh checkout on a new PC I’d need to make a new link…seems reasonable and seems like a good responsibility for the readme file.

That would certainly streamline development of a library - having it locally in the workspace of a project I’m working on.

If I don’t have the git ignore, it seems both VS Code windows (say, for project A and Project B) will recognize it as a modified file… which is not a surprise I guess and possibly just good to know. Also, just fyi… committing it in one project will leave it uncommitted in the other. Again, make sense… it is basically two different files in git.

1 Like
#6

Well, I needed to set up a new profile on my pc because we have kids and are now implementing microsoft screentime restricitons features… so I needed to basically start from scratch…

It was a cinch -
got vs code, added the particle extensions.

Got my 3 repositories from git hub (2 device projects and 1 library project).

Added the junction link using the info I had left in my readme file (mklink /j…).

Compiled fine.

I was getting this error when publishing…

:::: PUTTING DEVICE INTO DFU MODE

HTTP error 400 from https://api.particle.io/v1/devices/.... - The access token was not found

took a few googles, but I needed to log into particle in VS Code… forgot about that.

This got me back up:

really slick.

2 Likes