We all know that notebooks, mobile phones, tablet computers, and other products have powerful CPUs and large-capacity memory for network communication data processing, and storage. Therefore, when using WiFi, no additional MCU is required, and it is completely dependent on its high-speed processor and huge Software system.

But for smart home products such as home appliances, meters, and LED lights, because the main control chip of such products may be a low-cost, simple-function MCU, such products cannot support ordinary Wi-Fi functions.

At the same time, another important reason is that ordinary Wi-F has relatively high power consumption, while embedded WIFI has made great improvements in power consumption, which is more suitable for wireless home appliances that require high power consumption.

Based on the above reasons, embedded Wi development has emerged. The embedded Wi-Fi module is characterized by a high degree of software and hardware integration. The entire embedded Wi-Fi module integrates a radio frequency transceiver, MAC, Wi-Fi driver, all Wi-Fi protocols, wireless security protocols, and one key. Connection etc. In short, in one sentence: Embedded WiFi should be born for the Internet of Things!

Below we compare embedded WiFi with ordinary WiFi. Through the comparison in the table below, we can roughly understand what embedded WiFi is.

Before analyzing the WiFi driver, in fact, looking at the many device drivers of Linux, almost all use the bus as the carrier. All data transmission is based on the bus form. Even if the device does not have a so-called bus interface, Linux will still add one to it. Virtual bus, such as platform bus, etc.; the driver of WIFI is too huge, and at the same time, it is based on the more complicated USB bus.

Linux device drivers start with module loading to analyze its driver source code.

From a hardware perspective, the communication between the WIFI device and the CPU is through the USB interface, and the communication with other WiFi devices is through the radio frequency (RF). From a software perspective, if the Linux operating system wants to manage WiFi devices, it is necessary to mount the WiFi devices on the USB bus and realize management through the USB subsystem. At the same time, in order to connect to the network, the WiFi device is packaged into a network device.

We analyze the WIFI module with USB interface:

(1) From the perspective of the USB bus, it is a USB device;

(2) From the perspective of the classification of Linux devices, it is also a network device;

(3) From the perspective of WIFI itself, it has its own unique functions and attributes, so it is a private device.

Through the above analysis, we only need to grasp these three clues to analyze its driver source code in depth.

1. Now we start with the USB device. To write a USB device driver, the general steps are as follows:

• • Need to define a USB driver for the device, and define a usb_driver structure variable corresponding to the code. code show as below: struct usb_driver xxx_usb_wifi_driver;
  • Fill in the member variables of the usb_driver structure of the device. code show as below:

static struct usb_driver xxx_usb_wifi_driver = {

.name = “XXX_USB_WIFI”,

.probe = xxx_probe,

.disconnect = xxx_disconnect,

.suspend = xxx_suspend,

.resume = xxx_resume,

.id_table = xxx_table,

};

• • Register the driver to the USB subsystem. code show as below:

usb_register(&xxx_usb_wifi_driver);

The above steps are just a rough USB driver framework process, and the biggest and most complicated work is to fill in the member variables of the usb_driver structure. The main work of the above steps is to mount the WIFI device with the USB interface on the USB bus, so that the Linux system can find the device on the USB bus.

2. The next is the clues of network equipment, the general steps of network equipment driver are as follows:

• • Define a net_device structure variable ndev. code show as below:

struct net_device *ndev;

• • Initialize ndev variables and allocate memory. code show as below:

ndev=alloc_etherdev();

• • Fill in the member variables of the ndev -> netdev_ops structure. code show as below:

static const struct net_device_ops xxx_netdev_ops= {

.ndo_init = xxx_ndev_init,

.ndo_uninit = xxx _ndev_uninit,

.ndo_open = netdev_open,

.ndo_stop = netdev_close,

.ndo_start_xmit = xxx_xmit_entry,

.ndo_set_mac_address = xxx_net_set_mac_address,

.ndo_get_stats = xxx_net_get_stats,

.ndo_do_ioctl = xxx_ioctl,

};

• • Fill in the ndev->wireless_handlers structure member variable, which is a wireless extension function. code show as below:

ndev->wireless_handlers = (struct iw_handler_def *)&xxx_handlers_def;

• • Register the ndev device to the network subsystem. code show as below:

register_netdev(ndev);

3. The private functions and attributes of the WiFi device itself, such as its own configuration and initialization, the establishment of an interactive interface with the user space, and the realization of its own functions.

• • Its own configuration and initialization. code show as below:

xxx_read_chip_info();

xxx_chip_configure();

xxx_hal_init();

• • It is mainly to establish an interactive interface with user space on the proc and sys file systems. code show as below:

xxx_drv_proc_init();

xxx_ndev_notifier_register();

• • The realization of its own functions. The WiFi network and access principles have been explained before, such as scanning. At the same time, because WiFi is relatively large in power consumption in mobile devices, power consumption and power management will also be reflected in the drive.

Please contact us for more details about the embedded WiFi customization, or you can browse our innovative product website HIFCARE then find some products or services you are interested in.