scott wrote:

> You should never be leaving any inputs as floating anyway, that's just 
> asking for trouble (for example if you use a different IC series later). 
> Best to always tie your inputs to whatever you want them to be.

So what might be a good value for a pull-down resistor then?

(4.5V supply, 74HCxx ICs.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Am 23.05.2010 16:38, schrieb Orchid XP v8:

> So what might be a good value for a pull-down resistor then?
>
> (4.5V supply, 74HCxx ICs.)

A very common choice is 10 kOhm.

Post a reply to this message

>> So what might be a good value for a pull-down resistor then?
>>
>> (4.5V supply, 74HCxx ICs.)
> 
> A very common choice is 10 kOhm.

OK. That should only be a few pence...

Post a reply to this message

On 5/21/2010 9:57 AM, Invisible wrote:
>>> That and the subcircuit label...
>>
>> Actually, if you click on the subcircuit, you'll see some items in the
>> attributes window. One item is label. But, if you have multiple
>> instances of the same circuit and change the label for one, it changes
>> for all.
>>
>> Again, somewhat annoying.
>
> Yes, the "label" is so that if you have a dozen subcircuits, you can
> tell which type each one is. It's _not_ for labelling a specific
> instance. (E.g., if you insert a register, you can't label it with a
> register name. You can only label it with the kind of register it is.)
>

Right, but sometimes it would be nice to have a label that identifies 
the particular instance. At least, that's what I would expect when 
clicking on the item.

>>> It's trying to be helpful by detecting circuits which are unstable.
>>
>> I think it's more or less bailing out on a potential infinite loop.
>
> Hey, if it just wasn't handled, the program would crash. The fact that
> it's *noticing* the problem means that it's doing extra processing
> specifically to deal with it. But yes, it is a tad annoying. (Presumably
> the problem goes away if you use the built-in latch primitive...)
>

Well, of course the built-in latch primitive doesn't exhibit that 
problem. But with the Falstad app, the oscillation tends just to 
continue due to the way it's simulated. Logisim uses a propagation 
method where the values are carried from one component to the next, 
which can cause an infinite loop. Whereas Circuit Sim uses a timeslice 
method, where the entire circuit is calculated each tick, an oscillation 
can occur without any detriment to the program.

>>> Yeah. The whole wiring concept is just awkward. For example, Reactor
>>> (which has nothing to do with electronics but does involve wiring things
>>> together) has wires that go in a straight line from pin to pin. And when
>>> you move stuff, IT DOESN'T BREAK ALL THE WIRES OR RANDOMLY CONNECT THEM
>>> TO OTHER PINS! Sheesh, it's not rocket science...
>>
>> Actually, it can be a little tough to reroute wires when restricted to

>
> All I know is that I seem to spend more time trying to figure out how to
> move a component slightly to the side to make more space than actually,
> you know, designing my stuff! >_<
>

Yeah, Routing can be a pain when moving components. You can turn on an 
experimental feature where it allows you to sort of autoroute the wires 
in some cases when moving a component, but I've found if you move too 
far it will make bad connections. The algorithm that autoroutes needs to 
be a bit smarter, but I think it may be an instance of the halting problem.

>>> I'd prefer something less ugly to look at, personally.
>>
>> Well, sure, but function before form. I mean,
>>
>> this one was pretty, but was a pain to work with:
>> http://www.logiccircuit.org/
>
> What's up with it?
>

Not a clue... all the pretty ones aren't all that bright. ;)

>>> KLogic was easier to wire up. And it could do simulation graphs, which
>>> is extremely useful when you're trying to check, e.g., that your flip
>>> actually flops on the rising edge.
>>
>> Also, not available for Windows platform...
>
> I'd be surprised if nobody has ported it yet... but yeah, that's the
> least of the problems. A simulator that gives you THE WRONG ANSWER isn't
> very useful.
>

No, I suppose not. :)

>> http://www.falstad.com/circuit/
>
> I didn't even know that thing had logic gates...
>

It does. While it makes a great general circuit simulator, for anything 
non-trival its far from ideal for logic simulation, though.

>> The hex editor when I get finished with it will be very nice, though.
>
> No it won't. You'll never finish it. >:-)

Now I'll finish it just to prove you wrong, so ... Nyah!
-- 
~Mike

Post a reply to this message

>> Yes, the "label" is so that if you have a dozen subcircuits, you can
>> tell which type each one is. It's _not_ for labelling a specific
>> instance. (E.g., if you insert a register, you can't label it with a
>> register name. You can only label it with the kind of register it is.)
> 
> Right, but sometimes it would be nice to have a label that identifies 
> the particular instance. At least, that's what I would expect when 
> clicking on the item.

I won't disagree with that... ;-)

>> All I know is that I seem to spend more time trying to figure out how to
>> move a component slightly to the side to make more space than actually,
>> you know, designing my stuff! >_<
> 
> Yeah, Routing can be a pain when moving components. You can turn on an 
> experimental feature where it allows you to sort of autoroute the wires 
> in some cases when moving a component, but I've found if you move too 
> far it will make bad connections. The algorithm that autoroutes needs to 
> be a bit smarter, but I think it may be an instance of the halting problem.

The Halting Problem is unsolvable. I doubt wire routine is unsolvable. 
Finding the "perfect" wire routine sounds a bit like the Travelling 
Salesman problem, which is NP-Complete, not *not* unsolvable. And a 
routing algorithm which doesn't alter topology and gives "reasonable" 
results ought to be quite possible, though possibly not easy...

