Hello Ivan,
I also use Analogy and I believe that I am the user that Jan was
referring to.
I have used some of the newer NI cards a few years ago but, at the time
at least, developing Analogy drivers for them was not possible since NI
does not make low-level hardware register information
Good morning,
We do indeed use Analogy for both data acquisition and control. In the
past, our hardware platforms tended to be x86-based hardware with some
lower-cost analogue input hardware built into the base such as the
Diamond Neptune. Since this platform is EOL, we have moved to lower
:
On 13.07.21 15:57, Peter Laurich via Xenomai wrote:
Hi,
I noticed this patch being submitted and was caught a bit off-guard by
the situation. How long has it been since Analogy was actively
maintained? A lot of the drivers that I have developed use the Analogy
API to pass information between acquisition
Hi,
I noticed this patch being submitted and was caught a bit off-guard by
the situation. How long has it been since Analogy was actively
maintained? A lot of the drivers that I have developed use the Analogy
API to pass information between acquisition hardware and user-space code.
Thanks
about
my options.
Peter
On 5/12/2021 3:00 AM, Jan Kiszka wrote:
On 12.05.21 00:04, Peter Laurich via Xenomai wrote:
Hi,
I am hoping that someone can help me to solve a problem that I am having
with the Xenomai latency test.
Here is my set up:
* 4.9.146 kernel with ipipe patch (this is the last
Hi,
I am hoping that someone can help me to solve a problem that I am having
with the Xenomai latency test.
Here is my set up:
* 4.9.146 kernel with ipipe patch (this is the last kernel version
that supports 32-bit x86 and has a Xenomai patch file)
* kernel config options set as defined
No other way that I am aware of. I was troubled by the --session and
--mem-pool-size switches for a long time as well.
Peter
On 4/1/2021 10:44 AM, zy wrote:
Hi Peter,
You solved what has troubled me for a long time. Thank you for your reply.
I know the conception of session of linux for the
Hello,
I suspect that your problem may be the same as I had earlier. If you are
sharing heaps then you have more than one program that needs to have the
same Xenomai session. Here is how I spawn two programs that share the
same heap and other Xenomai objects:
./initSys --session=akamina
Hello all,
I am seeing significant differences in behaviour depending on whether I
spawn 2 Xenomai tasks from one program vs two programs. The 2 Xenomai
tasks that I spawn from the one program are line-for-line identical to
the 2 tasks that I spawn from two programs. The version where a
= as
well as --mem-pool-size=
* I have not sorted out if / how kernel config values such as
OPT_SHARED_HEAPSZ fit into the puzzle
Sadly, there is no --stop-page-faulting command line argument.
Good luck
Peter
On 2/25/2021 9:30 AM, Peter Laurich via Xenomai wrote:
Hi,
I am having
Hi,
I am having problems allocating a larger heap using Xenomai
rt_heap_create(). The attempt to allocate a heap of size 1.3M fails
after having allocated less than 8K from the heap. I have the Xenomai
memory configuration limits all set high enough (I think) and even pass
the
That's it. I added the session name and my test programs now can both
access the same mutex.
Thank you for the quick response. Now on to the next challenge :-)
Peter
On 2/12/2021 10:50 AM, Philippe Gerum wrote:
Peter Laurich via Xenomai writes:
Hello,
I am in the process of migrating
Hello,
I am in the process of migrating from Xenomai 2 to 3.1. I have existing
code with programs as individual c files where each file has a mainline
that then creates a task (rt_task_spawn()). The task spawn part is
working fine but I can not seem to access a mutex created in one task
from
13 matches
Mail list logo
