I'm curious is there any possibility to make a bluetooth server in kernel module. I've seen udp server, but I need exactly a bluetooth one.
Kernel code can call sock_create_kern() to create sockets of any family, including AF_BLUETOOTH.
Code under net/bluetooth/rfcomm/ already does it.
Related
I want to read the CAN bus and get the data from a specific device on the CAN bus. I have implemented this previously using the Socket communication api that is available in the user space (sys/socket).
I now have a similar requirement but this time working on device drivers which work in the kernel space. The same socket communication is i suppose not available in the kernel space which is why i guess i am not able to compile the kernel module with #include .
An approach i have come up to is to create a device driver for device creation and a supporting user-space program to interact it and provide CAN data by using socket communication. If there is any better approach please suggest me.
I want to make a network camera, stm32 through the camera to collect images, and then sent to the server through the WIFI module. As 1 second need to transfer a lot of data, so I would like to use the USB interface wifi module program to achieve. Or what better solution to achieve.
Thank you!
I think that you have no idea how the USB works.
You have a couple solutions.
Use a wifi module with SPI interface.
Use a SOC like CC3200.L
Use ESPxxxx module or similar (RTL8710)
You can of course try to use STM with host usb interface, but you will have to implement the USB host stack + driver for USB wifi module + network stack (eg TCP/IP stack). But it is quite complicated as the STM ones are not very good, there are some better paid ones - but expensive. USB host is not easy to implement.
If you want to go along the "networking over USB" path on STM32 (and I'm assuming you're not planning to buy any commercial drivers) it's going to be rough for you.
When it comes to USB, vast majority of the WiFi dongle drivers are proprietary and unless you're on an operating system such as Windows or Linux you're out of luck, unless you want to for the reverse engineering or porting at least parts of the drivers from Linux. With the USB you can think of using the USB-ECM (ethernet over USB) class, but two things here. One - ST doesn't provide any free implementations of this class so you're down do searching for it or implementing it yourself. After a bit of googling I've found one instance of this on githbu, although I havent tested it myself. Second thing - this is no longer wireless as you'll need to be connected to some kind of host providing internet connection, at which point it's probably better to not use USB-ECM and networking at all and just send data using a class that can be implemented easily (USB-CDC or USB-HID). I'm a bit worried about the throughput here.
You can also try to find WiFi modules that are connected over other interface. Generally those modules are connected over UART, some over SPI. This way, integrating it with the TCP/IP stack will also be up to you, at least when it comes to implementing the WiFi module protocol (most likely AT-commands) and implementing network interface so that the stack can "talk" to it. In this approach, I'm almost sure that you'll lack the throughput required for your application.
Personally I'd strongly suggest trying Ethernet if that's an option for you. It's going to be highest bandwidth (which you're going to need), plus it's most "out of the box". There's multiple projects implementing various applications using a free LWIP stack over this interface, including examples generated by ST's CubeMX.
I am in a dilemma that whether i can use Ethernet chip with ATmega 16 for performing socket programming or not?
I actually want to send the real time position signals over the internet to the server using client server model. But will the ATmega 16 be able to process such high data using socket programming? I will be performing socket programming in c just a basic one.
You cannot implement a useful application with TCP socket connections in 1k RAM. So you should look for an Ethernet controller with integrated TPC/IP stack, like the WIZnet W5100.
If wireless is OK, you may also look out for GPRS/UMTS or WLAN modules with integrated TCP/IP stack. They are much more common than their cable-based counterparts.
I would like to be able to develop an iPhone application that can communicate with Modbus devices, but I'm not sure how to proceed. Has anyone had experience with this or are there existing libraries out there for this purpose?
You will need first to know how to make a simple TCP client on your iPhone, and a simple TCP server on your computer that your iPhone client will talk to via WiFi. Make sure PING command works and firewall does not block your server port before any client/server experiments, and make sure that server port for experimenting is greater then 1024 and not already used. Then take a look at MODBUS TCP specification from official site, get familiar with function codes you are interested in, and study C code found here. Then make a simple MODBUS TCP client that can send a request to MODBUS TCP server and interprete an answer. The best way is to start reading single register value, then progress in time and add more functions.
I do exactly all above points, my iOS Modbus lib works fine, application is now up on AppStore, PLCLink read and set any modBus data into my Wago home automation.
Installation guide : http://pautex.fr/plclink
I have two devices that are interfaced with PCI. I also have code for both devices that uses generic socket code. (The devices were originally connected by MII/Ethernet.)
Now, I need to write a PCI device driver to transport packets back and forth between the two devices.
How do I access the file descriptors opened by the socket code? Is this the same as accessing a character device file?
The PCI driver has to somehow capture packets from read() and write() in the code.
Thanks!
The answers to your questions are: (1) You don't, and (2) no.
File descriptors are a user-space concept, and kernel drivers don't interact with user-space concepts. (Yes, they're implemented by the kernel, but other device drivers don't get to play with them directly, and shouldn't play with them even indirectly.)
What you do is implement methods that will receive data that is buffered in a kernel-accessible memory space, and send that to your hardware, and then receive data from your hardware and write it (when asked) to a buffer in kernel-accessible memory.
You'll do this by implementing the character device driver APIs as well as the PCI device driver APIs and then registering your driver as a PCI device, and then a character device. While some of these methods may refer to file structures, they will not be the user-land structures that you know and love.
For devices that implement the Ethernet protocols, life is easier because you implement the Net Device Interface instead. This way all you have to write is the parts necessary to get data to and from your hardware.
What you'll need is specifications for the device hardware, how you control the hardware using PCI registers and regions.
The good news is, you don't have to do this alone -- there's a large community of kernel developers, and several good (and current) books on developing for the Linux kernel (see below).
References
Understanding the Linux Kernel
Linux Device Drivers
Essential Linux Device Drivers