Driver interaction

Hello together,

I adapted an existing code for the use of a I/O expander and it works.

As far as I know, the only way to interact with a (this) driver is using the ioctl() command. Trying to use a own function like doSomething() did not work because it could not find this function, also not if I declared it in the header file… (does it matter it is a function inside a class?)

  • And therefore, why does the ioctl command work, even it is not defined in a head and it is a in-class function in my drivers .cpp code?

Next point:
The ioctl command has three arguments to give over:
The first one is the file-pointer (struct file *filp) to my own driver location which I just created, right?
Thus the question is, are there any restrictions for the values of the second argument(int cmd). I mean, can I just use any number? I heard there are/can be restrictions, which could cause a bad interaction with other drivers. Is that possible?

I would highly appreciate a answer and hope I stated myself clearly enough.

Thank you ahead! :slight_smile:

Hi @Tachsche, I think you’ll need to provide more detail. In general you should try to interact via uORB messages instead of IOCTL, although it’s not clear what’s appropriate in your case without more detail.

So I don’t know anything about uORB messages…

regarding my ioctl understanding problem:
I edited/ enhanced a driver and the only way i knew how to was to use the existing ioctl method. I changed the argument(3rd parameter) and the address (second parameter) of the ioctl command.
But the guy who created the driver originally had an adress offset for the second argument. He started like at 0x2800 and restriced the usage up to e.g. 0x28FF.
And that was confusing me. Thats why I asked:
Do i need to care where my number of the second argument starts? Like if I use another number, could it effect another component/driver?
I´m not sure, but I think rather it does not effect it, because my first argument defines the driver (my driver) to use. Only if the ioctl query cannot be processed in my code and it is forwarded to the main ioctl (e.g. linux’s), then it could/will effect other drivers.
So once more. For my own driver as 1. parameter, could the number of the second parameter effect any other driver?

Does that make it clearer?

(PS: I made it run, but I would like to know that to ensure it won’t cause an error/ for future changes)

Are there any restrictions about the ioctl function?
The programmer doesn’t specify the hardware address,because it’s decided by the cpu.