I have done a similar thing both in the workplace and at home. At work, I got two fishing tackle boxes and put the identical set of tools in each box. When someone came into the lab and wanted to borrow a screwdriver, I made a big issue of giving them the entire toolbox.

In the lab itself, I hung tools on the classic pegboard with tool outlines.

At home, I omit the tool outlines because each tool goes back on to the same hook. My hex keys are on a piece of 2x4 in marked holes, much like a drill bit index. Similarly, metric and imperial sized socket sets are on DIY dowels on 2x4 or on a permanent shelf above the workbench. Every tool goes back where it belongs and at the end of the day, you know when a tool is missing.

Same with writing code. What it takes is an organized system and discipline.

 

How many of you guys routinely use Git? That system is as beneficial to ANY software developer as the policies for tools discussed above. If you aren't using Git it's like relying on pliers for all nuts/bolts, no wrenches, just pliers. Coding standards are akin to how to use tools, not how to organize them, but I digress.

Dave Cutler (the designer of DEC's VMS) once said the best team size is one, I agree, there are no team misunderstandings, no personality clashes, no "but I thought we agreed we'd...". Personal projects allow us to organize better, apply the standards we find useful.

 

So, this is something that generally requires a word-from-on-high imposition of discipline to benefit from.

The same is true in software style guidelines. Most people lack the self-discipline to adhere to good, consistent style even when they fully appreciate the value of doing so.

I just wanted to bring a bit of focus back to what I’m trying to do with this project. I’m working with limited hardware, and I’m mainly doing this as a hobby project to learn and explore embedded software development skills. My setup is based on an ATmega8A, which only has one UART. Since my RFID reader also works over UART, I decided to use reader outside the door and use a push button for exit from inside the room.

I’m using an RTC (DS1307) to keep track of real time. The plan is to divide the day into three shifts morning, noon, and evening so the system can validate both the card ID and the time when authentication happens.

For data storage, I’m currently using a small 2-Kbit EEPROM to log attendance records mainly for practice, since it’s the one I already have on hand. I know it’s quite limited in size, but it’s perfectly fine for testing and learning purposes. Later on, I plan to upgrade to a larger EEPROM once I get the basic functionality working.

On the software side, I’ve started organizing my code into separate modules each with its own header and source file for things like LCD, UART, I2C, and the RFID reader. I’m trying to keep naming conventions clean and meaningful for example, using function names like Send_Device or Write_Device when sending data, and Receive_Device or Read_Device when receiving. I’ve also made sure to avoid magic numbers wherever possible to keep the code more readable and maintainable.

For portability, I’ve started using #define macros and #ifdef blocks so I can easily enable or disable specific parts of the code depending on the hardware I’m compiling for. That way, I can switch between modules or configurations without rewriting everything.

Basically, my goal with all this is to learn how to structure my embedded code properly so that it’s not just working, but also modular, readable, and somewhat portable.

Welcome for any feedback or suggestion

 

How many of you guys routinely use Git?

I’ve actually started using Git recently not super deep into it yet, but I’m getting the hang of the basics Right now, my project folder looks something like this

/README.md
/src/            # Firmware source code
/docs/           # Documentation
/hardware/       # Schematics, PCB layouts etc
/tests/          # Tests, Image, Video

I know there’s a lot more to learn (like proper versioning, branching strategies, etc.), but I’d prefer to discuss that part a bit later

 

I’ve actually started using Git recently not super deep into it yet, but I’m getting the hang of the basics Right now, my project folder looks something like this

/README.md
/src/            # Firmware source code
/docs/           # Documentation
/hardware/       # Schematics, PCB layouts etc
/tests/          # Tests, Image, Video

I know there’s a lot more to learn (like proper versioning, branching strategies, etc.), but I’d prefer to discuss that part a bit later

Use a Git GUI client, that's advice that will save your brain and make it much faster to work with, one of the worst things about Git is the archaic and laborious command line, it is much easier to understand and work with, I strongly recommend SmartGit.

One you have that the GUI makes it look like you basically have a change-aware file system, the main window shows any file that has changed since the previous commit, you can right click files, back out changes, save them etc, all very intuitive.



I just made a tiny change to that .cs file and you can see it, the GUI shows me anything that has changed.

If I double-click the file I see what the change is (left side is before and right side is now)



If I were to commit that change then a new commit would appear in the bottom window (above the commit a02aa3a5) and the main window would become empty.

I could go back and double-click the commit 989cb82c and the whole file folder will go back to the state it was at that point in time, this makes it trivial to set our code to any of the historic states it was in. I often do this, I will find some code seems to be broken and so I can go back to last week and satisfy myself that it worked OK then and that makes it quick to home in on the exact point at which I broke the code.

So bear this in mind, the command line is a huge pain and I never ever need it, the GUI does everything and that particular product is excellent, never had any problems with it in ten years.

If I'd had git twenty years ago it would have saved so much time, it makes development much more pleasurable having this degree of insight into changes.

I'm no fan of Linux but I give Torvald 100% credit and respect for what is arguably a superbly designed system.

 

I’m currently working on other parts of the project, but I had a question in mind. As the project grows, the amount of code is going to increase a lot with multiple modules and files interacting together. At that point, finding where exactly something went wrong or debugging specific parts might become difficult.

So I was thinking, is it a good idea to create a separate source file (say, error.c or debug.c) dedicated just for error handling and debugging functions? Something like having standard error codes, logging, or maybe some common debug print functions that all modules can use.

What’s the usual or recommended approach for handling this in larger embedded projects?

 

Yes, in professional projects the code is organised through more source files (dbgLib.c/h, spiLib.c/h etc) and one or more makefiles.

EDIT: with separated object files from sources.