You actually can just work in the schematic as well, then generate the board.
True, but with gsch2pcb you don't need to delete the board. You can just run the command, and it will add and remove the requisite parts and regenerate the netlist without destroying the board. My point is, a design engineer can make changes to the schematic while the board is being worked on. EAGLE will only let you do that if the two engineers somehow work at the same machine.
Also, eagle severely limits what can be back annotated from the PCB to the schematic - in fact, there seems to be very little that it WILL let you do in that direction.
Yes. However, you can just click over to the schematic window and wreak havoc. This can easily happen unintentionally. This possibility does not exist in PCB, since the PCB engineer won't be using the schematic editor.
It's not like they are getting life in prison or something. 9 years is pretty reasonable for breaking in and trying to steal credit card information. What if someone broke into your house and stole all your stuff? Would you want him to return the items and do some community service or actually serve a sentence?
Actually, I think this is a win for both open-source and Linux. Think about it: if lots of people start using Openoffice on Windows, it will become much better much quicker (Windows programmers outnumber UNIX programmers probably 100 to 1 -- just look at Mono, for instance). People will become less dependent on Microsoft's products (Visual Studio, Office, etc), thus removing a major barrier for Linux. In return, Linux gets high-quality free software and lots of users familiar with it.
If you don't believe me, try to find any successful open-source project without a Windows port of some kind. Look at Mozilla/Firefox, one of the most successful free software projects -- 90% of its users are using Windows. Look at Openoffice -- same deal.
Free software succeeds by being available to everyone. Artificially restricting the number of users is just stupid. It has been tried many times before, and a killer application has never been enough to support a platform. The iPod is a perfect example: Apple first thought not making it available for Windows would help sell Macs. The situation is actually quite the opposite.
I have to really disagree with you here. Most expensive EDA tools (schematic/PCB type stuff) have been pretty much unchanged for the last 5 years or so.
Look at all the pricey crap put out by Cadence, for instance. Their basic schematic/pcb tools have same interface and roughly the same guts as the Windows 3.11 versions did in 1992. And the programs have so many glaring bugs and omissions, you wonder how they ever made it past the QA people. Of course, gEDA lacks so many features and has so many bugs that it's not even a contender, but I really wouldn't say the bar has been set very high.
Of course, you can't expect someone to put together a free tool for ASIC design or something equally arcane, but basic tools for schematic drawing and PCB layout are not that difficult (and much more useful). Given that commercial EDA software is not tightly integrated and uses relatively open formats, it shouldn't be that hard to make a viable alternative to Capture or Allegro.
That's actually a pretty stupid feature of EAGLE. gEDA does it much better with gsch2pcb. Think about it: what if there are 50 engineers working on that particular board? You don't want a PCB engineer screwing around with the schematic and messing things up. You also want to be able to edit the schematic separately and annotate the changes to the board.
Basically, the way pcb does it is the way any real EDA program does it (EAGLE doesn't count, it's a cheap product aimed mostly at hobbyists and very small businesses). Also, I wouldn't bitch about PCB's interface until you've used a real EDA program, such as Allegro. That program has such a horrible interface you wonder how the hell it became #1.
My system didn't stop the spam, but you can't call my replying to an email address as a spam.
Yes, it _is_ spam. YOU sent out large quantities of junk email because you were too lazy to sort through it. This isn't solving the spam problem, this is contributing to it.
Just stop calling other people "spammer" when you choose to leave your box unprotected.
Just because I left my door unlocked does not mean you can enter and take stuff. The same applies to email: you are a spammer irrespective of whether or not I protect my mailbox.
At lower temperatures electrical wires have less resistance and it could do some damage (theoretically of course) to some electronic components.
Bullshit. Wire resistance in an electronic component should be negligible. The resistance change caused by temperature is just about impossible to detect without very sensitive instruments.
In general, electronics do not care about temperature much. Most chips, for instance, are rated from -40 to +70 degrees C. It's the mechanical stuff (hard drives and, to a lesser extent, fans) that you have to worry about. The only electrical problems that could occur would be related to condensation.
No, you dumbass, that's the old version of google groups. The new one is at groups-beta.google.com, and there is no search option there. RTFA yourself, dammit.
It only took 10 years for all those comments to become irrelevant.... because IBM and others invested millions of dollars into bringing these things to Linux. Had they not done so, Linux would not have been anything close to the enterprise-class system it is now.
I started with MPASM and that's the only thing I use still. I really think things like the OOPic are kinda pointless (not to mention overpriced). Half the fun is being able to use the processor directly for microsecond-definite timing and other neat features. Microcontrollers are for simple things. If you are doing something that is too complex to write in assembly, you shouldn't be using an 8-bit microcontroller.
I don't see any point in using a compiler, really. Compilers generate very inefficient code, often generating 15 instructions where 3 would suffice. In a processor with 2K of ROM and 40 bytes of RAM, that's not good. Compilers are nice for some things, but are most certainly optional.
For most microcontrollers, a dev board is not necessary. PICs are in-circuit programmable, and the only external part they require to run is a ceramic resonator. You can make a programmer for PICs for about $5 (see here). I would just make a board with the programmer, a PIC, and a jumper to switch it to programming mode. Route all the I/O pins to a header and put all sensors and electronics onto that board.
The 8 defects/sector discs are indeed made in Taiwan by CMC (or someone else -- the media code only tells you who made the master and doesn't identify a specific manufacturer reliably). The Mitsubishi discs are still not as good as Taiyo Yuden, they are about 1 defect/sector (but obviously an order of magnitude better than CMC). I heard various bad things about the Mitsubishi technology (AZO) and it does indeed seem inferior to phtalocyanine (what most other manufacturers use).
What's surprising is that price is not an indicator. The Taiyo Yuden music discs are sold under the Maxell brand for less than CMC discs (about half the Maxell spindles in the store were made in Japan, the others were made in Taiwan). Really, the only way to tell good discs from bad ones is to check the country of manufacture.
Make sure you are using Taiyo Yuden blanks for burning CDs. Usually, media quality causes the most problems. I compared TY to Verbatim with kprobe -- BIG difference. Verbatim has an average of 8 errors per sector, while Taiyo Yuden had 0.2. Look for CD-Rs made in Japan -- they are Taiyo Yuden (often, they are sold as "music" CD-Rs).
Well, yes, 50 2 Farad 1200V caps WILL probably kill you. That's a lot of energy. However, computer-sized power supplies typically have about 5 capacitors, at roughly 500 microFarads/200V (DC). This is definitely enough to give you a nasty zap, but it's not particularly dangerous to a human without major heart problems.
As far as capacitors holding their charge: they will hold it for a very long time without a load connected. However, any reasonably well-designed power supply will have "bleeder" resistors across the capacitors that are supposed to discharge them to a safe level within a minute or so. The attached computer also provides quite a nice load. I've taken apart many dozen switching power supplies and have never run into a capacitor that was still charged.
If you are really worried about charged capacitor, a (reasonably) safe and easy way to discharge them is to just short the terminals with a screwdriver a few times. This is usually safe for smaller capacitors.
Do you want someone to be killed by blindly believing this statement?
Even the biggest capacitor doesn't have enough energy stored in it to kill you. It could give you a nasty shock, but it's not particularly life-threatening (unless you have major health problems to begin with).
The important statement is that it takes a lot of time for the capacitors do discharge.
Unless the power supply was designed by monkeys with soldering irons, it should take no more than a minute for all the capacitors to fully discharge.
Also, you don't need any special equipment or tools for working on an unplugged power supply. An isolation transformer is only necessary if you are poking inside a live one using grounded test equipment (such as an oscilloscope).
Why the hell do various people keep propagating the same silly myths over and over? I guess you're one of those idiots that interpret warning labels literally. Either that, or you think you are l33t because you poked inside a power supply and didn't get killed. There are quite a few dangerous electrical things, but UNPLUGGED power supplies do not belong in that category.
If the store/merchant does this, all you need to do is report it to the credit card company (call the number on the back of your credit card). All CC companies have agreements with merchants that, among other things, prohibit merchants from declining credit cards for any reason. If they do this too much, they could lose their merchant account.
You don't seem to understand how PCI works. There are only 15 IRQs on a PC, and most are used for system stuff. The onboard stuff doesn't share IRQs any more than PCI cards do. IRQ sharing is perfectly normal and does not cause performance degradation -- it's what the system is supposed to do.
Even assembly is not necessarily deterministic, depending on the system
Then it's not a real-time system! Hard real-time systems should always be deterministic.
Any system has some degree of determinism. It's just that a hard real-time system needs to guarantee that the required tasks will be completed in the required amount of time. It's not possible to guarantee that the tasks will be completed if your processor does not have a strict upper bound on the amount of time any given instruction will take.
If you want to code a real-time app in C++, you will pretty much have to disassemble your program afterwards to make sure the compiler didn't do something stupid. That's rather difficult, so hardly anybody does it. Unlike an assembler or a C compiler, a C++ program does not easily translate directly to assembly, and the compiler generates thousands of instructions (various virtual function tables, default constructors, default destructors, and other shit). If you are telling me you can actually work through that with a disassembler, try it sometime. In any program that uses stuff like inheritance, it's damn near impossible to figure out what's going on, much less verify correctness.
Besides, C++ doesn't work at all for things like DSPs and Harvard architecture 8-bit microcontrollers (which is what's used in about 80-90% of the real-time systems out there). They usually have less than a kilobyte of RAM. Assembly and C work very well for these architectures.
Since when is 1/2 second real time? Real-time means millisecond to microsecond resolution, and even C is often too high-level for truly real-time systems. Usually that type of stuff is coded in assembler, where you can predict exactly how much time any given instruction will take. Of course, that does require a more skilled programmer.
Well, you got a point about drivers being pretty shitty, but the core kernel is not nearly as bad. Drivers pretty much have to meet one criterion, and that's not crashing the kernel TOO often. Especially something really obscure (what you are looking at is a driver for a Gravis gamepad that hasn't been made for about 5 years now). I wouldn't expect that driver to work, much less have the same coding standards as the rest of the kernel.
I do realize you can work around many of the flaws in C++, but doing so is more complex than just sticking to C. I just don't think that kernel complexity is something that can be tackled with OOP. C++ is great for writing applications, but it was never intended for kernels. After all, there is a good reason why there are virtually no production-grade operating systems that actively use C++ for the kernel.
Contrary to what you think, I _have_ read Linux kernel code. It's perfectly readable for a project of that magnitude. I don't know why you think it's obfuscated, I am sure the thousands of contributors would disagree with you on that one. Of course, it's not exactly a project for a beginning programmer -- DUH.
First, C is sufficiently low-level that it's possible to know exactly what machine instructions a compiler will generate. Second, if a kernel developer actually benefits from type checking, they should not be developing kernel code.
Yeah, who wants a common driver API for video, network, or sound cards...
Why that requires C++ is beyond me.
You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
It's kinda hard to know what you're doing when the compiler generates megabytes of extra code. Ever try disassembling a program written in C++? Want to tell me you know exactly what the compiler will generate?
Nothing will come out of it, for the simple reason that C++ does not belong in any kernel. In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.
The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.
A monopoly can never collapse by itself. Think about it. If they are the only ones providing a necessary product, they will do very well. Customers can get as pissed as they want, but it's not like they can just stop using cellphones. It doesn't have to be an essential product, it just needs to be a somewhat useful one.
Slashdot Mirror
You actually can just work in the schematic as well, then generate the board.
True, but with gsch2pcb you don't need to delete the board. You can just run the command, and it will add and remove the requisite parts and regenerate the netlist without destroying the board. My point is, a design engineer can make changes to the schematic while the board is being worked on. EAGLE will only let you do that if the two engineers somehow work at the same machine.
Also, eagle severely limits what can be back annotated from the PCB to the schematic - in fact, there seems to be very little that it WILL let you do in that direction.
Yes. However, you can just click over to the schematic window and wreak havoc. This can easily happen unintentionally. This possibility does not exist in PCB, since the PCB engineer won't be using the schematic editor.
It's not like they are getting life in prison or something. 9 years is pretty reasonable for breaking in and trying to steal credit card information. What if someone broke into your house and stole all your stuff? Would you want him to return the items and do some community service or actually serve a sentence?
Actually, I think this is a win for both open-source and Linux. Think about it: if lots of people start using Openoffice on Windows, it will become much better much quicker (Windows programmers outnumber UNIX programmers probably 100 to 1 -- just look at Mono, for instance). People will become less dependent on Microsoft's products (Visual Studio, Office, etc), thus removing a major barrier for Linux. In return, Linux gets high-quality free software and lots of users familiar with it.
If you don't believe me, try to find any successful open-source project without a Windows port of some kind. Look at Mozilla/Firefox, one of the most successful free software projects -- 90% of its users are using Windows. Look at Openoffice -- same deal.
Free software succeeds by being available to everyone. Artificially restricting the number of users is just stupid. It has been tried many times before, and a killer application has never been enough to support a platform. The iPod is a perfect example: Apple first thought not making it available for Windows would help sell Macs. The situation is actually quite the opposite.
I have to really disagree with you here. Most expensive EDA tools (schematic/PCB type stuff) have been pretty much unchanged for the last 5 years or so.
Look at all the pricey crap put out by Cadence, for instance. Their basic schematic/pcb tools have same interface and roughly the same guts as the Windows 3.11 versions did in 1992. And the programs have so many glaring bugs and omissions, you wonder how they ever made it past the QA people. Of course, gEDA lacks so many features and has so many bugs that it's not even a contender, but I really wouldn't say the bar has been set very high.
Of course, you can't expect someone to put together a free tool for ASIC design or something equally arcane, but basic tools for schematic drawing and PCB layout are not that difficult (and much more useful). Given that commercial EDA software is not tightly integrated and uses relatively open formats, it shouldn't be that hard to make a viable alternative to Capture or Allegro.
That's actually a pretty stupid feature of EAGLE. gEDA does it much better with gsch2pcb. Think about it: what if there are 50 engineers working on that particular board? You don't want a PCB engineer screwing around with the schematic and messing things up. You also want to be able to edit the schematic separately and annotate the changes to the board.
Basically, the way pcb does it is the way any real EDA program does it (EAGLE doesn't count, it's a cheap product aimed mostly at hobbyists and very small businesses). Also, I wouldn't bitch about PCB's interface until you've used a real EDA program, such as Allegro. That program has such a horrible interface you wonder how the hell it became #1.
My system didn't stop the spam, but you can't call my replying to an email address as a spam.
Yes, it _is_ spam. YOU sent out large quantities of junk email because you were too lazy to sort through it. This isn't solving the spam problem, this is contributing to it.
Just stop calling other people "spammer" when you choose to leave your box unprotected.
Just because I left my door unlocked does not mean you can enter and take stuff. The same applies to email: you are a spammer irrespective of whether or not I protect my mailbox.
At lower temperatures electrical wires have less resistance and it could do some damage (theoretically of course) to some electronic components.
Bullshit. Wire resistance in an electronic component should be negligible. The resistance change caused by temperature is just about impossible to detect without very sensitive instruments.
In general, electronics do not care about temperature much. Most chips, for instance, are rated from -40 to +70 degrees C. It's the mechanical stuff (hard drives and, to a lesser extent, fans) that you have to worry about. The only electrical problems that could occur would be related to condensation.
No, you dumbass, that's the old version of google groups. The new one is at groups-beta.google.com, and there is no search option there. RTFA yourself, dammit.
It only took 10 years for all those comments to become irrelevant. ... because IBM and others invested millions of dollars into bringing these things to Linux. Had they not done so, Linux would not have been anything close to the enterprise-class system it is now.
I started with MPASM and that's the only thing I use still. I really think things like the OOPic are kinda pointless (not to mention overpriced). Half the fun is being able to use the processor directly for microsecond-definite timing and other neat features. Microcontrollers are for simple things. If you are doing something that is too complex to write in assembly, you shouldn't be using an 8-bit microcontroller.
I don't see any point in using a compiler, really. Compilers generate very inefficient code, often generating 15 instructions where 3 would suffice. In a processor with 2K of ROM and 40 bytes of RAM, that's not good. Compilers are nice for some things, but are most certainly optional.
For most microcontrollers, a dev board is not necessary. PICs are in-circuit programmable, and the only external part they require to run is a ceramic resonator. You can make a programmer for PICs for about $5 (see here). I would just make a board with the programmer, a PIC, and a jumper to switch it to programming mode. Route all the I/O pins to a header and put all sensors and electronics onto that board.
The 8 defects/sector discs are indeed made in Taiwan by CMC (or someone else -- the media code only tells you who made the master and doesn't identify a specific manufacturer reliably). The Mitsubishi discs are still not as good as Taiyo Yuden, they are about 1 defect/sector (but obviously an order of magnitude better than CMC). I heard various bad things about the Mitsubishi technology (AZO) and it does indeed seem inferior to phtalocyanine (what most other manufacturers use).
What's surprising is that price is not an indicator. The Taiyo Yuden music discs are sold under the Maxell brand for less than CMC discs (about half the Maxell spindles in the store were made in Japan, the others were made in Taiwan). Really, the only way to tell good discs from bad ones is to check the country of manufacture.
Make sure you are using Taiyo Yuden blanks for burning CDs. Usually, media quality causes the most problems. I compared TY to Verbatim with kprobe -- BIG difference. Verbatim has an average of 8 errors per sector, while Taiyo Yuden had 0.2. Look for CD-Rs made in Japan -- they are Taiyo Yuden (often, they are sold as "music" CD-Rs).
Well, yes, 50 2 Farad 1200V caps WILL probably kill you. That's a lot of energy. However, computer-sized power supplies typically have about 5 capacitors, at roughly 500 microFarads/200V (DC). This is definitely enough to give you a nasty zap, but it's not particularly dangerous to a human without major heart problems.
As far as capacitors holding their charge: they will hold it for a very long time without a load connected. However, any reasonably well-designed power supply will have "bleeder" resistors across the capacitors that are supposed to discharge them to a safe level within a minute or so. The attached computer also provides quite a nice load. I've taken apart many dozen switching power supplies and have never run into a capacitor that was still charged.
If you are really worried about charged capacitor, a (reasonably) safe and easy way to discharge them is to just short the terminals with a screwdriver a few times. This is usually safe for smaller capacitors.
Do you want someone to be killed by blindly believing this statement?
Even the biggest capacitor doesn't have enough energy stored in it to kill you. It could give you a nasty shock, but it's not particularly life-threatening (unless you have major health problems to begin with).
The important statement is that it takes a lot of time for the capacitors do discharge.
Unless the power supply was designed by monkeys with soldering irons, it should take no more than a minute for all the capacitors to fully discharge.
Also, you don't need any special equipment or tools for working on an unplugged power supply. An isolation transformer is only necessary if you are poking inside a live one using grounded test equipment (such as an oscilloscope).
Why the hell do various people keep propagating the same silly myths over and over? I guess you're one of those idiots that interpret warning labels literally. Either that, or you think you are l33t because you poked inside a power supply and didn't get killed. There are quite a few dangerous electrical things, but UNPLUGGED power supplies do not belong in that category.
If the store/merchant does this, all you need to do is report it to the credit card company (call the number on the back of your credit card). All CC companies have agreements with merchants that, among other things, prohibit merchants from declining credit cards for any reason. If they do this too much, they could lose their merchant account.
You don't seem to understand how PCI works. There are only 15 IRQs on a PC, and most are used for system stuff. The onboard stuff doesn't share IRQs any more than PCI cards do. IRQ sharing is perfectly normal and does not cause performance degradation -- it's what the system is supposed to do.
Even assembly is not necessarily deterministic, depending on the system
Then it's not a real-time system! Hard real-time systems should always be deterministic.
Any system has some degree of determinism. It's just that a hard real-time system needs to guarantee that the required tasks will be completed in the required amount of time. It's not possible to guarantee that the tasks will be completed if your processor does not have a strict upper bound on the amount of time any given instruction will take.
If you want to code a real-time app in C++, you will pretty much have to disassemble your program afterwards to make sure the compiler didn't do something stupid. That's rather difficult, so hardly anybody does it. Unlike an assembler or a C compiler, a C++ program does not easily translate directly to assembly, and the compiler generates thousands of instructions (various virtual function tables, default constructors, default destructors, and other shit). If you are telling me you can actually work through that with a disassembler, try it sometime. In any program that uses stuff like inheritance, it's damn near impossible to figure out what's going on, much less verify correctness.
Besides, C++ doesn't work at all for things like DSPs and Harvard architecture 8-bit microcontrollers (which is what's used in about 80-90% of the real-time systems out there). They usually have less than a kilobyte of RAM. Assembly and C work very well for these architectures.
Since when is 1/2 second real time? Real-time means millisecond to microsecond resolution, and even C is often too high-level for truly real-time systems. Usually that type of stuff is coded in assembler, where you can predict exactly how much time any given instruction will take. Of course, that does require a more skilled programmer.
Well, you got a point about drivers being pretty shitty, but the core kernel is not nearly as bad. Drivers pretty much have to meet one criterion, and that's not crashing the kernel TOO often. Especially something really obscure (what you are looking at is a driver for a Gravis gamepad that hasn't been made for about 5 years now). I wouldn't expect that driver to work, much less have the same coding standards as the rest of the kernel.
I do realize you can work around many of the flaws in C++, but doing so is more complex than just sticking to C. I just don't think that kernel complexity is something that can be tackled with OOP. C++ is great for writing applications, but it was never intended for kernels. After all, there is a good reason why there are virtually no production-grade operating systems that actively use C++ for the kernel.
Contrary to what you think, I _have_ read Linux kernel code. It's perfectly readable for a project of that magnitude. I don't know why you think it's obfuscated, I am sure the thousands of contributors would disagree with you on that one. Of course, it's not exactly a project for a beginning programmer -- DUH.
First, C is sufficiently low-level that it's possible to know exactly what machine instructions a compiler will generate. Second, if a kernel developer actually benefits from type checking, they should not be developing kernel code.
Yeah, who wants a common driver API for video, network, or sound cards...
Why that requires C++ is beyond me.
You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
It's kinda hard to know what you're doing when the compiler generates megabytes of extra code. Ever try disassembling a program written in C++? Want to tell me you know exactly what the compiler will generate?
Nothing will come out of it, for the simple reason that C++ does not belong in any kernel. In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.
The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.
A monopoly can never collapse by itself. Think about it. If they are the only ones providing a necessary product, they will do very well. Customers can get as pissed as they want, but it's not like they can just stop using cellphones. It doesn't have to be an essential product, it just needs to be a somewhat useful one.