If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Hardware is easier to program than software?
So says a Computer Science programmer whose book I am reading. This is because you cannot make certain mistakes (or potential mistakes) when programming hardware-they physics won't let you--but you can in software, leading to problems down the road (this is why software often fails in 'mysterious ways' necessitating a reboot). Having done only a bit of programming in hardware (on a breadboard) in college but lots of software programming, I found his statement counter-intuitive (it seems hardware programming is harder) but it may indeed be true. After a while, after you memorize and master the hardware building block templates used in hardware programming (for example, a oscillator circuit, a Wheatstone bridge for balancing, etc etc, add your list here) indeed hardware programming maybe 'easier'.
Paul, what you say? |
#2
|
|||
|
|||
Hardware is easier to program than software?
RayLopez99 wrote:
So says a Computer Science programmer whose book I am reading. This is because you cannot make certain mistakes (or potential mistakes) when programming hardware-they physics won't let you--but you can in software, leading to problems down the road (this is why software often fails in 'mysterious ways' necessitating a reboot). Having done only a bit of programming in hardware (on a breadboard) in college but lots of software programming, I found his statement counter-intuitive (it seems hardware programming is harder) but it may indeed be true. After a while, after you memorize and master the hardware building block templates used in hardware programming (for example, a oscillator circuit, a Wheatstone bridge for balancing, etc etc, add your list here) indeed hardware programming maybe 'easier'. Paul, what you say? What a load of rubbish :-) (That's the short answer...) I guess you'll have to wait for my new book now, where I give my considered opinion, on the habits and qualities of Computer Science graduates :-) Paul |
#3
|
|||
|
|||
Hardware is easier to program than software?
"RayLopez99" wrote in message ... So says a Computer Science programmer whose book I am reading. This is because you cannot make certain mistakes (or potential mistakes) when programming hardware-they physics won't let you--but you can in software, leading to problems down the road (this is why software often fails in 'mysterious ways' necessitating a reboot). Having done only a bit of programming in hardware (on a breadboard) in college but lots of software programming, I found his statement counter-intuitive (it seems hardware programming is harder) but it may indeed be true. After a while, after you memorize and master the hardware building block templates used in hardware programming (for example, a oscillator circuit, a Wheatstone bridge for balancing, etc etc, add your list here) indeed hardware programming maybe 'easier'. Paul, what you say? I may be missing something, but how do you program hardware without software? You build hardware, but if you need it to do a special function (like say, an electric door opener/closer), then you build parts into it that make it perform the function you need. In this example, you would probably use some kind of limit switch to stop the motor when the door reaches its full open or closed sequence. I don't really see that as programming; it's just hardware. Now if you're looking for a microcontroller to use maybe an electric eye or two to limit the speed with which it goes at end of cycle, then you're talking about firmware programming (still not hardware). But simply putting resistors, capacitors, and ICs on a breadboard isn't really programming, it's simple circuitry, even if it's designed to perform a particular function. Did I miss something? -- SC Tom |
#4
|
|||
|
|||
Hardware is easier to program than software?
Not . . . logic errors can be made in hardware as well, some being subtle
and hard to track down. |
#5
|
|||
|
|||
Hardware is easier to program than software?
"SC Tom" wrote in message ...
I may be missing something, but how do you program hardware without software? . . . Did I miss something? The OP's textbook may be rather old. Its reference was to the earliest generations of computers programmed by manual switches (or paper tape simulating many switches). Within a decade computer operators discovered that (1) languages (e.g. ASM, Fortran) and (2) Disk Operating Systems (as well as (3) much-improved larger memory = data storage) was more efficient and more powerful. -- Don Phillipson Carlsbad Springs (Ottawa, Canada) |
#6
|
|||
|
|||
Hardware is easier to program than software?
"Don Phillipson" wrote in message ... "SC Tom" wrote in message ... I may be missing something, but how do you program hardware without software? . . . Did I miss something? The OP's textbook may be rather old. Its reference was to the earliest generations of computers programmed by manual switches (or paper tape simulating many switches). Within a decade computer operators discovered that (1) languages (e.g. ASM, Fortran) and (2) Disk Operating Systems (as well as (3) much-improved larger memory = data storage) was more efficient and more powerful. It would be REALly old then :-) Are we talking about the computers like the WWII language decryption models? If so, I don't think that was any easier than the originators of Fortran or DOS had it. -- SC Tom |
#7
|
|||
|
|||
Hardware is easier to program than software?
On Wednesday, September 12, 2012 2:58:01 PM UTC-4, SC Tom wrote:
Did I miss something? -- SC Tom I was thinking ASICs. It is true that ASIC design is software driven but the actual stitching together of the ASIC to do something useful is hardware design. As for firmware, etc, that's usually a small part of ASIC design, typically for bootup. That part is still hardware design in my mind, though you can quibble over definitions. RL |
#8
|
|||
|
|||
Hardware is easier to program than software?
On 2012-09-13 03:11:44 +1000, RayLopez99 said:
So says a Computer Science programmer whose book I am reading. This is because you cannot make certain mistakes (or potential mistakes) when programming hardware-they physics won't let you--but you can in software, leading to problems down the road (this is why software often fails in 'mysterious ways' necessitating a reboot). Having done only a bit of programming in hardware (on a breadboard) in college but lots of software programming, I found his statement counter-intuitive (it seems hardware programming is harder) but it may indeed be true. After a while, after you memorize and master the hardware building block templates used in hardware programming (for example, a oscillator circuit, a Wheatstone bridge for balancing, etc etc, addyour list here) indeed hardware programming maybe 'easier'. Paul, what you say? Writing firmware for hardware can be easier as long as you have the appropriate tools (logic/bus analyser oscilloscopes etc). It is easier in the sense that you are not working with an operating system and you are totally in control of what the hardware is doing. If it breaks, it is your fault and it can be diagnosed. With an operating system there are often many layers of abstraction and 3rd party systems that you have negotiate with - all areas that are ripe for presenting problems. Debugging race conditions in hardware can be ****iferous. |
#9
|
|||
|
|||
Hardware is easier to program than software?
On Wednesday, September 12, 2012 11:43:10 PM UTC-4, Astropher wrote:
Debugging race conditions in hardware can be ****iferous. Yes, race conditions are unstable and do not replicate--the same hardware can have a race condition in one moment and on reboot be fine the next moment. That's why designers have timing constraints that factor in a safety factor. I think I read somewhere that in fact it's possible to have a race condition even with certain inputs and/or operating conditions (temperature, voltage swings, etc at the limit) no matter what you do, or that was the implication. Every flip-flop, a backbone of hardware design, is unstable by definition in certain conditions btw. RL |
#10
|
|||
|
|||
Hardware is easier to program than software?
RayLopez99 wrote:
On Wednesday, September 12, 2012 11:43:10 PM UTC-4, Astropher wrote: Debugging race conditions in hardware can be ****iferous. Yes, race conditions are unstable and do not replicate--the same hardware can have a race condition in one moment and on reboot be fine the next moment. That's why designers have timing constraints that factor in a safety factor. I think I read somewhere that in fact it's possible to have a race condition even with certain inputs and/or operating conditions (temperature, voltage swings, etc at the limit) no matter what you do, or that was the implication. Every flip-flop, a backbone of hardware design, is unstable by definition in certain conditions btw. RL If this were true (that "flip-flops were evil"), your computer wouldn't stay running for very long. Obviously, it does stay running, so there's got to be a measure of stability present. Where a flip-flop can screw up, is if the data input changes, at the same instant that the clock input is used to take a sample. This typically arises in digital systems where two subsystems use a different clock. Clock relationships can be synchronous (flip-flop "likes"), plesiochronous (if phase is wrong, fails horribly and repeatedly), or asynchronous (fails statistically, and potentially once in a blue moon). In this case, Wikipedia doesn't have a good article, but if you're a hardware guy, you'll recognize the subject matter on this page. http://www.asic-world.com/tidbits/metastablity.html My company had its own fab and CMOS process. I shared office space in the fab building, with some of the geniuses over there. One neat gadget they build, was to measure metastability (parameters). It's so they could tell their customers (people who made use of the fab products), what the statistics of metastability were for that particular CMOS process. So if you visited there, you could be shown an oscilloscope trace, of the squiggles caused by metastability. A way to reduce metastability, is to use resampling. This is fine, except in cases where the additional delay affects performance. Or, in the old days, adding additional resampling stages, to improve the statistics, cost more money. And that would be an incentive not to use eight stages of resampling (as suggested in some document I read). Typically, we'd use the two stage resampler, if a solution was required, just like in this example. Certain late model 74F flip flops, could be used at a couple hundred megahertz to fix problems like this. This was back when we were still doing significant amounts of "board logic", rather than ASICs. http://www.asic-world.com/images/tidbits/meta.h1.gif Ah, this brings back memories. The good ole days... Our home-brew metastability measurement jig, may have been based on the concept in this paper. Documents like this, would have been required reading, at the time. http://www.ti.com/lit/an/sdya006/sdya006.pdf If your design is purely synchronous, the flip-flop is as stable as can be. It's when you purposely change the data, as the clock causes the flip-flop to sample, that bad things happen. That's effectively a timing violation. Paul |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Hardware monitor program? | John | Asus Motherboards | 6 | June 2nd 10 03:14 AM |
when starting one software program, another pops up | isabellesup | Dell Computers | 3 | October 8th 08 10:41 PM |
Internal Error: 2738 appears when uninstalling a software program. | [email protected] | Dell Computers | 3 | November 21st 07 04:48 AM |
descramble cable tv with software program? | john smith | Ati Videocards | 0 | August 9th 03 04:45 AM |
need software advice for editing program files from dvdr! | KillMkLuv | Cdr | 0 | July 11th 03 06:37 AM |