I have gone through some driver implementation in Linux Kernel Source and can see that these are the platform driver.
drivers/net/ethernet/smsc/smsc911x.c
static struct platform_driver smc911x_driver = {
.probe = smc911x_drv_probe,
.remove = smc911x_drv_remove,
.suspend = smc911x_drv_suspend,
.resume = smc911x_drv_resume,
.driver = {
.name = CARDNAME,
.owner = THIS_MODULE,
},
};
Above is a driver for platform device(smsc based Ethernet controller) and platform devices are devices which are not probed automatically during system boot-up unlike legacy devices sitting on the pci bus.
I guess this understanding of mine is OK here?
Now when I say it is the platform devices, is it mean these devices(Ethernet Controller) are sitting on Platform bus and on ARM architecture default platform bus is AMBA.
So when we solder the Ethernet controller on ARM based board it should be sit on or interfaced with AMBA bus?
How Do we decide that driver we're going to write is Platform driver or Normal driver?
From my limited experience in developing ARM platform drivers, AMBA devices typically have identification registers at the end of their memory mapped IO register interface.
Generally speaking, if you look at the reference manual for your ethernet controller and register summary specifies peripheral/component identification registers (usually at offsets 0xFE0-0xFEC and 0xFF0-0xFFC), you should write an AMBA bus driver. These drivers can be identified automatically by the bus driver.
Otherwise, if the register interface doesn't specify any ID registers at offsets 0xFE0-0xFEC and 0xFF0-0xFFC, you'll probably just want to write a platform driver. These devices cannot be automatically identified and you need to specifically attach a driver to the device.
Related
I'm working on stm32f3 discovery board. For my current project I planned on coding a simple UART program on the board, I happened to read somewhere on the internet that to use the board for UART communication with PC the 'USER USB' has to be used.
My questions are the following
Firstly when i connect my board to PC using the 'USER USB'. The PC refuses to recognize the board.(F.Y.I- OS used is windows 7 64bit). This problem persists even after I update the driver! How to resolve this?
Is the "Connecting USER USB" part correct? because I can't see any RS232 chip on board
Should I use an add on board?
P.S I've installed all the necessary drivers from ST website and works flawlessly while using 'ST-Link interface' part of the board
I started working with the STM32F3 disco a few weeks ago. The user USB thing is a bit tricky.
To get it clear: The board has 2 USB ports.
One mostly for programming and debugging. It connected to a second ST chip which works as programming adapter.
The seconds (called USER USB) is connected to the STM32F303 chips you program
So what you can do is to configure your STM32 to implement a CDC over USB. With the windows driver installed (automatic or from ST, depends on OS version) you should get a virtual com port in your device manager. If you don't have the driver, you also get a device labeled as virtual com port but with a yellow exclamation mark.
So if I get you question right, this is what you're trying to do? Then yes, "Connecting USER USB" is correct. No, you don't need an extension board.
How to resolve that? It depends:
Do you already see the device in your device manager as communication device or serial interface or something? Then only the CDC driver from ST is missing.
Or do you get an "Unknown Device" in your device manager? That is what I experienced.
In STM32CubeMX you need to enable the USB device (Peripehrals->USB)
In STM32CubeMX you need to select the USB stack (MiddleWares->USB_DEVICE->Communication Device Class)
Generate the code. If you are using HSI as clock source CubeMX will generate a error message you can ignore for now. For a real product you should use an external clock.
Note that there is a bug in CubeMX version 4.20. The code generator generates code which may not work if you select HSE as clock input source. Even if you go back to HSI, the error remains.
Compile an run the code. You maybe need to reset the board removing BOTH USB plugs
Windows should detect the board now.
Extra problem: The board is ... well. Tricky. If you only plug in the USER USB to your PC, it should work but Windows may also inform you that you have an UNKNOWN DEVICE because enumeration has failed.
Remove the plug again. Now, first plug in the other, ST-LINK USB to power on the board. Wait 1-2 seconds. Now plug in the USER USB. There seems to be a startup problem. Only using the USER USB for power supply and CDC seems to run in a race condition between boot and USB and USB enumeration fails. First powering the board and then plugging in removes this race condition (at least at my board)
Now Windows should enumerate the device and offer you a virtual com port. Actually you should get two of them: One "ST... STLink Virtual COM Port" and one "ST... Virtual COM Port". The seconds one is the one you are looking for.
I hope that was the answer on the question you had.
Thanks for the post, had the same issue, here is what I added
Approach: Turn-off USB lines programmatically by changing input to output, forcing it to zero and reenable them after around 1 second
Also used power-off and on from ST USB Libs
// Force Re-Enumeration by the USB Host
//
int aux_retrigger_usb()
{
GPIO_InitTypeDef GPIO_InitStructure;
// ST USB Function
PowerOff();
// Program Pin 12 USB_DP from Input to Output
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOA, &GPIO_InitStructure);
// Set USB_DP to 0
GPIOA->BRR |= GPIO_Pin_12 ;
// Wait for for minimum 32* 50msec , 1,6 secs
while(tim3_cnt%32!=0) ; while(tim3_cnt%32!=31) ;
// ST USB Functions
PowerOn();
USB_Init();
Virtual_Com_Port_Reset() ;
// Program Pin 12 USB_DP from Output to input
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOA, &GPIO_InitStructure);
return 1 ;
}
So basically to avoid the power on race condition, the ports may be programmed
first to outputs and then released after 1 second.
I'm also struggling with the STM32F302. The USB is not recognized by the HUB Down stream port, and therefore does not appear in a device manager on PC(HUB's upstream port is connected to PC).
So, I made a deep search after I checked all the HW and SW.
It appears that 1.5Kohm resistor should be added on a DP, as F302 does not have the embedded one.
My design does not have neither, so hopefully, it will solve the issue tomorrow, so I have a hope for tonight)
You can read AN4879 by ST - the place I found these directions.
When reading about hardware/device independence this statement from wikipedia (http://en.wikipedia.org/wiki/Device_independence#Desktop_computing) states that:
The application software does not need to know anything about the hardware on which it was to be used. Instead it discovers the capabilities of the hardware through the standardized abstraction layer, and then use abstracted commands to control the hardware.
I wanted to know about the lower level interaction between the BIOS routine/device driver/HAL/OS and the device controller about discovering the hardware capabilities.
Kindly help me out to understand the communication between these entities that takes place which helps in hardware independence.
Hardware devices, normally, connect to the main controller through a standard bus of some kind.
For example - PCI, PEX, USB.
Each connected device on the bus will be allocated with a device #, bus #, function #, etc, by the bus controller.
Modern bus contollers either provide the main controller with the ability to perform a scan, or send an event when a device is hot plugged into the bus.
Per each discovered device, it is possible, using the bus controller standard commands (such as read/write registers of a device, by device ID, bus number, etc), to interrogate the device for details such as:
Manufacturer ID
Device ID
Class (controller / networking device / Human interface / imaging device / and so on)
Per bus type, all these details must be available in the same way for every connected HW device, thus enabling the OS to use an abstraction layer.
Once a device has been discovered and identified, the OS will call all the specific bus registered device drivers' probe function, which use the details mentioned above to decide if can handle it.
When a device driver probe succeeds, an instance of the driver is allocated and can be used directly by the application that needs to access the HW.
For example:
USB PC CAM connects to USB port. An event is sent to the main CPU by the USB bus controller. The CPU will use the standard USB bus controller functions to learn the manufacturer & device ID/s, device class, functions, etc, and will call all the USB registered device drivers probe functions.
If an appropriate device driver is installed (registered), it will successfully create an instance of the device and a video application (such as skype) can use it directly, through DLLs supplied by the driver SW.
Hope this helps.
I am doing my Project using win 32 programming.I am just learning about win32 programming and able to create an UI.I want to communicate with an USB Device with that UI.SO,How can i go for that?Is there any predefined functions will be there are we need to create the function for communicating with the OS and get the devices List and got the details about them.
My purpose is to ,
1.Creating an UI that tells about the Basic information about the device.
2.For that first of all i want to communicate with the OS for device attachment and find the drivers for that.That will lead to get the information about the device and communicate with the device using that UI.
So,can anyone help me about this?How can i achieve this or approach this?
Assuming your USB Device enumerates as a vendor specific device and not a class that has a preloaded driver WinUSB would be perfect for your case. If it is loading a class driver such as HID or some other class you will need to look up the API for that type of device on MSDN.
I'm developing an embedded USB device which needs to be available to two different hosts.
The first is a normal PC, where it will be used as a MSC (mass storage) device, and the second is a specific hardware which the USB device needs to comunicate with a CDC profile.
during the enumeration, the USB device send descriptor table where it declares its capabilities.
Is there a way in the enumeration process to know to which host the device was connected to ?
The simplest solution perhaps would be to implement a "USB Composite Device", where the single device presented both the MSC and CDC class interfaces simultaneously. The host PC would see both interfaces, but you could simply leave one unused. The "specific hardware" would probably simply ignore the MSC class if it had no support for it.
Is it possible for a USB device to support multiple drivers? I'd like to support my own proprietary driver but also CCID as a second choice. When the device is plugged in, the user can select which one to use. The driver to use is determined by what the USB descriptor says, right? If that is so, is it possible to indicate that both drivers are supported? Is the idea of supporting two drivers doable?
On Windows, having two supported drivers is possible. In fact, to get Microsoft Logo certification, it is mandatory that the USB device supports this functionality. (Requirement CONNECT-0123)
However, the UI behavior you describe isn't offered by Microsoft. Driver selection is automatic.
Your USB device can indicate it supports two interfaces. In that case, both drivers will be loaded.
I am sure that it is not possible for a device to use two drivers at the same time but what is possible is for the device to enumerate using one class type and driver and then during its operation, in response to some command over the USB or operation of the device, for it to disconnect and then re-enumerate as a different type of device using the second driver.
As an example the product that I am developing normally enumerates as a CDC (serial port emulation) but when I need to reload the code it re-enumerates as a different device type and uses the chip vendor supplied driver to perform the code download. Once this completes then the device re-enumerates itself again as a CDC device type and resumes its serial port emulation.
You therefore need to provide a "command" interface that will trigger the transition between the two operating modes and to ensure that the two drivers are installed on the host computer ready for the mode switch.