Re: [Xenomai-core] why does not the share memory work well ?
On 05/12/2011 06:15 AM, arethe rtai wrote:
Hi all:
I wirte a share memory program, but I found the share momory does
not work while I try to take a communication between user space and
kernel space.
The task in kernel is OK, we can get the shared space. But the
task in user space can not get the share memory.
The code of the task in user space as follows:
What happens when the user-space tries to get the shared space?
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/mman.h
#include sys/stat.h
#include fcntl.h
#include rtai/rtai.h
#include rtai/rtai_shm.h
int main(void)
{
unsigned int *adr;
adr=(unsigned int *)rt_shm_alloc(0xa, sizeof(*adr), USE_VMALLOC);
if (adr==NULL)
printf(NULL pointer find \n);
//rt_shm_free(0xa);
printf(%dline \n,__LINE__);
fflush(stdout);
return 0;
}
BTW: I added some printf in file src/skins/rtai/shm.c, but they cannot
be outputted to the console.
I doubt that very much. If printf did not work, a lot of application
would not work on your system.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] arm ixp: more trouble with recent xenomai
On Thu, May 12, 2011 at 02:03:34AM +0200, Gilles Chanteperdrix wrote: the issue on ixp looks like the last one to be fixed on arm. If you have time, could you try the following program? It makes a very basic test, but not having a big-endian ixp at end, I am wondering about very basic assumptions...: ~ armeb-unknown-linux-gnueabi-gcc -Wall arm.c arm.c: In function 'f': arm.c:7: warning: control reaches end of non-void function arm.c: In function 'g': arm.c:13: warning: control reaches end of non-void function and then # ./a.out f: g: If you do not have time, do you agree for a revert of the KUSER_TSC code to the one we had before, and which is working for you? I sorry about not getting back about this. I have had crunch trying to meet a deadline, but now that is over. Tomorrow I'm on the road, but next week looks good for IXP testing. And thanks, thanks, for all your good work, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] analogy: wake-up threshold
Hi Stefan, A few months ago, you asked me whether it was possible to prevent the OS from waking up your process each time a few bytes were acquired. You came with the idea to implement a wake-up threshold below which the user space process is kept in sleep state. A few days ago, I updated my experimental branch: two new user-space functions were added: a4l_set_wakesize() and a4l_get_wakesize(). Thanks to them, you will be able to configure the wished behaviour. I hope this will help you. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] I suspect the shared memory of Xenomai has bug.
HI all: I always got null while I request a shared memory through RTAI skins in the user space. Some bugs maybe exist in the sub-system. I traced the execution stream of rt_shm_alloc, and found the mmap() operation always return -22. I suspect the problem should be same while we use other skins, because the mmap operation is implemented in /ksrc/nucleus/heap.c. Is there anyone encountered this problem? Regards Arethe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy: wake-up threshold
Hi Alexis, thanks so much for the new feature! I will try it and report back. In the last months, I actually did run some comparisons between Comedi and Analogy, and in all cases found that your Analogy implementation performs exactly the same as Comedi, actually, for CMD-based streaming, I noticed shorter latencies in Analogy. I also couldn't find any Comedi functionality (for our problems) that was missing in Analogy. Thus, for our work, there may simply be an issue that the communication protocol we are porting from vxWorks may not easily be implemented with our NI6259 board using either Comedi or Analogy, and we are considering to change the protocol with the help of some intermediate electronics. After all is working, I will email the method of solution to the xenomai-core list. But I am eager to check your new functions. Best wishes, -Stefan On May 12, 2011, at 15:52, Alexis Berlemont wrote: Hi Stefan, A few months ago, you asked me whether it was possible to prevent the OS from waking up your process each time a few bytes were acquired. You came with the idea to implement a wake-up threshold below which the user space process is kept in sleep state. A few days ago, I updated my experimental branch: two new user-space functions were added: a4l_set_wakesize() and a4l_get_wakesize(). Thanks to them, you will be able to configure the wished behaviour. I hope this will help you. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I suspect the shared memory of Xenomai has bug.
On 05/13/2011 03:25 AM, arethe rtai wrote: HI all: I always got null while I request a shared memory through RTAI skins in the user space. Some bugs maybe exist in the sub-system. I traced the execution stream of rt_shm_alloc, and found the mmap() operation always return -22. I suspect the problem should be same while we use other skins, because the mmap operation is implemented in /ksrc/nucleus/heap.c. Is there anyone encountered this problem? This is the third time you post this incomplete report. See: http://www.xenomai.org/index.php/Request_for_information If you want to receive an answer. Because in xenomai 2.5 branch, each process maps a shared memory when starting. So, if shared memory were not working, no xenomai process would work, not even the latency test. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
