How to view board component and capacitor
-
Please update when you find this libary
Why should Sascha find this library for you?
This space for rent
-
Hello, How to view and maniplate board component and capacitor physical controllers (voltage, temerators, etc) given board circuits coordinate programitaclly? Thanks on repose to the erliest of this .
I've worked with a format called Gencad for this. The Gencad file specification is available somewhere on the Internet; once you get it, you need to read the CAD file based on this spec, and then render the different PCB elements on the screen using GDI kind of commands. Had developed a Gencad viewer, and this is property of one of my earlier employers.
-
Please update when you find this libary
As Sascha noted, it is essentially impossible in the general case.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
As Sascha noted, it is essentially impossible in the general case.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
How is it impossible? Ths same sofotawre can run on a motherboard whether it is Linx, Windows Vista, 7, 8 or 10, etc. If hardware is unchanging, softwre must know to
-
How is it impossible? Ths same sofotawre can run on a motherboard whether it is Linx, Windows Vista, 7, 8 or 10, etc. If hardware is unchanging, softwre must know to
regerteast wrote:
Ths same sofotawre can run on a motherboard whether it is Linx, Windows Vista, 7, 8 or 10, etc. If hardware is unchanging, softwre must know to interact.
The software does not care about the details of the motherboard. All non-standard hardware comes with software that knows how to talk to that hardware, aptly called "drivers".
regerteast wrote:
ON SOFTWARE
Software can only process signals from hardware. It's not magic.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
regerteast wrote:
Ths same sofotawre can run on a motherboard whether it is Linx, Windows Vista, 7, 8 or 10, etc. If hardware is unchanging, softwre must know to interact.
The software does not care about the details of the motherboard. All non-standard hardware comes with software that knows how to talk to that hardware, aptly called "drivers".
regerteast wrote:
ON SOFTWARE
Software can only process signals from hardware. It's not magic.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
The software does not care about the details of the motherboard. All non-standard hardware comes with software that knows how to talk to that hardware, aptly called "drivers".
But even on completly standard hardware I can widnows view the temperature of CPU, etc. How is the code to see it?
-
Eddy Vluggen wrote:
The software does not care about the details of the motherboard. All non-standard hardware comes with software that knows how to talk to that hardware, aptly called "drivers".
But even on completly standard hardware I can widnows view the temperature of CPU, etc. How is the code to see it?
There is no such thing as "completely standard hardware" in the PC world: all PC's are assembled using a huge number of possible components. Your example is spectacularly wrong: there are Intel and AMD versions of the "basic" processor, each of which has a large number of different processors in it's range. And to read the processor temperature is different in each family! So the OS has a API which works out which processor it is, and reads the temperature appropriately - but it looks like a simple WMI request to your application (most of the time, sometimes the motherboard design makes it unavailable) because the OS "hides" the hardware from your application. That is part of what drivers are for: to interface between the hardware (or a virtualisation of the hardware - don't ask, just don't) and the OS so that the hardware maker can communicate in a way that the OS can understand, and interpret for the applications. It's a bit like your car: it has a fuel gauge, but you have no idea how that gauge actually works or how many litres of fuel it is showing - and you don't need to know as long as you can glance at the dashboard and see you have 1/3 tank left.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Eddy Vluggen wrote:
The software does not care about the details of the motherboard. All non-standard hardware comes with software that knows how to talk to that hardware, aptly called "drivers".
But even on completly standard hardware I can widnows view the temperature of CPU, etc. How is the code to see it?
regerteast wrote:
But even on completly standard hardware I can widnows view the temperature of CPU, etc.
Completely standard hardware does not have to include the sensor. If it is, it will be conforming to a standard. If Windows supports the sensor, then you can query it using the Sensor API introduced with Win7.
regerteast wrote:
How is the code to see it?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
regerteast wrote:
But even on completly standard hardware I can widnows view the temperature of CPU, etc.
Completely standard hardware does not have to include the sensor. If it is, it will be conforming to a standard. If Windows supports the sensor, then you can query it using the Sensor API introduced with Win7.
regerteast wrote:
How is the code to see it?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Thanks
-
There is no such thing as "completely standard hardware" in the PC world: all PC's are assembled using a huge number of possible components. Your example is spectacularly wrong: there are Intel and AMD versions of the "basic" processor, each of which has a large number of different processors in it's range. And to read the processor temperature is different in each family! So the OS has a API which works out which processor it is, and reads the temperature appropriately - but it looks like a simple WMI request to your application (most of the time, sometimes the motherboard design makes it unavailable) because the OS "hides" the hardware from your application. That is part of what drivers are for: to interface between the hardware (or a virtualisation of the hardware - don't ask, just don't) and the OS so that the hardware maker can communicate in a way that the OS can understand, and interpret for the applications. It's a bit like your car: it has a fuel gauge, but you have no idea how that gauge actually works or how many litres of fuel it is showing - and you don't need to know as long as you can glance at the dashboard and see you have 1/3 tank left.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
So the OS has a API which works out which processor it is, and reads the temperature appropriately - but it looks like a simple WMI request to your application (most of the time, sometimes the motherboard design makes it unavailable) because the OS "hides" the hardware from your application. That is part of what drivers are for: to interface between the hardware (or a virtualisation of the hardware - don't ask, just don't) and the OS
So software if sits on top of the OS enabled through drivers and underlying to access but all is encapsulated in the OS so to software it is the same so one code to examine physical component of the motherboard the same regardless of individual hardware so to read temperature of component onw libary is good
-
OriginalGriff wrote:
So the OS has a API which works out which processor it is, and reads the temperature appropriately - but it looks like a simple WMI request to your application (most of the time, sometimes the motherboard design makes it unavailable) because the OS "hides" the hardware from your application. That is part of what drivers are for: to interface between the hardware (or a virtualisation of the hardware - don't ask, just don't) and the OS
So software if sits on top of the OS enabled through drivers and underlying to access but all is encapsulated in the OS so to software it is the same so one code to examine physical component of the motherboard the same regardless of individual hardware so to read temperature of component onw libary is good
That's the whole idea - the application doesn't get to look at the hardware, any more than you have to physically look at the sensor in your fuel tank! The OS and the drivers each provide a layer of abstraction that prevent your app getting anywhere near it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Thanks
