Files
rose/devlog/2025-06-05-Much-progress.md

3.1 KiB

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.