[Ktechlab-devel] 74164 shift register.

[Alan Grimes]

Right now I have a hand-implemented shift register with a ton of
D-flippies. There is a standard chip that does the same thing called the
74164 (or more modern: 74LS164).

I started to implement the part then I remembered that I wanted to
re-design the parts library.

Here are some of the things that are pissing me off about the code right
now.


>>> Nonlinear is broken, affecting Diode and Jfet but apparently leaving
bjt untouched for some unfathomable reason, might be a computational
drift issue or exponentially huge value returned by the current version
of diodeJunction, or some other bug in the engine. (!!!) there is plenty
of evidence for other bugs, IE seeing 27 volts in a circuit with nothing
except 5 volt power supplies.  (We need infrastructure to
benchmark/measure when the nonlinear iterations converge and not and
obtain debugging on when it doesn't.)

>>> Connectors still mess up, It's not the catastrophy it used to be,
the showstopper bugs have been fixed but there are MANY problems. For
example, I came across a class Point today. Why the hell do we have a
class point?? Well anyway, I started to refactor it to see whether it
tends to either evaporate or pull in other functions to become a proper
class... Well, two of its four variables were set but never read, so I
cleaned lines of code from several other methods. The connector router
is the most algorithmically complex thing ktechlab does. In order to
make it work we _MUST_ do our best to organize that code so that it
makes the best sense, has no dead variables or functions so that it is
plainly obvious what everything does.


>>> there are still many classes stacked on top of each other (in the
same files. If all the classes in the file are tiny, then OK. If there
are two or more decent sized classes in a single file THEY SHOULD BE
SEPARATE!!!!

There are many many advantages to keeping classes separate, for one
thing it becomes easier to audit which classes a class is using. In one
case I found a class including a bunch of child classes when it should
have included only a parent class. By cleaning up includes we also
improve compile time and the reliability of our builds.

Fortunately, ktechlab is shaping up to have several discreet layers of
organization. These layers should be made more distinct and the
separation between them should be rigorously enforced. Ie, most code in
/src should be completely ignorant of anything and everything going on
in either /src/electronics or /src/flowparts. This way the code becomes
more robust and maintainable.

In general there should not be any super huge or super tiny classes.
Some of the super tiny classes might be better treated as structs or
even switch to library functionality.

One of the reasons its difficult to debug the simulation engine is that
I messed up the current reading code from the wires. =P (Yes it's my
fault too.) But to get it working again I need a traceable path from the
engine through the model classes (pin and wire, I think), to the
interface classes such as electricconnector and ECNode.

I want to simplify jkflipflop some more but am not using it right now
and don't really have any good test circuits.

Anyway.

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.