>>> this one was pretty, but was a pain to work with:
>>> http://www.logiccircuit.org/
>>
>> What's up with it?
> 
> Not a clue... all the pretty ones aren't all that bright. ;)

I tried it on Friday. Jesus, it sucks so hard! Eats RAM like candy, 
locks up for minutes at a time for no apparent reason, and doesn't even 
look particularly good anyway. Basically there's nothing to recommend 
it. (Plus I had to wait 30 minutes for the .Net framework to install...)

>>> http://www.falstad.com/circuit/
>>
>> I didn't even know that thing had logic gates...
> 
> It does. While it makes a great general circuit simulator, for anything 
> non-trival its far from ideal for logic simulation, though.

Yeah, it's designed to show you examples, not for serious design work.

>>> The hex editor when I get finished with it will be very nice, though.
>>
>> No it won't. You'll never finish it. >:-)
> 
> Now I'll finish it just to prove you wrong, so ... Nyah!

Heh. I'd like to see that. ;-)

Post a reply to this message

BTW:

http://sourceforge.net/projects/logicsim/

Requires .NET Framework 3.5

Only really just tiny pieces of the UI implemented, but you can sort of 
see how it will work.

-- 
~Mike

Post a reply to this message

On 5/24/2010 7:56 AM, Invisible wrote:
>>> Yes, the "label" is so that if you have a dozen subcircuits, you can
>>> tell which type each one is. It's _not_ for labelling a specific
>>> instance. (E.g., if you insert a register, you can't label it with a
>>> register name. You can only label it with the kind of register it is.)
>>
>> Right, but sometimes it would be nice to have a label that identifies
>> the particular instance. At least, that's what I would expect when
>> clicking on the item.
>
> I won't disagree with that... ;-)
>
>>> All I know is that I seem to spend more time trying to figure out how to
>>> move a component slightly to the side to make more space than actually,
>>> you know, designing my stuff! >_<
>>
>> Yeah, Routing can be a pain when moving components. You can turn on an
>> experimental feature where it allows you to sort of autoroute the
>> wires in some cases when moving a component, but I've found if you
>> move too far it will make bad connections. The algorithm that
>> autoroutes needs to be a bit smarter, but I think it may be an
>> instance of the halting problem.
>
> The Halting Problem is unsolvable. I doubt wire routine is unsolvable.
> Finding the "perfect" wire routine sounds a bit like the Travelling
> Salesman problem, which is NP-Complete, not *not* unsolvable. And a
> routing algorithm which doesn't alter topology and gives "reasonable"
> results ought to be quite possible, though possibly not easy...
>

I suppose that's correct.

http://www.freerouting.net/index.php?page=home

But can be rather difficult to calculate an optimal route. Of course, 
the program above treats wires as physical obstacles.

On thinking a bit more about it, it's probably not horribly difficult.


>
> I tried it on Friday. Jesus, it sucks so hard! Eats RAM like candy,
> locks up for minutes at a time for no apparent reason, and doesn't even
> look particularly good anyway. Basically there's nothing to recommend
> it. (Plus I had to wait 30 minutes for the .Net framework to install...)
>

Yeah, I didn't get that far.... about the point where I had to drag and 
drop components to the circuit was when I decided it wasn't a viable 
solution.

>>>> http://www.falstad.com/circuit/
>>>
>>> I didn't even know that thing had logic gates...
>>
>> It does. While it makes a great general circuit simulator, for
>> anything non-trival its far from ideal for logic simulation, though.
>
> Yeah, it's designed to show you examples, not for serious design work.
>

Yup, but a great learning tool :)

>> Now I'll finish it just to prove you wrong, so ... Nyah!
>
> Heh. I'd like to see that. ;-)

You'll see... you'll see.

-- 
~Mike

Post a reply to this message

On 23-5-2010 16:38, Orchid XP v8 wrote:
> scott wrote:
> 
>> You should never be leaving any inputs as floating anyway, that's just 
>> asking for trouble (for example if you use a different IC series 
>> later). Best to always tie your inputs to whatever you want them to be.
> 
> So what might be a good value for a pull-down resistor then?
> 
> (4.5V supply, 74HCxx ICs.)

There is seldom a need to use a pull-down resistor at the input. You can 
simply connect it to the ground. With e.g. a 7400 you can connect both 
inputs together in stead of one to the positive power supply line to get 
functionally an inverter (that is often easier to route than the 
alternative).

Post a reply to this message

>>> So what might be a good value for a pull-down resistor then?
>>>
>>> (4.5V supply, 74HCxx ICs.)
>>
>> A very common choice is 10 kOhm.
>
> OK. That should only be a few pence...

Unless you are connecting a switch to the input, I don't see why you'd need 
a pull-down resistor, just connect it directly to ground.

Post a reply to this message

>>>> So what might be a good value for a pull-down resistor then?
>>>>
>>>> (4.5V supply, 74HCxx ICs.)
>>>
>>> A very common choice is 10 kOhm.
>>
>> OK. That should only be a few pence...
> 
> Unless you are connecting a switch to the input, I don't see why you'd 
> need a pull-down resistor, just connect it directly to ground.

Indeed. So it looks like I'm going to end up needing a seperate 
pull-down resistor for each "external" input to the logic system. I was 
hoping I could get away with just one, but that apparently won't work at 
all...

Oh well, I guess I'm not going to have all that many manual inputs.

The other problem is that I suspect connecting an LED to an output drags 
the voltage out of spec, so I probably can't connect the same output to 
an input. I guess I'll just buy myself a hex buffer and be done with it.

Post a reply to this message