Re: [Xenomai-help] xnpod help
Brandt Erickson wrote: Ok, things get clearer. But why a kernel module? Are you *that* short on CPU cycles? The reason why I'm trying to develop a kernel-space application is not for latency issues but because I need to be in kernel-space to read/write to/from my DAC. There are several way you can write an application with Xenomai: - first, the canonical way, split your application between driver code and application code, implement the driver in kernel-space and the application in user-space. Xenomai ease your work by providing the RTDM skin for writing drivers in kernel-space, and user-space skins (posix, native, vxworks, etc...) for writing applications in user-space. For a good portability, I would suggest to use the posix skin in user-space. - second, the rapid way, good for prototyping, do it all in user-space. You may use iopl or ioperm to allow your application to access I/O regions, and libpci and mmaping /dev/mem to access PCI devices from user-space. Xenomai will ease your work here by allowing you to run your whole application in gdb, and skins generally provide functions to implement IRQ servers in user-space. See for example pthread_intr_wait_np. - a third way, maybe useful as an intermediate between the first two. Split your code between kernel-space and user-space, but use the same skin in user-space and kernel-space. Xenomai ease your work here because skin interfaces are written to be very similar in kernel-space and user-space, and IPCs may generally be used to communicate between the two address spaces. Is the IPC between kernel-space realtime and user-space non-realtime that much more difficult the user-space realtime to user-space non-realtime? I've familiar with regular user-space IPC using condition variables, semaphores, and shared memory, so if it's fairly similar, I'm hoping that won't be a problem. -Brandt The only IPC existing to communicate between real-time (whether user-space or kernel-space) and non-realtime user-space threads is the native skin message pipes: http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html By contrast all other IPC implemented by all skins are accessible to real-time threads running in secondary mode: they will simply switch to primary mode the time they use blocking services. So, it is probably a better idea to create your non-realtime threads as real-time threads and let them switch to secondary mode when they use non-realtime services. -- Gilles Chanteperdrix. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] shm_open, ftruncate
Hi,
I got some problems with shared memory.
I started from the shm_open example from opengroup.org.
When I compile it as non real time tasks, it works properly. But since I
tried to compile it with
gcc $(xeno-config --posix-cflags) shm_open.c $(xeno-config
--posix-ldflags) -o xeno_shm_open,
i get an EINVAL error from ftruncate that i can fix.
Does shm under xenomai require particular things ?
Thanks for your help...
Lionel
#include unistd.h
#include sys/mman.h
...
#define MAX_LEN 1
struct region {/* Defines structure of shared memory */
int len;
char buf[MAX_LEN];
};
struct region *rptr;
int fd;
/* Create shared memory object and set its size */
fd = shm_open(/myregion, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if (fd == -1)
/* Handle error */;
if (ftruncate(fd, sizeof(struct region)) == -1)
/* Handle error */;
/* Map shared memory object */
rptr = mmap(NULL, sizeof(struct region),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (rptr == MAP_FAILED)
/* Handle error */;
/* Now we can refer to mapped region using fields of rptr;
for example, rptr-len */
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] shm_open, ftruncate
Lionel Perrin wrote:
Hi,
I got some problems with shared memory.
I started from the shm_open example from opengroup.org.
When I compile it as non real time tasks, it works properly. But since I
tried to compile it with
gcc $(xeno-config --posix-cflags) shm_open.c $(xeno-config
--posix-ldflags) -o xeno_shm_open,
i get an EINVAL error from ftruncate that i can fix.
Does shm under xenomai require particular things ?
When applying the attached patch to xenomai (do not forget to rebuild
the kernel), the attached program compiled with the attached Makefile
works here.
--
Gilles Chanteperdrix.
Index: ksrc/skins/posix/shm.c
===
--- ksrc/skins/posix/shm.c (revision 1143)
+++ ksrc/skins/posix/shm.c (working copy)
@@ -516,10 +516,8 @@
is aligned). */
if (len)
{
-len += PAGE_SIZE + xnheap_overhead(len, PAGE_SIZE);
+len += PAGE_SIZE + PAGE_ALIGN(xnheap_overhead(len, PAGE_SIZE));
len = PAGE_ALIGN(len);
-if (len == 2 * PAGE_SIZE)
-len = 3 * PAGE_SIZE;
}
err = 0;
#include stdlib.h
#include stdio.h
#include errno.h
#include fcntl.h
#include unistd.h
#include sys/mman.h
#define MAX_LEN 1
struct region {/* Defines structure of shared memory */
int len;
char buf[MAX_LEN];
};
struct region *rptr;
int fd;
int main(int argc, const char *argv[])
{
int fd, status;
mlockall(MCL_CURRENT|MCL_FUTURE);
/* Create shared memory object and set its size */
fd = shm_open(/myregion, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if (fd == -1) {
perror(shm_open);
exit(EXIT_FAILURE);
}
if ((status = ftruncate(fd, sizeof(struct region))) == -1) {
/* Handle error */;
perror(ftruncate);
close(fd);
status = EXIT_FAILURE;
goto close_and_unlink;
}
/* Map shared memory object */
rptr = (struct region *) mmap(NULL,
sizeof(struct region),
PROT_READ | PROT_WRITE,
MAP_SHARED,
fd,
0);
if (rptr == MAP_FAILED) {
/* Handle error */;
perror(mmap);
status = EXIT_FAILURE;
goto close_and_unlink;
}
/* Now we can refer to mapped region using fields of rptr;
for example, rptr-len */
munmap(rptr, sizeof(struct region));
close_and_unlink:
close(fd);
shm_unlink(/myregion);
return status;
}
DESTDIR=/home/gilles/files/perso/dev/build/nestor/inst
XENO_CONFIG=$(DESTDIR)/usr/xenomai/bin/xeno-config
CFLAGS:=$(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --posix-cflags) -g -O2 -Wall
-W -Werror-implicit-function-declaration
LDFLAGS:=$(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --posix-ldflags)
LOADLIBES=-lpthread_rt
all: test_shm
test_shm: test_shm.o
clean:
$(RM) foo foo.o test_shm.o test_shm
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xnpod help
ioperm() or iopl() not applicable? I'm not sure. I'm using a Sensoray S626 card (PCI). The driver I have is something I pieced together from psuedo-working code I got from someone else, so I'm not entirely sure how it works (or if it's even rt-safe). -Brandt ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
