Communicating with hardware directly

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
JAAman
Member
Member
Posts: 879
Joined: Wed Oct 27, 2004 11:00 pm
Location: WA

Re: Communicating with hardware directly

Post by JAAman »

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?
not exactly

when you access memory (or anything mapped as memory) the CPU puts the address you are accessing on the address bus, and indicates with another pin whether it wants to read or write

then whatever is watching the address bus, sees its own address, and responds by either placing data on the data bus, or receiving the data that is on the data bus

when you us "in" and "out" instructions, what the CPU does, is put the address (in this case 0x60) on the address bus, and then indicate with another pin that it is accessing the I/O bus rather than the memory bus, then whatever device is watching for I/O writes to that particular address responds as appropriate

the CPU doesn't know that 0x60 is the keyboard, it only knows that it is an address, its the keyboard controller that "knows" it should respond to address 0x60

in the diagram you posted, those pins labled AD# are both the address and data bus, the another pin (don't remember which one) indicates whether it is an address on the I/O bus, or memory bus, and another pin indicates whether it is a read or write



of course this is a very simple view of things, modern CPUs are extremely complex, relatively speaking
computertrick
Member
Member
Posts: 71
Joined: Wed May 29, 2013 1:07 pm

Re: Communicating with hardware directly

Post by computertrick »

JAAman wrote:
When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?
not exactly

when you access memory (or anything mapped as memory) the CPU puts the address you are accessing on the address bus, and indicates with another pin whether it wants to read or write

then whatever is watching the address bus, sees its own address, and responds by either placing data on the data bus, or receiving the data that is on the data bus

when you us "in" and "out" instructions, what the CPU does, is put the address (in this case 0x60) on the address bus, and then indicate with another pin that it is accessing the I/O bus rather than the memory bus, then whatever device is watching for I/O writes to that particular address responds as appropriate

the CPU doesn't know that 0x60 is the keyboard, it only knows that it is an address, its the keyboard controller that "knows" it should respond to address 0x60

in the diagram you posted, those pins labled AD# are both the address and data bus, the another pin (don't remember which one) indicates whether it is an address on the I/O bus, or memory bus, and another pin indicates whether it is a read or write



of course this is a very simple view of things, modern CPUs are extremely complex, relatively speaking
So basically all the hardware share the same channel and in this case all the hardware that don't have an ID of 0x60 wont respond?
1100110100010011
Casm
Member
Member
Posts: 221
Joined: Sun Oct 17, 2010 2:21 pm
Location: United Kingdom

Re: Communicating with hardware directly

Post by Casm »

computertrick wrote:Do you think I should be using 16 bit registers in case the keyboard sends 16 bit values?
The keyboard registers addressable by software are all eight bits wide, although, just to make things more complicated, some keys send a stream of eight bit bytes, instead of just one. Usually that happens with keys which were not present on the original IBM keyboard.
Also could you explain 0x60 to me. How does the CPU know 0x60 is the keyboard? is 0x60 a pin number or something?
It doesn't need to know, any more than a port on a microcontroller needs to "know" that it is connected to an LED. It is the hardware designer and programmer who need to know that.

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?
If it helps you to think in those terms you can do so. When I first began programming the PC in assembly language, in my minds eye I imagined something like that to be happening. Programming a computer means thinking in terms of pictures, because, after all, to try and think in terms of electrons trapped in depletion layers is not especially useful. But, as Jaaman says, what you imagine happening in your mind's eye, and what happens in reality, are not necessarily the same thing.
Gigasoft
Member
Member
Posts: 856
Joined: Sat Nov 21, 2009 5:11 pm

Re: Communicating with hardware directly

Post by Gigasoft »

All communication with other components (memory and I/O) comes through the same pins. Every device examines the incoming address signals to determine if it is being addressed. The addressed device then performs the requested operation, and in the case of a read cycle, the data lines are driven as appropriate. All other devices leave their output pins in high-Z. Don't try to read or write using the wrong data size. For example, the keyboard controller requires bytes.
When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?
Not quite. Reading an I/O port on an x86 system may have side effects, whereas reading a pin on a microcontroller does not. In the same manner, writing to an I/O port may have side effects, even if it is the same value that was just written. Port 60h on a PC has a side effect both when reading and when writing.
User avatar
DavidCooper
Member
Member
Posts: 1150
Joined: Wed Oct 27, 2010 4:53 pm
Location: Scotland

Re: Communicating with hardware directly

Post by DavidCooper »

