I am writing here because I am having some problems understanding some key concepts regarding kernel/drivers development.
First, I am going to try to describe what I want to achieve:
Develop a driver that uses the SPI to communicate receiving the payload from user space (I cannot use spidev because I pretend to transparently add some info to the payload before sending it). I want to load the module manually (insmod).
The problem I am seeing: I do not know where or how to specify my interface. If I define the interface within the device tree, is it mandatory to include the compatible field? I ask this because the driver will not be included within the kernel modules as it starts up... Maybe there is not a problem with it. In the examples, I found about spi they only speak about the BUS, Chip Select... but they do not mention MISO and MOSI, so I guess these must be defined by the device tree or maybe since you specify the bus the definition of the rest of the pins is straight forward... I would like to understand this.
Thanks in advance.
Best regards,
Fulgo.
Related
I am creating a REDHAWK device that outputs either 16 bit signed complex samples, or VITA49 packets. I want the device to be told which output type it should provide when it is allocated.
How should I go about this?
Should I just add a simple property to the front_end_tuner_allocation struct?
Some other recommended approach.
Is there an example that I might look at?
ANSWER
I was able to speak with an experienced REDHAWK developer.
Apparently in situations where the device is capable of producing different data flows then separate Device node specifications should be created. This means that the output port to be used will be dictated when the device is started and should not be configured at run time.
This actually makes sense given the life-cycle of the device and the component receiving the data.
This is how I rationalize it, the component won't be able to control the device until the allocate-capacity is performed. So there would be no way for the component/waveform to setup the device ahead of time.
Reading about the driver-model platform, my understanding is that a platform driver is a static piece of kernel code that controls a platform device, which is a device which generally is always present in the system, as opposed to a driver composed of a kernel module, which can be loaded or removed at will and controls devices which might not always be connected. This answer seems to support that statement.
If all this is true, I expect it's what I'm looking for. I am trying to write a kernel module which, among other things, needs to communicate with an external device over I2C. While the external device isn't always part of the system, the I2C bus IS, so it ought to be controlled by a platform driver. So rather than writing code in my module to directly control the I2C, I ought to be using the platform driver. I found what I believe to be the proper platform driver for the I2C bus on my platform here, and it does use < linux/platform_device.h >, so that seems to be consistent.
However, in addition to this, when looking up I2C in general, I have seen reference to an I2C "client". From the name alone, this sounds like what I am trying to write now, a kernel module that uses the platform driver to communicate over I2C. However, in the documentation for the driver-model platform, nothing about a "client" is mentioned, so I don't know if this is correct or if it is some completely separate different model.
So how does a "client" kernel module fit into the driver-platform model for interfacing with hardware in Linux? Is my module supposed to instantiate a struct of the i2c_driver, or is that something done by the platform driver, and the module is supposed to create an interface to that?
This is a basic question of understanding. I'm trying to follow this explanation http://www.barryvandam.com/node-js-communicating-with-arduino/ but something there sounds a bit off to me.
As far as I understood before, I only need to push the standard Firmata code into the Arduino and code via Node.js to call actions and information from the Arduino.
But in this link they point our that I need to upload a code to the Arduino, which will obviously delete the Firmata code that is now there. wouldn't it result in loosing connection to the Arduino?
How does it work?
many thanks!
The example above does not use Firmata, though Firmata makes things easier. If you want to implement your own serial control protocol, there nothing stopping you.
However, if you load StandardFirmata on your Arduino, and then use the Firmata.js package in node, then you have a full-featured, well established serial protocol and an api to access the pins from.
There are Firmata controller implementations for most languages out there.
On top of Firmata.js, you might choose to use an abstraction called Johnny-Five. Johnny-Five abstracts the pins as components, with an intuitive API. Instead of controlling a servo by setting a pin value, you create a servo, and call servo.to(angle). It is kind of like jQuery but for hardware. It abstracts the platforms and devices in such a way that the shape of the interface is the same, but the hardware might be completely different. It is a very comfortable place to develop from.
Firmata is a set of functions that you can pre-load onto your Arduino that libraries like Johnny-Five can call to perform certain tasks.
As previously said by the author of the accepted answer, you don't have to use it, you can write your own logic to send and receive custom message.
In Node.js you can use the node-serialport library to send the message:
myPort.write();
Then read the message from the Arduino with the built in Serial library:
while(radio.available()){
radio.read(chr, 1);
}
Firmata is one way to communicate with an Arduino, you do not have to use it.
You can "talk" to Arduindo directly using the SerialPort module - which is what the linked example is doing.
I'm trying to write a Linux character device driver for a device that just happens to communicate over I2C. The device is an Atmel microcontroller with code that provides an I2C address. It already works using the typical i2c-dev method on the Linux-side.
So now I want to replicate i2c-dev as a new driver that works specifically with this particular device, so that I can add some of my own device-specific abstraction code on top. But I'd like to trim out all the unnecessary code from i2c-dev that currently makes it generic. What can be removed in this situation?
What can be removed in this situation?
You're actually asking an XY question.
You would be better off looking at and adapting an existing I2C device driver that is already similar in required functionality, rather than hacking a special case driver for userspace access.
So now I want to replicate i2c-dev as a new driver that works specifically with this particular device, so that I can add some of my own device-specific abstraction code on top
So then you actually need to write a "Client driver" as described below (from Linux Documentation/i2c/summary):
When we talk about I2C, we use the following terms:
Bus -> Algorithm
Adapter
Device -> Driver
Client
An Algorithm driver contains general code that can be used for a whole class
of I2C adapters. Each specific adapter driver either depends on one algorithm
driver, or includes its own implementation.
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
code to access some type of device. Each detected device gets its own
data in the Client structure. Usually, Driver and Client are more closely
integrated than Algorithm and Adapter.
Details are in Documentation/i2c/writing-clients.
To find a driver of similar functionality, scan the list of I2C client drivers. Note that these I2C drivers are located in the Linux source tree by their functionality (e.g. drivers/rtc/ or drivers/hwmon/) and not their interface (i.e. I2C).
I have a question regardind dbus on the current(2.6.35) kernel. Is dbus a way of communication between kernel and user space? I can figure it out by myself. For exemple if you make use of the usb driver(inserting something like a usb flash pen) and monitoring the activity of the dbus(dbus-monitor) the answer might be yes. But in the source code(usb-skeleton.c and the driver for gadgets there's no sign of dbus). Dbus.h is not to be found in the kernel tree.
Thank you very much. Sorry if i've got this wrong but i am kind of a noob on device drivers and dbus!
D-Bus is for user space applications to communicate with one another.
If you want to communicate with a device driver you want to use either IOCTLs, netlink or create a new syscall. I've created netlink code in the past to speak to a special networking card, and it was relatively easy to do. Using the ioctl is also quite easy but you are limited by how much information you can/should pass via it.
If you are curious how dbus relates to a USB device being inserted, I think it is something like this:
D-Bus (or "daemon bus") is a means of communication between processes (inter-process communication or IPC for short) on Linux/Unix based systems.
It lets processes expose a "D-Bus service" with methods that clients can call. These methods usually map to real methods written in some programming language. D-Bus is language-independent, but most toolkits have some library to make it easier to use - e.g. QtDbus.
It is in no way related to the kernel or drivers, but of course no one prevents a driver from also having a D-Bus service if they want to. (This could be useful in some cases.)