Sheep64 on Thu 11 Nov 2021 wrote:
You're probably over-thinking this problem.
No, actually, I'm under-thinking the problem. The shift register solution requires four signal lines: clock, data, set bits live - and then a programming pulse with controlled duration. I considered bodging this into a
NES input peripheral extension. However, that would be a horrible exercise. For a more elegant solution, I highly recommend
AndersNielsen's scheme to de-couple processor speed and pulse width by using a crystal clocked shift register which deliberately runs dry. AndersNielsen devised this to control WS2812B LEDs from 2MHz 6502 but the principle is widely applicable.
XR2801 is an attempt to implement a shift register design. I'm beginning to understand that circuit board layout is an iterative annealing process where the first attempt is best discarded. Even after several iterations, there may be WTF design decisions which can be optimized; most typically wires to nowhere, curious junctions (which look great on screen) or scenic tours around a board.
My first attempt was entertainingly awful. I "painted myself into a corner" where I required a fly lead to continue the shift register chain. In mention this because experienced designers may be amused by my first encounter with this phenomena. Likewise, I was unhappy with a power, clock and serial data bus which ran around the edge. I was more disappointed by component orientation. In an draft version of the XR2601 main board, I found that inward DIP components allowed ground around the outside and an inner power rail. However, this is only useful is very specific circumstances and is deprecated on all designs. I can almost feel BigEd's stern, tutting disapproval of my willful violation of
least surprise. (In this and other matters, I am considerably swayed by BigEd's advice.) However, this was not the most disappointing feature of my design. A design of this triviality should not have 10 vias.
I repeated the design with a more suitable data path. I also ensured that the two most popular EEPROM types can be programmed. Oddly, this didn't make the design wider. It only made the design taller to accommodate 28 pin DIP and 32 pin DIP chips. The
discussion about "river routing" aided one tight spot. Overall, I am happy that I got a superior design down to one via.
I am working on a list of design rules and this redundant newbie exercise has been helpful to refine the list. In particular, I specify large (3mm tall, 0.3mm thick) silk-screen component numbers on both sides of the board. Likewise, interface signals are silk-screened on both sides. I am similarly fastidious about fixing holes and rounded corners. I am my primary customer and I am able to describe in vast detail how my primary customer is not only an idiot but an
award winning idiot. This is particularly true before a second coffee. Therefore, skimping on safeguards will disproportionately disadvantage myself.
My overall intention is that any module may be soldered, interfaced, affixed and programmed without reference to documentation. Obviously, this is impossible in most cases. However, I believe that it is highly beneficial to streamline the process wherever possible. Unlike software comments which may fall out of step, text on a board must be current otherwise it will be mis-leading or contradictory. Sheep20 is amused by my placement of text typically of the form "SOLDER GOES ON THIS SIDE. COMPONENTS GO ON OTHER SIDE." and is particularly amused by abbreviated versions on smaller boards, such as "CHIPS THIS SIDE" or "CHIP SIDE", and suggested that we might be mistaken for a venture called Chipside Technology or similar. Actually, that could be a plausible Taiwanese name and it wouldn't look out of place among Allwinner, Ainol or Award. Nor would it look out of place among CkeyiN®, Dttrol or Xiomi.
I highly recommend designing your own EEPROM programmer. Although it has been done thousands of times before, it is a good exercise and oddly satisfying. However, if you are in a hurry, an untested example is freely available.