Getting started with logic cuircuits and the arduino.
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Getting started with logic cuircuits and the arduino.
Having been learning to program recently I've become interested in the more physical aspects of it. I would like to learn to make circuits using logic gates and also hooking this up to my computer with a arduino.
Information on books, websistes, where to buy (I'm in thr uk), and other relevant stuff would be greatly appreciated.
It's hard to say where a beginner should start on logic circuits. First of all there's the logic - all sorts of gates have been implemented (with all sorts of inputs too) and you can wire inputs to outputs of different gates to obtain different results.
There is actually quite a bit to learn about the logical combination of such gates. For example, what basic gates can you use to build all other logic gates? ('or' and 'not' - but if you care even less for efficiency, 'nor' gates can be abused to do everything) If you care about efficient use of gates and how to reduce a logic problem to its simplest form, there is an awful lot to read. One of the more basic skills is learning to write out logic tables (what outputs correspond to what inputs).
Now aside from the logic, there are the physical limitations of the actual implementations of the gates. Things don't happen instantaneously - changes in the inputs take time to be propagated to the outputs. Connecting too many inputs to an output will 'load' that output and the voltage will not be able to achieve the levels needed to signal other circuitry. With CMOS design, a change in state is always associated with essentially a short-circuit of the CMOS devices; this is the primary reason that using higher frequency clocks results in more heat generated. Logical '0' and '1' are *not* voltages as such, but voltage ranges (<X means '0' and >Y means '1' - except for negative logic in which the reverse is true). Different logic families (for example, TTL, HCMOS, LCMOS, NMOS, ECL) often have different threshold ranges for logical 0 and 1 (and even different power supply voltages!); you have to be aware of that when mixing logic chips or you might get a rude surprise when the (correct) schematic you have on paper doesn't actually work using the chips you chose to implement it. And finally - if you ever use or create very complex logical circuits, there is a danger of 'lock-up' as the circuit is started. Basically, every input should be considered to be in a random state as the circuit is powered; if you're unlucky, some of those random states will result in your overall circuit switching into a stable (but unusable) state or (even worse) a stable sequence of unusable states (which sometimes results in overheating and fried circuitry).
So - be prepared for a lot of reading and a lot of homework. But it's all fun and certainly not impossible to learn.
Distribution: Debian Wheezy/Jessie/Sid, Linux Mint DE
Pinniped are you sure that CMOS circuits dissipate power because of power lines get shorted momentarily during transition? To my knowledge, a CMOS output consumes virtually no power when in either 1 or 0 state because either there is no voltage across the transistor, or there is voltage, but no current. However since a state transition is not infinitely short, for some time current will run thru a transistor, and hence the product of U and I becomes non-zero. But the current is mainly the charge from the next stage being transferred to one of the power rails, or vice versa from the power rail to the next stage. It could even be charge from the other transistor in the totem pole, dunno that detail. I thought short circuits (both transistors conducting at the same time) were something of the past.
The beautiful about ECL is that the current thru each stage was equal no matter what the state was, not matter whether it was transitioning (sp?) or not. I thing the PDP7 was implemented in ECL, PDP11 used TTL and a lot of fans for cooling
If you find an older PC with traditional parallel ports that are mapped into the traditional IO address space, it is quite easy to hook up external logic to it for experimenting. Try hooking up some logic to read and write some static RAM, or operate some LED's, read some switches, etc. The pinout and behavior of the parallel port is well documented online, and the connector is usually easily accessible. Get yourself an experimenter's board, the so-called SK-10 board, which allows you to quickly wire up logic circuits. You will have to tap into the power supply's five volt supply to drive your TTL/CMOS logic. This is easily done by splicing into the red (+5VDC) and black (Ground) wires exiting the power supply (I *did* say 'use an older PC', right?). If you can find a PC with an ISA bus, and a prototyping wire-wrap board, your can build your own plug-in peripherals. These may be difficult to find in this day and age. Trying to do the equivalent on PCI bus is probably way over the head of most basement designers and hobbyists.
Pinniped are you sure that CMOS circuits dissipate power because of power lines get shorted momentarily during transition?
Yes, it is a short circuit which lasts while both output transistors are biased to the full ON state. The duration (from much less than 1ns to a few tens of ns depending on the era and the designs used) helps limit the overall current drawn. Otherwise the only substantial limitation is in the inherent resistance of the gates. Since the gates themselves are so small, the resistance is moderate rather than near-zero.
Distribution: Debian Wheezy/Jessie/Sid, Linux Mint DE
This is from an article in Wikipedia. Emphasis by me:
CMOS logic dissipates less power than NMOS logic circuits because CMOS dissipates power only when switching (dynamic power). On a typical ASIC in a modern 90 nanometer process, switching the output might take 120 picoseconds, and happen once every ten nanoseconds. NMOS logic dissipates power whenever the output is low (static power), because there is a current path from Vdd to Vss through the load resistor and the n-type network.
CMOS circuits dissipate power by charging the various load capacitances (mostly gate and wire capacitance, but also drain and some source capacitances) whenever they are switched. The charge moved is the capacitance multiplied by the voltage change. Multiply by the switching frequency on the load capacitances to get the current used, and multiply by voltage again to get the characteristic switching power dissipated by a CMOS device: P = CV2f.
A different form of power consumption became noticeable in the 1990s as wires on chip became narrower and the long wires became more resistive. CMOS gates at the end of those resistive wires see slow input transitions. During the middle of these transitions, both the NMOS and PMOS networks are partially conductive, and current flows directly from Vdd to Vss. The power thus used is called crowbar power. Careful design which avoids weakly driven long skinny wires has ameliorated this effect, and crowbar power is nearly always substantially smaller than switching power.
Well, I didn't inspect them closely, but when I Googled 'parallel port interfacing', the first 50 or so hits looked very relevant. I will leave it up to you to discover which are most valuable to you. I know there were numerous good sites some years ago. Also check out a reputable book by Jan Axelson on the subject of Parallel ports.
If you find an older PC with traditional parallel ports that are mapped into the traditional IO address space, it is quite easy to hook up external logic to it for experimenting.
Any PC with a parallel port should do; you just need to use the ioctl() call to set up the port as you please. But if someone already has an arduino, I don't see the point because the ioctl() coding and wiring to the parallel port just makes things more complicated. There is also a greater chance of damaging the chip which provides the parallel port.
Actually, yes, I did. I got a large number of hits, of which numerous seemed to have possible connections to this thread. But really, I was also hoping to coax a little more information out of the original poster, as to his plans.
Any PC with a parallel port should do; you just need to use the ioctl() call to set up the port as you please.
Actually, I specified 'older PC with traditional parallel ports that are mapped into the traditional IO address space' for a deliberate reason. Many newer such ports, require navigating the PCI interface. This can be tricky, and especially so for a newbie. The plethora of older online documentation about parallel ports will be substantially biased toward the class of devices that would map into the older ISA/real-mode address space. Doing real tricks with a parallel port requires access that ioctl() does not provide. In fact, I suggest starting with something simple like MS-DOS and debug for rapid testing & experimenting. Once some of the main techniques are learned, they can be transported to Linux, but the /dev/port() interface gives somewhat greater creative freedom.
If you can scrounge up an older (make that ancient) book called 'Handbook of Software and Hardware Interfacing for IBM PCs' (ISBN 0-13-381849-7, Prentice Hall) by Jeffrey Royer, it is a great way to learn about logic and low-level programming for computers. There were a few others of that era (one by Peter Norton) that can also be instructive.