I have questions about can communication

1.Do I have to build the module into the kernel when communicating with CAN? Do I just need to build as a module? If you
build the module into the kernel, you will not see the drive when modprobe.
It will appear again when you build the module.

2.And Is it possible to make a transceiver from chips and boards in the company rather than buying from eBay?

What should I do?

20171024_144637.jpg

I don’t know specifically about CAN, but the following might be useful for you to know (this isn’t an answer, it is intended to help you research)…

The kernel has many features, and drivers are actually features, but the term tends to be used with software related to devices which can be attached. The feature does not usually care if it is in the form of a module, or if it is in the form of being integrated into the kernel.

A module is convenient since it can usually be added or removed to a kernel while it runs, and is less invasive than replacing the kernel itself. lsmod lists modules, but the lack of the module does not mean the feature doesn’t fully exist…it might be part of the kernel itself. The content of “/proc/config.gz” is a gzip compressed pseudo (“fake”) file which exists in RAM and directly reflects the kernel’s features. You can copy this to another directory, use gunzip on the copy, and then look at its content to see what the running kernel was built for (e.g., “cp /proc/config.gz ~; cd ~; gunzip config.gz; less config”). This is the authoritative list of what the kernel is configured for, not lsmod. Note that a module compiled and shown in config.gz may not actually be loaded, so the module must be loaded before that feature can be considered as existing.

Many features (especially drivers) can be built as a module, but extra code must be put in place so some code can’t be built as a module simply because the extra code was not written for it. Other features cannot be put in place as a module because the nature of the feature does not allow adding and removing it during operation (an example is that configuring to use swap files for memory is invasive to how memory works, so this cannot be made as a module because of its nature).

There may be a slight performance disadvantage for module format since there is a direct branch instruction required between a module and the kernel which would not otherwise exist (a direct branch is not particularly significant for many purposes, but can be).

Menu utilities used in a kernel compile tend to offer only the kinds of options which are allowed, e.g., “make menuconfig” or “make nconfig” menus will allow you to select swap as an integrated feature, but won’t allow you to select swap as a module. Some features depend on other features, and menu utilities tend to not allow you to select a feature until that other feature is selected (or sometimes the menu utility will automatically select prerequisite features). If you edit the config file directly you might violate this, so normally a menu utility should be your guide as to whether the feature can be module format or integrated.

Device special files show up as a file but are not really files. These exist only in RAM, and when data is sent to the file, or data is read from the file, it is the driver which is accepting or sending data. These files usually show up only when the driver is in place. Ethernet does not show up as a device special file, but in reality the end points are a kind of device special file. The name you see from “ifconfig” (such as “eth0” or a CAN device) implies the driver is in place and has the ability to talk to the hardware.

Having a driver in place for hardware means the hardware can be configured, but it doesn’t mean the hardware will necessarily just do what you want. An example is that ethernet device needs to know what its address is, what its netmask is, so on…and other software needs to be configured to know if network routing should even use the device at all. I don’t know what CAN bus uses, but since the CAN device appears in ifconfig without errors listed you know it is possible for the CAN device to be configured, and the hardware driver itself is already in place. The driver is working, but you’ll need to know what configuration is required.

Protocols are another feature a kernel can implement, or protocols can be implemented in the user software itself. Example: Ethernet uses Internet Protocol 4 or Internet Protocol 6 (a.k.a., “IPv4” or “IPv6”)…these protocols are implemented in the kernel, but many encryption software features are at the end user software (such as in a web browser or library the browser links to). You may need information on what configuration is required by the device from ifconfig, and your end user software may need other configuration on top of that. One example which I can’t answer (because I haven’t worked on CAN) is that perhaps the device seen from “ifconfig” needs an address assigned…after that perhaps the software you use to talk to your device needs configuration, e.g., the end CAN device probably has an address too and your software would need to know what address it is trying to talk to.