# Journaling your progress Written by [Alex Ren](https://github.com/qcoral/) for [hwdocs.hackclub.dev](https://hwdocs.hackclub.dev) Journaling! You’ve probably seen this term thrown around here and there. What is it? Journaling is a way you can keep track of your progress while working on your project! It usually involves creating a JOURNAL.md file in the root of your repository, and then taking short notes on what you did each day! Journaling isn’t just useful for Hack Club projects, but it gives you something to look back long after you’ve finished your project! It’s also a great way to share your journey with other people who might be interested in your project! ## How to journal First, you’ll need to make a JOURNAL.md file in your project folder! Just make a .txt file and rename it to .md! The .md extension is for [markdown](https://www.markdownguide.org/basic-syntax/), a text format that allows you to style text using symbols like # and a \_! All of the pages on this site are written in markdown Next, at the top of the file, add the following data: ```yaml --- title: "Your Project Name" github: "your repo" description: "Describe your project in a short sentence!" created_at: "2026-03-20" total_time: "2h" --- ``` This is called frontmatter, and it’s a short [YAML](https://yaml.org/) section that just contains info about your project! From there, just start writing new journal entries! Each one should go something like this: ```markdown # June 8, 2026: **Total time spent: 2h** ``` Here’s an [example journal entry](/docs/example-journal-entry) I did for reference! And that’s it! Keep making journal entries, read other journals for inspiration, and then submit once you’re done! ## More info Here’s some more info on journaling! Things you can journal: - Time spent designing your project in software like KiCad, Fusion 360, etc! - Time spent working on art for your project! - Time spent researching, esp. referencing datasheets! Things you can’t journal: - Time spent watching YouTube videos on your project (I know it’s technically research - doesn’t count!) Some extra tips: - Try to make it less of a log of purely “I did X and Y” and include interesting things you came across! Weird quirks in a specific chip, cool inspo you came across, etc! - Images are worth a lot! Try to add a lot of images and avoid walls of text. It makes it much easier to convey information. If you’re using VSCode, one plugin I recommend is [Image Paste CDN](https://marketplace.visualstudio.com/items?itemName=dari.paste-cdn). It allows you to paste images from your clipboard and have them automatically uploaded to Hack Club’s storage, which means you don’t have to store the images locally! ![Image Paste CDN demo](Imagesimage-paste-cdn-demo.webm) (pretty nifty, huh ^^) ## Example Journal Entry It’s for a retro game console I’m building that runs on a Raspberry Pi Zero 2W! I find that writing journals like this can be pretty tedious, so one thing I recommend is just recording a vlog of what you did and then summarizing that instead. To that end though, you still need to include images and fairly detailed descriptions! # June 8, 2026: Got the screen to work! I got the Raspberry Pi to actually display on the LCD! Can’t believe it actually works I based the wiring off of the [pi-tin](https://github.com/jackw01/pi-tin) project originally, but they used an ILI9341 display instead of the ST7735R I was reusing from Sprig. That meant that I had to figure out not only how they got it to display originally, but also how to modify that to use the ST7735R drivers instead ![LCD first output](Images/lcd-first-output.webp) Fortunately for us, the pi-tin project actually documented how the software was set up! They actually cross-reference an Adafruit script, which is a derivative of one from Pimoroni. In short, here’s how the original method worked: - Install FBCP (framebuffer copy) drivers, which captures whatever would’ve been outputted to HDMI and allows you to redirect it somewhere else - Modify the dtoverlays (device tree overlay) in /boot/config.txt to use the built-in kernel drivers for the ILI9341 - Reboot. The framebuffer should automatically redirect everything to the display. The main problem was then figuring out what parameters I needed to add to /boot/config.txt to make it work with the new display. I wasn’t even sure if there were the right drivers built into the Linux kernel! Here’s how I figured that out: - the original [rpi-fbcp](https://github.com/tasanakorn/rpi-fbcp) repository mentions some sort of FBTFT driver - a quick search links to [this](https://github.com/notro/fbtft) repository, which then mentions that the drivers were now in staging on the [Linux kernel](https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing) - a bunch more digging eventually leads me to stumble on this file: [st7735r.c](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/tiny/st7735r.c) Bingo. The drivers exist. Anyhow, digging into the existing dtoverlays eventually led me to an st7735r generic overlay in the raspberrypi/linux repo! Using ChatGPT to then convert that to a dtparam, I eventually got video output: ![ST7735R video output](Images/st7735r-video-output.webp) The tl;dr is that Raspberry Pi provides the dtoverlay files for the ST7735R built in, so it’s a matter of installing a framebuffer and redirecting that to the display in the /boot/config.txt file **Total time spent: 5h**