tag:blogger.com,1999:blog-5979917482629813809.post1641646163300974937..comments2024-03-14T12:00:36.905+01:00Comments on Searching For A Bit: WinUSB communication with STM32 round 2 (Part 1: Firmware)P.http://www.blogger.com/profile/13977783876539635073noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-5979917482629813809.post-23765535104456894642019-09-07T11:44:39.857+02:002019-09-07T11:44:39.857+02:00Source By: Unlock Bootloader on Vivo Z5Source By: <a href="https://techstribe.com/unlock-bootloader-on-vivo-z5/" rel="nofollow"> Unlock Bootloader on Vivo Z5</a>Muneer Ahmedhttps://www.blogger.com/profile/02272371583378871713noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-58744084232168738062018-01-23T11:25:23.485+01:002018-01-23T11:25:23.485+01:00It's up to the available EP FIFO RAM and the n...It's up to the available EP FIFO RAM and the number of EPs in your device how you will assign EP sizes. Of course comply to the FS/HS constraints. You will transfer bigger buffers with multiple EP transfers. I.e. so called pipes. Application buffers needs to be present on both sides, e.g. PC and STM. EP FIFOs are only FIFOs. Piping is handled for you in libs so you don't have to worry about chopping your data to EP size chunks. P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-57608375767889338912018-01-22T10:31:15.634+01:002018-01-22T10:31:15.634+01:00Hi,
I got over the problem with the GUID, thanks,...Hi,<br /><br />I got over the problem with the GUID, thanks,<br /><br />I'm now trying to achieve the fastest transfer rate possible, I see that you defined the EPs like that:<br /><br /> /******************** Some interface over WinUSB Endpoints ********************/<br /> 0x07, /*Endpoint descriptor length = 7*/<br /> 0x05, /*Endpoint descriptor type */<br /> WINUSBCOMM_EPIN_ADDR, /*Endpoint address (IN, address 1) */<br /> 0x02, /*Bulk endpoint type */<br /> LOBYTE(WINUSBCOMM_MAX_FS_PACKET),<br /> HIBYTE(WINUSBCOMM_MAX_FS_PACKET),<br /><br />first, if I use HS, it should be at least WINUSBCOMM_MAX_HS_PACKET (i.e. 512 and not 64), isn't it? and any how, what are the maximum possible sizes I can use?<br /><br />I need to transfer pictures frames of size around 600K,<br /><br />ThanksEGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-62756489106592592082018-01-14T09:09:44.780+01:002018-01-14T09:09:44.780+01:00Well, try calling SetupDiGetClassDevs with your pr...Well, try calling SetupDiGetClassDevs with your private GUID.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-83240611091054001262018-01-14T07:17:25.505+01:002018-01-14T07:17:25.505+01:00No, In the device I used a private GUID, this GUID...No, In the device I used a private GUID, this GUID {88bae032-5a81-49f0-bc3d-a4ff138216d6} is used by windows SetupDiGetClassDevs setupapi.dll to find all the WinUSB devices, it is the Interface class GUID for WinUSBEGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-90333885086191454522018-01-13T20:14:26.085+01:002018-01-13T20:14:26.085+01:00Is {88bae032-5a81-49f0-bc3d-a4ff138216d6} the GUID...Is {88bae032-5a81-49f0-bc3d-a4ff138216d6} the GUID you give in OS descriptor of your device?<br />I use my own made up GUID. Find "DeviceInterfaceGUID" in the post. I always use this and never had problems.<br />The GUID you mention seems to be related to WinUSB driver.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-20058541060049413812018-01-13T18:47:41.699+01:002018-01-13T18:47:41.699+01:00Based on your reply I was able to read and write f...Based on your reply I was able to read and write from both EP0 and EPn! Thanks<br />Now, After I had a based working project on both ends (FW and PC WIN10 C#) based on http://janaxelson.com WinUsb_cs I wanted to start to develop my proprietary data flow.<br />But, from unclear reason or action I suddenly have a problem when I call FindMyDevice(), its look like the FW side registered OK on the PC (I started to use USBlyzer...):<br /><br />Description: WinUsb Device<br />Instance Status: 0180600Ah DN_DRIVER_LOADED<br /> DN_STARTED<br /> DN_DISABLEABLE<br /> DN_REMOVABLE<br /> DN_NT_ENUMERATOR<br /> DN_NT_DRIVER<br />Instance ID: USB\VID_26F9&PID_7555\SSSSSSSSSSSSSSSSSSS1<br />Hardware IDs: USB\VID_26F9&PID_7555&REV_0200<br /> USB\VID_26F9&PID_7555<br />Compatible IDs: USB\MS_COMP_WINUSB<br /> USB\Class_FF&SubClass_00&Prot_00<br /> USB\Class_FF&SubClass_00<br /> USB\Class_FF<br />Service Name: WINUSB<br />Setup Class: USBDevice<br />Setup Class Description: Universal Serial Bus devices<br />Setup Class GUID: {88bae032-5a81-49f0-bc3d-a4ff138216d6}<br />Software Key: {88bae032-5a81-49f0-bc3d-a4ff138216d6}\0037<br />Manufacturer: WinUsb Device<br />Friendly Name: WinUSBComm Device in HS Mode<br />Hardware Location: Port_#0003.Hub_#0010<br />PDO Name: \Device\USBPDO-21<br /><br />But the call to SetupDiGetClassDevs with {88bae032-5a81-49f0-bc3d-a4ff138216d6} fail to get any devices?!<br /><br />What could be wrong?<br /><br />I'm pretty sure that there is no change in the code that used to work, I suspect that something on Windows registry is causing this but I have no idea where to start looking for it.<br /><br />I tried to uninstall the device from USBDview and delete the registry entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\26F975550200 but this did not helped.<br /><br />Thanks,<br />Eyal EGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-89957212375895733522018-01-07T12:20:56.615+01:002018-01-07T12:20:56.615+01:00I have following two handlers in my unpublished co...I have following two handlers in my unpublished code:<br />unsigned char WinUSBComm_SetupVendorInterface(USBD_HandleTypeDef *pdev, SWinUSBCommSTM32 *psWinUSBCommSTM32, unsigned char byRequest)<br />{<br /> switch ( byRequest )<br /> {<br /> case winusbcomm2commandReset:<br /> psWinUSBCommSTM32->m_dwExpectedByteCountUSB = 0;<br /> psWinUSBCommSTM32->m_dwSendByteCountUSB = 0;<br /> break;<br /> case winusbcomm2commandGetVersion: USBD_CtlSendData(pdev, &s_byWinUSBCommVersion, 1); break;<br /> case winusbcomm2commandGetState: USBD_CtlSendData(pdev, &psWinUSBCommSTM32->m_byStateUSB, 1); break;<br /> case winusbcomm2commandGetBufferSize: USBD_CtlSendData(pdev, (uint8_t*)(&psWinUSBCommSTM32->m_dwBufferSizeInBytes), 4); break;<br /> case winusbcomm2commandGetReturnSize: USBD_CtlSendData(pdev, (uint8_t*)(&psWinUSBCommSTM32->m_dwSendByteCountUSB), 4); break;<br /> case winusbcomm2commandFollowingPacketSize:<br /> psWinUSBCommSTM32->m_dwReceivedByteCount = 0;<br /> USBD_CtlPrepareRx(pdev, (uint8_t*)(&psWinUSBCommSTM32->m_dwExpectedByteCountUSB), 4); break;<br /> default:<br /> return USBD_FAIL;<br /> }<br /> return USBD_OK;<br />}<br /><br />And when incoming data size arrives:<br /><br />void WinUSBComm_EP0_RxReady(USBD_HandleTypeDef *pdev, SWinUSBCommSTM32 *psWinUSBCommSTM32, unsigned char byRequest)<br />{<br /> switch ( byRequest )<br /> {<br /> case winusbcomm2commandFollowingPacketSize:<br /> USBD_LL_PrepareReceive(pdev, psWinUSBCommSTM32->m_byEPOutAddress, psWinUSBCommSTM32->m_pbyBuffer, psWinUSBCommSTM32->m_dwExpectedByteCountUSB);<br /> break;<br /> default:<br /> break;<br /> }<br /> USBD_WinUSBComm_UpdateState(psWinUSBCommSTM32);<br />}<br />P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-65252266940614271572018-01-07T12:16:59.592+01:002018-01-07T12:16:59.592+01:00I don't think you need to worry about flow con...I don't think you need to worry about flow control on EP0. Just keep command packets in size less than EP0 buffer size (8B or is it 64B). Your device code handlers will be called in general like:<br />For commands with incoming data (relative to device):<br />- "Incoming data on EP0"; where to put it?<br />- "Incoming data on EP0 received" (this is where you parse it and act on it, e.g. send application data on bulk EP)<br />For commands with outgoing data (relative to device):<br />- "Give data to send" (e.g. this is where you provide the number of bytes to be sent over bulk EP to application on PC)<br /><br />Note that commands should be given not in data stage of USB control transfer (http://www.beyondlogic.org/usbnutshell/usb4.shtml#Control) but rather in the setup stage of USB transfer (http://www.beyondlogic.org/usbnutshell/usb6.shtml#SetupPacket).<br />I set:<br />- Recipient to 1(Interface) and type to 2(Vendor) in bmRequestType filed.<br />- bRequest to my chosen/madeup value (command)<br />- wIndex to the USB interface index addressed (0, unless you have multiple pairs of bulk in/out EPs associated with WinUSB driver in one device; see Windows enumeration up in the post)<br />- I think I don't use wValue<br />Payload sizes are transferred in data stage. I could use wValue for incoming packet size probably.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-21255406503728108212018-01-07T11:12:27.517+01:002018-01-07T11:12:27.517+01:00Thanks for the very detailed answer, it was a grea...Thanks for the very detailed answer, it was a great help and now I can send multiple packets with no problem.<br />I still have a problem though with sending my custom messages over EP0, I believe it is related to flaw control as it was with the EPn messages.<br />How should I handle flow control with EP0? Ack? etc.<br />I found those function relevant to this issue but I'm not sure in what sequence I should use them:<br />USBD_CtlSendData<br />USBD_CtlContinueSendData<br />USBD_CtlPrepareRx<br />USBD_CtlContinueRx<br />USBD_CtlSendStatus<br />USBD_CtlReceiveStatus<br />USBD_GetRxCount<br /><br />Thanks,<br />EyalEGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-17915310357053006392018-01-06T15:49:42.170+01:002018-01-06T15:49:42.170+01:00What? Uninstalling and manually deleting the regis...What? Uninstalling and manually deleting the registry keys didn't make Windows query for 0xEE string descriptor again? This worked for me a month or so ago.<br />Anyway... I'm happy for your progress.<br />You now only have a device associated with WinUSB driver which allows you pushing and pulling data from USB endpoints from user space. How you are going to do it it's up to you. What you want to achieve is that device is ready to receive data when you are sending it from PC side. Kind of flow control. Device will NAK (or STALL) any USB request to some EP until your application (in device) tells it receive (or send) data.<br />I do it with commands from PC via control EP0. In general like follows:<br />- PC sends "incoming N bytes of data" message via EP0 to device<br />- Device calls USB lib function to receive N bytes on EPa<br />- PC writes N bytes to EPa<br />- Device receives data on EPa and starts processing it<br />- PC sends "any data to return?" message to EP0<br />- Device returns 0 if no data available or M otherwise (on EP0) and calls USB lib function to send M bytes of data on EPb<br />- PC is repeating "any data to return" message until it gets nonzero value (M)<br />- PC reads M bytes from EPb<br /><br />Which are specific function I don't know by heart - I have to study this every time.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-38919880784894689932018-01-06T13:19:42.266+01:002018-01-06T13:19:42.266+01:00Hi,
After a lot of digging I realized that the uni...Hi,<br />After a lot of digging I realized that the uninstalling of the device was not enough, I changed the PI\VID and I saw that I get the EE so I'm good with that issue.<br />Now, I try to use some C# code I found to communicate with the device, I can see that the device receive and transmit on EP0.<br />If I send data to EP2 it is receive on the device side but only once, the second time from some reason is not working.<br />Since I did not port all the communication protocol part of your code I'm trying first only to send and receive a simple 64 bytes of data (loopback).<br />I see that if I add to the USBD_WinUSBComm_DataOut a call to USBD_LL_Transmit it is working, but again, only once.<br />I can see that when I try to send the second transmission it is not reach the device at all.<br />Any idea what can be the problem?<br />Thanks,<br />Eyal EGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-70156762230458731752018-01-05T20:20:11.728+01:002018-01-05T20:20:11.728+01:00Sorry for not answering directly before, you don&#...Sorry for not answering directly before, you don't have to install anything or enable anything in Win10 AFAIK.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-6996012886782850432018-01-05T20:00:43.875+01:002018-01-05T20:00:43.875+01:00Changing the VID\PID did not helped
The device is ...Changing the VID\PID did not helped<br />The device is identified as USB2.0 in USBDview<br />GetUsrStrDescriptor is not being called<br />I don't have the BluePill<br />I'm sorry but I have to ask again, do I need to do some installation on my PC Win 10 in order to have the WinUSB or should it be part of Win 10 as a default?<br />Thanks<br />EyalEGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-22742979085941087482018-01-05T16:58:27.334+01:002018-01-05T16:58:27.334+01:00Hmmm... I read somewhere that MS is keeping a list...Hmmm... I read somewhere that MS is keeping a list of devices that have problem with 0xEE string descriptor request. Maybe change VID and PID to test. Also it doesn't work with devices prior to USB2.0 - check USB line pull up resistor.<br />With reasonable low effort I can currently only built you a binary image to test with modified BluePill board (STM32F103) - do you have it? Maybe unmodified.<br />Does GetUsrStrDescriptor get called?P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-45715755861111779242018-01-05T15:57:32.239+01:002018-01-05T15:57:32.239+01:00The dump is from my printfs within the code.
I don...The dump is from my printfs within the code.<br />I don't have USBlyzer license, I'm using HHD SW device monitoring and I recorded a session after I uninstall the device and re-plugged it but I did not see any 0xEE string request.<br />I have USBD_SUPPORT_USER_STRING set to 1.<br />I'm using updated STM32Cube F4 1.17 and F7 1.8 <br />I added a printf in usbd_ctlreq.c @ function USBD_GetDescriptor where the host requests are being processed under the string case:<br /> case USB_DESC_TYPE_STRING:<br /> printf("USB_DESC_TYPE_STRING 0X%X\r\n",req->wValue);<br />You said that the 0xEE is deprecated by MS but it still works, is there a way for me to test it on my PC without connecting to my target STM32?<br />I think it might be something that I need to install under windows in order to have it.<br />Do you have an updated version of the project that I can test at my end?<br />Thanks,<br />Eyal<br />EGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-59778332229703572082018-01-05T10:58:32.156+01:002018-01-05T10:58:32.156+01:00I don't know where this dump is from. Did you ...I don't know where this dump is from. Did you try to record the USB request with some USB analyzer tool (e.g. USBlyzer) to see all requests? You need an analyzer that will record hot plugged devices.<br />Also, ST USB library handles string descriptors separately in USBD_DescriptorsTypeDef for standard descriptors. I return OS string descriptor in call to GetUsrStrDescriptor of USBD_ClassTypeDef type.<br />You need to #define USBD_SUPPORT_USER_STRING 1 for this to work.<br />This info is based on usage of STM32Cube_FW_F1_V1.6.0 (so, totally out of sync with the blog post).P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-59733956580702523832018-01-04T23:48:02.431+01:002018-01-04T23:48:02.431+01:00Thanks for your quick reply, I did uninstalled the...Thanks for your quick reply, I did uninstalled the device before I test it, I just tried that again and you can see from the list below what is being quired by the host, I don't see the 0xEE there.<br />Is there an option that the WinUSB is not installed on my system from some reason? I thought it is there as a defualt Win 10, isen't it?<br />WinUSB<br />USBD_WinUSBComm_DeviceDescriptor<br />USBD_WinUSBComm_DeviceDescriptor<br />USBD_WinUSBComm_GetCfgDesc<br />USB_DESC_TYPE_STRING 0X303<br />USBD_WinUSBComm_SerialStrDescriptor<br />USBD_WinUSBComm_Setup<br />USBD_WinUSBComm_Setup<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_DeviceDescriptor<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_Setup<br />USBD_WinUSBComm_Setup<br />USBD_WinUSBComm_DeviceDescriptor<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_Init<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X301<br />USBD_WinUSBComm_ManufacturerStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X303<br />USBD_WinUSBComm_SerialStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetDeviceQualifierDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X301<br />USBD_WinUSBComm_ManufacturerStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X304<br />USBD_WinUSBComm_ConfigStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X305<br />USBD_WinUSBComm_InterfaceStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X301<br />USBD_WinUSBComm_ManufacturerStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X301<br />USBD_WinUSBComm_ManufacturerStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetDeviceQualifierDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USBD_WinUSBComm_GetCfgDesc<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X300<br />USBD_WinUSBComm_LangIDStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X301<br />USBD_WinUSBComm_ManufacturerStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X302<br />USBD_WinUSBComm_ProductStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X304<br />USBD_WinUSBComm_ConfigStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br />USB_DESC_TYPE_STRING 0X305<br />USBD_WinUSBComm_InterfaceStrDescriptor<br />USBD_WinUSBComm_EP0_TxReady<br /><br />EGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-49252852720888073332018-01-04T13:00:43.672+01:002018-01-04T13:00:43.672+01:00Quote from post above:
Note that Windows queries t...Quote from post above:<br />Note that Windows queries this descriptor only once. It can be a hassle during development. Information that OS descriptors have been queried for some device is stored in registry under<br />HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\VVVVPPPPRRRR<br />(VVVV - vendor ID; PPPP - product ID; RRRR - revision).<br />Delete VVVVPPPPRRRR key and also uninstall the device with utility like USDDeview to always get fresh device plug in behavior.<br />End quote.<br />0xEE string descriptor query is deprecated by MS but it still works - I just did a device this way. BOS descriptors are the way to go. Anyway, try clearing device info.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-22261176463413687832018-01-04T10:31:37.971+01:002018-01-04T10:31:37.971+01:00Hi,
I was trying to port your work to my target (S...Hi,<br />I was trying to port your work to my target (STM32F7) and was able to get a build and running project but I was not able to communicate with the device from the PC (Windows 10).<br />I try to investigate this and found that the 0xEE string request is not perfomed (I printed all the string descriptor requests and it was not there)<br />I follow the link you gave to Microsoft OS 2.0 Descriptors Specification and saw that it is not using the 0xEE any more.<br />Is that mean that I cannot use the ported project on my machine or should I do somthing else that I'm missing?<br />Can you please advise on that?<br />Thanks,<br />EyalEGhttps://www.blogger.com/profile/11878043595933120434noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-14649614254652783312017-01-18T20:48:02.955+01:002017-01-18T20:48:02.955+01:00Probably. I have used FREE USB Protocol Analyzer f...Probably. I have used FREE USB Protocol Analyzer from HHD Software and tried USBTrace from sysnucleus. AFAIK these are all software hook loggers. They attach to USB hooks prepared by in Windows through some API I forgot. Log they produce is quite helpful.P.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-11550292457521533212017-01-18T12:42:52.195+01:002017-01-18T12:42:52.195+01:00Hello!
Thanks for an important information. Wold ...Hello! <br />Thanks for an important information. Wold it be worth trying software such as this USB Capture (http://www.eltima.com/products/usb-capture/) to log USB communication?<br />Anonymoushttps://www.blogger.com/profile/10891993550117830652noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-26241281232490799762016-09-03T10:36:29.981+02:002016-09-03T10:36:29.981+02:00Hi.I have received your email.Thank you for your k...Hi.I have received your email.Thank you for your kindness.Thanks a lot.oberlihttps://www.blogger.com/profile/01350161352582295826noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-58663737584480374412016-09-03T10:21:41.892+02:002016-09-03T10:21:41.892+02:00Hi. I didn't find time to migrate the code to ...Hi. I didn't find time to migrate the code to GitHub yet. But there is an archive download still available on Google Code site: https://code.google.com/archive/p/found-bits/source/default/sourceP.https://www.blogger.com/profile/13977783876539635073noreply@blogger.comtag:blogger.com,1999:blog-5979917482629813809.post-32025670089436319052016-09-02T09:43:02.457+02:002016-09-02T09:43:02.457+02:00Hello!Can i get a copy of your project source code...Hello!Can i get a copy of your project source code,which i couldn't find at the google code webside.Thanks a lot.And my email:oberli@126.comoberlihttps://www.blogger.com/profile/01350161352582295826noreply@blogger.com