I use same source files for most functionality, i.e. target builds or PC regression testing.

The hardware mapping functions are normally in own files, allowing me to have multiple versions linked.

Then I normally have one header file containing the pin mappings and another file that contains low-level functions - for example a 3.3V chip may require switching between active drive low, and then changing pin to floating for high to allow a pull-up to go all the way to 5V for controlling a FET.

It's hard to just start writing the code to allow validation runs on a PC. It's a bit of step-by-step progression to get the experience how to best set up the solutions. But it becomes simpler for each new project. No, I didn't make use of any resources. I just started from scratch, writing helper functions and learning how best to structure the software. And with time, I get more and more functionality that can be reused.

The 8051 isn't the easiest processor. There is the issue with integer promotion normally skipped by the Keil C51 compiler to reduce the code size. And it's normally better to have a #define for SET_ALARM instead of an inline function. But with careful use of data types, the majority of code can be tested on a 32-bit or 64-bit machine even if written for an 8-bit target.

Obviously, a PC can't be used for testing timing issues, but it's normally quite few lines of code in a big program that have critical timing. If I just believe that the processor is fast enough for the task, I can worry about specific timings when I have the real hardware.

In the other direction - it's easier with a 8051 in that it normally don't use any RTOS. Normal threads in a PC application can simulate most actions performed by ISR or by the other side of a communication link. It's more work with a microcontroller that is used with an RTOS, since that requires a mapping layer to have the RTOS API duplicated into PC thread primitives.

Testing on a PC means I can create a GUI that shows a keypad and an LCD, and push buttons to simulate input stimuli. Or the program can load and run a stimuli file where it pays canned stimuli - possibly synchronizing stimuli with responses.

In the end, it's often possible to get very good code coverage when testing the code in the simulated environment (obviously except for the ISR and the code that performs the specific device register accesses).