finished the hub's logic, half done with the interfaces, and hopefully working on pi logic soon

This commit is contained in:
2025-06-05 22:38:26 -04:00
parent f61de84b4a
commit a94823b44a
8 changed files with 304 additions and 266 deletions

View File

@ -0,0 +1,71 @@
# Reworking Almost Done
Date: 2025-06-05
## Goals and expectations
Build the framework for the entire fabric's logic.
## Results
Nicely done.
This should've been split into several commits, but it's still work on
the same project. The following is all that's been done:
1. Completed the hub's logic.
2. Began reworking the interfaces' logic, already done with the RX
side of things (the RX side always seem simpler).
3. Built my own `git` server using `gitea` and `nginx` to host my
stuff (ROSE included).
4. Removed `specifications.md` and revised `protocol.md` to keep them
updated with the reworked routing logic.
## Is KISS elegance?
> Keep It Simple, Stupid.
Is this elegance?
It could be, when everything else is working within strict bounds
(e.g. the hub's strict logic), leveraging that strictness to simplify
some logic (e.g. adding a cooldown period for queue slot allocation)
is elegance. Leveraging the strictness allows the logic to be
simplified, and the simplicity is elegance in its most natural form.
## Reflections
1. KISS. Letting the interfaces manage the packet addresses was a
great decision. It dumbed down the hub's logic at the cost of
adding a bit of complexity to the interfaces' logic. This would
also make things do one thing and do that thing well.
2. Be organized. Organize the components by their functionalities.
It would prove to be very useful when there's a dozen latches
coming in and out of the interfaces/hub and you'd like to know if
you missed something.
3. Get sidetracked, absorb outside stimulation. Even though my last
devlog said to focus, there's still the need to know how other
things operate, even if they may seem irrelevant. I remember
reading the code for `SMaRTT-REPS` and `STrack` and some new CC
algorithms for UET during my time at Huawei, and then reading one
of their proprietary CC algorithms, which had a much simpler logic
but performs similar to the above-mentioned more complex ones.
Getting sidetracked would help you think - is there a simpler way
to achieve what I want?
4. Get started. I think I might stress this every time two commits
happen days away from each other, but I can never stress this
enough. I spent hours deciding whether or not to start coding with
the time I have on hand, but the real action only took a fraction
of that time. Begin, progress is progress, no matter how much it
is.
## Final thoughts
There are a lot of ideas that are still "under validation" in my mind,
like for example implementing a dual-issue round-robin scheme for the
hub to increase the maximum throughput and prepare ROSE for scale.
They don't go unnoticed, I'd add them to the devlog and hoping that
someday when I get the leisure to return to them, I can implement
them.
Also, finding time for ROSE has been hard, only fragments of time has
been found on most days. But there's no say that I can't do something
with that time.
## Next steps
Complete the TX logic, figure out the byte syncing for the SPI side of
things, and also test the things out on a TB and hopefully start
making my way back to C land on RPi's.