Cpu pins
-
A cpu has a lot of pins. What are they meant for? Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource on the motherboard (video adapter, sound board, etc)
-
A cpu has a lot of pins. What are they meant for? Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource on the motherboard (video adapter, sound board, etc)
-
A cpu has a lot of pins. What are they meant for? Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource on the motherboard (video adapter, sound board, etc)
A lot of those pins are power and ground. In simple terms, pins go to memory and buses, but not to individual boards, like video and sound. Those peripherals are connected to an expansion bus, like PCI-E, and the chip talks to devices through the bus.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
A lot of those pins are power and ground. In simple terms, pins go to memory and buses, but not to individual boards, like video and sound. Those peripherals are connected to an expansion bus, like PCI-E, and the chip talks to devices through the bus.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
>but not to individual boards I know it’s not dive in the cpu socket pop up in the sound or video card slot type of circuit, there is some mediation in between the two. Thanks for your answer.
-
Thanks for the tip
-
A lot of those pins are power and ground. In simple terms, pins go to memory and buses, but not to individual boards, like video and sound. Those peripherals are connected to an expansion bus, like PCI-E, and the chip talks to devices through the bus.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
The driver problem. When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors. Companies provide drivers for their equipment. Is a driver the place from where an Apps program machine code gets at run time the resource addresses required to get the sound board, MB etc working, is it some kind of compile at runtime?
-
The driver problem. When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors. Companies provide drivers for their equipment. Is a driver the place from where an Apps program machine code gets at run time the resource addresses required to get the sound board, MB etc working, is it some kind of compile at runtime?
It's up to the O/S to manage that stuff and provide an API for the applications to do something with it. Drivers are part of the O/S, not the applications. Windows Kernel-Mode HAL Library - Windows drivers | Microsoft Learn[^]
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
A cpu has a lot of pins. What are they meant for? Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource on the motherboard (video adapter, sound board, etc)
Calin Negru wrote:
Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource
It varies a lot from chip to chip, or - for PC type chips - from socket to socket. Chips meant for embedded use, IoT-style, may have general I/O-pins that can be configured by software to behave according to this or that signal standard, among maybe 2-4 different ones (but not too different from each other). This rarely if ever means that the CPU switches among different I/O-standards dynamically; at boot time, it configures the chip to the protocol it uses for communicating with other chips, and then is stays that way. The reason for having this configurability is that the CPU manufacturer can offer a single chip model to users of several different I/O-standards. Making two, three, four different chips, one per I/O standard is far more expensive. But note: I am not talking about x86 or x64 chips now - more like 8051 or ARM M0-chips.
When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors.
As Dave Kreskowiak pointed out: I/O on 'PC class' (general, x86/x64 or similar), is generally done using some standardized hardware at the physical level, e.g. USB, PCIe, ... (or earlier: FireWire, COM-port, VGA, ...). The external device is responsible for adapting to one such standard at the physical signal level. The PC uses low-level, usually OS provided driver software for transferring bytes, or frames of multiple bytes, from the CPU out on the interface. This is independent of whatever device is in the other end. The device must be able to receive bytes or frames, but this is given by the standard (e.g. by USB) and is not device dependent. Of course this goes both ways, for both input and output. The driver for the physical interface offers an API that is independent on the actual electronics, and usually standardized (although there may be a couple alternatives) for that class of physical interface. Say, the low-level USB driver offers a standard API for sending a USB frame to a given USB address. The byte stream, or contents of the frames, contains commands and data that may differ from device to device. This is where you may need a device specific driver. Say, your scanner software
-
Calin Negru wrote:
Do they have a general purpose usage or does the processor have specialized groups of pins where each group talks to certain type of resource
It varies a lot from chip to chip, or - for PC type chips - from socket to socket. Chips meant for embedded use, IoT-style, may have general I/O-pins that can be configured by software to behave according to this or that signal standard, among maybe 2-4 different ones (but not too different from each other). This rarely if ever means that the CPU switches among different I/O-standards dynamically; at boot time, it configures the chip to the protocol it uses for communicating with other chips, and then is stays that way. The reason for having this configurability is that the CPU manufacturer can offer a single chip model to users of several different I/O-standards. Making two, three, four different chips, one per I/O standard is far more expensive. But note: I am not talking about x86 or x64 chips now - more like 8051 or ARM M0-chips.
When an program is run it’s machincode doesn have the data required to run the sound card or the Mother Board or another piece of hardware because all computers contain hardware that is different, it comes from different vendors.
As Dave Kreskowiak pointed out: I/O on 'PC class' (general, x86/x64 or similar), is generally done using some standardized hardware at the physical level, e.g. USB, PCIe, ... (or earlier: FireWire, COM-port, VGA, ...). The external device is responsible for adapting to one such standard at the physical signal level. The PC uses low-level, usually OS provided driver software for transferring bytes, or frames of multiple bytes, from the CPU out on the interface. This is independent of whatever device is in the other end. The device must be able to receive bytes or frames, but this is given by the standard (e.g. by USB) and is not device dependent. Of course this goes both ways, for both input and output. The driver for the physical interface offers an API that is independent on the actual electronics, and usually standardized (although there may be a couple alternatives) for that class of physical interface. Say, the low-level USB driver offers a standard API for sending a USB frame to a given USB address. The byte stream, or contents of the frames, contains commands and data that may differ from device to device. This is where you may need a device specific driver. Say, your scanner software
Thanks for taking the time to write down all that. In the case of my second question it all boils down to Windows being a very versatile piece of software.
-
It's up to the O/S to manage that stuff and provide an API for the applications to do something with it. Drivers are part of the O/S, not the applications. Windows Kernel-Mode HAL Library - Windows drivers | Microsoft Learn[^]
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
Thanks