On 5/21/2010 5:25 AM, Invisible wrote:

>
> Of course, when you buy a kit, somebody else has already figured out
> what kind of LEDs to put in there, and what resister you need to connect
> it to. I recall routinely using ICs to drive LEDs - but that was TTL,
> and now I'm looking at CMOS, which has different characteristics.

Not that hard to figure out what kind of resistor you'd need to safely 
drive an LED for a given voltage.

You subtract the Vf of the LED from the supplied voltage, then use ohms 
law to calculate the resistance you'll need to drive the LED in its 
current range.

BTW, why CMOS? TTL is more robust for experimentation. CMOS you have to 
worry about damage from ESD, etc...

>
> Anyway, we'll see what happens I guess.


-- 
~Mike

Post a reply to this message

Am 21.05.2010 10:18, schrieb Invisible:

> The datasheet for the 7400 is 1 page. It tells you the maximum voltages
> and currents, a few time constants, and that's literally *it*.

I guess you're talking about the Texas Instruments Digital Logic Pocket 
Data Book; I must confess that I lied to you about that: It only 
contains summaries of the actual datasheets. For each individual device, 
TI has much more detailed documentation; for instance, the datasheet for 
the SN54HC00/SN74HC00 alone is 18 pages in total.

> As I say, it's not a manual. It assumes that you already *know* what a
> NAND gate is (which fortunately I do).

Yes, the Pocket Data Book does indeed assume you already have some 
/general/ idea what each of the devices (or at least the subset thereof 
that you're interested in) does.

So do the datasheets. Still they're manuals (and often better at that 
than most software documentation) - but remember that a manual does not 
necessarily include a tutorial.

> I have no idea how or why transistors work. But then, the entire _point_
> of a logic gate is that it doesn't matter _how_ it works. It's a black
> box. It implements a logical function. That should be all you need to know.

Note however that this black-box-knowledge should include the interface 
characteristics - and knowing what goes on in a /simple/ logic gate 
helps a lot to this end.

For instance, you should know how many inputs a logic gate output can 
drive reliably; how an unconnected input behaves; how the gate creates, 
and how it is affected by, noise on the power rails (and how to deal 
with that phenomenon); how much current the gate draws, and what 
parameters affect the power consumption (e.g. a TTL device will draw 
current primarily due to its internal state, while a CMOS device will 
draw current primarily due to changes of its internal state); and plenty 
more such stuff.

Post a reply to this message

>> Of course, when you buy a kit, somebody else has already figured out
>> what kind of LEDs to put in there, and what resister you need to connect
>> it to. I recall routinely using ICs to drive LEDs - but that was TTL,
>> and now I'm looking at CMOS, which has different characteristics.
> 
> Not that hard to figure out what kind of resistor you'd need to safely 
> drive an LED for a given voltage.

I wouldn't have thought so.

> You subtract the Vf of the LED from the supplied voltage, then use ohms 
> law to calculate the resistance you'll need to drive the LED in its 
> current range.

My plan was to just connect it up and see if it works - but sure, your 
way would work too. ;-)

> BTW, why CMOS? TTL is more robust for experimentation. CMOS you have to 
> worry about damage from ESD, etc...

This was my initial reaction too. However, it seems that CMOS has 
several advantages here:

1. It's fractionally cheaper.

2. It uses less power.

3. It has a much bigger fan-out.

4. It can source more current.

5. It works over a greater range of supply voltages.

Seems the only real disadvantage is static damage...

Post a reply to this message

>> Not that hard to figure out what kind of resistor you'd need to safely 
>> drive an LED for a given voltage.
> 
> I wouldn't have thought so.

Uh, how did this sentence end up saying the inverse of what I meant?

Maybe I've been staring at logic gates too long?

Post a reply to this message

On 5/21/2010 7:40 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.

>> One thing that is particularly annoying is if you need a gate with an
>> even number of inputs beyond 2: They don't exist.
>
> Yeah, that too. Hello? It's software? It's not like with real hardware
> where it would *cost money* to have more sizes available. :-P

Well that and the fact that some of the sizes aren't actually available 
in hardware, yet some sizes that are available in actual hardware aren't 
available in the app. (in particular 4-input gates!)


> 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.

> Actually, I found a small hack: If you have, say, an RS latch and you
> configure the S pin to float low and the R pin to float high, it
> generally stops complaining. (Unless something really *is* wrong...)

Right, so the circuit isn't in an invalid state when it's plopped onto 
the board.

> 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 


>> Also frustrating is the lack of bidirectional pins for subcircuits.
>
> So far I haven't found this to be a problem.
>

It is when you have something that is communicating on a data bus, and 
can send and receive data.

>> I'm not terribly concerned with how the application looks. It
>> functions reasonably if you stay away from the caveats.
>
> 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/


>>> But apart from all that, it works perfectly. :-}
>>
>> It does the job, at least. It's somewhat better than the rest of the
>> programs out there.
>
> 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...

>
> It already *has* keyboard shortcuts for selecting different gates and
> stuff. What are you asking for?
>

Oh, yeah, the 10 Ctrl-# keys for the toolbar items, but that's it.

>> Falstad's circuit sim seems a bit easier to use at times, and it's
>> interface isn't stellar.
>
> Which one?
>
http://www.falstad.com/circuit/

> I also considered doing this. It would be nice to be able to concentrate
> on building logic rather than working around the limitations of some tool.

Yep.