computertrick wrote:In long term I'm hoping to read in visual input from a camera or something.
If this is where you're thinking of going with it, I wonder if you'd be better off biting the bullet and writing device drivers for USB. It's probably less work and more useful than trying to wire something up which no one else will ever duplicate.
Help the people of Laos by liking - https://www.facebook.com/TheSBInitiative/?ref=py_c

MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming
computertrick
Member
Member
Posts: 71
Joined: Wed May 29, 2013 1:07 pm

Re: Communicating with hardware directly

Post by computertrick »

DavidCooper wrote:
computertrick wrote:In long term I'm hoping to read in visual input from a camera or something.
If this is where you're thinking of going with it, I wonder if you'd be better off biting the bullet and writing device drivers for USB. It's probably less work and more useful than trying to wire something up which no one else will ever duplicate.
I think you could be right do you know what address the usb port uses?
1100110100010011
User avatar
DavidCooper
Member
Member
Posts: 1150
Joined: Wed Oct 27, 2010 4:53 pm
Location: Scotland

Re: Communicating with hardware directly

Post by DavidCooper »

computertrick wrote:I think you could be right do you know what address the usb port uses?
Don't expect it to be that easy - it's a massive task which I'm only just taking on now. You need to start with this PCI page in the wiki which will show you how to look for things like USB controllers which will have different locations in different machines (use one of the external links at the end to identify what the devices you find are). The next thing you should do is read the book Mike Gonta recommends in the Book Recommendations thread in this forum - a Kindle version is now available for a much lower price (though the paper version's well worth the money), and some of it can be read at Amazon without buying it.
Help the people of Laos by liking - https://www.facebook.com/TheSBInitiative/?ref=py_c

MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming
computertrick
Member
Member
Posts: 71
Joined: Wed May 29, 2013 1:07 pm

Re: Communicating with hardware directly

Post by computertrick »

DavidCooper wrote:
computertrick wrote:I think you could be right do you know what address the usb port uses?
Don't expect it to be that easy - it's a massive task which I'm only just taking on now. You need to start with this PCI page in the wiki which will show you how to look for things like USB controllers which will have different locations in different machines (use one of the external links at the end to identify what the devices you find are). The next thing you should do is read the book Mike Gonta recommends in the Book Recommendations thread in this forum - a Kindle version is now available for a much lower price (though the paper version's well worth the money), and some of it can be read at Amazon without buying it.
I'm aware that their are protocols involved. Thanks for the link I'm going to check it out! :)
1100110100010011
Mikemk
Member
Member
Posts: 409
Joined: Sat Oct 22, 2011 12:27 pm

Re: Communicating with hardware directly

Post by Mikemk »

No.
On intel processors, devices are mapped by the bios to changable port numbers or memory addresses. 0x60/0x64 for ps/2 is fairly standard, most arent
Programming is 80% Math, 20% Grammar, and 10% Creativity <--- Do not make fun of my joke!
If you're new, check this out.
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Re: Communicating with hardware directly

Post by SpyderTL »

computertrick wrote:I think you could be right do you know what address the usb port uses?
Heh. That makes me smile. :)

The CPU is wired (more or less) directly to the Keyboard controller, which is why you can communicate with it using IN and OUT commands. This technology and those port numbers were defined about 40 years ago.

USB controllers on the other hand, have only been around for around, well, 20 years. But still, the technology between a PS/2 keyboard and a USB keyboard is completely different.

To communicate with USB devices, you need to communicate with the USB Host Controller, which is a PCI device. So before you can communicate with the USB Host Controller, you will need to communicate with the PCI Bus and "find" the USB Host Controller. Check out the wiki page for "PCI" to get started. Then take a look at the "USB" wiki page.

I am currently working on some USB code myself, so feel free to PM me any questions about the PCI bus or the USB controllers after you have read the wiki pages.

Good luck! :)
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Communicating with hardware directly

Post by bluemoon »

SpyderTL wrote:
computertrick wrote:I think you could be right do you know what address the usb port uses?
Heh. That makes me smile. :)

The CPU is wired (more or less) directly to the Keyboard controller, which is why you can communicate with it using IN and OUT commands. This technology and those port numbers were defined about 40 years ago.
I'm not sure what you meant by (more or less) directly wired, it is so ambiguous.
However, some modern machine don't have KBC at all. Some BIOS may provide emulation, otherwise accessing such port may result in freezing the machine (as for mac).
In case a legacy KBC is physically exists, it's commonly hosted on the south-bridge, which is far from directly wired to CPU.
Post Reply