POV-Ray : Newsgroups : povray.off-topic : Electronics research Server Time
4 Sep 2024 19:21:18 EDT (-0400)
  Electronics research (Message 71 to 80 of 104)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Mike Raiford
Subject: Re: Electronics research
Date: 21 May 2010 08:32:24
Message: <4bf67d58$1@news.povray.org>
On 5/20/2010 3:20 AM, Invisible wrote:

> Now looking at <http://focus.ti.com/lit/ug/scyd013b/scyd013b.pdf>, on
> page 231 (which is actually page 236 of the PDF file), we see that for
> the 74HC00 I'm looking at using, we have Icc <= 0.02 mA, Iol = -Ioh <= 4
> mA, and tPLH = tPHL <= 27 ns. Now, if I actually knew WTF that means...

Icc sounds like the supply current, Ioh/Iol would be the currents the 
output is capable of sourcing or sinking, tPLH and tPHL would be the 
slew rate for the device (e.g. how fast it transitions from one state to 
the next)

-- 
~Mike


Post a reply to this message

From: Invisible
Subject: Re: Electronics research
Date: 21 May 2010 08:40:44
Message: <4bf67f4c@news.povray.org>
>>> Unrelated, but tangential, How do you like LogiSim?
>>
>> Not very much.
>>
>> I mean, it *works*, but that's about it. It's really hard work to *do*
>> anything with it. All gates default to having 5 inputs, no matter how
>> many times you change it back to 2. All devices default to East
>> orientation, no matter how many times you change it. Even just moving
>> part of the circuit to make some room is quite unecessarily difficult.
> 
> Funny, it seems to get high ratings on SourceForge. ;)
> 
> But, yeah, all of your complaints are legitimate.

Too right! ;-)

> Actually, if you click 
> an item on the toolbar (And I hate the way the toolbar is tied to the 
> project, BTW...) and change its attributes there, then it should stick. 

I would literally have never thought of that.

> Pin labels on a subcircuit are a major PITA. IMO it should print the pin 
> on the block (even if the block needs to be a tiny bit larger)

That and the subcircuit label...

> 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

> Yeah, it doesn't do too well with latches or flip-flops. I tried to 
> build a J-K flip-flop in it, and it fell flat. Surprisingly the latch 
> worked fine (Maybe because it was a NAND latch, instead of a NOR latch?)

It's trying to be helpful by detecting circuits which are unstable.

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

> Another nuisance that I've encountered a frustratingly large amount of 
> the time is the "phantom wire"

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

> Also frustrating is the lack of bidirectional pins for subcircuits.

So far I haven't found this to be a problem.

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

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

On the other hand, KLogic crashes constantly, and sometimes gives you 
blatently incorrect results, which is far, far worse than merely being 
difficult to use.

> One thing the program truly needs is hotkeys. The way it is now requires 
> excessive mousing.

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

> Falstad's circuit sim seems a bit easier to use at times, and it's 
> interface isn't stellar.

Which one?

> Heh. A side project to this whole thing is writing my own logic 
> simulator.

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.

> I've got it at least moving signals from point a to point b 
> reliably. I can modify wires and move things around in the program, but 
> that's about it. My simulation model is different (from what I can tell) 
> from Logisim, so I'm guessing the whole flipping out over oscillation 
> and stopping the simulator may not happen. We'll see, but that's the 
> trouble with feedback. ;)

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

> I have the project on SourceForge (yeah, I'm going to do the entire open 
> source thing with it. Why not?) But, contrary to their suggestions of 
> releasing files on essentially day 0, I haven't released anything yet. 
> Once I get more of the basics done, I'll do a preview release.
> 
> One of the things that would be nice is the ability to create a timing 
> graph.
> 
> I also have a design goal of allowing the interface to be flexible. Such 
> as allowing the user to assign hotkeys to items, giving a choice between 

> 
> We'll see if it turns out to be anything more than vaporware, though. I 
> have a history of ethereal personal programming projects.

Join the club. ;-)


Post a reply to this message

From: Mike Raiford
Subject: Re: Electronics research
Date: 21 May 2010 09:20:18
Message: <4bf68892$1@news.povray.org>
On 5/20/2010 3:38 AM, scott wrote:

>
> The HC series can sink and source up to 4 mA on the output pins if you
> want the signals to still be valid (eg for input to further logic
> gates). If you are just using them to drive LEDs then apparently up to
> 20 mA is OK.
>

So long as the voltage doesn't sag below the forward voltage for the LED 
it should be OK. I think at that current it will barely be able to drive 
an LED.

-- 
~Mike


Post a reply to this message

From: Mike Raiford
Subject: Re: Electronics research
Date: 21 May 2010 09:25:05
Message: <4bf689b1@news.povray.org>
On 5/20/2010 12:14 PM, Orchid XP v8 wrote:

>
> Datasheets aren't manuals. They assume that you already know what, say,
> a Gated D-Latch is, and that you just want to know what its maximum
> driving current is or something. If you *don't* already know what a
> Gated D-Latch is, the datasheet will be of no use at all. You need
> *real* instructions.
>

Many datasheets will give you a truth table, and some even have 
schematic diagrams. They assume a basic understanding of electronics, 
though.


>> Have you ever looked at e.g.
>> http://en.wikipedia.org/wiki/File:TTL_npn_nand.svg ?
>
> 1. What is this thing?

A TTL NAND gate

>
> 2. How does it help?
>

You should be able to see why the input floats high from the schematic.

-- 
~Mike


Post a reply to this message

From: Mike Raiford
Subject: Re: Electronics research
Date: 21 May 2010 09:39:37
Message: <4bf68d19$1@news.povray.org>
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

From: clipka
Subject: Re: Electronics research
Date: 21 May 2010 09:53:44
Message: <4bf69068@news.povray.org>
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

From: Invisible
Subject: Re: Electronics research
Date: 21 May 2010 10:14:11
Message: <4bf69533$1@news.povray.org>
>> 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

From: Invisible
Subject: Re: Electronics research
Date: 21 May 2010 10:15:08
Message: <4bf6956c$1@news.povray.org>
>> 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

From: Mike Raiford
Subject: Re: Electronics research
Date: 21 May 2010 10:42:59
Message: <4bf69bf3$1@news.povray.org>
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

From: Invisible
Subject: Re: Electronics research
Date: 21 May 2010 10:57:35
Message: <4bf69f5f@news.povray.org>
>> 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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.