On 01/23/2016 01:44 AM, Gmail wrote:
> Hello,
>
> Good day gentleman. I recently switched to xenomai 3 and found a problem when
> I use rt_pipe_write() function.
>
> A pipe can be created successfully by rt_pipe_create() but when it comes to
> rt_pipe_write(), the function returns ENOMEM. I used strerror to print out
> the problem and I got the message “cannot allocate memory”.
>
> I don’t know if it’s the problem of the buffer size parameter in
> rt_pipe_create(), rt_pipe_write() or rt_task_create() ?
> Or it’s the problem of the parameter in config file setting when I compile
> the xenomai kernel?
The code illustrating the problem is incomplete, the issue is likely in
the non-rt side which must exist for sending the "World" message back to
the rt endpoint, reading the "Hello" string from some /dev/rtp* device.
This code does not appear in your description.
>
> Here is (some parts of) my code on /* Kernel-side */:
>
You must mean user-space side.
>
> /*****************************************************************************************************/
> #include <alchemy/task.h>
> #include <alchemy/pipe.h>
> #include <trank/rtdk.h>
Either your build flags have been obtained from xeno-config
--compat/--native in which case you can include <rtdk.h> directly, or
you did not but then you should not force the libtrank headers in.
>
> #define TASK_PRIO 50
> #define TASK_MODE 0
> #define TASK_STKSZ 10000 /* Stack size (in bytes) */
It's tiny, especially when calling stdio routines. The Xenomai API will
likely pick a larger size under the hood anyway.
>
> RT_TASK task_desc;
> RT_PIPE pipe_desc;
>
> void task_body(void *arg)
> {
> while (1) {
> fprintf(stderr, "Failed: %s\n", strerror(-rt_pipe_write(&pipe_desc,
> "Hello", sizeof("Hello"), P_NORMAL)));
>
> // Then wait for the reply string "World":
> rt_printf("******waiting******\n");
rt_print() is obsolete with xenomai 3. printf() does the job provided
the app is linked with the proper flags obtained from xeno-config --ldflags.
>
> char buf[200];
> rt_pipe_read(&pipe_desc, buf, 200, TM_INFINITE);
Any reason not to test return values? This is asking for painful
troubles, especially with blocking calls which might receive error
conditions when sleeping.
> rt_printf("received msg> %s\n", buf);
>
> sleep(1);
> }
> }
>
>
> int main(int argc, char* argv[])
> {
> mlockall(MCL_CURRENT|MCL_FUTURE);
>
This is useless over xenomai 3.
> rt_print_auto_init(1);
>
Ditto.
> rt_pipe_create(&pipe_desc, "my_pipe", P_MINOR_AUTO, 32);
>
Since your code asks for a free /dev/rtp device to be picked by the core
by passing P_MINOR_AUTO, but doesn't read the return value of
rt_pipe_create(), how does your non-rt program figure out which
/dev/rtp* is connected to the rt endpoint?
lib/alchemy/testsuite/pipe-1.c illustrates proper usage.
Aside of the missing test code, you did not mention the xenomai version,
the kernel version, not even the CPU architecture you are running such
code on. Please consider reading
http://xenomai.org/start-here/#If_something_goes_wrong
--
Philippe.
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
