I'm creating some parts in LogicWorks and instead of having individual pins for input and output I want to use a bus pin. I can't seem to figure out how to make the bus pins appear in the part builder. I created a breakout in the sub-circuit to symbolize a bus, but when I go to create the part and import the sub-circuit the bus port doesnt show up. Anyone know how to do this?
Electronic – Creating a bus port in custom made part in LogicWorks
buslogicworks
Related Solutions
You don't show what the optos are connected to, but some logic devices (not 74LSxx devices) include "bus-keeper" circuits which behave as weak pull-ups when an input is high, and weak pull-downs when it is low. Such circuitry is often useful, but may cause difficulties when interfacing with logic which doesn't drive very strongly. Still, I would expect that a 10K pull-up should win against a bus keeper.
If the signals from the optos are connected to microcontroller I/O pins, I would suggest that between rows you release all the L1, L2, etc. wires, set the pins to outputs driven "high", then set the pins back to inputs and then drive the proper Lx pin. That approach should let you scan much faster than would otherwise be possible, whether there are bus-keeper circuits or not.
To clarify my later point, pins which are high tend to stay high, and vice versa (due to parasitic capacitance if not bus keepers). The time required for a pin to switch depends how hard it's driven. I would expect that an opto which is "on" would drive a pin low relatively strongly, while a 10K pull-up drives comparatively weakly. If one can disable the optos (e.g. by releasing all the Lx pins high) and use something to unconditionally strongly drive the column pins high (e.g. an I/O port configured as output), it will take almost no time to switch those pins high. If that high drive is then disabled and one Lx pin is driven low, it should be able to quickly switch the appropriate port pin. By contrast, if one simply changed which Lx pin was enabled without precharging the column, it might many many microseconds for the resistor to switch the pin high.
Since you don't have the columns connected to microcontroller I/O pins, you probably don't have a means of pre-charging them. If the only things that can pull the columns high are resistors, the speed at which the columns pull high will be controlled by the resistance. The lower the resistance, the faster the action, but if the resistors are too low the optos won't be able to sink enough current to yield a clean "low". If you want faster action, you could use diodes to connect a port pin to the bus pins such that when the pin is high it pulls all the bus pins high via the diodes.
I would agree on the likelihood of a wiring error (or else a design error), but would dispute the best solution for a complex system, particularly with parallel data paths (though we don't see as many of those today).
The problem with the preformed kits is that they restrict your color choice, and probably aren't long enough to go between multiple modules. (I probably could be talked into paying for a set of perfectly formed ones for ground straps and very short jumpers though)
Instead, for a complex project get yourself some good 22 gauge hookup wire in multiple colors, or if you can find some that fits well, surplus solid core telecom cable to split into individual wires.
I did enough breadboarding in childhood, that by the time I was assigned to build a fairly complex system in a course lab in engineering school, I realized I needed to do it in a way that would be durable and debuggable.
I used the same four colors in quasi-spectral order for busses. An 8-bit bus meant using them twice, but the bit position / color assignment remained constant in each nibble. If memory matches what I'd do today, the bus colors were never used for anything else - power, ground, config strappings and selects used something else.
No wires over chips (possible exception for a rare direct "staple")
Runs were grouped together, and often held down with short pieces of wire stuck in power buses or unused holes.
One could try to make a theoretical argument that running signals together in routing channels / bundles increases crosstalk, but the reality is that for the types of digital systems properly built on breadboards, crosstalk is not the problem.
Wires falling out, and not being able to figure out which hole they go back into, or which wire is which, is the problem.
Best Answer
I figured this one out. It turns out you have to create your own bus port inputs and outputs. It's fairly easy:
Open a new file for creating a device symbol. In Device Symbol Editor, Choose “Set to primitive type” in Options-> subcircuit/part type and then choose Port Connector. The symbol will then be of Type Port Connector. Create a number of pins for a bus by choosing Option->Add pins with, for example, INPUT[A0..A3] for a four-bit input bus that has signals A0 to A3. The signal names must match those that the bus is to be connected to. Therefore each bus port connector can only be used once to connect signals with same names. A bus internal pin can be either output or input or bi-directional. Set pins on a bus to be output pins if the pins are to be connected to inputs of a sub-circuit. Draw a bus symbol that can be any shape you want. Select a bus pin from the symbol palette and place it on the bus symbol. There are four bus pins, one for each side of the bus symbol. A screen capture on the right shows how a 4-bit input bus port can be created. Notice that the pin functions are designated as Output, although the bus port is an input bus port. Make sure the pin directions and the number of pins match the intended application. Save the port connector symbol to your own library.