Belcarra PIC32MZ USBLAN Function Driver; The Belcarra PIC32MZ USBLAN Function Driver is a TCPIP NIC driver that uses the PIC32MZ USB High Speed Device Driver to connect to another system. It uses CDC-EEM to transfer network packets to and from the other system. The driver is distributed in this project as a libary archive (libusblan.a) Testing. The Gadget USB Device implementation has three layers when using the new libcomposite driver: Function Drivers, e.g. Usbfacm, usbfecm, usbf eem; LibComposite, for selecting and configuring the device to use the Function Drivers; UDC, to connect the Function Drivers to the underlying USB Device Controller hardware.
A USB device presents various descriptors to the host in one or more configurations. If the first configuration matches an driver information (INF) file on Windows, then a matching driver in Windows will be loaded. The driver will then examine additional descriptors from the device, and if it is satisfied, it will issue a Set Configuration request to the device, and the device will now be enumerated.
All of the major microcontrollers have libraries that implement the foregoing for simple cases. To implement a custom protocol, such as CDC-EEM, you need to do the following
- Modify the Device Descriptor to conform to the requirements of the protocol. Specifically, you need to set the following values:
- Subclass - 0xc
- Vendor ID
- Modify the Configuration Descriptor and supplementary descriptors (interface, endpoint, string descriptors) to match
- Modify your network subsystem transmit to fill EEM frames. Your code fills EEM buffers with one or more network frames, and when a buffer is deemed ready, start transmitting it
- The USB OUT (receive) subsystem will receive 1 EEM frame in a USB transfer, consisting of 1 or more USB packets of maximum length (64 bytes for full speed, 512 bytes for high speed USB) followed by a short or ZLP (zero-length packet). We assume there already support for low-level USB operations. In particular, at interrupt time we can be informed that a packet of data has been received. If we are in the process of building an EEM frame, the a full-speed packet is copied to the frame. The EEM standard doesn’t say how big an EEM frame is but USBLAN provides a way for both sides to agree on the maximum size.
- When an incoming EEM frame is complete, a loop should be triggered that unpacks it into its component parts (1 or more Ethernet frames) which end become incoming frames to the network subsystem.
- During the time that incoming EEM frame is being unpacked, new OUT (incoming) data needs to be directed to another buffer. So the system needs at least two EEM frames in each direction, one to feed the network subsystem and the other to feed the USB subsystem.
Download Belcarra Driver Free
The EEM Standard document not only specifies the frame formats and other technical data in the usual terse language of standards, but contains a number of explanatory appendices which give a lot of guidance on how to implement and use EEM.
Download Belcarra Drivers License