How many physical channels SATA controller has? - windows

Imagine a system with one SATA controller. If controller operates in IDE mode it will show up in device manager like this:
Windows XP:
IDE controller's name
Primary IDE Channel
Secondary IDE Channel
Windows >= Vista:
IDE controller's name
ATA Channel 0
ATA Channel 1
And if controller operates in AHCI mode it will show up like "SATA AHCI controller" on both XP and >= Vista.
SATA controller in AHCI mode supports up to 32 devices (32 bit mask indicates device connection). I think it is just software limitation, given that each device requires separate channel, it is unlikely that such system exist where SATA controller is "wired" with all 32 channels. But I think 32 is a number that implies that controller can deal with more than two devices and thus has more than two channels. So, I want to ask how many channels SATA controller often has in practice. ATA controller has two channels, so does it mean that SATA controller has the same number of channels for software compatibility in IDE mode? Or maybe it has more than two channels, but in IDE mode only first two channels will be available? (at least on XP because "primary" channel and "secondary" channel greatly reduce the possibility of "third" channel which is not the case with "0" channel, "1" channel, "2" channel and so on)

A bit later but maybe would be useful for others.
Let's add some clarifications. There is SATA Host Controller with AHCI interface (Advanced Host Controller Interface). And there is SATA drive (or any other device with AHCI interface).
SATA Host Controller (HC) has a number of ports. Theoretically there could be up to 32 SATA ports but not less than 1 (well w/o any port HC itself doesn't make any sense). The number of actual ports depends on implementation. General HC chips used in PC more likely to have 1 or 2 ports. SATA drives are connected to ports. So if SATA HC has 2 ports than up to 2 SATA drives/devices could be attached.
In real life everything is even more interesting. As #Ross Ridge mentioned in comments, port multipliers could be used. Port Multiplier is to increase the number of devices that can be attached. Again port multiplier is device connected to SATA HC port (not to Host Controller itself). One multiplier to one port. Second multiplier could be connected to other port, etc. The support of multipliers is implementation defined. Some HC could work with them, some might not. Multipliers have 16 ports. Port '0xF' is special control port of multiplier. So up to 15 devices could be connected.
So all above is about SATA specification. Considering the listed questions itself:
OS drivers could enumerate and name drives by it's own way. Like you mentioned Secondary IDE Channel or ATA Channel 1. First name more likely is legacy from drives w/ parallel interfaces. In fact the word 'channel' even is not in SATA AHCI specification. There are ports :)
Some fu... drivers could imply "software limitations" like do not support multipliers or work only with one port. Regularly update drivers.
thus providing Windows with a way to change such options like enable/disable DMA mode. Windows DMA mode has nothing to do with SATA drive. SATA Host Controller use special buffers to allocate data received from drives. DMA mode in this case more like how OS get access to these buffers but not how HC communicate with attached drives.
Also can you tell me what is the maximum number of ATA Channels that SATA controller can have?. There are ports. The number of ports is implementation defined. If you know the address of SATA Host Controller on your motherboard read CAP register, 4 low bits are Number of Ports - 1. PS: you will need a driver to get direct access to physical memory so...

Related

USB stack confusion/serial emulator

I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?

How Operation System obtain Hardware ID

I am recently read documentation about Windows-Driver-Model, one of a chapter of it says :
Before a driver is installed for a new device, the bus or hub driver to which the device is connected assigns a hardware identifier (ID) to the device.
But how ??
For example the OS want to communicate with a USB device.
How can it ( the os ) obtain the hardware-id of the device ?
Is there some kind of protocol to communicate with the hardware that works like :
The OS send a signal ( or USB formatted message ) with a body of such as "I want to know hardware-id"
The hardware must response to this message to OS with a body of such as "My hardware-id is xxx"
If there is a protocol like this, could you please told me the "standard" of such a protocol.
On most modern computers every USB hub is connected to one xHCI controller (https://wiki.osdev.org/EXtensible_Host_Controller_Interface). At boot the BIOS will build ACPI tables in RAM that the OS will look for in conventional positions. Once the OS finds these tables, it will look at every entry to determine what devices are plugged to the computer including xHCI controllers. As stated on osdev.org
All xHCI controllers will have a Class ID of 0x0C, a Sublcass ID of 0x03, and an Interface value of 0x30. The configuration space for this device will contain two Base Address Registers: BAR0 and BAR1. These two 32-bit address fields combine to create a single 64-bit address that points to the base address of the memory mapped registers for the controller.
The memory mapped register of the xHCI s are then used to send commands to the USB device including commands to get the device descriptor of the USB device. The document on https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf is the spec for the xHCI. So if you want to really understand how it works under the hood then this is a great place to look at.

USRP X310 not recognized via 1GbE

I possess the USRP X310 with a Basic TX daughterboard installed. My plan is to use it via 10GbE together with LabView with a Win10 host machine.
I have connected the SDR with an Ethernet cable using Port 0 and the included SFP adapter to my host PC's (1GbE) ethernet interface for network testing purposes. The ethernet adapter is configured to use the static IP 192.168.10.1. Furthermore I have installed the UHD (uhd_3.15.0.0-release_Winx64_VS2017.exe). However when the device is connected and powered on, I can neither ping 198.168.10.2 nor detect it running the uhd_find_devices.exe. I have also started the NI-USRP Configuration Utility which I recently updated but it was not able to detect the SDR either. I do observe that none of the LEDs on the back is illuminated (especially not the Port 0 ethernet).
How can I get it working?
If you've worked with other usrps (I have a few), then you'll find the X310 to be somewhat different, to the lower models.
Anyway, there are different fpga loads / images, which corrospond to whether you are trying to connect via a 1G or 10G module.
"The PCIe interface is always available regardless of what FPGA image is loaded. Ettus ships two FPGA image variants, the HG or HGS image which has one 1 GigE interfaces and one 10 GigE interfaces, and the XG image which has two 10 GigE interfaces.
So you need to be sure you have the right image to connect to it via 1GE... or I expect it won't work, as it seems to be.
HTH's.

Do I understand the mechanism of COM Port assignment for USB-Serial bridge (VCP) correctly?

I have to base a critical Windows 7 software on virtual COM Port assignment. The software has to test devices in a production line. Each device is different and needs to be supplied with individual security keys.
There are 20 serial connections from an USB-Serial bridge (Silicon Lab CP2103). Each connection on a physical USB Port gets some virtual COM Port, which I can adapt by the device manager (e.g. to COM7).
If the serial number of the bridges are all the same, I was told, that Windows remembers the chosen COM Port for each USB Port. Can I rely on that to be "stable" under restarts and other USB activities, not related to my adapters?
What would be the difference, if each adapter has individual serial number: Is it true, that in this case Windows remembers the COM assignment, but is doesn't matter which physical USB port is used for connection?
Are there any recommendations to do it in one or an another way?

Can I access the Parallel Port normally when using USB to Parallel Port adapter?

Preliminary story
There is this program which uses the Parallel Port to synchronize with other hardware. It will set the Parallel Port output to a specified (byte) value. This works without problems when using the built-in Parallel Port of a PC. The target platforms are Windows XP to 7, all worked fine so far. Source code is in Delphi, accessible and can be modified.
How it works
In Delphi I can use the io.dll to set the value of the Parallel Port, but there are also other solutions available, like inpout32.dll or port.dll. I call something like PortOut, specify a port number and the byte value and the port is set.
What I now want to do - and where I need help
Now the change: this needs to work on a machine which has no Parallel Port built-in (not even on the mainboard). There are several options available:
use a USB to Parallel Port adapter to add a LPT port to the PC
use a PCI card which adds a LPT port to the PC
use a PCI Express card which adds a LPT port to the PC
I am currently heading for and concentrating on the easiest and cheapest possibility: a USB to Parallel Port adapter.
Main question
There seem to be differences between Parallel Port adapters which are made to connect just a printer and other adapters which seem to be more powerful. Is there really a difference? Or can I just use one of these 5$ printer-adapters, plug in my own hardware and access the port from Delphi code? Or do I need a special adapter? Has anyone experience with this? There is a related question here, but the different adapter types (if existent) are not mentioned there. This page suggests that there are indeed differences:
Contrary to all other USB parallel ports which can connect to printers only, this makes connection to most hardware.
I hope there exists a solution via USB because for this you don't have to open the PC, which means the adapter can be added on demand.
Sub-question
Do you have experience with PCI (Express) solution? I have to use one if the USB approach is not successful.
Since I've been wrestling with this very thing recently here's what I've discovered; If you mean by using IO port addressing (indicated by your reference to inpout32.dll), no. Unless your USB-parallel port driver supports full port emulation or virtualization, which most do not, this is generally not possible. If you need to directly access the port to do normal "bit-twiddling", you should get a separate Parallel port PCI-card. Most of them present themselves as normal IO at the standard address(es). I am presuming you're not planning on using the parallel port to actually communicate with a printer, right?
What is interesting is that USB-Serial adapters are much easier to use since they appear as simple virtual devices where you can merely "open" them using a simple stream; TFileStream.Create("COM1", fmOpenRead) or Windows.CreateFile("COM2", ...);
Here is some devices that purport to do full emulation of a parallel port through USB:
https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/index.en.htm

Resources