4. Embedded Programming

This week I developed my Git workflow and experimented with boards and toolchains.

Research

Prior to this week, I had little to no experience using CircuitPython; however, I did have experience with Arduino and the Arduino IDE software. I had previously used the Arduino IDE to run NeoPixel-powered projects, controlling 82 NeoPixels while adjusting their color and brightness individually. While I was familiar with the power circuits could provide, I had not fully understood how to use smaller boards that might be better suited for certain projects. The Raspberry Pi Pico is much smaller than the Arduino Uno board, which now feels somewhat outdated. I also wanted to explore the Seeed Xiao board, but I didn’t have time to do so.

nanopixel circut

This week, we experimented with group work and collaborated on various tasks. We also worked with boards and new toolchains to establish connectivity between the hardware and software, similar to how we maintained connection and collaboration with our teammates through the Git repository. We used the Arduino Uno and the Raspberry Pi Pico, along with the Arduino IDE and CircuitPython. I experimented with various code-writing software, toolchains, and boards. Additionally, I explored Wokwi to create my own circuits online and run simulations.

• • • Microcontrollers and Toolchains

In Week 4, our group worked on embedded programming and version control. We cloned our GitLab repository and programmed Arduino Uno and Raspberry Pi Pico boards using Arduino IDE and CircuitPython. I documented the setup process, wrote LED-blinking code, and troubleshot issues while exploring different toolchains.

You can find our group documentation site here.

• • • Git Workflow

Challenges

Understanding how to use Git beyond personal work was definitely a challenge. Before Fab Academy, I had never used it for my own projects, and I had never coded before. The most collaborative cloud platforms I had used were G Suite and maybe Adobe, but those don’t synchronize as seamlessly across platforms or collaborators. It’s also a very different level of work and intricacy. Code isn’t as easy to understand at face value, whereas Google Docs makes it simple to see changes directly. Learning how to use Git for website development and group documentation was a challenge.

It was also challenging to have everyone working on different aspects of the project simultaneously on the same site. Our class has eight members, with four of us split into two groups, meaning we had two groups working on one main website. Each group had its own subpage, but sometimes the other group would accidentally make changes to our page, leading to confusion. We tried to communicate, but it was difficult for one person to keep up with seven others making small edits. It was also hard to remember to consistently pull and push updates to keep the website as current as possible. At times, we had to talk in person to resolve issues that Git couldn’t understand—but humans could. I guess it’s a reminder that AI and robots won’t be taking over our jobs anytime soon.

Clone Git Repo

I followed this git tutorial.

The first step was to clone the Git repository onto my local computer. A group documentation site already existed for all the groups, so each member of my group cloned the site onto their own computer to make edits and push changes to the Git repository. However, to do this, we first needed to set up the Git repository on our local devices.

To start, we had to copy the SSH key from the Git online site.

clone ssh key

In close;

git@gitlab.fabcloud.org:academany/fabacademy/2025/labs/wheaton/group-assignments.git

Then, I opened Terminal on my computer and navigated to the folder where I wanted the Git repository to be stored.

cd Documents

Then, I cloned the repo onto my local computer.

git clone git@gitlab.fabcloud.org:academany/fabacademy/2025/labs/wheaton/group-assignments.git

Now, the repo exsists on my local computer, in a place called group-assignments. I can make changes locally and push and pull them to the remote repo to communicate with my collaborators. When I perform these commands, my local folder will update with the changes made in the remote repo.

git folder clone

Local Changes

I am using Visual Studio Code to edit the webpages, just like I use to edit my personal documentation site. To experiment, I made a small change and just updated my name.

visual studio code editing

I saved the change I made in Visual Studio Code and onto my local computer. This means it is saved for anyone using my local computer but not for my collaborators on the remote repo. In essence, it doesn't exsist to anyone else.

Sync With Remote Repo

Ok, now that I've made my change, I instinctively want to commit my changes. But because I am working with many collaborators it's possible someone has made a change. To check this, I need to perform;

git pull

My Terminal responded that it was already up to date so I didn't need to worry about merging.

I am now clear to push my changes. I can do this as follows;

git add .

then,

git commit -m "week04 updated"

and finally...

git push

A divine sucess!

Merging with Other Collaborators

Not always will it be so easy. What if I forget and try to push before pulling? That means there will be conflicting changes in my local repo compared to the remote repo.

In this scenario, I have already used the git pull command. Terminal gives me an error and tells me that there are conflicting changes that have been made.

example of git pulls

This typically happens when the same lines of code are edited both locally and remotely. In such cases, Git won’t be able to automatically merge the changes, and it will mark the conflicting sections in the files.

To resolve this, follow these steps:

  1. Identify the conflicts: Git will mark the conflicting sections with special markers (e.g., <head> and <//>). Open the conflicting files and review the marked sections.
  2. Manually resolve the conflict: Edit the files to choose between your changes, the remote changes, or a combination of both. Remove the conflict markers after making your changes.
  3. Stage the resolved files: Once the conflicts are resolved, use git add to stage the changes: git add <filename>.
  4. Commit the merge: After staging the changes, commit the merge with git commit. Git will prompt you to enter a commit message, typically noting that the conflict has been resolved.
  5. Push the changes: Finally, push your changes to the remote repository using git push.

If you're unsure or need to abort the merge process, you can use git merge --abort to stop the merge and return to the state before the merge was initiated.

Remember, communication with collaborators can help avoid these conflicts. Always try to git pull frequently to keep your local repo up to date.

• • • Simulate Microcontroller Operation