How does one structure an assembly-language project?

A book could be written on this topic. I bet some have . . .

It's hard to answer because each tool-chain has its own strengths, shortcomings and quirks. I must have structured different projects a half-dozen different ways, but I will mention the two that I've used the most.

For almost all techniques, you need to partition the components adequately. The goal is to make each module 1) a well defined and documented black box that can be easily used without needing to dig into the code, and 2) general enough that it can be reused as-is in subsequent projects. All of my projects use my "math", "dispatcher" and "timer" modules. Then there may be modules for the SPI, I2C, SCI, PWM etc. Most of the time, this separation of functionality is pretty intuitive.

The first technique is to assemble each module separately and then put them all in a object library ("object" as in machine code, not "object" as in object-oriented programming). Then, when you write the main program, you just make calls to your library routines, and the linker will automatically include the necessary object modules in your executable.

But some tool-chains either don't support object libraries well, or make it a pain-in-the-neck to create and maintain. In that situation, I "include" each necessary source module at the end of the main program, and the assembler creates one large object module (which makes it easy for the linker).

In both cases, the main program starts with a list on "includes" for the hardware definitions and the macro definitions (I use LOTS of macros, both for readability and portability). Then I add the main code. If I'm using an object library, then that's it. If I'm using a source library, then I end with a list of "includes" for the required source modules.

I could go on, but its late . . .

I've written and maintained a reasonably-sized commercial package in assembly language (40,000 lines of 16-bit code and 35,000 lines of 8-bit). It worked well and had zero bugs.

The only inter-module communications possible were that a symbol (an address in program code or a data address in memory) could be declared public in one module and external in another. I didn't bother with libraries because assemblers and linkers are fast enough anyway, so compiling and linking everything each time worked just fine.

Header files were used to define constants, but could equally well have been used to declare external symbols as well.

That's the mechanics of it. As for the choice of what to divide up into what source module, that is programming as a literary art and you need to work out what works best for you. I had a layer of utility routines (even arithmetic ones) at the bottom, and then vertical divisions for different areas of functionality.

The freedom of assembler is both liberating and challenging, but it is an unparalleled opportunity to develop your own style.