One of the first demos that a new Synergy user is exposed to is the communications framework on sf_el_ux_comms , which implements a USB device CDC connection. I thought it would be useful to implement a host CDC driver and create a simple machine-to-machine demo. A demo where one might press a button on one board to light an LED on the other. As a starting point I selected an RL78/G14 RPB board. This board has an NEC 78K '730 chip that does the USB to serial communications. I wrote a simple program for the RL78 board to spit out a timer value every second. Connected it to the PC and verified using teraterm. I searched in vain for a host side demo for USBX and the only thing I could come up with was the mass storage demo. I used this demo as a starting point. The demo contains a function tx_application_define_user() that allows users to register class drivers. So I added the host_cdc_acm class. status = ux_host_stack_class_register(_ux_system_host_class_cdc_acm_name, _ux_host_class_cdc_acm_entry); if (status != UX_SUCCESS) { return ; } Then in the demo thread, following the mass storage as an example, I make a call to: status = ux_host_stack_class_get(_ux_system_host_class_cdc_acm_name, &class); This function returns UX_SUCCESS once a cdc class device is attached, otherwise some other value. Setting a breakpoint here, and attaching the RL78 board, the function never returns UX_SUCCESS. Diving into the USBX source the ux_host_class_cdc_acm_entry function is looking for a device descriptor .dDeviceCLass to be 0x02, meaning a CDC device class. The descriptor from the RL78 board was a 0x00. I tried a couple other USB - serial devices and they all had the same 0x00 descriptor. According to the USB specs, this means you examine the PID and VID and load the appropriate driver. I tried to “fake” the descriptor by writing my own cdc_acm_entry function (which is passed in the registration process) following the default one as a guide. In my code I didn't check the descriptor, rather returned UX_SUCCESS on the initial connection request. This led to an issue with activating the device which forced me to write some more hacks. I got all the way to reading the interface, traced to the transfer, and it was locked up from there. Clearly faking it was an issue. Then it dawned on me that I had a second SK. So I dug it out and created a simple CDC ACM demo that spit out “HELLO” every 1 second. Tested it with teraterm. Went back to the built-in default ux_host_class_cdc_acm_entry() function. Built the project, downloaded, set my breakpoint and ran the code. I plugged in the second SK board as a USB device and the breakpoint hit. I examined the device descriptors in the expressions window and noted that this time the .bDeviceClass descriptor was a 0x02 (promising!). I also note that this device has 2 interfaces whereas the RL78 board (and the other USB - UART devices at hand) had only one interface. So the second SK board enumerated and the LEDs on that board started blinking. This meant that the slave board was happily sending "HELLO WORLD"s. Then I try to do a read operation using ux_host_class_cdc_acm_read(cdc_acm,&data,data_len,&actual). The call always returns UX_HOST_CLASS_INSTANCE_UNKNOWN. Diving into the USBX code there is a conditional that looks for cdc_acm- ux_host_class_cdc_acm_interface- ux_interface_descriptor.bInterfaceClass != UX_HOST_CLASS_CDC_DATA_CLASS and if true, returns an error... so it is expecting this interface to be a data interface. This condition is true in this case because the first interface is the control interface, not the data interface. The data interface is cdc_acm- ux_host_class_cdc_acm_interface- ux_interface_next_interface - ux_interface_descriptor.bInterfaceClass It looks to me there is either a disconnect somewhere, or I'm not doing it right. Has anyone implemented a CDC host? I'd be interested in seeing how you did it.
↧