Hello,
After a couple of weeks of sometimes very frustrating work, I finally
managed it to write an USB-Driver, that is able to handle a
read-Syscall for a ForceFeedbackJoystick…
Now, because it’s a ForceFeedbackJoystick, my driver needs a function
to handle a write-Syscall triggered by applications.
The structure of the data_to_sent is the following:
typedef struct _joys_senddata
{
short usCtrlState; // field of bit for control 0 … 0xFFFF
short sSollPosX; // referenced position (X-Axes)
short sSollPosY; // referenced position (Y-Axes)
short sFSollX; // referenced force (X-Axes)
short sFSollY; // referenced force (Y-Axes)
} joys_senddata_t;
My questions:
Are there any examples for how such an joys_io_write-function must
look like??? Some ideas or a framework what the io_write-function has
to include??? Any hints of any kind???
R.I.P.wrote:
Hello,
After a couple of weeks of sometimes very frustrating work, I
finally managed it to write an USB-Driver, that is able to handle a
read-Syscall for a ForceFeedbackJoystick…
Now, because it’s a ForceFeedbackJoystick, my driver needs a
function to handle a write-Syscall triggered by applications.
The structure of the data_to_sent is the following:
typedef struct _joys_senddata
{
short usCtrlState; // field of bit for control 0 … 0xFFFF
short sSollPosX; // referenced position (X-Axes)
short sSollPosY; // referenced position (Y-Axes)
short sFSollX; // referenced force (X-Axes)
short sFSollY; // referenced force (Y-Axes)
} joys_senddata_t;
My questions:
Are there any examples for how such an joys_io_write-function must
look like??? Some ideas or a framework what the io_write-function has
to include??? Any hints of any kind???
Would be fine to get some answers…
Any ForceFeedbackJoystick - model docs info etc available?
You must know, that I’m working for a research institute (German
Aerospace Center) as an trainee.
And that Joystick has been developed her. So it’s nothing custom.
But I think those IDs are just Makros to fill in.
What I’m looking for is how such an write-Syscall has to be processed
theoretically. What functions do I need?
I search some example drivers, where I can see, how it might work.
For example I want to know, whether you need an URB for read as well
as an URB for write or whether you can do it with only one URB for
both.
So you see, I need more general information!
greets
Ok, yet I made some progress in writing my io_write-function, so I can
specify my problems now.
The situation I have is the following:
my testapplication calls write(fd, buffer, sizeof(buffer)),
where buffer is a memcpy of the to_send_data-Structure (look up!!)
Then the joys_io_write-function in the driver starts its work.
after checking some Flags, I use the resmgr_msgread(ctp,
joys->ep_int_out_buf, nbytes, offset)-function to copy the data to
send to the Joystick into the endpoint-buffer.
where ctp (Context),
ep_int_out_buf (Buffer for interrupt-out-transfer, size:
ep_out_maxpacketsize, which is equal to sizeof(to_send_data_t)),
nbytes (Length of the msg, the testapplication sends to the driver, =
sizeof(to_send_data_t)) and
offset (=sizeof(msg->i), so it starts reading the buffer of the
msg-union)
this works fine! and when I test the content of ep_int_out_buf it’s
correct (equal to send_data from the testapplication)
after that I set-up the URB with usbd_setup_interrupt(joys->urb,
URB_DIR_OUT, joys->ep_int_out_buf,
sizeof(joys->ep_int_out_buf)
and send it with usbd_io( joys->urb, pipe, joys_int_out_cbf, joys,
USBD_TIME_INFINITY ),
where joys_int_out_cbf should be the completion-function.
But I don’t know, what has to be done in the
joys_ep_int_out_cbf-function. Maybe you can help me with that…
Somehow I have to wait till the transfer has completed, but how do I
manage that???
R.I.P.wrote:
Ok, yet I made some progress in writing my io_write-function, so I
can specify my problems now.
The situation I have is the following:
my testapplication calls write(fd, buffer, sizeof(buffer)),
where buffer is a memcpy of the to_send_data-Structure (look up!!)
Then the joys_io_write-function in the driver starts its work.
after checking some Flags, I use the resmgr_msgread(ctp,
joys->ep_int_out_buf, nbytes, offset)-function to copy the data to
send to the Joystick into the endpoint-buffer.
where ctp (Context),
ep_int_out_buf (Buffer for interrupt-out-transfer, size:
ep_out_maxpacketsize, which is equal to sizeof(to_send_data_t)),
nbytes (Length of the msg, the testapplication sends to the driver,
= sizeof(to_send_data_t)) and
offset (=sizeof(msg->i), so it starts reading the buffer of the
msg-union)
this works fine! and when I test the content of ep_int_out_buf it’s
correct (equal to send_data from the testapplication)
after that I set-up the URB with usbd_setup_interrupt(joys->urb,
URB_DIR_OUT, joys->ep_int_out_buf,
sizeof(joys->ep_int_out_buf)
and send it with usbd_io( joys->urb, pipe, joys_int_out_cbf,
joys, USBD_TIME_INFINITY ),
where joys_int_out_cbf should be the completion-function.
But I don’t know, what has to be done in the
joys_ep_int_out_cbf-function. Maybe you can help me with that…
Somehow I have to wait till the transfer has completed, but how do I
manage that???
ok, looks like, the data I want to write to the Joystick and is set in
my testapplication, is written correctly to the Joystick.
Because if I do a read-Syscall after the write I get the
usCtrlState-value I previosly wrote to the Joystick. But
unfortunately only the usCtrlState-value. For all the other values
(position, forces), I just get the current values back and the
Joystick doesn’t move in any direction.
Thus, it seems not to be a driver-problem anymore and maybe I have to
check the hardware.
Thank you for your help, so far…
R.I.P.wrote:
ok, looks like, the data I want to write to the Joystick and is set
in my testapplication, is written correctly to the Joystick.
Because if I do a read-Syscall after the write I get the
usCtrlState-value I previosly wrote to the Joystick. But
unfortunately only the usCtrlState-value. For all the other values
(position, forces), I just get the current values back and the
Joystick doesn’t move in any direction.
Thus, it seems not to be a driver-problem anymore and maybe I have
to check the hardware.
Thank you for your help, so far…