>
> The reason I haven't attempted this yet is that I have literally no clue
> how to do something as complex as registering arbitrary mouse clicks and
> drawing sophisticated graphics in response. (E.g., how the hell do you
> figure out what the user just clicked on? Usually I let the toolkit sort
> that out - but this doesn't work if you draw everything yourself.)
>

You have a choice between hit-testing a rectangle or using something 
like a region to hit-test. (Either your own "is this point inside a 
polygon" test (Actually, really simple: How many times do you cross a 
line in the poly from the point going in one direction, if its an even 
number you're outside, if it's an odd number, you're inside), or using 
the operating system's ability to create regions from paths (At least 
under Windows... Dunno about X) Once the region is created, it's a 
bitmap and very quick to test. I've done quite a few custom controls in 
my day. One of which is a nearly cad-like environment.


>
> Join the club. ;-)

Hehe ... I have a rather ambitious half-finished hex editor sitting on 
my hard drive. Dozens of other little things, as well.

The hex editor when I get finished with it will be very nice, though. 
Able to interpret text data, overlay structures, use alternate word 
groupings, etc. The core editor portion is nearly complete, but I'm 
still working out how best to manage large files, as far as storing 
edits without actually writing to the file, and without slurping the 
entire file into memory. The big challenge is how to handle the ability 
to insert/delete bytes, since these involve shifting subsequent data, 
and only loading what is needed. Simple for a single span, but when you 
start getting multiple spans of data, it gets a bit complicated in how 
to deal with it and still be efficient.

-- 
~Mike

Post a reply to this message

>> 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.)

>> 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...)

>> 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! >_<

>> 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?

>> 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.

>>> Falstad's circuit sim seems a bit easier to use at times, and it's
>>> interface isn't stellar.
>>
>> Which one?
>>
> http://www.falstad.com/circuit/

I didn't even know that thing had logic gates...

>> Join the club. ;-)
> 
> Hehe ... I have a rather ambitious half-finished hex editor sitting on 
> my hard drive. Dozens of other little things, as well.

Again... join the club.

> The hex editor when I get finished with it will be very nice, though. 

No it won't. You'll never finish it. >:-)

Post a reply to this message

On 5/19/2010 7:07 AM, Invisible wrote:
> Ah yes. That's the fun thing about doing digital electronics. You can't
> just *buy* a 7400. No, you have to decide whether you want a 74LS00 or a
> 74HC00 or a 74HCT00 or...
>
> Reading the datasheets is like walking into another world. (Especially
> since the datasheets are usually poorly-scanned grainy PDFs that don't
> match the part number you actually asked about!)
>


A book that I found immensely helpful

http://www.amazon.com/CMOS-Cookbook-Second-DON-LANCASTER/dp/0750699434

Mine is well used and worn.

Great for getting off the ground quickly without spending hours 
searching the net.


Tom

Post a reply to this message

On 21-5-2010 15:53, clipka wrote:
> Am 21.05.2010 10:18, schrieb Invisible:

>> I have no idea how or why transistors work. But then, the entire _point_
>> of a logic gate is that it doesn't matter _how_ it works. It's a black
>> box. It implements a logical function. That should be all you need to 
>> know.

Wrong. See clipka's comment below. Also it is vitally important to know 
how a logical function is implemented if you are going to use it outside 
the logical specification. In particular the mathematical logical NAND 
is not specified if you leave one input open. What would a Haskell 
implementation do if you leave one input open?

> Note however that this black-box-knowledge should include the interface 
> characteristics - and knowing what goes on in a /simple/ logic gate 
> helps a lot to this end.
> 
> For instance, you should know how many inputs a logic gate output can 
> drive reliably; how an unconnected input behaves; how the gate creates, 
> and how it is affected by, noise on the power rails (and how to deal 
> with that phenomenon); how much current the gate draws, and what 
> parameters affect the power consumption (e.g. a TTL device will draw 
> current primarily due to its internal state, while a CMOS device will 
> draw current primarily due to changes of its internal state); and plenty 
> more such stuff.

Post a reply to this message

On 21-5-2010 16:15, Invisible wrote:
>>> Not that hard to figure out what kind of resistor you'd need to 
>>> safely drive an LED for a given voltage.
>>
>> I wouldn't have thought so.
> 
> Uh, how did this sentence end up saying the inverse of what I meant?

http://www.datasheetcatalog.org/datasheets/270/487906_DS.pdf

Post a reply to this message

On 21-5-2010 10:20, Invisible wrote:
> andrel wrote:
> 
>> Ok, Andy, here is the deal: we trust Ken in this, you put one of these 
>> books on your Amazon Wish list and you give me a link to that wish 
>> list. In exchange, after you received it, you read it and you stop 
>> asking questions that are answered in the book. Remember: Ken has also 
>> a copy.
> 
> My mother once said something to me, which I try to follow [although I 
> don't always succeed]. She said "if you don't have anything nice to say, 
> don't say anything".
> 
> If you think my questions are stupid or you don't feel like answering 
> them, then fine. Don't answer them. Ignore the thread or something. But 
> there's no need to make a point of telling me I'm stupid just because I 
> *dared* to ask for a few pointers. OK?

I think you missed the point entirely. You really need a book or 
something else that simply teaches you the basics. That in the end is 
much more effective than asking questions here one at a time. I don't 
have a book to recommend (I actually learned it from reading 
datasheets). Ken apparently has, so my suggestion is to buy that book. I 
can do that in two ways 1) simply say: 'Andy, buy that book', but that 
has the problem that I cannot decide how you should spend your money or 
2) what I said above. You are of course entirely free to see 2) as a 
less friendly way, just as I am allowed to be totally flabbergasted by that.

Post a reply to this message