How to install Feitian R502 driver on Windows 10 IoT - raspberry-pi2

I have Raspberry Pi 2 B with Windows 10 IoT. I try to run Universal Windows Platform which use SmartCardReader. When I connect Feitian R502 Dual reader it's not found as CardReader. I found indicator description:
USB data transfer – red color
No explanation Status
1 USB enumerating 1Hz flashing
2 USB enumerated Turn on
3 Firmware checksum failure 4Hz flashing
Contact card – Blue color
No explanation Status
1 No card Turn off
2 Card inserted Turn on
3 Data transfer flashing
Contactless card-Green color
No explanation Status
1 No card Turn off
2 Card inserted Turn on
3 Data transfer flashing
I have red indicator flashing with freq 1Hz. Others indicators flash properly. Can anyone help mi with configuration/installation? I found how to install drivers: link and link but i have't sources of proper drivers.

I wrote some messages with Feitian Support. We came to conclusion that Microsoft didn't deliver usb ccid drivers for Windows 10 IoT core. Finally communication with SmartCardReader connected to Windows 10 IoT core device is possible using HID reader (W10 IoT has driver). It's possible but it's not support classes from Windows.Device.Smartcard namespace.

Related

Automatic screenshot when circuit is broken in 26 pin connector

There is a Digital I/O Board in the back of my computer:
Digital I/O plug-in
The 26w HD Dsub connector has been configured with a wire loop connecting pins 9 and 10, and 2 wires connected separately to pins 11 and 19:
26w HD Dsub connections schematic
Physical connector set up
Most of the time the wires from pins 11 and 19 will be in contact forming a closed circuit. When the wires are disconnected, the circuit will break. In this instance, I would like a screenshot of the screen to be taken, and the photo to be saved in a specified file directory.
If anyone can help with this it would be much appreciated!!
Many thanks,
Taylor
I have never coded before so i have not attempted anything yet.
I'm expecting a screenshot to be taken of the screen when the wires from pins 11 and 19 no longer form a closed circuit.

How many isochronous USB2.0 devices can a USB3.0 Hub enumerate?

I am working on a hardware-embedded software project involving USB protocol. My plan is to use a USB3.0 Hub that clusters many USB2.0 isochronous devices, each requiring around 33 Mbps BW.
Now, I know that USB3 is able to enumerate up to 127 devices [1], what I'd like to know is whether this is true if I connect USB2 devices to the USB3 Hub. Can I, in theory, use the hub with 97 USB2 devices?
Also, could I utilize the entire BW (yes, only around 70% is feasible) of a USB3 port this way? The above figures add up to 5 Gbps*70% = 3.2 Gbps = 97*33Mbps.
Any help is much appreciated.
I believe there is some confusion with your understanding.
USB 3.0 hub contains 2 logical hub partitions.
1 - USB 3.0 hub
2 - USB 2.0 hub
USB 2.0 devices communicate through the USB 2.0 hub data path which has nothing to do with USB 3.0 data path. So the assumption of the bandwidth is incorrect as they are for USB 3.0 devices connected via USB 3.0 data path.
Also USB 2.0 devices will get connected via USB 2.0 lines and NOT USB 3.0 lines.
Another misconception in your question.
The speed which you mentioned i.e. 5 Gbps, that is USB 3.0 link speed.
What that means is that 2 devices over USB 3.0 link can send or receive data at 5 Gbps. Since every hub downstream port is physically a separate link, the link speed will be same for all i.e. 5 Gbps. So its speed between 2 link partners and not end to end speed.
Now when you say End to End data transfer rate, that will depend on your host controller driver architecture, your OS performance, your Hub, etc.
For Isochronous endpoints, the hub will start data transfer on service intervals for each endpoints on each port as per USB spec but you cannot be sure that End to End data transfer rate will be equally divided.
PS - You will get a lot less end to end bandwidth by the way as the link speed for USB 2.0 is 480 Mbps. :)

stm32f3 'USER USB' not detected

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.

Turn USB power off/on with BeagleBone Black kernel >= 3.8

I need to:
turn off -> sleep some seconds -> turn on the USB power of beaglebone black
to be able to hardware-reset a device that is connected to USB (Huawei E220 Modem)
Already tried soft-reset (with unbind/bind and with authorize 0/1), but software reset is not enough to make the device to work well again; the device has some weird bug, that is triggered by a long-time usage (after a few days connected).
Many answers were found using /sys/debug/omap_mux, but this device does not exist anymore in new kernels.
Since this question took a pair of days to get a workable answer, I decided to post it here, with the answer, so it may be useful for others.
Thanks to my friend Cleiton Bueno http://cleitonbueno.wordpress.com/ that found this solution for me:
prerequisites:
apt-get install devmem2
Code that solved the problem:
devmem2 0x47401c60 b 0x00
sleep 1
echo "usb1" > /sys/bus/usb/drivers/usb/unbind
sleep 20
echo "usb1" > /sys/bus/usb/drivers/usb/bind
sleep 1
devmem2 0x47401c60 b 0x01
The "devmem2" command is responsible to direct access GPIO3_13 of the beaglebone, that controls the IC that powers on/off the USB port.
The "unbind/bind" commands are responsible to tell the usb driver to "rescan" the port after the power.

Routing Multiple USB 2.0 connections through a USB 3.0 connection

Is there any USB 3.0 hub or device that multiple USB 2.0 devices can be connected to and still retain the maximum USB 2.0 bandwidth for each device by utilizing the higher bandwidth of USB 3.0?
These devices exist for USB2.0/1.1 interfacing (they are called Multi-TT USB hubs).
Are there any such devices that exist for USB3.0/2.0? What I'm trying to do is connect 3 high-bandwidth USB 2.0 cameras to one USB 3.0 port.
I've been personally trying to find details about this as well. I'm trying to get multiple USB based audio cards to MUX over USB 3.0.
So far the following two URLs are giving me my details:
http://www.via-labs.com/en/products/vl810/index.jsp
http://electronicdesign.com/embedded/what-s-difference-between-usb-20-and-30-hubs
-- 1 --
This is interesting because it shows a block diagram of the VIA VL810 controller chip. Unfortunately, it sure looks like the USB2.0 functions are completely seperate from the USB 3.0 sections. This leads me to believe that, at least this chip, and HUBs that use it, can not multiplex USB2.0 transfers over USB3.0.
-- 2 --
This site spends a lot of time talking about how the HUBs are suppose to work. It takes the time to explain that the USB3.0 bus is separate from the USB2.0 bus:
Within the hub, only the port power control logic is shared between the USB 3.0 path and the USB 2.0 path, since there is only one 5-V power path in either USB 2.0 or USB 3.0.
This leads me to assume that most if not all current USB 3.0 HUBs can't multiplex.
You comment about Multi-TT Hubs being available for USB 2.0/1.1 gives me hope that some time in the (near?) future we'll have the same ability with USB3.0/2.0.