[Xenomai-core] Analogy: A4L_CHAN_AREF_* and AREF_* and other macros
Hello Alexis, I have noticed that in Analogy headers there are two sets of macros to define channels references, one with prefix A4L_CHAN_AREF_ and the other with prefix AREF_. I think keeping both is confusing and dangerous, because similar symbols are defined with different numerical values! The later form is the one used in comedi API and drivers, but i think it is better to prefix all exported symbols and constants with a namespace like string. I would be for keeping only the former form. If you agree, I can provide a patch for you to review. Similarly, I would rename TRIG_ constants to something like A4L_TRIG_, and while at it I think TRIG_WAKE_EOS should become A4L_CMD_WAKE_EOS, as it is a command flag and not a trigger source. Similarly, it would be nice also to rename other macros defined in command.h, adding at least a common A4L_ prefix. While at it I think that, maybe after a rename to make their purpose more clear, CR_* macros should be exposed to user space too. If you think API breakage should be avoided, even in a so early stage of development and diffusion, we can keep the old definitions for a while, issuing deprecation warning (in this case those symbols would have to be exposed as constant variables where to apply the __deprecated__ gcc attribute). Let me know what you think about this proposal. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Analogy: improve a4l_find_range()
Hello Alexis, I wrote a small patch to improve a4l_find_range().
As many every other functions expect to have the range specified as its
idx into the struct describing the subdevice it is useful have it
returned from a4l_find_range(). I also made returning a pointer to the
range struncture optional.
I also attache a simple patch to clean up trailing whitespaces in the
range.c file.
Cheers,
--
Daniele
commit ec80d59f5ecfdc74b45d9da7edfdb54f6cab555a
Author: Daniele Nicolodi
Date: Mon Mar 29 22:11:44 2010 +0200
Make a4l_find_range() more useful by returning the idx of the most suitable range too.
diff --git a/src/drvlib/analogy/range.c b/src/drvlib/analogy/range.c
index 934c52a..fc4e302 100644
--- a/src/drvlib/analogy/range.c
+++ b/src/drvlib/analogy/range.c
@@ -154,8 +154,9 @@ int a4l_sizeof_subd(a4l_sbinfo_t *subd)
* @param[in] max Maximal limit value
* @param[out] rng Found range
*
- * @return 0 on success. Otherwise:
+ * @return The index of the most suitable range on success. Otherwise:
*
+ * - -ENOENT is returned if a suitable range is not found.
* - -EINVAL is returned if some argument is missing or wrong;
*idx_subd, idx_chan and the dsc pointer should be checked; check
*also the kernel log ("dmesg"); WARNING: a4l_fill_desc() should
@@ -171,10 +172,14 @@ int a4l_find_range(a4l_desc_t * dsc,
int i, ret;
long lmin, lmax;
a4l_chinfo_t *chinfo;
- a4l_rnginfo_t *rnginfo;
+ a4l_rnginfo_t *rnginfo, *tmp = NULL;
+ unsigned int idx_rng = -ENOENT;
+
+ if (rng != NULL)
+ *rng = NULL;
/* Basic checkings */
- if (dsc == NULL || rng == NULL)
+ if (dsc == NULL)
return -EINVAL;
/* a4l_fill_desc() must have been called on this descriptor */
@@ -184,38 +189,39 @@ int a4l_find_range(a4l_desc_t * dsc,
/* Retrieves the ranges count */
ret = a4l_get_chinfo(dsc, idx_subd, idx_chan, &chinfo);
if (ret < 0)
- goto out_get_range;
+ return ret;
/* Initializes variables */
lmin = (long)(min * A4L_RNG_FACTOR);
lmax = (long)(max * A4L_RNG_FACTOR);
- *rng = NULL;
/* Performs the research */
for (i = 0; i < chinfo->nb_rng; i++) {
ret = a4l_get_rnginfo(dsc, idx_subd, idx_chan, i, &rnginfo);
if (ret < 0)
- goto out_get_range;
+ return ret;
if (A4L_RNG_UNIT(rnginfo->flags) == unit &&
rnginfo->min <= lmin && rnginfo->max >= lmax) {
- if (*rng != NULL) {
-if (rnginfo->min >= (*rng)->min &&
-rnginfo->max <= (*rng)->max)
- *rng = rnginfo;
- } else
-*rng = rnginfo;
+ if (tmp != NULL) {
+if (rnginfo->min >= tmp->min &&
+rnginfo->max <= tmp->max) {
+ idx_rng = i;
+ tmp = rnginfo;
+}
+ } else {
+idx_rng = i;
+tmp = rnginfo;
+ }
}
}
-out_get_range:
-
- if (ret < 0)
- *rng = NULL;
+ if (rng != NULL)
+ *rng = tmp;
- return ret;
+ return idx_rng;
}
/**
commit 10dca3a6ae97cff6b2ebf9cf595283ffac94af44
Author: Daniele Nicolodi
Date: Mon Mar 29 22:13:03 2010 +0200
Remove trailing white spaces.
diff --git a/src/drvlib/analogy/range.c b/src/drvlib/analogy/range.c
index fc4e302..51b0405 100644
--- a/src/drvlib/analogy/range.c
+++ b/src/drvlib/analogy/range.c
@@ -130,7 +130,7 @@ int a4l_sizeof_subd(a4l_sbinfo_t *subd)
channels are acquired in one shot); for other kind of
subdevice, the user must use a4l_sizeof_chan() so as to
find out the size of the channel he wants to use */
- if ((subd->flags & A4L_SUBD_TYPES) != A4L_SUBD_DIO &&
+ if ((subd->flags & A4L_SUBD_TYPES) != A4L_SUBD_DIO &&
(subd->flags & A4L_SUBD_TYPES) != A4L_SUBD_DI &&
(subd->flags & A4L_SUBD_TYPES) != A4L_SUBD_DO)
return -EINVAL;
@@ -233,7 +233,7 @@ int a4l_find_range(a4l_desc_t * dsc,
*
* @param[in] chan Channel descriptor
* @param[in] rng Range descriptor
- * @param[out] dst Ouput buffer
+ * @param[out] dst Ouput buffer
* @param[in] src Input buffer
* @param[in] cnt Count of transfer to copy
*
@@ -257,7 +257,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
if (chan == NULL)
return -EINVAL;
- /* Find out the size in memory */
+ /* Find out the size in memory */
size = a4l_sizeof_chan(chan);
/* Get the suitable accessor */
@@ -285,7 +285,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
j++;
}
- return j;
+ return j;
}
/**
@@ -293,7 +293,7 @@ int a4l_rawtoul(a4l_chinfo_t * chan, unsigned long *dst, void *src, int cnt)
*
* @param[in] chan Channel descriptor
* @param[in] rng Range descriptor
- * @param[out] dst Ouput buffer
+ * @param[out] dst Ouput buffer
* @param[in] src Input buffer
* @param[in] cnt Count of conversion to perform
*
@@ -322,7 +322,7 @@ int a4l_rawtof(a4l_chinfo_t * chan,
if (rng == NULL || chan == NULL)
return -EINVAL;
- /* Find out the size in memory */
+ /* Find out the size in memory */
size = a4l_sizeof_chan(chan);
/* Get the suitable accessor */
@@ -366,7 +366,7 @@ int a4l_rawtof(a4l_chinfo_t * chan,
*
* @param[in] chan Ch
Re: [Xenomai-core] [announce] Xenomai v2.5.2
Hi! Gilles Chanteperdrix wrote: > here comes Xenomai v2.5.2, codenamed "Souls Of Distortion" available > from Xenomai download area: > http://download.gna.org/xenomai/stable/xenomai-2.5.2.tar.bz2 Cool, thanks! I'm attaching a patch from Debian. I needed to introduce it because without it, --with-test didn't cause /usr/bin/xeno to access the executables in the specified directory. Thanks for considering! bye, Roland --- xenomai-2.5.2.orig/scripts/xeno.in +++ xenomai-2.5.2/scripts/xeno.in @@ -6,9 +6,6 @@ # e.g. "xeno latency" # -prefix="@prefix@" -exec_prefix="@exec_prefix@" -BINDIR="@bindir@" -unset prefix exec_prefix +XENO_TEST_DIR="@XENO_TEST_DIR@" -exec $BINDIR/$@ +exec $XENO_TEST_DIR/$@ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed
Alexis Berlemont wrote: > Daniele Nicolodi wrote: >> After fixing analogy to permit continuous acquisition, I discovered that >> ongoing commands are not canceled when a device is closed (I obtain a >> DMA buffer owerwrite warning in the kernel log when I abruptly terminate >> my acquisition program). >> >> I think this is quite a surprising behavior. I would expect that the >> commands are canceled when there isn't a data consumer any more. Would >> it be possible to cancel any ongoing command on device close? If there >> is agreement on this, I can look into providing a patch. >> > The close should indeed stop any occurring acquisition. I implemented > this behaviour. It is in my git repository. Hi Alexis. I have been working with analogy from your git three and I should say that the new behavior, in my use case, is worst than the previous. Now, when a device is closed, all accurring acquisition are terminated, also the ones that haven't been started by the current process. While it is possible to use at the same time two different subdevices, from two different processes, now it is not possible to terminate one process and leave the other one running. I think that the correct behavior would be to terminate just the acquisitions started by the current process. However, I have no idea on how difficult this would be. This bring me also to the fact that there isn't currently a way to prevent two concurrent processes to access the same subdevice, interfering each other. Would it possible to have a lock() method, as comedi has? Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Alexis Berlemont wrote: > There is a bug in cmd_write and cmd_read. I have should have taken > into account the buffers edges. I will fix it. The function > a4l_mark_bufrw() is not designed to handle boundaries, that is why its > arguments represent data size not addresses. That makes sense. I can provide a patch for cmd_read and cmd_write, as i got the same kind of code working in my own test programs, but I'm quite busy right now... Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in a4l_get_chan
Alexis Berlemont wrote: > Daniele Nicolodi wrote: >> Hello Alexis, >> >> I found that a4l_get_chan() in buffer.c does not work for subdevices >> that use a global channels description struct (mode = >> A4L_CHAN_GLOBAL_CHANDESC in the a4l_chdesc_t structure). > However, with your accurate description, I think this patch should > solve the problem: Thanks Alexis. Your patch has the same effect as the one I cracked up myself after some head scratching. It is more readable than mine, however my solution avoids the iteration and the multiple checks for A4L_CHAN_GLOBAL_CHANDESC and can be a little more efficient, but i think compiler optimizations should make it a non noticeable difference. Cheers, PS: Looks like free.fr does not like my university SMTP server. I have difficulties in sending mails to your account there. -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
