Re: [Xenomai-core] Analogy/mite
Hi On Thu, Dec 1, 2011 at 4:03 PM, Anders Blomdell anders.blomd...@control.lth.se wrote: On 11/30/2011 07:03 PM, Anders Blomdell wrote: Hi, just found that echo :06:01.0 /sys/bus/pci/drivers/analogy_mite/unbind does not do the same thing as analogy_config -r analogyN in fact it leaves the system in a state where using the driver results in a kernel OOPS. Will try to look into it further tomorrow... OK seems like we have some interrupt cleanup problem, the following command sequence: OK thank you for the report. I did not have time to look at it yet but that will be done soon. Is it blocking for you? Alexis. modprobe xeno_native modprobe analogy_ni_pcimio sleep 1 /usr/local/sbin/analogy_config analogy0 analogy_ni_pcimio 6,1 /usr/local/sbin/analogy_config -r analogy0 rmmod analogy_ni_pcimio rmmod analogy_ni_mio rmmod analogy_ni_tio rmmod analogy_8255 rmmod analogy_ni_mite rmmod xeno_analogy sleep 2 modprobe xeno_native modprobe analogy_ni_pcimio sleep 1 /usr/local/sbin/analogy_config analogy0 analogy_ni_pcimio 6,1 Gives: [ 412.623639] Analogy: MITE: Available NI device IDs: 0x70af [ 413.648335] Analogy: analogy_ni_pcimio: pcimio_attach: found pci-6221 board [ 413.676105] Analogy: analogy_ni_pcimio: pcimio_attach: found irq 22 [ 413.682385] BUG: unable to handle kernel paging request at f8bc4bf4 [ 413.683367] IP: [f8846efe] xnintr_attach+0x6e/0xfe [xeno_nucleus] [ 413.683367] *pdpt = 00aca001 *pde = 31ca5067 *pte = [ 413.683367] Oops: [#1] SMP [ 413.683367] last sysfs file: /sys/bus/pci/drivers/analogy_mite/uevent [ 413.683367] Modules linked in: analogy_ni_pcimio analogy_ni_mio analogy_ni_tio analogy_8255 analogy_ni_mite xeno_analogy xeno_native nfs fscache snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore rt_e1000 rt_e1000_new rtnet xeno_rtdm nfsd lockd nfs_acl auth_rpcgss xeno_nucleus snd_page_alloc ppdev iTCO_wdt iTCO_vendor_support microcode sunrpc exportfs i2c_i801 pcspkr serio_raw e1000e parport_pc parport uinput ipv6 firewire_ohci firewire_core ata_generic pata_acpi crc_itu_t pata_marvell i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: xeno_analogy] [ 413.683367] [ 413.683367] Pid: 1579, comm: analogy_config Not tainted 2.6.38.8.xenomai.2.6.0.rtnet.26db745.2030.1211 #1 /DG965SS [ 413.683367] EIP: 0060:[f8846efe] EFLAGS: 00010286 CPU: 1 [ 413.683367] EIP is at xnintr_attach+0x6e/0xfe [xeno_nucleus] [ 413.683367] EAX: f8bc4be4 EBX: f87d2be4 ECX: 0001 EDX: 0003 [ 413.683367] ESI: f885b840 EDI: fff0 EBP: f169ddf4 ESP: f169dde0 [ 413.683367] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 413.683367] Process analogy_config (pid: 1579, ti=f169c000 task=f40925e0 task.ti=f169c000) [ 413.683367] I-pipe domain Linux [ 413.683367] Stack: [ 413.683367] 205bde08 0001 f87d2be4 0001 f169de10 f89a0c91 f87cea28 [ 413.683367] 0001 f87d2bd8 f169de28 f87ceb64 0001 f87d134f [ 413.683367] f87d2bd8 f87d2bb8 f169de44 f87cf727 0001 f87d2bb8 0016 f87d2bb8 [ 413.683367] Call Trace: [ 413.683367] [f89a0c91] rtdm_irq_request+0x37/0x5a [xeno_rtdm] [ 413.683367] [f87cea28] ? a4l_handle_irq+0x0/0x1f [xeno_analogy] [ 413.683367] [f87ceb64] __a4l_request_irq+0x38/0x3e [xeno_analogy] [ 413.683367] [f87cf727] a4l_request_irq+0x67/0xad [xeno_analogy] [ 413.683367] [f86b1593] pcimio_attach+0x4e0/0x53e [analogy_ni_pcimio] [ 413.683367] [f87cde93] a4l_assign_driver+0x73/0x100 [xeno_analogy] [ 413.683367] [f87cdfd9] a4l_device_attach+0x59/0x6e [xeno_analogy] [ 413.683367] [f87ce0d7] a4l_ioctl_devcfg+0xbd/0xf6 [xeno_analogy] [ 413.683367] [f87cf943] a4l_ioctl+0x1e/0x20 [xeno_analogy] [ 413.683367] [f899fa5a] __rt_dev_ioctl+0x4d/0x104 [xeno_rtdm] [ 413.683367] [c07c35b6] ? do_page_fault+0x2f7/0x322 [ 413.683367] [f89a1a85] sys_rtdm_ioctl+0x2e/0x30 [xeno_rtdm] [ 413.683367] [f8851414] losyscall_event+0xb1/0x174 [xeno_nucleus] [ 413.683367] [c04887ab] __ipipe_dispatch_event+0xcb/0x17a [ 413.683367] [f8851363] ? losyscall_event+0x0/0x174 [xeno_nucleus] [ 413.683367] [c0415b32] __ipipe_syscall_root+0x50/0xc9 [ 413.683367] [c07c0a21] system_call+0x2d/0x53 [ 413.683367] Code: 00 e8 73 ff ff ff 8b 4b 10 f7 c1 00 00 01 00 89 45 f0 0f 85 92 00 00 00 8b 73 14 c1 e6 06 81 c6 c0 b2 85 f8 8b 46 24 85 c0 74 25 8b 50 10 89 ce 21 d6 83 e6 01 74 73 8b 73 18 39 70 18 75 6b 31 [ 413.683367] EIP: [f8846efe] xnintr_attach+0x6e/0xfe [xeno_nucleus] SS:ESP 0068:f169dde0 [ 413.683367] CR2: f8bc4bf4 /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden
Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t
Hi, On Tue, Oct 4, 2011 at 3:31 PM, Daniele Nicolodi dani...@grinta.net wrote: On 04/10/11 13:17, Gilles Chanteperdrix wrote: If you want things merged, send the patches, they will reach xenomai-head repository through Alex. Of course. Here is my simple patch. Thanks. Thank you. Cheers, -- Daniele Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO data acquisition with NI6259
Hi, On Wed, Sep 14, 2011 at 5:38 AM, Stefan Schaal ssch...@usc.edu wrote: This is a summary and conclusion of using a NI6259 with Xenomai/Analogy for digital data I/O. First of all, many thanks to Alexis whose Analogy branch really allowed us to succeed! We would just like share the final results of our implementation with the hope that this might help others. Goals: We needed a 19 bit parallel I/O for bi-directional communication between a host computer and a robot controller. The 32bit DIO of the NI6259 seemed to well suited. The communication protocol needs about 300 DIO commands per ms, where every about 20 commands the DIO port needs to switch from write to read and then back. Problems: Initially we tried a4l_sync_dio() (synchronous communication). We measured that one a4l_sync_dio() takes about 5us. Additionally, the switch from read to write mode also seems to take some additional time. Thus, the communication speed was not sufficient. A 2nd attempt was to use instructions and instruction lists using a4l_snd_insnlist() and a4l_snd_insn(). We measure that this can bring down one data acquisition to about 3.5us when all commands are queued up in an instruction list, but due to the read/write switch we needed, we cannot use very long instruction lists, and the read/write switch takes too long. Thus, the communication speed did not improve a lot. A 3rd attempt was to use CMD structures. Following comedi examples, we create a 200ns clock and triggered the CMD streaming with this clock. This allows VERY fast DIO. But, again, the read/write switches that are needed frequently made CMD structures inefficient as we could not cue up a lot of DIO commands before the next read/write switch, and in order to do the read/write switch, the CMD has to be aborted. We also noted that starting a CMD has some delays. We realized that none of these approaches was feasible. Solution: We create a simple IC-based circuit that allowed to branch the read/write DIO protocol such that we could use one DIO channel of the NI6259 for write only (never switched to read), and the 2nd DIO channel on the NI6259 for read only (no switching). By avoiding the read/write switching, all three ideas from above are possible and run fast enough (after some optimization of our communication protocol). We ended up using a4l_sync_dio() as it is the easiest to use, and yielded sufficient speed. With the CMD approach, we would be able to go a factor 5-10 faster even. For you info, our interface C-code is attached. This is not general purpose software, but should allow other to get the idea of what we do. Many thanks for this feedback! Best wishes, and thanks again to Alexis! -Stefan Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] PULL REQUEST: analogy
The following changes since commit fa167ed2f2d9ce569968d801796f7e760772e97b: doc: regenerate (2011-09-04 21:48:41 +0200) are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (28): analogy: add first version of waveform generation analogy: rename waveform files analogy: minor changes analogy: add wf_generate tool analogy: add verbose output in wf_generate tool analogy: add a 1st version of wf_cmd_write analogy: 1st rework of fake driver analogy: [fake] minor fix in attach parameters handling analogy: [fake] validate the looping feature analogy: minor fix in wf_generate analogy: [fake] add instruction callbacks for the loop subdevices analogy: [loop] remove the driver analogy: [fake] correctly manage EOA events for loop subdevices analogy: minor change in cmd_read.c analogy: various basic bug fixes in wf_cmd_write analogy: minor cosmetic changes in wf_facilities.c analogy: [fake] fix synchronization bugs at cancel time analogy: minor change in the test program wf_cmd_write analogy: add signal injection in the cmd_write tool analogy: implement the configuration of a wake-up threshold analogy: update cmd_read and cmd_write with a wake-count option analogy: [ni_660x] replace spin_lock_* calls by al4_lock_* calls analogy: [pcimio] minor cosmetic change analogy: [ni_660x] review indentation analogy: [ni_660x] review coding style and traces analogy: [ni_670x] review coding style analogy: [ni_660x] remove useless headers analogy: [ni_670x] replace printk calls by a4l_[err,info] calls Anders Blomdell (2): analogy: fix duplicate symbols analogy: [pcimio] fix wrong IRQ setup after reboot Julien Delange (1): analogy: integrate the drivers ni_660x and ni_670x. include/analogy/analogy.h | 80 +- include/analogy/buffer.h | 23 + include/analogy/channel_range.h| 16 +- include/analogy/ioctl.h|7 +- ksrc/drivers/analogy/buffer.c | 86 +- ksrc/drivers/analogy/driver_facilities.c | 12 +- ksrc/drivers/analogy/intel/8255.c | 10 +- ksrc/drivers/analogy/intel/8255.h |8 +- ksrc/drivers/analogy/national_instruments/Kconfig | 18 + ksrc/drivers/analogy/national_instruments/Makefile |6 + .../analogy/national_instruments/mio_common.c | 152 +- ksrc/drivers/analogy/national_instruments/mite.c | 164 ++- ksrc/drivers/analogy/national_instruments/mite.h | 51 +- .../drivers/analogy/national_instruments/ni_660x.c | 1485 .../drivers/analogy/national_instruments/ni_670x.c | 446 ++ ksrc/drivers/analogy/national_instruments/ni_mio.h | 18 +- ksrc/drivers/analogy/national_instruments/ni_tio.h | 28 +- ksrc/drivers/analogy/national_instruments/pcimio.c | 70 +- .../analogy/national_instruments/tio_common.c | 82 +- ksrc/drivers/analogy/rtdm_interface.c |8 +- ksrc/drivers/analogy/sensoray/s526.c |4 +- ksrc/drivers/analogy/subdevice.c | 14 +- ksrc/drivers/analogy/testing/Config.in |1 - ksrc/drivers/analogy/testing/Kconfig | 11 +- ksrc/drivers/analogy/testing/Makefile | 11 +- ksrc/drivers/analogy/testing/fake.c| 427 +- ksrc/drivers/analogy/testing/loop.c| 287 src/drvlib/analogy/async.c | 31 + src/utils/analogy/Makefile.am | 18 +- src/utils/analogy/cmd_read.c | 24 +- src/utils/analogy/cmd_write.c | 721 ++ src/utils/analogy/wf_facilities.c | 158 +++ src/utils/analogy/wf_facilities.h | 36 + src/utils/analogy/wf_generate.c| 252 34 files changed, 3719 insertions(+), 1046 deletions(-) create mode 100644 ksrc/drivers/analogy/national_instruments/ni_660x.c create mode 100644 ksrc/drivers/analogy/national_instruments/ni_670x.c delete mode 100644 ksrc/drivers/analogy/testing/loop.c create mode 100644 src/utils/analogy/wf_facilities.c create mode 100644 src/utils/analogy/wf_facilities.h Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai 2.6.0, or -rc1?
Hi, On Fri, Aug 26, 2011 at 2:34 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: Hi, I think it is about time we release Xenomai 2.6.0. Has anyone anything pending (maybe Alex)? Should we release an -rc first? Yes. in my experimental branch, I have a few things which are not that experimental. I would like to push: - a first version of Julien Delange's ni_660x driver - Anders Blomdell's fix on duplicate sympbols with comedi - Anders Blomdell's fix in pcimio driver (wrong IRQ number after reboot) - some waveform generation tools (fully generic) - an overhaul of the testing drivers (fake + loop = fake) I will integrate them in my analogy branch and send a pull request if you are OK with that. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANALOGY] ni660x and ni670x : patch and examples
Hi, Sorry for the late reply, I just came back from holidays. On Wed, Aug 3, 2011 at 2:18 PM, Julien Delange julien.dela...@gmail.com wrote: Dear all, Please find a patch for the support of ni660x and ni670x in the analogy layer. The driver works fine and I tested it. I enclosed test programs with my mail. The test program for the 660x use the counters and the one for the 670x board use the analogy output function. These programs can be included in the tests/demo programs from Xenomai, as you want. Many thanks, this is a great contribution! So far, I just had time to have a look at your first patch (patch-xenomai-current.diff.gz). I just have a few remarks before merging it: - You modified few lines in some analogy core source files (instruction.c, subdevice.c). The changes are just coding style modifications. However, the original lines seem to already comply with the kernel coding guidelines. - In ni_660x.c:ni_660x_attach(), there is a call to Linux's request_irq() function, the interrupt will not be handled in Xenomai's domain but by the Linux kernel. You should use a4l_request_irq() instead (this is just a wrapper around the appropriate RTDM service). Thus, that would be ok with the call to a4l_free_irq() in ni_660x_detach(). - In ni_670x.c, there is a call to a4l_free_irq() in the detach function but no call to a4l_request_irq() in the attach function. - A last detail: it seems that some parts of your code does not comply with kernel's coding style (ex.: if statements and their associated brackets, 80 columns) I will also try to add/update the documentation according to the information needed by these drivers. Many thanks in advance. Please tell me if this patch can be integrated in the Xenomai distribution. If there is any problem/issue, just let me know how I can fix that. Unfortunately, I cannot make a patch against the latest git revision because I cannot make a checkout : the firewall checks the http request content and I cannot make a checkout of a source repository, even if it provides http access ... sorry for that inconvenience. On the other hand, I don't think there was too many upgrade in the directory I modified so that this patch might be easily merged with the current tree. Indeed. Hope this might be helpful, Best regards, ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ 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] [PULL REQUEST] analogy: bug fixes in buffer size config
The following changes since commit c0993894a7ab56d9c3f5444e90e68602673288de: 16550A: Disable PCI configuration option for platforms without PCI (2011-01-08 01:05:02 +0100) are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (5): analogy: fix the default size of the buffer analogy: [pcimio] minor fix in log messages analogy: implement configuration of buffer default size analogy: add a sys function for the ioctl BUFCONFIG analogy: add buffer configuration facility in analogy_config include/analogy/analogy.h|2 + include/analogy/buffer.h |8 + include/analogy/transfer.h |3 + include/analogy/types.h |4 +- ksrc/drivers/analogy/buffer.c| 17 +- ksrc/drivers/analogy/national_instruments/mite.c |2 +- ksrc/drivers/analogy/rtdm_interface.c| 10 +- ksrc/drivers/analogy/transfer.c |4 + src/drvlib/analogy/async.c |9 +- src/drvlib/analogy/sys.c | 33 +++ src/utils/analogy/analogy_config.c | 241 ++ 11 files changed, 223 insertions(+), 110 deletions(-) -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] CMD based acquisition with Analogy
Hi,
Stefan Schaal wrote:
Hi Alexis,
here is an observation with CMD-based acquisition that puzzles
me. Just to recall, we use an NI6259 board, using your latest
analogy branch of xenomai on a 2.6.29.5 kernel in Ubuntu 9.10. Our
computer is a 32bit Dell Precision with 8 core Xeon processors.
A normal CMD based acquisition with internal trigger has the core
elements as listed below. What puzzles me that it appears from my
tests that the triggering of the acquisition with
a4l_snd_insn(desc, insn) seems to take about 200-300 us to
complete. This is a very long time for us, as we need to start and
stop a CMD based acquisition multiple times in our code.
Thus, my question is simply whether this long latency is normal from
your experience? I used other a4l_snd_insn commands for INSN based
data acquisition before (and I believe your sync data acquisition
uses INSN, too), but always had 3-5us duration for these commands.
Just on testing purpose, if you replace the NI driver with the
analogy_fake driver, I think you will be unable to reproduce such high
latencies...
The latencies you have noticed are waiting periods during which the CPU
has to wait for DMA buffer to be (half-)filled before triggering the
output acquisition. That's a way to prevent buffer underflow.
As you may know, the NI driver was ported from Comedi; I have noticed
this issue but did not fix it yet. In a nice world, the CPU should be
notified, thanks to an interrupt, when the DMA FIFO is in the suitable
state. Unfortunately, I remember this alternative was not
possible. The best I can do is to use an RTDM task so as to
asynchronously wait for the event.
Best wishes,
-Stefan
//
// fill out data structures
a4l_cmd_t cmd = {
.idx_subd = ID_SUBDEV_DIGITAL,
.flags = 0,
.start_src = TRIG_INT,// internal trigger
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = NI_CDIO_SCAN_BEGIN_SRC_G0_OUT, // channel used to
trigger the scans
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 32,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 32,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = ID_SUBDEV_DIGITAL,
.data_size = 0,
};
// send command
rc = a4l_snd_command(desc, cmd);
if (rc 0)
printf(ni_test: a4l_snd_command failed (ret=%d)\n, rc);
}
// add some date to FIFO buffer
// trigger acquisition
rc = a4l_snd_insn(desc, insn);
if (rc 0)
printf(ni_test: triggering failed (rc=%d)\n,rc);
//
--
Alexis.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO data acquisition
Hi, Sorry for the late reply. Happy new Year!!! Stefan Schaal wrote: Hi Alexis, I was wondering whether you could help me with some information about CMD based data acquisition in analogy. You might recall from previous emails with you, we are trying to implement high speed data DIO communication with a NI6259 board. We use the CMD structure to create a periodic task, that is clocked by a timer, to achieve the required communication speed. As we need to change the R/W polarity on some channels every 20-30 scans, we need essentially to find out when the data in the communication buffer are consumed, such that we change polarity and trigger the next set of acquisitions. Currently, working with the MMAP options seems to be the best way of handling this. I just had some questions concerning how to detect when the data are consumed. It appears that the periodic task is automatically canceled when a DMA underun is discovered (as can be checked with dmesg). Is this automatic canceling behavior the officially correct behavior? I can use a4l_poll to find out how much data is left in the communication buffer --- I noticed that it returns -EPIPE when the data buffer has been consumed, which also seems to indicate that the periodic task has been canceled. (So for, the -EPIPE return code is not documented in Analogy). In my TODO list, there is something which might satisfy your needs. Once, someone asked for getting awoken only when a specific amount of data has been made available by an input subdevice. Gilles proposed the use of a specific ioctl to configure a wake-up threshold. I kept his idea and put it in my list. I just have not found the time to implement it yet. I think this ioctl could suit your needs because it could work for both input and output asynchronous subdevices. If you want to implement it, you are more than welcome. Or else, I am currently finishing something D. Nicolodi proposed a few month ago and I will implement just after (the counting subdevices will wait a little bit more). At first sight, I think this task should be feasible quite quickly; the poll ioctl handler just has to be rewritten. I am running your latest Analogy branch. Be careful, the wf_* tools are not complete. I was just wondering whether my observations are correct, and that it makes sense to develop more communication code by using this behavior of Analogy. Best wishes, and Happy Holidays! -Stefan -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy regressions in xenomai 2.5.5.1
Hi, Do not worry. I have not forgotten. On Fri, Oct 15, 2010 at 11:16 AM, Daniele Nicolodi dani...@grinta.net wrote: Hi Alexis, do you have the possibility to look at those bugs soonish? Otherwise I can try to fix them, but I would need some hints on where I should look in the code. Thank you. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: bugfixes
The following changes since commit 9d70c373eee0ac43a1b5869600e33ec6bff89868: rtcan: Mask the SJA_MOD register when probing for channels (2010-09-16 20:43:34 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (9): analogy: minor change in analogy Kconfig text analogy: add comments in the buffer management code analogy: fix a bug in the DIO subdevice's mite configuration analogy: minor changes in cmd_bits analogy: comsetic change in mite.c analogy: [pcimio] rework the mite setup procedures analogy: [pcimio] fix a forgotten warning analogy: [pcimio] add the initialization of the ring for gpct subd analogy: fix compilation warnings with gcc-4.4.1 include/analogy/buffer.h | 52 ++- ksrc/drivers/analogy/Kconfig |2 +- ksrc/drivers/analogy/buffer.c | 23 +++- .../analogy/national_instruments/mio_common.c | 155 +--- ksrc/drivers/analogy/national_instruments/mite.c |4 +- src/drvlib/analogy/sync.c | 44 -- src/utils/analogy/cmd_bits.c |6 +- src/utils/analogy/insn_bits.c |9 +- 8 files changed, 213 insertions(+), 82 deletions(-) -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, On Wed, Sep 8, 2010 at 4:30 PM, Stefan Schaal ssch...@usc.edu wrote: Hi Alexis, sorry for my late reply -- I was traveling. Essentially, in my DIO communication, I need to switch some DIO channels from READ to WRITE after several scans, and than back. This is why the stop argument would be very useful. Also, currently in the cmd_bits test program, one gets a lot messages from dmesg: [1325379.753432] Analogy: MITE: DMA underrun which comes, I guess, from not continuously filling the FIFO buffer with data. I will try to look through comedi and the NI documentation what register might have the counting information. The needed documentation is the register level programing manual for M series. The registers related with asynchronous DIO acquisition are not defined in the DAQ documentation. Best wishes, -Stefan Alexis. On Sep 4, 2010, at 14:45, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, we are making great progress with our work. One issue that came up is whether it would be possible to add .stop_src = TRIG_COUNT, .stop_arg = n, in the command structure, i.e., that the command terminates after n scans. Currently, when I try this, dmesg tells me that this method is not supported. I don't have the documentation of the CDIO registers; so, I dont' know how to tell the subdevice to stop after having sent a specified amount of data. However, analogy stops an acquisition when the stop_arg of the command structure has been reached. We would be able to cancel the acquisition after having sent _at_ _least_ the specified amount but we would not be able to accurately send the specified amount of data. I think we should firstly get the proper documentation. I will try to have a look at the open source code delivered by NI. Best wishes, -Stefan On Aug 23, 2010, at 23:49, Stefan Schaal wrote: Hi Alexis, amazing progress!! And it works! I just ran my test program on our NI6259 board and got perfect performance. I quickly tested 5MHz DIO rate, and it appeared to work fine according to the square waves on the oscilloscope. I will go back to developing our DAQ interface, and report back to the Xenomai list about performance. Thanks so much Best wishes, -Stefan On Aug 23, 2010, at 16:09, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions: 1) I tried CR_INVERT -- no success 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all? 4) I have my own test program to send alternating 0x and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed. At last, it comes!!! Thanks to your test program and your help, I think I have fixed this bug. Could you clone my git repository (branch analogy), and give it a try with your own test program. There was a bug in the mite configuration which explained why the wrong data were sent to the DIO subdevice. That was also the reason why no interrupt came from the mite. Best wishes, -Stefan On Jul 19, 2010, at 15:01, Alexis Berlemont wrote: Hi, Sorry for answering late. Stefan Schaal wrote: Hi Alexis, I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up). Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file). When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition. In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, we are making great progress with our work. One issue that came up is whether it would be possible to add .stop_src = TRIG_COUNT, .stop_arg = n, in the command structure, i.e., that the command terminates after n scans. Currently, when I try this, dmesg tells me that this method is not supported. I don't have the documentation of the CDIO registers; so, I dont' know how to tell the subdevice to stop after having sent a specified amount of data. However, analogy stops an acquisition when the stop_arg of the command structure has been reached. We would be able to cancel the acquisition after having sent _at_ _least_ the specified amount but we would not be able to accurately send the specified amount of data. I think we should firstly get the proper documentation. I will try to have a look at the open source code delivered by NI. Best wishes, -Stefan On Aug 23, 2010, at 23:49, Stefan Schaal wrote: Hi Alexis, amazing progress!! And it works! I just ran my test program on our NI6259 board and got perfect performance. I quickly tested 5MHz DIO rate, and it appeared to work fine according to the square waves on the oscilloscope. I will go back to developing our DAQ interface, and report back to the Xenomai list about performance. Thanks so much Best wishes, -Stefan On Aug 23, 2010, at 16:09, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions: 1) I tried CR_INVERT -- no success 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all? 4) I have my own test program to send alternating 0x and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed. At last, it comes!!! Thanks to your test program and your help, I think I have fixed this bug. Could you clone my git repository (branch analogy), and give it a try with your own test program. There was a bug in the mite configuration which explained why the wrong data were sent to the DIO subdevice. That was also the reason why no interrupt came from the mite. Best wishes, -Stefan On Jul 19, 2010, at 15:01, Alexis Berlemont wrote: Hi, Sorry for answering late. Stefan Schaal wrote: Hi Alexis, I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up). Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file). When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition. In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help. Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code). Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board. I had time to have a look at your problem. Unfortunately, I do not have any solution. I just have some questions you may find stupid: - Did you try to invert the sample clock polarity by setting the flag CR_INVERT in the command field scan_begin_arg? - Which frequencies did you generate with the counter subdevice? Even the lowest
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, as usually, we are more than grateful that you are willing to spend time on this issue. Here are answers to your questions: 1) I tried CR_INVERT -- no success 2) I tried very slow frequencies like 10Hz in the counter clock (which is nicely visualized on my oscilloscope) -- no success 3) I tried to send a 0 with cmd_bits -- and interestingly, this ALSO takes my DIO line high (sorry, I thought I had tested this before). This would indicate that we do not access the FIFO at all? 4) I have my own test program to send alternating 0x and 0x0 values to the devices to generate a square wave on the oscilloscope. I cannot see anything of the square wave executed. At last, it comes!!! Thanks to your test program and your help, I think I have fixed this bug. Could you clone my git repository (branch analogy), and give it a try with your own test program. There was a bug in the mite configuration which explained why the wrong data were sent to the DIO subdevice. That was also the reason why no interrupt came from the mite. Best wishes, -Stefan On Jul 19, 2010, at 15:01, Alexis Berlemont wrote: Hi, Sorry for answering late. Stefan Schaal wrote: Hi Alexis, I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up). Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file). When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition. In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help. Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code). Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board. I had time to have a look at your problem. Unfortunately, I do not have any solution. I just have some questions you may find stupid: - Did you try to invert the sample clock polarity by setting the flag CR_INVERT in the command field scan_begin_arg? - Which frequencies did you generate with the counter subdevice? Even the lowest one did nothing (Something like 10Hz)? - Did you try to send 0 with cmd_bits ? Just to check that the DO stay to LOW, which would mean that the values (or at least the first one) are properly loaded into the device. - So far, cmd_bits always sends the same value (the one you passed as argument); we should modify it so that the complement value is written every two samples. That would allow us to physically check how many samples are played by the DO. Best wishes, -Stefan On Jul 14, 2010, at 17:46, Stefan Schaal wrote: Hi Alexis, in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal kCDO_Update_Source_SelectG0_Out= 28 from the enum you found in the NI documentation. For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality. Or, do you happen to know whether there is another, easier to access, clock source? Best wishes, -Stefan On Jul 14, 2010, at 14:03, Alexis Berlemont wrote: Stefan Schaal wrote: Hi
Re: [Xenomai-core] analogy - experimental branch
Hi, Sorry for answering late. Stefan Schaal wrote: Hi Alexis, I managed to port some of the Comedi examples to Analogy. In particular, I could configure one of my counter subdevices to become a high frequency clock, following the gpct_pulse_generator.c example. I routed the output of the clock to my PFI0 pin, and could visualize the signal on an oscilloscope. Thus, I know have the clock I need to trigger CMD-based DIO, as you suggested. (I will post some sample code of this in the near future after all is cleaned up). Next, I went back to cmd_bits.c and try to make it work on my NI6259 board. For scan_begin_src=TRIG_EXT I need to choose scan_begin_arg = 28 (which is kCDO_Update_Source_SelectG0_Out in the NI documentation, and NI_CDIO_SCAN_BEGIN_SRC_G0_OUT in the comedi.h file). When running cmd_bits.c in this way and monitoring the DO channels on an oscilloscope, the DO switches to HIGH when the acquisition is triggered (i.e., the value of the first element in the FIFO), but the FIFO is not processed any further, i.e., not emptied. If I DO NOT run the counter-clock above, the DO does not even switch to HIGH. I also checked whether 28 is the right value for scan_begin_arg by trying a wide range of values, but only for scan_begin_arg = 28 I get the DO bit switched to HIGH at the beginning of the acquisition. In Comedi, the cmd.flags is set to CMDF_WRITE for such externally triggered acquisitions, which I tried, but it did not help. Thus, it appears that I still have a problem in processing the FIFO, despite it appears that all other things are now correctly connected (Comedi has an example do_waveform.c, which is pretty much what I try to use for testing in my own code). Would you have any thoughts on what might go wrong? It looks like we are just a tiny bit away from succeeding with cmd_bits.c on my board. I had time to have a look at your problem. Unfortunately, I do not have any solution. I just have some questions you may find stupid: - Did you try to invert the sample clock polarity by setting the flag CR_INVERT in the command field scan_begin_arg? - Which frequencies did you generate with the counter subdevice? Even the lowest one did nothing (Something like 10Hz)? - Did you try to send 0 with cmd_bits ? Just to check that the DO stay to LOW, which would mean that the values (or at least the first one) are properly loaded into the device. - So far, cmd_bits always sends the same value (the one you passed as argument); we should modify it so that the complement value is written every two samples. That would allow us to physically check how many samples are played by the DO. Best wishes, -Stefan On Jul 14, 2010, at 17:46, Stefan Schaal wrote: Hi Alexis, in the Comedi examples (http://www.comedi.org/download/comedilib-0.8.1.tar.gz, the do_waveform.c example), they suggest to use a general purpose counter as clocking input to a cmd-based DIO acquisition. This seems to be the signal kCDO_Update_Source_SelectG0_Out= 28 from the enum you found in the NI documentation. For this purpose, the counter needs to be configured and triggered. Does Analogy already have the functionality to do such operations? The Comedi libraries have an example for this, too, in gpct_pulse_generator.c, just that this example uses a variety of function calls that I cannot directly map to the current Analogy functionality. Or, do you happen to know whether there is another, easier to access, clock source? Best wishes, -Stefan On Jul 14, 2010, at 14:03, Alexis Berlemont wrote: Stefan Schaal wrote: Hi Alexis, maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259. My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO. Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice. Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality? Right now, I don't know. I think your idea of using DIO commands may be suitable (I don't know your timing constraints). So what not proceeding ? Thanks a lot! -Stefan On Jul 12, 2010, at 22:51, Stefan Schaal wrote
Re: [Xenomai-core] analogy - experimental branch
Stefan Schaal wrote: Hi Alexis, thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O? The analog output subdevice has its own sampling source. That is why, according to the command API logic, TRIG_TIMER is appropriate. It indicates that the scans are triggered by a periodic timer delivered by the analog output subsystem. Best wishes, -Stefan On Jul 12, 2010, at 15:29, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, I guess I slowly understand that my clocking signal connected to scan_begin_arg has to come from an external DIO input, if scan_bigin_src = TRIG_EXT, and that the insn instruction is still needed to trigger the entire acquisition. Yes. The trigger instruction is needed so as to start the whole acquisition (which is composed of many scans). A periodic external signal is needed so as to trigger each scan. Alternatively, would it be possible to use the internal clocking signals like scan_bigin_src = TRIG_FOLLOW or scan_bigin_src = TRIG_TIMER I think you are right. If the sampling clock comes from another subdevice, TRIG_EXT may not be the most appropriate constant. However, the original comedi driver only expects TRIG_EXT even if... the sampling signal is not external. TRIG_TIMER does not seem suitable because it assumes an independant sampling clock is available. And TRIG_FOLLOW may be the most appropriate one. We should modify the driver so that TRIG_FOLLOW is used if the analog sampling clock is chosen. if I try any of these sources, I get an error -22, and dmesg reports: [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported For me, the command interface is an empty shell because the various parameters (start_src, scan_begin_src, ...) and the values (TRIG_*) are imposed. And, on the other side, the driver is fully in charge of the command structure as it is. So, the comedi command imposes a communication method but does not ease the driver's task of managing it (errors checking, translation, etc.) And, in our case: DIO, we may conclude that this imposed API does not fit well: in scan_begin_arg, we have to pass an index which is supposed to correspond to some sampling clock (which is specific to a board). Then, we use a generic interface with board-specific arguments. So, to sum up, I understand your point: the way we control the driver may not always be the most appropriate one. But, we inherited from comedi both the interface and the drivers. On my side, I am working on trying to implement (as a background task) a generic interface a little bit more based on discovery (query / enum) that would render the command interface obsolete. Unfortunately, I have nothing interesting to show yet. Best wishes, -STefan -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Stefan Schaal wrote: Hi Alexis, maybe it is more useful to mention what I actually want to achieve with DIO on my NI6259. My DIO communication involves a series of interactions with another board to collect sensory data from a robot, and to send out commands to this board. For instance, to read one of the sensors, a sequence of DIO values need to be written to tell the board to send the data. I programmed this initially with synchronous instructions using a4l_sync_dio(), but this turns out to be too slow. Thus, the hope is to use commands, i.e., fill the FIFO with the sequence of values which I need to execute, and then use asynchronous DIO to obtain much higher speed of communicating the values in the FIFO. Thus, what I essentially try to do is to put about 10-20 scans in the FIFO, and then write the FIFO as fast as possible to my NI6259 DIO subdevice. Would you have any ideas how to do this fast writing of the scans in the FIFO with the current analogy functionality? Right now, I don't know. I think your idea of using DIO commands may be suitable (I don't know your timing constraints). So what not proceeding ? Thanks a lot! -Stefan On Jul 12, 2010, at 22:51, Stefan Schaal wrote: Hi Alexis, thanks a lot for the explanations. One item I am confused about is that you write that TRIG_TIMER is not suitable for DIO, but in cmd_write.c in your sample code, it is used for the analog write without problems. Wouldn't one be able to just use the same clock source for DIO as in analogue I/O? Best wishes, -Stefan On Jul 12, 2010, at 15:29, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, I guess I slowly understand that my clocking signal connected to scan_begin_arg has to come from an external DIO input, if scan_bigin_src = TRIG_EXT, and that the insn instruction is still needed to trigger the entire acquisition. Yes. The trigger instruction is needed so as to start the whole acquisition (which is composed of many scans). A periodic external signal is needed so as to trigger each scan. Alternatively, would it be possible to use the internal clocking signals like scan_bigin_src = TRIG_FOLLOW or scan_bigin_src = TRIG_TIMER I think you are right. If the sampling clock comes from another subdevice, TRIG_EXT may not be the most appropriate constant. However, the original comedi driver only expects TRIG_EXT even if... the sampling signal is not external. TRIG_TIMER does not seem suitable because it assumes an independant sampling clock is available. And TRIG_FOLLOW may be the most appropriate one. We should modify the driver so that TRIG_FOLLOW is used if the analog sampling clock is chosen. if I try any of these sources, I get an error -22, and dmesg reports: [195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported For me, the command interface is an empty shell because the various parameters (start_src, scan_begin_src, ...) and the values (TRIG_*) are imposed. And, on the other side, the driver is fully in charge of the command structure as it is. So, the comedi command imposes a communication method but does not ease the driver's task of managing it (errors checking, translation, etc.) And, in our case: DIO, we may conclude that this imposed API does not fit well: in scan_begin_arg, we have to pass an index which is supposed to correspond to some sampling clock (which is specific to a board). Then, we use a generic interface with board-specific arguments. So, to sum up, I understand your point: the way we control the driver may not always be the most appropriate one. But, we inherited from comedi both the interface and the drivers. On my side, I am working on trying to implement (as a background task) a generic interface a little bit more based on discovery (query / enum) that would render the command interface obsolete. Unfortunately, I have nothing interesting to show yet. Best wishes, -STefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi,
Stefan Schaal wrote:
Hi Alexis,
I guess I slowly understand that my clocking signal connected to
scan_begin_arg has to come from an external DIO input, if
scan_bigin_src = TRIG_EXT, and that the insn instruction is still
needed to trigger the entire acquisition.
Yes. The trigger instruction is needed so as to start the whole
acquisition (which is composed of many scans). A periodic external
signal is needed so as to trigger each scan.
Alternatively, would it be possible to use the internal clocking signals
like
scan_bigin_src = TRIG_FOLLOW
or
scan_bigin_src = TRIG_TIMER
I think you are right. If the sampling clock comes from another
subdevice, TRIG_EXT may not be the most appropriate constant. However,
the original comedi driver only expects TRIG_EXT even if... the
sampling signal is not external.
TRIG_TIMER does not seem suitable because it assumes an independant
sampling clock is available.
And TRIG_FOLLOW may be the most appropriate one. We should modify the
driver so that TRIG_FOLLOW is used if the analog sampling clock is
chosen.
if I try any of these sources, I get an error -22, and dmesg reports:
[195882.321300] Analogy: a4l_check_cmddesc: scan_begin_src, trigger
unsupported
For me, the command interface is an empty shell because the various
parameters (start_src, scan_begin_src, ...) and the values (TRIG_*)
are imposed. And, on the other side, the driver is fully in charge of
the command structure as it is. So, the comedi command imposes a
communication method but does not ease the driver's task of managing
it (errors checking, translation, etc.)
And, in our case: DIO, we may conclude that this imposed API does not
fit well: in scan_begin_arg, we have to pass an index which is
supposed to correspond to some sampling clock (which is specific to a
board). Then, we use a generic interface with board-specific
arguments.
So, to sum up, I understand your point: the way we control the driver
may not always be the most appropriate one. But, we inherited from
comedi both the interface and the drivers.
On my side, I am working on trying to implement (as a background task)
a generic interface a little bit more based on discovery (query /
enum) that would render the command interface obsolete. Unfortunately,
I have nothing interesting to show yet.
Best wishes,
-STefan
On Jul 9, 2010, at 17:10, Stefan Schaal wrote:
Hi Alexis,
thanks a lot for the clarification. Thus, scan_begin_arg is set to the
digital line that I would like to use as a trigger. The triggering itself
has to happen by flipping the bit on this specific digital line, e.g.,
using a4l_sync_dio() on this specific line? I assume that I do not need to
re-wire anything on my board.
In your cmd_bits.c code, you use the a4l_insn_t insn structure below for
triggering, which is what I have to replace with a4l_sync_dio(), I guess?
Best wishes,
-Stefan
On Jul 9, 2010, at 15:17, Alexis Berlemont wrote:
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am
not sure that there is anything special to be configured. I
Re: [Xenomai-core] [PULL REQUEST] analogy bug fixes
Hi, Gilles Chanteperdrix wrote: Alexis Berlemont wrote: The following changes since commit 653a38669af4427471ed8cdd129eb0bbb33ba178: nucleus: finalize heap mapping sanitization (2010-07-04 18:57:54 +0200) Ok. Could you rebase on the current master? The commit message would be: Update autotools files Sorry for the delay. That should be better now. -- Gilles. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Stefan Schaal wrote:
Hi Alexis,
I conceptually understand what you are telling us, but I am bit confused
how to implement your advice:
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
The data structures in question are:
/* The command to send by default */
a4l_cmd_t cmd = {
.idx_subd = -1,
.flags = 0,
.start_src = TRIG_INT,
.start_arg = 0,
.scan_begin_src = TRIG_EXT,
.scan_begin_arg = 0, /* in ns */
.convert_src = TRIG_NOW,
.convert_arg = 0, /* in ns */
.scan_end_src = TRIG_COUNT,
.scan_end_arg = 4,
.stop_src = TRIG_NONE,
.stop_arg = 0,
.nb_chan = 4,
.chan_descs = chans,
};
a4l_insn_t insn = {
.type = A4L_INSN_INTTRIG,
.idx_subd = -1,
.data_size = 0,
};
Thus, I assume you mean that
scan_begin_src = TRIG_EXT
should be modified to one of the enum items below? Are all these
timers automatically running, or do they need to be configured, too?
Sorry, I am a bit at a loss how to proceed.
Sorry for the delay.
I was not clear enough. In fact, scan_begin_arg should be
modified. scan_begin_src indicates the type of trigger and
scan_begin_arg gives an associated argument. In our case, it is the
signal number. Sorry for the comment (/* in ns */) which is an
inappropriate copy-paste (as a matter of fact, it is the whole command
interface which is unsuitable but that's another topic).
Best wishes,
-Stefan
On Jul 5, 2010, at 15:02, Alexis Berlemont wrote:
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am
not sure that there is anything special to be configured. I will check
again. Feel free to log into our machine with the pwd I indicated to you
some time ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15
[Xenomai-core] [PULL REQUEST] analogy bug fixes
The following changes since commit 653a38669af4427471ed8cdd129eb0bbb33ba178: nucleus: finalize heap mapping sanitization (2010-07-04 18:57:54 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy ..BRANCH.NOT.VERIFIED.. Alexis Berlemont (48): analogy: change the context's role (broken) analogy: the buffer structure is now the central field of a4l_context (broken) analogy: the subdevice structure got a new status field (broken) analogy: the transfer structure is left with a minimal role (broken) analogy: first draft of buffer initialization functions (broken) analogy: adapt open, r/w, select and ioctl functions (broken) analogy: adapt a4l_set_dev() after a4l_context's overhaul (broken) analogy: update a4l_set_dev() declaration (broken) analogy: update comments on a4l_context (broken) analogy: changes related with subdevice's status field (broken) analogy: replace transfer setup functions with buffer setup ones (broken) analogy: update cancel functions (broken) analogy: rewrite the cancel ioctl handler (broken) analogy: fix bulk flag declaration in buffer.h (broken) analogy: update a4l_read and a4l_write (broken) analogy: update all a4l_buf_* functions (broken) analogy: last updates in the buffer part (broken) analogy: cosmetic changes (broken) analogy: declare the reserve / release functions at the subd level (broken) analogy: update a4l_get_minor function (broken) analogy: update a4l_set_dev and remove useless info traces (broken) analogy: use rtdm_context_to_private (broken) analogy: minor fix in the subdevice structure declaration analogy: add some helper macros to test the subdevice's characteristics analogy: remove useless functions in the subdevice part analogy: fix the buffer syscalls (ioctl + r/w) after buffer review (broken) analogy: fix the declaration of the structure a4l_context (broken) analogy: fix compilation issues and review the mmap ioctl handler (broken) analogy: cosmetic change (broken) analogy: fix buffer's compilation issues (broken) analogy: prettify some subdevice tests (broken) analogy: [pcimio] fix a huge hack in the mite initialization (broken) analogy: fix the last compilation problems analogy: fix a missing setting of the buf field in subdevice (broken) analogy: fix the subdevice status management analogy: fix buffer initialization/cleanup calls at open/close times analogy: [loop] add a debug trace when trigger is called analogy: fix test of subdevice status in a4l_write analogy: [fake - loop] remove volatile keywords analogy: add a detail in a4l_close doxygen doc analogy: add an arbitrary sleep in cmd_write before closing the device analogy: [ni_pcimio] really minor changes analogy: [ni_pcimio] add the missing allocation of the digital ring analogy: [ni_pcimio] fix timeout value in digital trigger analogy: remove a4l_subd_is_busy calls in analogy core analogy: remove calls of a4l_release/reserve_subd in the core analogy: remove some tests which become with the buffer overhaul analogy: fix a bug in a4l_fill_desc() when called on an idle device include/analogy/buffer.h | 72 ++- include/analogy/context.h | 37 +- include/analogy/device.h |7 +- include/analogy/subdevice.h| 47 ++- include/analogy/transfer.h | 17 +- ksrc/drivers/analogy/buffer.c | 629 +++- ksrc/drivers/analogy/command.c | 55 +- ksrc/drivers/analogy/device.c | 51 +-- ksrc/drivers/analogy/driver_facilities.c |4 +- ksrc/drivers/analogy/instruction.c | 11 +- .../analogy/national_instruments/mio_common.c | 39 +- ksrc/drivers/analogy/national_instruments/mite.c | 10 +- ksrc/drivers/analogy/national_instruments/mite.h |2 +- ksrc/drivers/analogy/national_instruments/pcimio.c |2 + ksrc/drivers/analogy/rtdm_interface.c | 137 +++--- ksrc/drivers/analogy/subdevice.c | 12 +- ksrc/drivers/analogy/testing/fake.c| 12 +- ksrc/drivers/analogy/testing/loop.c| 22 +- ksrc/drivers/analogy/transfer.c| 274 + src/drvlib/analogy/descriptor.c| 14 + src/utils/analogy/cmd_write.c |3 + 21 files changed, 655 insertions(+), 802 deletions(-) -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not sure that there is anything special to be configured. I will check again. Feel free to log into our machine with the pwd I indicated to you some time ago. The computer is not used productively. Sorry for answering late, I was unavailable. My question was: did you ensure that the digital line were properly modified after having launched cmd_bits ? As I said, the digital output system does not consume the data (now I am sure). I instrumetented the code and I found out that the mite copied about 8000 bytes from the RAM and filled the digital output FIFO. Then, the DO FIFO status register keeps on indicating the FIFO is full. Nothing happens, the digital output system does not retrieve data from the FIFO. I tried to find out why and I had a close look at the driver: I noticed that no sample clock was configured. The driver only proposes to use an external signal (from the digital system, so AI/AO clocks, counters, PFI, etc.) as sample clock. Unfortunately, I do not know which value corresponds to which clock source. I had a look a the DAQ documentation: unfortunately the M series digital system is different (the DAQ-STC document is not valid for this board). I tried to find the M series developer manual but it is unavailable according to the NI support. I found a document named mseries_registermap.doc in: http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument Unfortunately, it does not tell how to configure the sample clock source (I know which register I have to fill, but I do not know which value to put so as to use AI clock, digital counters or PFI...) So, I am kind of stuck. I will proceed on looking for the missing pieces of information. Please, if anyone have the info (the mapping between the CDO_Mode register values and the sample clock source), do not hesitate to help us. Best wishes, -Stefan On Jun 30, 2010, at 15:45, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, I did a reboot, ran my modified cmd_bits.c again one time. cat /proc/xenomai/irq reports: IRQ CPU0CPU1CPU2CPU3CPU4 CPU5CPU6CPU7 56: 0 0 0 0 0 0 0 0 Analogy device 518: 0 1 1 1 1 1 1 1 [IPI] 521: 626392 618020 618539 620274 617326 625008 622464 626300 [timer] 522: 0 0 0 0 0 0 0 0 [critical sync] 546: 0 0 0 0 0 0 0 0 [virtual] I have not forgotten you. I am still stuck with your bug: The mite transfers the first 8000 bytes and after does nothing; no interrupt is generated by the mite so as to finally awake your application. It seems like the data retrieved by the mite are not consumed by the board. Are you sure the digital output lines correspond to what you configured with cmd_bits ? I think the digital output is misconfigured. I am working on it. -Stefan On Jun 27, 2010, at 3:37, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet
Re: [Xenomai-core] analogy - experimental branch
Hi,
Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
thanks for the feedback. We have 32 bit DIO on subdevice #2, and I am not
sure that there is anything special to be configured. I will check again.
Feel free to log into our machine with the pwd I indicated to you some time
ago. The computer is not used productively.
Sorry for answering late, I was unavailable.
My question was: did you ensure that the digital line were properly
modified after having launched cmd_bits ?
As I said, the digital output system does not consume the data (now I
am sure). I instrumetented the code and I found out that the mite
copied about 8000 bytes from the RAM and filled the digital output
FIFO. Then, the DO FIFO status register keeps on indicating the FIFO
is full. Nothing happens, the digital output system does not retrieve
data from the FIFO.
I tried to find out why and I had a close look at the driver: I
noticed that no sample clock was configured. The driver only proposes
to use an external signal (from the digital system, so AI/AO clocks,
counters, PFI, etc.) as sample clock. Unfortunately, I do not know
which value corresponds to which clock source.
I had a look a the DAQ documentation: unfortunately the M series
digital system is different (the DAQ-STC document is not valid for
this board). I tried to find the M series developer manual but it is
unavailable according to the NI support. I found a document named
mseries_registermap.doc in:
http://digital.ni.com/express.nsf/bycode/exyv4w?opendocument
Unfortunately, it does not tell how to configure the sample clock
source (I know which register I have to fill, but I do not know which
value to put so as to use AI clock, digital counters or PFI...)
So, I am kind of stuck. I will proceed on looking for the missing
pieces of information. Please, if anyone have the info (the mapping
between the CDO_Mode register values and the sample clock source),
do not hesitate to help us.
Argh, I found it. I did not see an item in the url displayed above.
Here is an enum found in:
ftp://ftp.ni.com/support/daq/mhddk/examples/nimseries.zip
// Field Accessors (Compile-time selectable)
typedef enum {
kCDO_Update_Source_SelectGround= 0,
kCDO_Update_Source_SelectPFI0 = 1,
kCDO_Update_Source_SelectPFI1 = 2,
kCDO_Update_Source_SelectPFI2 = 3,
kCDO_Update_Source_SelectPFI3 = 4,
kCDO_Update_Source_SelectPFI4 = 5,
kCDO_Update_Source_SelectPFI5 = 6,
kCDO_Update_Source_SelectPFI6 = 7,
kCDO_Update_Source_SelectPFI7 = 8,
kCDO_Update_Source_SelectPFI8 = 9,
kCDO_Update_Source_SelectPFI9 = 10,
kCDO_Update_Source_SelectRTSI0 = 11,
kCDO_Update_Source_SelectRTSI1 = 12,
kCDO_Update_Source_SelectRTSI2 = 13,
kCDO_Update_Source_SelectRTSI3 = 14,
kCDO_Update_Source_SelectRTSI4 = 15,
kCDO_Update_Source_SelectRTSI5 = 16,
kCDO_Update_Source_SelectRTSI6 = 17,
kCDO_Update_Source_SelectAI_Start = 18,
kCDO_Update_Source_SelectAI_Convert= 19,
kCDO_Update_Source_SelectPXI_Star_Trigger = 20,
kCDO_Update_Source_SelectPFI10 = 21,
kCDO_Update_Source_SelectPFI11 = 22,
kCDO_Update_Source_SelectPFI12 = 23,
kCDO_Update_Source_SelectPFI13 = 24,
kCDO_Update_Source_SelectPFI14 = 25,
kCDO_Update_Source_SelectPFI15 = 26,
kCDO_Update_Source_SelectRTSI7 = 27,
kCDO_Update_Source_SelectG0_Out= 28,
kCDO_Update_Source_SelectG1_Out= 29,
kCDO_Update_Source_SelectAnalog_Trigger= 30,
kCDO_Update_Source_SelectAO_Update = 31,
kCDO_Update_Source_SelectFreq_Out = 32,
kCDO_Update_Source_SelectDIO_Change_Detect_Irq = 33,
} tCDO_Update_Source_Select;
So, Stefan, here is a quick solution:
if you have access to your board you can choose one of these signals
(in which a regular pulse is occuring) and you can modify accordingly
the field scan_begin_arg of the structure a4l_cmd_t in cmd_bits.c.
Best wishes,
-Stefan
On Jun 30, 2010, at 15:45, Alexis Berlemont wrote:
Hi,
Stefan Schaal wrote:
Hi Alexis,
I did a reboot, ran my modified cmd_bits.c again one time.
cat /proc/xenomai/irq reports:
IRQ CPU0CPU1CPU2CPU3CPU4
CPU5CPU6CPU7
56: 0 0 0 0 0
0 0 0 Analogy device
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, I did a reboot, ran my modified cmd_bits.c again one time. cat /proc/xenomai/irq reports: IRQ CPU0CPU1CPU2CPU3CPU4CPU5 CPU6CPU7 56: 0 0 0 0 0 0 0 0 Analogy device 518: 0 1 1 1 1 1 1 1 [IPI] 521: 626392 618020 618539 620274 617326 625008 622464 626300 [timer] 522: 0 0 0 0 0 0 0 0 [critical sync] 546: 0 0 0 0 0 0 0 0 [virtual] I have not forgotten you. I am still stuck with your bug: The mite transfers the first 8000 bytes and after does nothing; no interrupt is generated by the mite so as to finally awake your application. It seems like the data retrieved by the mite are not consumed by the board. Are you sure the digital output lines correspond to what you configured with cmd_bits ? I think the digital output is misconfigured. I am working on it. -Stefan On Jun 27, 2010, at 3:37, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == -- Alexis. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, Stefan Schaal wrote: Hi Alexis, thanks so much for the new analogy software. Here are some first observations: 1) cmd_bits.c works fine on our NI6250 board 2) however, a slightly modified version hangs -- I appended my cmd_bits.c to this email. All what I added is a for loop around the a4l_async_write() and a4l_snd_insn() commands, i.e., I wanted to trigger a write repeatedly. Look for the sschaal comment in my modified cmd_bits.c . After 32 iterations, cmd_bits hangs, no error messages in dmesg. Interesting, when I change your trigger_threshold variable from 128 to 256, my loop runs for 16 iterations (other changes of the trigger threshold adjust the number of iterations I get in a similar way). Thus, it feels like there is a buffer which does not get reset after a4l_snd_insn() is called -- does this make sense? Could you tell me if the mite triggered an interrupt ? Could you send a dump of cat /proc/xenomai/irq after having made the test program hang ? Many thanks, Best wishes, -Stefan On Jun 24, 2010, at 15:43, Alexis Berlemont wrote: Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. === cmd_bits.c == -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy a4l_fill_desc() bug
Hi, Alexis Berlemont wrote: Hi, On Wed, Jun 16, 2010 at 7:01 PM, Daniele Nicolodi dani...@grinta.net wrote: On 11/03/10 18:12, Daniele Nicolodi wrote: Hello. I found a bug in a4l_fill_desc(). If I call it on a descriptor obtained for an unattached device, the memory allocated for the sbdata descriptor field is corrupted in a bad way. When, after the failing a4l_fill_desc() call, I free() it, glibc complains about an invalid next size for the memory chunk. I'm on x86 architecture using kernel 2.6.30.10 with xenomai 2.5.1. This bug is still biting me... A few months ago, I fixed a bug in a4l_fill_desc() and I forgot there were two. So I closed the case in my TODO list. Many thanks for reminding me. The bug should be fixed in my git repository now (branch analogy). Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] analogy - experimental branch
Hi, Alexis Berlemont wrote: Hi Stefan, Stefan Schaal wrote: Hi Alexis, I was just wondering whether the new experimental branch in your git repository is something that can be tried already. No. Not yet. This branch is aimed at temporarily holding the corrections I am trying to do for the cmd_bits issue. It needs quite a lot of work and I have not finished yet. If you have a look at the commits in this branch, we will see many (broken). I just rebased the experimental branch into the branch analogy. So, starting from now, we should be able to properly use cmd_bits with a clone of my git repository. After having reworked the asynchronous buffer subsystem (and having fixed some oops in the NI driver and in the new code), cmd_bits can correctly communicate with the DIO subdevice. A command like ./cmd_bits 0x 0x works on my board. Unfortunately, I have not done the necessary to check the digital output lines yet. Best wishes, -Stefan -- Alexis. -- Alexis. ___ 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
Hi, Alexis Berlemont wrote: Hi, Daniele Nicolodi wrote: 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. I just pushed into the branch analogy of my git repository what you asked. Starting from now, the only asynchronous acquisition to be cancelled will be the one which is related with the file descriptor to be closed. I reviewed the Analogy core to do so. You should not notice any API / ABI breakage. We had two alternatives: either stopping nothing or cancelling any ongoing command related with the device. Cancelling only acquisitions initiated by a specific process implies the implementation of some tricky mechanism above the file approach (open, ioctl, close). I am afraid that we will create some complex code for an issue which should be solved by a suitable device file organization (maybe many dev files instead of a single one). I will have a look at what you asked but I cannot ensure anything, I have no clear solution in mind. 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? There is a lock mechanism but it is not exposed as it is in comedi. The lock system is at the subdevice level: you cannot initiate an instruction if a command is occuring (the reverse is true of course). This is handled with a subdevice status bitfield atomically accessed. Have a look at a4l_reserve_transfer() and tell me if I miss something. Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Alexis. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Some changes in Analogy core
Hi, I just pushed into my git repository (branch analogy) some significant changes in the asynchronous buffer management. These modifications intend to fix a major issue in the analogy architecture: only the default input and output subdevices were reachable via read / write syscalls. These changes do not induce any API / ABI breakage. If you notice a problem, please tell me. -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy bug fixes + rtdm_rt_capable related changes
The following changes since commit e9b509c9021e0134117d0fe75d11e495f0e954b7: arm: add missing #include (2010-05-04 03:44:01 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (17): analogy: fix ring-buffer issues analogy: cosmetic fix analogy: fix buffer checkings so as to allow infinite acquisitions analogy: make cmd_read work with infinite acquisitions (-S 0) analogy: fix a misuse of channel descriptors in a4l_get_chan analogy: [pcimio] register the digital trigger routine analogy: minor change in the header command.h analogy: minor cosmetic fix analogy: add the test program cmd_bits (beta version) analogy: minor fix in insn_bits analogy: add triggering in cmd_bits analogy: in the core, call rtdm_in_rt_context() instead of a4l_test_rt() analogy: add calls to rtdm_rt_capable() in ioctl handlers analogy: remove useless device declarations in read / write syscalls handlers analogy: add rtdm_rt_capable() calls in read / write syscall handlers analogy: fix a stupid bug in the use of rtdm_rt_capable() analogy: make the command registering perform in NRT context Daniele Nicolodi (2): analogy: make a4l_find_range return the index of the selected range analogy: minor change (white spaces removals) include/analogy/buffer.h | 37 ++-- include/analogy/command.h | 15 +- ksrc/drivers/analogy/buffer.c | 57 +++-- ksrc/drivers/analogy/command.c |6 + ksrc/drivers/analogy/device.c |2 +- ksrc/drivers/analogy/instruction.c |6 + .../analogy/national_instruments/mio_common.c | 18 +- ksrc/drivers/analogy/rtdm_interface.c | 10 +- ksrc/drivers/analogy/subdevice.c |6 +- ksrc/drivers/analogy/transfer.c| 10 +- src/drvlib/analogy/range.c | 64 +++-- src/utils/analogy/Makefile.am | 10 +- src/utils/analogy/cmd_bits.c | 277 src/utils/analogy/cmd_read.c |6 +- src/utils/analogy/insn_bits.c |2 +- 15 files changed, 425 insertions(+), 101 deletions(-) create mode 100644 src/utils/analogy/cmd_bits.c -- Alexis. ___ 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
Hi, Daniele Nicolodi wrote: 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. We had two alternatives: either stopping nothing or cancelling any ongoing command related with the device. Cancelling only acquisitions initiated by a specific process implies the implementation of some tricky mechanism above the file approach (open, ioctl, close). I am afraid that we will create some complex code for an issue which should be solved by a suitable device file organization (maybe many dev files instead of a single one). I will have a look at what you asked but I cannot ensure anything, I have no clear solution in mind. 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? There is a lock mechanism but it is not exposed as it is in comedi. The lock system is at the subdevice level: you cannot initiate an instruction if a command is occuring (the reverse is true of course). This is handled with a subdevice status bitfield atomically accessed. Have a look at a4l_reserve_transfer() and tell me if I miss something. Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: A4L_CHAN_AREF_* and AREF_* and other macros
Hi, Daniele Nicolodi wrote: 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. Argh, I missed it. I agree, of course. Unfortunately, the AREF_* symbols are used in the NI driver. The other drivers used the constants A4L_CHAN_AREF_*. The presence of both constants is an inconsistency. I did not doublecheck my port of the NI driver. The use of AREF_* symbols in the NI driver could be considered as a misuse of the API (in the driver I mean). However, for the people who already use this driver, they will not understand why their applications will not work anymore. I am afraid the deprecated solution could not be skipped. 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. I agree with all your ideas. However, for me, the whole command API is a problem because of its lack of consistency with the instruction API and because of the fact commands are not really compatible with many subdevices (ex. DIO). So, for me, instead of inducing a little API breakage in commands, it would be nicer to work on a new API (coherent with instructions). The new API and the command API will live in parallel until the next major release. Thus, no API breakage. 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 -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy: improve a4l_find_range()
Hi, Sorry for the delay. Daniele Nicolodi wrote: 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. I merged both. Thanks. Cheers, -- Daniele -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in a4l_get_chan
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).
The problem is that a4l_get_chan() iterates (twice) on the chan_desc
array looking for channel descriptions at indexes higher than 0, also in
the case where those are not populated because the subdevice uses a
single channel description structure for all channels.
This bug is quite bas, as it triggers a kernel oops for a integer
division by zero when an a4l_cmd_t command is issued with a channels
description array that does not have the channel id 0 as first acquired
channel. You can easily reproduce the bug using the ni_pcimio driver,
using cmd_read with the parameter -c 1.
I'm looking into providing a patch, but I have some difficulties in
understanding the rational of this part of analogy code...
I have some troubles with my dev environment (and I am in a hurry). So
I was not able to test this patch on my NI board.
However, with your accurate description, I think this patch should
solve the problem:
diff --git a/ksrc/drivers/analogy/buffer.c b/ksrc/drivers/analogy/buffer.c
index bbd79ec..3ec558a 100644
--- a/ksrc/drivers/analogy/buffer.c
+++ b/ksrc/drivers/analogy/buffer.c
@@ -112,7 +112,7 @@ a4l_cmd_t *a4l_get_cmd(a4l_subd_t *subd)
int a4l_get_chan(a4l_subd_t *subd)
{
a4l_dev_t *dev = subd-dev;
- int i, tmp_count, tmp_size = 0;
+ int i, j, tmp_count, tmp_size = 0;
a4l_cmd_t *cmd;
/* Check that subdevice supports commands */
@@ -132,9 +132,11 @@ int a4l_get_chan(a4l_subd_t *subd)
/* We assume channels can have different sizes;
so, we have to compute the global size of the channels
in this command... */
- for (i = 0; i cmd-nb_chan; i++)
- tmp_size += dev-transfer.subds[subd-idx]-chan_desc-
- chans[CR_CHAN(cmd-chan_descs[i])].nb_bits;
+ for (i = 0; i cmd-nb_chan; i++) {
+ j = (subd-chan_desc-mode != A4L_CHAN_GLOBAL_CHANDESC) ?
+ CR_CHAN(cmd-chan_descs[i]) : 0;
+ tmp_size += subd-chan_desc-chans[j].nb_bits;
+ }
/* Translation bits - bytes */
tmp_size /= 8;
@@ -146,9 +148,11 @@ int a4l_get_chan(a4l_subd_t *subd)
/* ...and find the channel the last munged sample
was related with */
- for (i = 0; tmp_count 0 i cmd-nb_chan; i++)
- tmp_count -= dev-transfer.subds[subd-idx]-chan_desc-
- chans[CR_CHAN(cmd-chan_descs[i])].nb_bits;
+ for (i = 0; tmp_count 0 i cmd-nb_chan; i++) {
+ j = (subd-chan_desc-mode != A4L_CHAN_GLOBAL_CHANDESC) ?
+ CR_CHAN(cmd-chan_descs[i]) : 0;
+ tmp_count -= subd-chan_desc-chans[j].nb_bits;
+ }
if (tmp_count == 0)
return i;
Concerning, the rationale of the this code, I understand what you
mean. Firstly, the function is badly named, it is quite hard to find
out its role. Secondly, the case I try to manage is intricate (but
real).
I will try to explain it tomorrow (with a proposal of a little patch to
set a better name for this function).
Cheers,
--
Daniele
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Alexis.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy: bug fixes
Daniele Nicolodi wrote: Alexis Berlemont wrote: The following changes since commit 8cfc1103fe1cf9e700698e8230baf562ffb5cf06: Gilles Chanteperdrix (1): x86 syscalls: make __xn_get_eip a macro are available in the git repository at: git://git.xenomai.org/xenomai-abe.git analogy Hello. Looking at your pull request, I see that my patch for correct buffer handling when using .stop_src = TRIG_NONE is not included. Does the patch need some more work? Or it simply get lost on the way? I have not forgotten it. I did not include it for two reasons: - I have not found time to (fully) test it - I wanted to properly modify the test program cmd_read so as to allow continuous acquisisitions Thanks. Cheers, -- Daniele -- Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy a4l_ioctl_bufinfo() bug?
Daniele Nicolodi wrote: Daniele Nicolodi wrote: Hello. As reported in the xenomai-help mailing list I'm investigating why a4l_mmap() is not supported for the ni pcimio driver. Hacking on the driver I discovered that, apparently, the only problem in supporting mmap of the device buffer is in the a4l_ioctl_bufinfo() function. The atached patch solves the problem. My solution is to avoid to mess with the subdevice buffer if a transmission is not occouring. This makes ni pcimio driver work as expected. The second patch enables mmapping for the ni pcimio driver. Merged. Thank you. Cheers, ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Analogy DIO speed
Hi, On Thu, Mar 4, 2010 at 1:54 AM, Stefan Schaal ssch...@usc.edu wrote: Hi Alexis, thanks a lot or the reply. Just to check: is it possible to use commands with digital subdevices at all? I am not sure whether I understood your comment below correctly. Are your *currently* working to enable commands for DIO subdevices? Commands are possible with DIO subdevices. The main problem is my test application which does not handle all the cases. Thanks a lot! -Stefan On Mar 3, 2010, at 15:58, Alexis Berlemont wrote: Hi Stefan, Sorry for the late reply, I was unavailable yesterday. Stefan Schaal wrote: Hi Alexis, we pulled your analogy branch, and now cmd_write works. Great, and thanks a lot! Next, I tried to use commands with the digital IO subdevice on our board (subdevice #2), but the get an error message: [ 2482.771913] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported Unfortunately, cmd_write was not designed to work with digital subdevices; the command's fields are not appropriate, I am trying to make it work quite quickly. Is there just missing support for the DIO subdevices using commands? Best wishes, -Stefan ps.: feel free to use our machine for debugging -- it now has the latest version of your software installed with linux kernel 2.6.29.5. On Feb 28, 2010, at 16:24, Alexis Berlemont wrote: Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi Alexis, On Feb 18, 2010, at 14:34, Alexis Berlemont wrote: I have some problems with implementing commands on my NI6259 so far. Could you remind me what was the problem ? See the print-outs below for the problem we have. Thanks so much for looking into this! -Stefan Using the cmd_write() function that you provide in analogy, we get the following problem: I am currently trying to fix this bug, which is not that easy. I just have one question (that I remember I have already asked you in some way, but I just want to be sure): Does this bug occur the very first time you launched cmd_write (I mean after a reboot) ? I managed at last to fix the bug you were facing (at least I hope so). The problem was located in the trigger callback which waited for a bit-status (fifo half full) before going further; however, sometimes the DMA interrupt already occurred and cleaned everything behind your back. I have not made a pull request because the current implementation is not perfect. If you have some time, could you clone my git repository (branch: analogy) and check that a simple call to cmd_write does not trigger the bug anymore ? Many thanks. r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load3Analogy: a4l_do_special_insn: execution of the instruction failed (err=-32) Another problem we have is with the --mmap option: r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: channel 1 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 4 cmd_write: size to write = 400 cmd_write: buffer size = 65536 bytes cmd_write: a4l_mmap() failed (ret=-22) r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this subdevice Alexis. Alexis. Alexis. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Sensoray 526 analogy driver
Hi,
On Mon, Jan 11, 2010 at 5:08 PM, Alessio Margan @ IIT
alessio.mar...@iit.it wrote:
Hi,
I try to configure sensoray counters to generate PWM signal
#define SUBD_CNT 0
#define SUBD_AI 1
#define SUBD_AO 2
#define SUBD_DIO 3
insn.type = A4L_INSN_CONFIG;
insn.idx_subd = SUBD_COUNTER;
insn.chan_desc = CHAN(channel);
insn.data_size = sizeof(dataC) / sizeof(dataC[0]);
insn.data = data;
data[0] = A4L_INSN_CONFIG_GPCT_PULSE_TRAIN_GENERATOR;
data[1] = cmReg.value;
data[2] = down_ticks;
data[3] = up_ticks;
ret = a4l_snd_insn(dsc, insn);
in a4l_do_insn the subdevice is check in this way but the test for
counter, and I think also for dio, fails due
to A4L_SUBD_MASK_SPECIAL bit
#define A4L_SUBD_UNUSED (A4L_SUBD_MASK_SPECIAL|0x1)
#define A4L_SUBD_COUNTER (A4L_SUBD_MASK_SPECIAL|0x40)
#define A4L_SUBD_DIO (A4L_SUBD_MASK_SPECIAL|0x20)
/* Checks the subdevice's characteristics */
if ((subd-flags A4L_SUBD_UNUSED) != 0) {
__a4l_err(a4l_do_insn: wrong subdevice selected 0x%X\n,subd-flags);
return -EINVAL;
}
there is something wrong or I miss something ?
You miss nothing. There was a bug in the subdevice's flags checking line:
The problem is here: if ((subd-flags A4L_SUBD_UNUSED) != 0) {
I fixed it in my git repo one week ago.
Either you clone my git repot or you wait for the pull request I will
make tonight.
Regards,
TIA
Alessio
--
ISTITUTO ITALIANO
DI TECNOLOGIA
Alessio Margan
/Senior Technician/
mail me mailto:alessio.mar...@iit.it
Via Morego, 30 16163 Genova
http://maps.google.com/maps?f=qhl=engeocode=q=via+morego,+30+genovasll=37.0625,-95.677068sspn=85.420533,191.601563ie=UTF8ll=44.474913,8.907037spn=0.004685,0.011652t=hz=17iwloc=addr
www.iit.it http://www.iit.it
*Legal Disclaimer*
This electronic message contains information that is confidential. The
information is intended for the use of the addressee only. If you are
not the addressee we would appreciate your notification in this respect.
Please note that any disclosure, copy, distribution or use of the
contents of this message is prohibited and may be unlawful. We have
taken every reasonable precaution to ensure that any kind of attachment
to this e-mail has been swept for viruses. However, we cannot accept
liability for any damage sustained as a result of software viruses and
would advise you to carry out your own virus checks before opening any
attachment.
*Avvertenza legale*
Questo messaggio Email contiene informazioni confidenziali riservate ai
soli destinatari. Qualora veniate in possesso di tali informazioni senza
essere definito come destinatario vi reghiamo di leggere le seguenti
note. Ogni apertura, copia, distribuzione del contenuto del messaggio e
dei suoi allegati è proibito e potrebbe violare le presenti leggi.
Abbiamo attivato ogni possibile e ragionevole precauzione per assicurare
che gli allegati non contengano virus. Comunque non assumeremo alcuna
responsabilità per ogni eventuale danno causato da virus software e
simili in quanto è onere del destinatario verificarne l’assenza in ogni
allegato attuando propri indipendenti controlli.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Alexis.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: sensoray s526 and bug fixes
The following changes since commit 3c6b84c9ca7cfc0a9551fd835861f4a05ce7e649: Gilles Chanteperdrix (1): skins: factor user-space tacks sizes handling code are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alessio Margan (1): analogy: rename s526 driver (analogy_s526) Alexis Berlemont (3): analogy: fix the tests of the subdevice flags in the basic checks analogy: do not check the range if no range descriptor is found analogy: fix an ugly access in NI MIO driver Simon Boulay (8): analogy: add s526 driver analogy: some cosmetic change in s526 driver analogy: fix misuses of the instruction field data_size analogy: [s526] Remove dead code from attach function. analogy: [s526] Remove dead code from gpct_insn_config function. analogy: [s526] Cleanups; mainly generic comments from skel.c analogy: [s526] Remove useless HAVE_DIO option analogy: [s526] Cleanups; remove unused defines and variables ksrc/drivers/analogy/Config.in |3 +- ksrc/drivers/analogy/Kconfig |1 + ksrc/drivers/analogy/Makefile |3 +- ksrc/drivers/analogy/command.c |3 +- ksrc/drivers/analogy/instruction.c |2 +- .../analogy/national_instruments/mio_common.c |7 +- ksrc/drivers/analogy/sensoray/Config.in|2 + ksrc/drivers/analogy/sensoray/Kconfig |5 + ksrc/drivers/analogy/sensoray/Makefile | 30 + ksrc/drivers/analogy/sensoray/s526.c | 755 ksrc/drivers/analogy/subdevice.c | 29 +- ksrc/drivers/analogy/transfer.c|3 +- 12 files changed, 825 insertions(+), 18 deletions(-) create mode 100644 ksrc/drivers/analogy/sensoray/Config.in create mode 100644 ksrc/drivers/analogy/sensoray/Kconfig create mode 100644 ksrc/drivers/analogy/sensoray/Makefile create mode 100644 ksrc/drivers/analogy/sensoray/s526.c ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Sensoray 526 analogy driver
Hi,
Alessio Margan @ IIT wrote:
Hi,
I've got a doubt about s526 driver on reading analog input.
I read analog data in this way
sampl_t data;
a4l_insn_t insn_tab = {
.type = A4L_INSN_READ,
.idx_subd = idx_subd,
.chan_desc = CHAN(idx_chan),
.data_size = sizeof(data),
.data = data};
/* Sends the read instruction to the Analogy layer */
ret = a4l_snd_insn(dsc, insn_tab);
on driver side data_size is the number of samples not the nr of byte to
read,
the driver expect data_size to be the number of samples and data to be a
vector of samples
You are right. There is a bug in the driver. The field data_size is not
the acquisition count but the size of all the acquisitions in bytes.
So we should see:
for (n = 0; n insn-data_size / sizeof(uint16_t); n++) {
I will fix it tonight.
uint16_t *data = (uint16_t *)insn-data;
/* convert n samples */
for (n = 0; n insn-data_size; n++) {
/* trigger conversion */
outw(value, ADDR_REG(REG_ADC));
a4l_info(dev, s526_ai_rinsn: Wrote 0x%04x to ADC\n, value);
a4l_info(dev, s526_ai_rinsn: ADC reg=0x%04x\n, inw(ADDR_REG(REG_ADC)));
#define TIMEOUT 100
/* wait for conversion to end */
for (i = 0; i TIMEOUT; i++) {
status = inw(ADDR_REG(REG_ISR));
if (status ISR_ADC_DONE) {
outw(ISR_ADC_DONE, ADDR_REG(REG_ISR));
break;
}
}
if (i == TIMEOUT) {
a4l_warn(dev, s526_ai_rinsn: ADC(0x%04x) timeout\n,
inw(ADDR_REG(REG_ISR)));
return -ETIMEDOUT;
}
/* read data */
d = inw(ADDR_REG(REG_ADD));
a4l_info(dev, s526_ai_rinsn: AI[%d]=0x%04x\n, n, (unsigned short)(d
0x));
/* munge data */
data[n] = d ^ 0x8000;
}
TIA
Alessio
Alexis.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Sensoray 526 analogy driver
Alessio Margan @ IIT wrote: Hi, The irq parameter is not used. It's not used in comedi either. For the io_port, the command analogy_config analogy0 analogy_s526 0xdc0 works for me... not for me ... driver arg 0xdc0 when red by sscanf(opts, %u, res[(*nb) - 1]) in analogy_config.c in function compute_opts is set to 0 due to %u if I use the decimal value of ioport it works ... analogy_config analogy0 analogy_s526 3520 It seems the version you are using is not up to date, this bug was fixed two months ago: commit 01bcfd898555425e96350b306155cba429a65539 Author: Alexis Berlemont alexis.berlem...@gmail.com Date: Sun Nov 8 02:10:20 2009 +0100 analogy: fix a bug in the attach procedure The options to be sent to the driver at attach time were badly handled if the values were hexadecimal-based. Did you try to acquire data? I try with insn_read command find in src/utils/analogy but seems that subdevice should have commands enabled subd-flags |= A4L_SUBD_CMD; Alessio Regards, Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Sensoray 526 analogy driver
Hi Simon, Simon Boulay wrote: Hi, Here is a patch which adds the support of the Sensoray Model 526 board to analogy. Great ! I had a look at the code, that is fine for me. I just have few remarks: - some printk were left commented in the original comedi driver, you correctly translated them into a4l_info; however, could you use a4l_dbg instead and remove the comments ? - the sources of the original driver contain many areas of commented code and #if 0 #else #endif directives. In order to keep coherency with the original driver, I think the import of the driver should be done as it is; nonetheless, the second step would be to clean it inside the git repository. I think it is wise to wait for the release of 2.5 before integrating it. It will be made available in Xenomai 2.5.1. The driver compiles against head but have not been tested on real hardware yet. Alessio was interested by this driver; Alessio, the driver is yours as soon as it is available in my git repository. It has been ported from comedi (staging version) and should work as in comedi: - Encoder works - Analog input works - Analog output works - PWM output works - Commands are not supported yet. Regards, Many thanks for your work ! Simon. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: build fixes and many bug fixes.
The following changes since commit e305035eb6adc4220fe179477f3e300ad944f85c: Alexis Berlemont (1): analogy: fix bad error handling path in test programs are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (22): analogy: fix potentiel NULL instructions handlers executions analogy: fix the default writing subdevice. analogy: properly manage cancel operations on synchronous subdevices analogy: add a kernel error message when a driver rejects a command analogy: add missing channel and range descriptors in the loop driver analogy: in cmd_read, set a higher scan interval analogy: fix wrong names of conversion functions analogy: improve the test program insn_write analogy: fix a bug in the conversion routines analogy: minor change in the driver description analogy: add a simple helper function analogy: slight change in a kernel error message analogy: fix Doxygen documentation (a4l_sync_read, a4l_sync_write) analogy: fix a bug in the execution of a list of instructions analogy: review the conversion routines in the user library analogy: improve the test program cmd_read analogy: minor Doxygen change analogy: fix wrong use of the type unsigned long long in time retrieval analogy: fix a bug in the user/kernel copy of the instruction's data analogy: fix a first part of the compilation issues when mite is disabled analogy: fix the compilation issues when mite is disabled analogy: replace EXPORT_SYMBOL() by EXPORT_SYMBOL_GPL() include/analogy/analogy.h | 48 +- include/analogy/instruction.h |8 +- include/analogy/os_facilities.h|4 +- ksrc/drivers/analogy/command.c |8 +- ksrc/drivers/analogy/driver_facilities.c | 58 +- ksrc/drivers/analogy/instruction.c | 67 ++- ksrc/drivers/analogy/intel/8255.c | 28 +- ksrc/drivers/analogy/intel/parport.c | 38 +- .../analogy/national_instruments/mio_common.c | 579 ksrc/drivers/analogy/national_instruments/mite.c | 42 +- ksrc/drivers/analogy/national_instruments/ni_tio.h | 20 +- ksrc/drivers/analogy/national_instruments/pcimio.c |2 + .../analogy/national_instruments/tio_common.c | 92 ++-- ksrc/drivers/analogy/os_facilities.c | 10 +- ksrc/drivers/analogy/testing/fake.c| 19 +- ksrc/drivers/analogy/testing/loop.c| 20 +- ksrc/drivers/analogy/transfer.c|3 +- src/drvlib/analogy/range.c | 369 -- src/drvlib/analogy/sync.c |4 +- src/utils/analogy/cmd_read.c | 138 - src/utils/analogy/cmd_write.c |4 +- src/utils/analogy/insn_read.c | 180 +-- src/utils/analogy/insn_write.c | 84 ++- 23 files changed, 1272 insertions(+), 553 deletions(-) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: one forgotten option dependency
The following changes since commit eecb6ee65712a8b412be455344f84fc13ced555b: Alexis Berlemont (1): analogy: make the MITE option depends on the PCI option are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Hi Gilles, Gilles Chanteperdrix wrote: Alexis Berlemont wrote: Hi Gilles, Gilles Chanteperdrix wrote: Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense Yes it makes sense. I think the MITE is integrated into all PCI boards but the driver should work with the MITE disabled (one day, we could add the ISA boards). - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. Ack. I will fix these problems as quickly as possible. Ok. The fix for the second problem would be nice to have soon, as analogy breaks the build on blackfin for this reason. If it is of any help, you can send me a patch for this fix only which I will apply on my side while you are working on other changes. I modified the common part of the NI driver so that the PCI code can be disabled without any compilation issues. I made a pull request which contains the fixes. Merry Christmas. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] cmd_write
Hi, On Wed, Dec 23, 2009 at 2:12 AM, Stefan Schaal ssch...@usc.edu wrote: dmesg: Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [15619.322973] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load This bug hapens randomly on a card to which I have a remote access. The occurences were scarce, that is the reason why this bug is still at the tail of my todo list. On your board, I suppose it happens at every try. I will try to fix this bug as soon as possible. -Stefan On Dec 22, 2009, at 16:52, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] cmd_write
Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Hi Gilles, Gilles Chanteperdrix wrote: Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense Yes it makes sense. I think the MITE is integrated into all PCI boards but the driver should work with the MITE disabled (one day, we could add the ISA boards). - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. Ack. I will fix these problems as quickly as possible. * blackfin: I finally compiled blackfin! had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. Thanks in advance for your efforts. Regards. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] digital I/O with analgoy using ni_pcmcia
Hi, Stefan Schaal wrote: Hi everybody, we have an NI6259 board working xenomai 2.5, using the analogy APIs. Read/write to analog channels is quite straightforward and can be inferred from the cmd_read and cmd_write source code. Now I would also like to use the digital I/O of this board (e.g., the 32 digital I/O lines). In Comedi, there are functions to set the DIO lines to input/output mode (comedi_dio_config), and then functions to read/write, like comedi_dio_read and comedi_dio_write. Does xenomai/analogy already have similar functionality? Many thanks for this question, it is an issue I have been keeping on postponing the resolution. Currently, the functions are not implemented but it could be quickly done. Here is my understanding of the Comedi DIO features; please, correct me if I am wrong. In Comedi, here is the list of functions related with DIO: - comedi_dio_read (insn_read or deprecated insn trigger) - comedi_dio_write (insn_write or deprecated insn trigger) - comedi_dio_config (insn_config or deprecated insn trigger) - comedi_dio_get_config (insn_config or deprecated trigger) - comedi_dio_bitfield (insn_bits or comedi_dio_read/write) - comedi_dio_bitfield2 (insn_bits or comedi_dio_read/write) The instruction insn_bits is a combination of a read operation and a write operation (that is why, the function comedi_dio_bitfield* call comedi_dio_read and comedi_dio_write if the driver does not provide an insn-bits handler). I had a look at many Comedi drivers and most of them register the handler insn_bits for the DIO subdevice. The instructions insn_read and insn_write are not oftenly used in DIO contexts. comedi_dio_bitfield() uses the insn_bits instruction. However, it only works with DIO subdevice limited to 32 channels; that was why comedi_dio_bitfield2() was introduced, this latter function contains one more argument so as to shift the bits. Consequently, we may need a more limited set of functions: - a4l_sync_dio(dsc, idx_subd, mask, buf) - a4l_sizeof_subd(dsc, idx_subd) - a4l_config_subd(dsc, idx_subd, idx_chan, cfg_type, *val) a4l_sync_dio() could work with any DIO subdevice (more or less than 32 channels). The last argument would be a pointer to a buffer which size should be defined thanks to a4l_sizeof_subd() (8, 16, 32, 64 or more bits). a4l_config_subd() could be used to configure the polarity of the DIO channels. The argument cfg_type could be set to DIO_INPUT, DIO_OUTPUT, DIO_QUERY. And, we could even imagine that this function would not be limited to DIO subdevice; so, the argument cfg_type could accept more values (SERIAL_CLOCK, BIDIRECTIONAL_DATA, SET_CLOCK_SRC, GET_CLOCK_SRC, etc.) How do you see this approach ? Do you (or anyone else) have a better solution in mind ? Best regards, Thanks a lot, -Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests.
Hi Gilles, Gilles Chanteperdrix wrote: Hi, I am working on automated build tests of several configurations of Xenomai head. While running them, I found a few issues, and would need acks, since it is in parts others maintain. Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html Thank you for the fix. Wolfgang: https://mail.gna.org/public/xenomai-git/2009-12/msg00113.html Anyone: https://mail.gna.org/public/xenomai-git/2009-12/msg00114.html Philippe (check powerpc 2.4): https://mail.gna.org/public/xenomai-git/2009-12/msg00115.html The current status of the tests may be found here: http://sisyphus.hd.free.fr/~gilles/bx/ TIA, Regards. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: doxygen errors descriptions, headers sources fixes
The following changes since commit 76456b88f8fe8cf9885996f2c042df7d4b266df0: Alexis Berlemont (1): analogy: add error messages in instruction handling are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (4): analogy: add error codes descriptions for synchronous operations analogy: add error codes descriptions for descriptor routines analogy: add error codes descriptions for range management routines analogy: fix mistakes in license declarations ksrc/drivers/analogy/intel/8255.c| 23 ++--- ksrc/drivers/analogy/intel/parport.c | 22 ++-- src/drvlib/analogy/async.c |4 +- src/drvlib/analogy/descriptor.c | 57 ++--- src/drvlib/analogy/range.c | 21 +++-- src/drvlib/analogy/sync.c| 28 ++-- 6 files changed, 111 insertions(+), 44 deletions(-) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: many bugfixes, doxygen updates, parport driver, insn_write
The following changes since commit e6e21a3e183f145dd1c583e60fbecda982e00c70: Alexis Berlemont (1): analogy: improve ioctl error handling are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (21): analogy: fix a bug in the attach procedure analogy: remove EXPERIMENTAL flag from 2.4 Config.in files analogy: fix a mistyping error analogy: fix functions declarations in the 8255 driver analogy: add an analogy driver for standard parallel port analogy: add default attach options for analogy_parport driver analogy: make analogy_parport compile only for x86 architectures analogy: use the A4L_INSN_* constants to configure the DIO subdevice analogy: minor cosmetic change in instruction header analogy: change prefix for traces (a4l - Analogy) analogy: some coding style corrections analogy: fix a minor bug (filename management) in insn_read analogy: add a test program which performs synchronous write analogy: fix missing renamings for testing drivers analogy: fix doxygen documentation generation for analogy analogy: minor indentation fix analogy: fix positive error code in transfer cleanup analogy: add some details on the error codes for the syscall API analogy: add error codes descriptions for the asynchronous API analogy: fix a scan size miscalculation in cmd_read analogy: report scan size miscalculation fix in cmd_write and insn_* doc/doxygen/Doxyfile.in| 10 +- include/analogy/instruction.h | 10 +- include/analogy/os_facilities.h|2 +- ksrc/drivers/analogy/buffer.c |7 +- ksrc/drivers/analogy/intel/8255.c |4 +- ksrc/drivers/analogy/intel/Config.in |6 +- ksrc/drivers/analogy/intel/Kconfig |9 +- ksrc/drivers/analogy/intel/Makefile| 15 +- ksrc/drivers/analogy/intel/parport.c | 452 .../drivers/analogy/national_instruments/Config.in |4 +- ksrc/drivers/analogy/testing/fake.c|2 +- ksrc/drivers/analogy/testing/loop.c| 14 +- ksrc/drivers/analogy/transfer.c|2 +- src/drvlib/analogy/async.c | 78 +++- src/drvlib/analogy/sys.c | 41 ++- src/utils/analogy/Makefile.am |5 +- src/utils/analogy/Makefile.in | 18 +- src/utils/analogy/analogy_config.c | 20 +- src/utils/analogy/cmd_read.c |3 +- src/utils/analogy/cmd_write.c |3 +- src/utils/analogy/insn_read.c | 14 +- src/utils/analogy/insn_write.c | 274 22 files changed, 925 insertions(+), 68 deletions(-) create mode 100644 ksrc/drivers/analogy/intel/parport.c create mode 100644 src/utils/analogy/insn_write.c Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: critical bugfixes for the NI PCIMIO driver
Hi, Here are some important fixes for the NI PCIMIO driver. I would like to thank Cristian Axenie for giving me access to his development environment. These bugs were particularly noticeable on his PPC board (any acquisition triggered a CPU reboot). Alexis. The following changes since commit 255cf6b2bf8dca9dad05a1c169dcecf6e742955e: Alexis Berlemont (1): analogy: force NI TIO / MIO selections when NI PCIMIO is set are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (4): analogy: force NI MITE selection when NI PCIMIO is set analogy: fix a critical bug in the NI PCIMIO driver analogy: rename 8255 and NI PCIMIO driver analogy: fix a bug in NI PCIMIO driver ksrc/drivers/analogy/intel/8255.c |2 +- ksrc/drivers/analogy/national_instruments/Kconfig |1 + .../analogy/national_instruments/mio_common.c | 12 ksrc/drivers/analogy/national_instruments/pcimio.c |2 +- 4 files changed, 11 insertions(+), 6 deletions(-) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] Analogy: many bugfixes
Hi Philippe, Sorry, I forgot the prefix rule for the short log for many commits. I will take more care starting from now. Alexis. The following changes since commit 39614e10be1d7fc5344b56646b8801cbf8756e08: Alexis Berlemont (1): Add error messages for the IOCTL interface (attach, instruction, cmd, etc.) are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy ..BRANCH.NOT.VERIFIED.. Alexis Berlemont (4): Fix testing drivers' renaming issues Some Comedi - Analogy forgotten renamings Add modules descriptions and license specifications Fix comments Breeje, R. (Remco) den (2): Add a missing dependency for the NI MIO driver (NI TIO) In cmd_read, fix received bytes storing Philippe Gerum (1): analogy: fix debug options dependencies ksrc/drivers/analogy/Kconfig |2 + ksrc/drivers/analogy/instruction.c |2 +- ksrc/drivers/analogy/intel/8255.c | 10 +- ksrc/drivers/analogy/national_instruments/Kconfig |2 +- .../analogy/national_instruments/mio_common.c |3 + ksrc/drivers/analogy/national_instruments/mite.c |2 +- ksrc/drivers/analogy/national_instruments/pcimio.c |2 + .../analogy/national_instruments/tio_common.c |2 +- ksrc/drivers/analogy/testing/Config.in |4 +- ksrc/drivers/analogy/testing/Kconfig |8 +- ksrc/drivers/analogy/testing/Makefile | 26 ++-- ksrc/drivers/analogy/testing/fake.c| 116 +- ksrc/drivers/analogy/testing/loop.c| 136 ++-- src/utils/analogy/analogy_config.c | 22 ++-- src/utils/analogy/cmd_read.c | 54 src/utils/analogy/cmd_write.c | 44 +++--- src/utils/analogy/insn_read.c | 32 +++--- 17 files changed, 239 insertions(+), 228 deletions(-) Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PULL REQUEST] analogy renaming + many bugfixes
Hi,
On Sunday 25 October 2009 12:08:58 Philippe Gerum wrote:
On Mon, 2009-10-19 at 23:18 +0200, Alexis Berlemont wrote:
The following changes since commit
8c847c4bf43fa65c3ec541850ecdb7e96113e94f: Philippe Gerum (1):
powerpc: fix commit number for 2.6.30.3-DENX
are available in the git repository at:
ssh+git://g...@xenomai.org/xenomai-abe.git analogy
We likely need this:
I did not have time to apply this patch tonight but that will be done as soon
as possible.
Thank you
diff --git a/ksrc/drivers/analogy/Kconfig b/ksrc/drivers/analogy/Kconfig
index 437a1bc..9d17b1d 100644
--- a/ksrc/drivers/analogy/Kconfig
+++ b/ksrc/drivers/analogy/Kconfig
@@ -9,6 +9,7 @@ config XENO_DRIVERS_ANALOGY
drivers.
config XENO_DRIVERS_ANALOGY_DEBUG
+ depends on XENO_DRIVERS_ANALOGY
bool Analogy debug trace
default y
help
@@ -17,6 +18,7 @@ config XENO_DRIVERS_ANALOGY_DEBUG
core and drivers behaviours.
config XENO_DRIVERS_ANALOGY_DEBUG_LEVEL
+ depends on XENO_DRIVERS_ANALOGY_DEBUG
int Analogy core debug level threshold
default 0
help
Alexis Berlemont (18):
Remove useless wrappers (comedi_copy_*_user())
Initialize the freshly allocated device's private area
Fix obvious typo mistake
Fix some error checkings in analog output command test function
Fix various minor bugs
Fix internal trigger via instruction (we do not need any data in
the instruction structure)
Add ai / ao trigger callback
Add a trigger instruction
Replace an info message by an error message
Fix a problem in the mite configuration (only for AI)
Add a missing EXPORT_SYMBOL() comedi_alloc_subd.
Align fake macro declarations with real functions declarations
Fix modules compilations issues
Comedi4RTDM - Analogy (first part)
Comedi4RTDM - Analogy (second part)
Comedi4RTDM - Analogy (third part, kernel side compiles)
Comedi4RTDM - Analogy (last part, user side compiles and runs)
Update *_alloc_subd() after bugfix backport from comedi branch
Makefile.in|1 +
aclocal.m4 |4 +-
config/Makefile.in |1 +
configure | 5454
+++-
configure.in |6 +-
doc/Makefile.in|1 +
doc/docbook/Makefile.in|1 +
doc/docbook/custom-stylesheets/Makefile.in |1 +
doc/docbook/custom-stylesheets/xsl/Makefile.in |1 +
.../custom-stylesheets/xsl/common/Makefile.in |1 +
doc/docbook/custom-stylesheets/xsl/fo/Makefile.in |1 +
.../custom-stylesheets/xsl/html/Makefile.in|1 +
doc/docbook/xenomai/Makefile.in|1 +
doc/doxygen/Makefile.in|1 +
doc/man/Makefile.in|1 +
doc/txt/Makefile.in|1 +
include/Makefile.am|2 +-
include/Makefile.in|3 +-
include/{comedi = analogy}/Makefile.am|6 +-
include/{comedi = analogy}/Makefile.in| 13 +-
include/analogy/analogy.h | 152 +
.../comedi_driver.h = analogy/analogy_driver.h} | 16 +-
include/{comedi = analogy}/buffer.h | 192 +-
include/{comedi = analogy}/channel_range.h| 162 +-
include/{comedi = analogy}/command.h | 34 +-
include/{comedi = analogy}/context.h | 32 +-
include/{comedi = analogy}/descriptor.h | 28 +-
include/{comedi = analogy}/device.h | 58 +-
include/{comedi = analogy}/driver.h | 34 +-
include/analogy/instruction.h | 225 +
include/{comedi = analogy}/ioctl.h| 40 +-
include/analogy/os_facilities.h| 191 +
include/analogy/subdevice.h| 271 +
include/analogy/transfer.h | 105 +
include/{comedi = analogy}/types.h| 14 +-
include/asm-arm/Makefile.in|1 +
include/asm-arm/bits/Makefile.in |1 +
include/asm-blackfin/Makefile.in |1 +
include/asm-blackfin/bits/Makefile.in |1 +
include/asm-generic/Makefile.in|1 +
include/asm-generic/bits/Makefile.in |1 +
include/asm-nios2/Makefile.in |1 +
include/asm-nios2/bits/Makefile.in |1 +
include/asm-powerpc/Makefile.in|1 +
include/asm
Re: [Xenomai-core] Some thoughts on Analogy kernel side framework
On Saturday 17 October 2009 19:55:41 Philippe Gerum wrote: On Mon, 2009-10-12 at 23:52 +0200, Alexis Berlemont wrote: On Monday 12 October 2009 11:30:11 you wrote: On Mon, 2009-10-12 at 00:51 +0200, Alexis Berlemont wrote: On Friday 09 October 2009 10:04:07 you wrote: On Fri, 2009-10-09 at 00:00 +0200, Alexis Berlemont wrote: If I understand well, I have gone too far too soon; the idea should be to keep the current framework as it is for 2.5. However, my former mail was not a definitive plan. The first goal was to share ideas. So, do not worry too much. :) Maintaining two different frameworks for the same purpose won't fly. I'm worried because the future of Comedi/RTDM as merged in the 2.5 tree just became unclear - to say the least - as from you introduced the idea of changing its architecture. Your potential user-base has to know whether using the current Comedi/RTDM framework for new designs based on 2.5.x will still make sense in six months from now, when Analogy eventually emerges. In other words, is there any upgrade path planned? What would this entail? Would one have to rewrite custom DAQ drivers to port them from Comedi/RTDM to Analogy, or could rely on a some compat wrapper for supporting legacy Comedi/RTDM Driver-Kernel interface on top of the Analogy core? Would that new architecture bring changes in the applications, i.e. what about the impact of such changes on the way userland interfaces to the acquisition framework and/or its drivers? I would have thought that Comedi/RTDM in the 2.5 tree would become Analogy as is, and evolve over time in a careful manner so that people always have a reasonable upgrade path. But now, I'm unsure whether this is going to be the case, or we would end up with two different frameworks. So, what is the _exact_ plan? Ok. I will try to give my rough ideas. Comedi / RTDM is facing many questions: 1) Peter Soetens, a Comedi user, once told us that the APIs (kernel and user) divergences with upstream were going to bring many troubles. maintaining tasks, difficulties to lure orginal Comedi users, etc. - Should I ignore what was told that day or should I find a way to satisfy the main request which was a smooth transition between Comedi upstream and Comedi/RTDM. You don't seem to get the point yet: I'm in no way arguing about which technical direction you should head your project to, and I have no issue with your technical analysis. The issue I have is with your project management: Comedi/RTDM is currently part of the Xenomai tree, scheduled for 2.5 for more than a year, and you are now in the back to the future mode, asking people their feedback about major changes your would like to see in your infrastructure, at a moment when one may have expected it to be stable. This won't fly. 2) People developing with Comedilib do not seem to be the same guys working on the drivers. So, even if common users agreed with porting their applications on the new library interface, they could not integrate their needed drivers into the Xenomai drivers set. If you want a clue, have a look at the Comedi mailing list, there are plenty of mails starting with Is there a Comedi driver for ... - Should I still be confident that there will be contributions of drivers ? If your point is about mentioning that OS implementers should provide a stable framework to build over, for others to implement drivers for their own devices, well, ok, I was vaguely aware of this; thanks for the heads up anyway. Problem is that you have just shot yourself in the foot, by tagging Comedi/RTDM has unstable and unusable in the context of developing drivers. If you tell people that you are about to rewrite the kernel side significantly before they had a chance to get their feet wet with it and consider basing their future work on it, you won't get any contribution, obviously. They will wait for your own dust to settle. Or they may not wait at all, and walk away. At any rate, deprecating the current Comedi/RTDM architecture now, only a few weeks before Xenomai 2.5 is rolled out, has pretty bad timing, to say the least. 3) The Comedi framework is too different from other well-known frameworks. However, I consider that audio and multimedia cards are not different from acquistion devices. All of them can be divided into subdevices or components but neither v4l2 nor alsa did implement subdevices configurations like Comedi did. v4l2 and alsa drivers are working both with devices fops-like structures but Comedi is working with per subdevices callbacks far from the Linux driver model. Etc. - Should I leave our framework like it is ? Are we sure
[Xenomai-core] [PULL REQUEST] analogy renaming + many bugfixes
The following changes since commit 8c847c4bf43fa65c3ec541850ecdb7e96113e94f:
Philippe Gerum (1):
powerpc: fix commit number for 2.6.30.3-DENX
are available in the git repository at:
ssh+git://g...@xenomai.org/xenomai-abe.git analogy
Alexis Berlemont (18):
Remove useless wrappers (comedi_copy_*_user())
Initialize the freshly allocated device's private area
Fix obvious typo mistake
Fix some error checkings in analog output command test function
Fix various minor bugs
Fix internal trigger via instruction (we do not need any data in the
instruction structure)
Add ai / ao trigger callback
Add a trigger instruction
Replace an info message by an error message
Fix a problem in the mite configuration (only for AI)
Add a missing EXPORT_SYMBOL() comedi_alloc_subd.
Align fake macro declarations with real functions declarations
Fix modules compilations issues
Comedi4RTDM - Analogy (first part)
Comedi4RTDM - Analogy (second part)
Comedi4RTDM - Analogy (third part, kernel side compiles)
Comedi4RTDM - Analogy (last part, user side compiles and runs)
Update *_alloc_subd() after bugfix backport from comedi branch
Makefile.in|1 +
aclocal.m4 |4 +-
config/Makefile.in |1 +
configure | 5454
+++-
configure.in |6 +-
doc/Makefile.in|1 +
doc/docbook/Makefile.in|1 +
doc/docbook/custom-stylesheets/Makefile.in |1 +
doc/docbook/custom-stylesheets/xsl/Makefile.in |1 +
.../custom-stylesheets/xsl/common/Makefile.in |1 +
doc/docbook/custom-stylesheets/xsl/fo/Makefile.in |1 +
.../custom-stylesheets/xsl/html/Makefile.in|1 +
doc/docbook/xenomai/Makefile.in|1 +
doc/doxygen/Makefile.in|1 +
doc/man/Makefile.in|1 +
doc/txt/Makefile.in|1 +
include/Makefile.am|2 +-
include/Makefile.in|3 +-
include/{comedi = analogy}/Makefile.am|6 +-
include/{comedi = analogy}/Makefile.in| 13 +-
include/analogy/analogy.h | 152 +
.../comedi_driver.h = analogy/analogy_driver.h} | 16 +-
include/{comedi = analogy}/buffer.h | 192 +-
include/{comedi = analogy}/channel_range.h| 162 +-
include/{comedi = analogy}/command.h | 34 +-
include/{comedi = analogy}/context.h | 32 +-
include/{comedi = analogy}/descriptor.h | 28 +-
include/{comedi = analogy}/device.h | 58 +-
include/{comedi = analogy}/driver.h | 34 +-
include/analogy/instruction.h | 225 +
include/{comedi = analogy}/ioctl.h| 40 +-
include/analogy/os_facilities.h| 191 +
include/analogy/subdevice.h| 271 +
include/analogy/transfer.h | 105 +
include/{comedi = analogy}/types.h| 14 +-
include/asm-arm/Makefile.in|1 +
include/asm-arm/bits/Makefile.in |1 +
include/asm-blackfin/Makefile.in |1 +
include/asm-blackfin/bits/Makefile.in |1 +
include/asm-generic/Makefile.in|1 +
include/asm-generic/bits/Makefile.in |1 +
include/asm-nios2/Makefile.in |1 +
include/asm-nios2/bits/Makefile.in |1 +
include/asm-powerpc/Makefile.in|1 +
include/asm-powerpc/bits/Makefile.in |1 +
include/asm-sim/Makefile.in|1 +
include/asm-sim/bits/Makefile.in |1 +
include/asm-x86/Makefile.in|1 +
include/asm-x86/bits/Makefile.in |1 +
include/comedi/comedi.h| 151 -
include/comedi/instruction.h | 225 -
include/comedi/os_facilities.h | 211 -
include/comedi/subdevice.h | 271 -
include/comedi/transfer.h | 105 -
include/native/Makefile.in |1 +
include/nucleus/Makefile.in|1 +
include/posix/Makefile.in |1 +
include/posix/sys/Makefile.in |1 +
include/psos+/Makefile.in |1 +
include/rtai/Makefile.in |1 +
include/rtdm/Makefile.in |1 +
include/uitron
Re: [Xenomai-core] Some thoughts on Analogy kernel side framework
On Monday 12 October 2009 11:30:11 you wrote: On Mon, 2009-10-12 at 00:51 +0200, Alexis Berlemont wrote: On Friday 09 October 2009 10:04:07 you wrote: On Fri, 2009-10-09 at 00:00 +0200, Alexis Berlemont wrote: If I understand well, I have gone too far too soon; the idea should be to keep the current framework as it is for 2.5. However, my former mail was not a definitive plan. The first goal was to share ideas. So, do not worry too much. :) Maintaining two different frameworks for the same purpose won't fly. I'm worried because the future of Comedi/RTDM as merged in the 2.5 tree just became unclear - to say the least - as from you introduced the idea of changing its architecture. Your potential user-base has to know whether using the current Comedi/RTDM framework for new designs based on 2.5.x will still make sense in six months from now, when Analogy eventually emerges. In other words, is there any upgrade path planned? What would this entail? Would one have to rewrite custom DAQ drivers to port them from Comedi/RTDM to Analogy, or could rely on a some compat wrapper for supporting legacy Comedi/RTDM Driver-Kernel interface on top of the Analogy core? Would that new architecture bring changes in the applications, i.e. what about the impact of such changes on the way userland interfaces to the acquisition framework and/or its drivers? I would have thought that Comedi/RTDM in the 2.5 tree would become Analogy as is, and evolve over time in a careful manner so that people always have a reasonable upgrade path. But now, I'm unsure whether this is going to be the case, or we would end up with two different frameworks. So, what is the _exact_ plan? Ok. I will try to give my rough ideas. Comedi / RTDM is facing many questions: 1) Peter Soetens, a Comedi user, once told us that the APIs (kernel and user) divergences with upstream were going to bring many troubles. maintaining tasks, difficulties to lure orginal Comedi users, etc. - Should I ignore what was told that day or should I find a way to satisfy the main request which was a smooth transition between Comedi upstream and Comedi/RTDM. You don't seem to get the point yet: I'm in no way arguing about which technical direction you should head your project to, and I have no issue with your technical analysis. The issue I have is with your project management: Comedi/RTDM is currently part of the Xenomai tree, scheduled for 2.5 for more than a year, and you are now in the back to the future mode, asking people their feedback about major changes your would like to see in your infrastructure, at a moment when one may have expected it to be stable. This won't fly. 2) People developing with Comedilib do not seem to be the same guys working on the drivers. So, even if common users agreed with porting their applications on the new library interface, they could not integrate their needed drivers into the Xenomai drivers set. If you want a clue, have a look at the Comedi mailing list, there are plenty of mails starting with Is there a Comedi driver for ... - Should I still be confident that there will be contributions of drivers ? If your point is about mentioning that OS implementers should provide a stable framework to build over, for others to implement drivers for their own devices, well, ok, I was vaguely aware of this; thanks for the heads up anyway. Problem is that you have just shot yourself in the foot, by tagging Comedi/RTDM has unstable and unusable in the context of developing drivers. If you tell people that you are about to rewrite the kernel side significantly before they had a chance to get their feet wet with it and consider basing their future work on it, you won't get any contribution, obviously. They will wait for your own dust to settle. Or they may not wait at all, and walk away. At any rate, deprecating the current Comedi/RTDM architecture now, only a few weeks before Xenomai 2.5 is rolled out, has pretty bad timing, to say the least. 3) The Comedi framework is too different from other well-known frameworks. However, I consider that audio and multimedia cards are not different from acquistion devices. All of them can be divided into subdevices or components but neither v4l2 nor alsa did implement subdevices configurations like Comedi did. v4l2 and alsa drivers are working both with devices fops-like structures but Comedi is working with per subdevices callbacks far from the Linux driver model. Etc. - Should I leave our framework like it is ? Are we sure that the fact the original Comedi framework is slowly losing contributions is a coincidence ? Nobody tells you to freeze your work, and/or not to think of a better approach. But you need to do a better job of explaining how your potential users will get their upgrade path to your new architecture
Re: [Xenomai-core] Some thoughts on Analogy kernel side framework
On Friday 09 October 2009 10:04:07 you wrote: On Fri, 2009-10-09 at 00:00 +0200, Alexis Berlemont wrote: If I understand well, I have gone too far too soon; the idea should be to keep the current framework as it is for 2.5. However, my former mail was not a definitive plan. The first goal was to share ideas. So, do not worry too much. :) Maintaining two different frameworks for the same purpose won't fly. I'm worried because the future of Comedi/RTDM as merged in the 2.5 tree just became unclear - to say the least - as from you introduced the idea of changing its architecture. Your potential user-base has to know whether using the current Comedi/RTDM framework for new designs based on 2.5.x will still make sense in six months from now, when Analogy eventually emerges. In other words, is there any upgrade path planned? What would this entail? Would one have to rewrite custom DAQ drivers to port them from Comedi/RTDM to Analogy, or could rely on a some compat wrapper for supporting legacy Comedi/RTDM Driver-Kernel interface on top of the Analogy core? Would that new architecture bring changes in the applications, i.e. what about the impact of such changes on the way userland interfaces to the acquisition framework and/or its drivers? I would have thought that Comedi/RTDM in the 2.5 tree would become Analogy as is, and evolve over time in a careful manner so that people always have a reasonable upgrade path. But now, I'm unsure whether this is going to be the case, or we would end up with two different frameworks. So, what is the _exact_ plan? Ok. I will try to give my rough ideas. Comedi / RTDM is facing many questions: 1) Peter Soetens, a Comedi user, once told us that the APIs (kernel and user) divergences with upstream were going to bring many troubles. maintaining tasks, difficulties to lure orginal Comedi users, etc. - Should I ignore what was told that day or should I find a way to satisfy the main request which was a smooth transition between Comedi upstream and Comedi/RTDM. 2) People developing with Comedilib do not seem to be the same guys working on the drivers. So, even if common users agreed with porting their applications on the new library interface, they could not integrate their needed drivers into the Xenomai drivers set. If you want a clue, have a look at the Comedi mailing list, there are plenty of mails starting with Is there a Comedi driver for ... - Should I still be confident that there will be contributions of drivers ? 3) The Comedi framework is too different from other well-known frameworks. However, I consider that audio and multimedia cards are not different from acquistion devices. All of them can be divided into subdevices or components but neither v4l2 nor alsa did implement subdevices configurations like Comedi did. v4l2 and alsa drivers are working both with devices fops-like structures but Comedi is working with per subdevices callbacks far from the Linux driver model. Etc. - Should I leave our framework like it is ? Are we sure that the fact the original Comedi framework is slowly losing contributions is a coincidence ? 4) I tried to exchange with the original Comedi developers (even on the LKML). Nothing emerged from my mails (except that the Comedi maintainers told me to send my contributions to Greg KH and Greg KH told me to send my contributions to the Comedi maintainers). - Do you have any sign that someone is working on the Comedi core ? 5) So far, Comedi/RTDM has only one driver which deserves interest: the National Instruments NI PCIMIO. And it took quite a long time to make it work by myself and I still have some work to do on it. A user still has some troubles with his specific PPC host board. We are striving to find the bug. - Do we really have a significant user base for Comedi/RTDM ? These questions led me to the conclusions I shared in the ML: 1) I have a true worrisome problem: Comedi/RTDM is not living because it lacks users on one side and contributors on the other side. The machine is not running. 2) It is still time to make it overtake by assessing what went wrong. There are Comedi users but they cannot use our framework because of the lack of drivers. 3) The driver is the key. So, the kernel side is the key. We have to improve it in two ways: - (almost) seamlessly recover the original Comedi drivers; - get some feedback on the best way to implement such a framework and make it flexible, because, right now, I am pretty convinced I am in the middle of what people call the midlayer mistake. So, I was not at the plan level yet when I sent the first mail of this thread. I am still in the design phase just in case a redesign needs to be done. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Some thoughts on Analogy kernel side framework
Hi, On Thu, Oct 8, 2009 at 7:37 PM, Philippe Gerum r...@xenomai.org wrote: On Thu, 2009-10-08 at 01:26 +0200, Alexis Berlemont wrote: Hi, The last week, I have been working on the global architecture of the analogy project. I tried to sum-up the main characteristics of Comedi. That was a start to figure out what shape analogy will get. Here are some notes on that subject: 1) Comedi drivers are not common Linux drivers. In these drivers: - there is neither fops structure nor ioctl operations - there is, of course, no cdev registration - The Linux API is sometimes wrapped into Comedi-specific functions (ex. irq). 2) Comedi imposes a specific organization: devices are composed of subdevices which are themselves composed of channels. Then a Comedi driver: - declares a list of subdevices - displays a list of callbacks per subdevices (command, instructions, trigger, etc.). 3) The Comedi midlayer is the link between the Linux driver programming model and the Comedi drivers: - The Comedi core manages a set of pre-registered character devices - Via a specific ioctl, the core assigns a dev file to some driver and an attach callback is called within the driver. - The comedi core is in charge of routing the ioctls to the proper subdevice callbacks. According to me, this architecture brings some troubles: 1) Not all the drivers perfectly fit into the midlayer: - Some components of acquisition cards do not comply with the subdevice model (ex. the mite in NI card). - We find card specific declarations in the Comedi core layer (ex.: some NI specific counter modes in comedi.h); 2) On the user space side, it is difficult to write a card independant application. All these points make me think that the idea of midlayer itself is not suitable in our case. Because of the fact that the drivers do not fit well into the generic programing model, we find ourselves adapting user space programs to the card they will use. I would rather propose a framework composed of helper modules. Analogy drivers would be quite similar with common RTDM drivers (they would contain fops declarations, dev registrations, etc.); As a consequence, Analogy will be a set of tools: - ioctl routing function - acquisition device registration - asynchronous buffer management modules - etc. This sounds like a plan, but this also raises a major concern: what's the status of your current code wrt the upcoming 2.5 now, given that you seem to imply that the current Comedi/RTDM tree does not exhibit the final architecture yet, and your proposal entails fundamental changes? It was made very clear during the recent XUM that 2.5 will be out this year, which leaves us with enough time to tackle the current issues, but likely not to reshuffle a complete framework. We could live with that framework only providing a single acquisition driver in 2.5.0, but the former has to be stable, and the ABI written in stone for the 2.5.x series. Provisions for transparent multi-ABI support might be acceptable, but this still requires to be confident about what would be needed in the long run, and that sudden change in your architecture is worrisome. If I understand well, I have gone too far too soon; the idea should be to keep the current framework as it is for 2.5. However, my former mail was not a definitive plan. The first goal was to share ideas. So, do not worry too much. :) In short, assuming your current work description eventually holds, what's your timing to deliver? With my 1-2 hour(s) per night, I will need many months (at least 4). Eventually, instead of rewriting the whole Comedi drivers suite. I think we can develop an analogy driver which will route the analogy ioctls to the proper Comedi subdevice callbacks. I think everybody will agree to consider this point critical. We must retrieve the Comedi drivers as easy as possible. Full ack. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Some thoughts on Analogy kernel side framework
Hi, The last week, I have been working on the global architecture of the analogy project. I tried to sum-up the main characteristics of Comedi. That was a start to figure out what shape analogy will get. Here are some notes on that subject: 1) Comedi drivers are not common Linux drivers. In these drivers: - there is neither fops structure nor ioctl operations - there is, of course, no cdev registration - The Linux API is sometimes wrapped into Comedi-specific functions (ex. irq). 2) Comedi imposes a specific organization: devices are composed of subdevices which are themselves composed of channels. Then a Comedi driver: - declares a list of subdevices - displays a list of callbacks per subdevices (command, instructions, trigger, etc.). 3) The Comedi midlayer is the link between the Linux driver programming model and the Comedi drivers: - The Comedi core manages a set of pre-registered character devices - Via a specific ioctl, the core assigns a dev file to some driver and an attach callback is called within the driver. - The comedi core is in charge of routing the ioctls to the proper subdevice callbacks. According to me, this architecture brings some troubles: 1) Not all the drivers perfectly fit into the midlayer: - Some components of acquisition cards do not comply with the subdevice model (ex. the mite in NI card). - We find card specific declarations in the Comedi core layer (ex.: some NI specific counter modes in comedi.h); 2) On the user space side, it is difficult to write a card independant application. All these points make me think that the idea of midlayer itself is not suitable in our case. Because of the fact that the drivers do not fit well into the generic programing model, we find ourselves adapting user space programs to the card they will use. I would rather propose a framework composed of helper modules. Analogy drivers would be quite similar with common RTDM drivers (they would contain fops declarations, dev registrations, etc.); As a consequence, Analogy will be a set of tools: - ioctl routing function - acquisition device registration - asynchronous buffer management modules - etc. Eventually, instead of rewriting the whole Comedi drivers suite. I think we can develop an analogy driver which will route the analogy ioctls to the proper Comedi subdevice callbacks. I think everybody will agree to consider this point critical. We must retrieve the Comedi drivers as easy as possible. Many things need to be thought twice but I am quite convinced such a solution is feasible. If some people disagree or have other prospects in mind, I am looking forward to reading them. I think I will create a new branch in my git repository (analogy...) to push ugly and non-working code. The idea is to quickly show the shape of Analogy framework. Feedbacks welcome. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Comedi/RTDM becomes Analogy.
Hi, About two years ago, I started an effort aimed at porting the Comedi framework over RTDM. The goal was to provide, for the acquisition applications, strict determinism from kernel to user space. As the work progressed, it seemed to me that such effort should be an opportunity to improve the Comedi framework itself (the internal buffer management is a good example) A few months back, I tried once again to get some feedback from the original Comedi team, this time about the suggested changes, so that I could eventually submit patches which could get accepted into the mainline Comedi tree. http://marc.info/?l=comedim=114459505305823w=4 http://groups.google.com/group/comedi_list/browse_thread/thread/85be8195ddf52896# http://marc.info/?l=linux-nextm=124078248400745w=2 http://lkml.org/lkml/2009/5/6/543 From the answers I got (or lack thereof), it seems to me that goal #1 for the Comedi team now is rather to get their current code base into Linux mainline, with only the required changes to be accepted upstream. Changing the Comedi internals and/or adjusting its APIs is clearly not on the agenda. Therefore, there is no point in trying to port mainline Comedi over RTDM anymore, hoping for suggested changes to be merged back to the original tree over time. At any rate, the only thing that makes sense now is to keep on developing a full-featured acquisition framework (synchronous and asynchronous analogic/digital acquisitions, calibration tool box, etc.), within the frame of a completely independent effort. To reflect this new orientation, Comedi/RTDM becomes Analogy. By the way, the Analogy renaming does not mean we get rid of digital acquisition features, we still target any control and measurement device. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Pull request for head
The following changes since commit 13d66eb4c8f1648614095d43dd529a3c98fc5278: Philippe Gerum (1): x86: upgrade I-pipe support to 2.6.31-x86-2.4-05 are available in the git repository at: ssh+git://g...@xenomai.org/xenomai-abe.git comedi Alexis Berlemont (46): Replace comedi_channel_* char-typed fields by unsigned long fields. Update indentation, add flags related macros Add missing flags for instructions (configuration type, counter status bits, IO directions and events types). Fix indentation Fix indentation Add range_unknown declaration Add Comedi PCIMIO drivers set Review the subdevice registration system: get closer from Comedi upstream; Rework indentation in testing drivers; Remove useless drivers management functions (comedi_init_drv(), comedi_cleanup_drv()) Replace the first argument type: comedi_cxt_t becomes comedi_dev_t; the context structure is meaningless for the driver developer. Change subdevice related callbacks: replace their first argument: comedi_cxt_t - comedi_dev_t; the context is meaningless for drivers developers. Apply driver API change on testing drivers Slightly optimize the function comedi_get_chan() Change the second argument of the callback do_cmd() (in subdevice structure), the subdevice index is replaced by the command to apply (which contains the subdevice index). Fix typing mistake in the driver fake.c Review the tracing macros, mimic v4l2's system Add the subdevice registration index into the subdevice structure Simplify the declaration of comedi_get_chan Simplify munge function declaration Remove comedi_get_nbchan(), a specific function which became useless, and add comedi_get_subd(), a more general function which might be helpful at attach / detach time. Remove comedi_get_nbchan(), a specific function which became useless, and add comedi_get_subd(), a more general function which might be helpful at attach / detach time. Review trace macros Update 8255 driver Replace forgotten rtdm_printk() by comedi_err() Review traces Update NI TIO driver according to driver API changes Update NI MIO driver according to driver API changes Update NI PCIMIO driver according to driver API changes and fix a bug at the same time Minor indentation change in fake driver source Fix obvious bug in IRQ registering procedure Fix trivial compilation bug. Remove useless argument in the cancel callback Review comedi_get_cmd's arguments: the subdevice descriptor should be enough. Fix trace type (info - err) Properly implement debug traces Fix minor initialization bugs Add more checks in chaninfo, rnginfo ioctls Add comedi_presetup_transfer() function to be called before attach procedure; this function was added to prevent IRQ descriptor overwrite. Add a fake range descriptor; Add basic checks in *_info ioctls Add fake range descriptor Add missing types flags into COMEDI_SUBD_TYPES Fix debug trace routines Fix MSeries_PLL_Enable_Bit wrong definition Add RTSI and clock precompilation constants Improve comedi_buf_evt(): remove ugly subdevice guessing based on flags. Apply modifications due to comedi_buf_evt() declaration change Add missing RTSI / clock configuration routines include/comedi/buffer.h| 19 +- include/comedi/channel_range.h | 25 +- include/comedi/command.h | 22 +- include/comedi/device.h|7 +- include/comedi/driver.h| 24 +- include/comedi/instruction.h | 79 + include/comedi/os_facilities.h | 44 +- include/comedi/subdevice.h | 50 +- include/comedi/transfer.h |1 + ksrc/drivers/comedi/Config.in |2 + ksrc/drivers/comedi/Kconfig| 21 + ksrc/drivers/comedi/Makefile |4 +- ksrc/drivers/comedi/buffer.c | 232 +- ksrc/drivers/comedi/command.c | 64 +- ksrc/drivers/comedi/device.c | 117 +- ksrc/drivers/comedi/driver.c | 39 +- ksrc/drivers/comedi/driver_facilities.c| 112 +- ksrc/drivers/comedi/instruction.c | 20 +- ksrc/drivers/comedi/intel/8255.c | 331 ++ ksrc/drivers/comedi/intel/8255.h | 61 + ksrc/drivers/comedi/intel/Config.in|8 + ksrc/drivers/comedi/intel/Kconfig |5 + ksrc/drivers/comedi/intel/Makefile | 30 + ksrc/drivers/comedi/national_instruments/Config.in |8 + ksrc/drivers/comedi/national_instruments/Kconfig | 20 + ksrc/drivers
Re: [Xenomai-core] Comedi drivers in Xenomai porting/integration status ?
Hi, That was the reason why, I was really suprised to find Comedi integrated into the mainline kernel. What strikes me more is that Comedi seems to be left as is. Do you think, it will be cleaned up or reworked ? Without rework Comedi will not make into mainline (I wouldn't call the staging corner mainline). And when reading this http://permalink.gmane.org/gmane.linux.kernel/793476, it is probably the best time now to propose interface changes and contribute back improvements made for the RTDM rework. How would you proceed ? Maybe, the first step would be to ask on the Comedi mailing-list if someone is interested in discussing on the API rework. Maybe, someone will answer this time. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Comedi drivers in Xenomai porting/integration status ?
Hi,
Peter Soetens peter.soet...@fmtc.be writes:
On Tuesday 17 February 2009 10:41:10 Jan Kiszka wrote:
Peter Soetens wrote:
These are the facts we observed:
* The Xenomai/Comedi port breaks the complete Comedi API, user space
*and* kernel space. (We thought/assumed that only the user space
interface would go over RTDM and that once that was done, the kernel
modules could be almost copy/pasted into the new framework.)
Maybe you have a list of the major differences. Then please share it so
that the motivation can be discussed here and maybe clarified (it's a
blurred topic for me as well).
Damn. I should have posted back then :-) Our main lead was the Doxygen pages,
from which we went on to see how things were done in code. Unfortunately (?),
I'm not a Comedi developer, I twiddled only with one Comedi driver. Once. I
can't really compare to the bone. But what was clear immediately was that
both
user API and kernel API were different.
User ('Library') API was cleaned up and streamlined, we could live with that
for new applications. I'm sure there are still issues, but they'll only come
up once people start using this branch. I like the separation between a low
level 'instruction' api and a high level 'function' api. Something upstream
comedi mixes to much.
For kernel ('Driver') API, a new data transfer mechanism is in place, which
requires the 'porting' of all drivers. I genuinely can't estimate how
drastically this changes existing drivers, but the API is quite huge and
works
with the 'inversion of control' paradigm: Each driver must implement a series
of hooks, and the Comedi/RTDM framework will call these when necessary.
Just to sum-up why the whole Comedi API suffers so many changes from
the upstream Comedi API (sorry for 'legacy'):
* At the very beginning (If I remember well), I just wanted to port
the current Comedi layer so as to comply with RTDM API. My first
resolution was to leave the drivers set unchanged so as to
seamlessly use them in the ported framework. However, I was facing
many issues (RT/NRT contexts, mix with kernel API, etc.) I could not
handle without altering drivers code. Eventually, I was unable to
provide a coherent RTDM Comedi module considering the code
organization.
* That was the point which makes try to overhaul the original
branch. I sent an email on the Comedi mailing list. I received no
answer; by the way, the activity seemed quite low. I wanted to
develop a Comedi infrastructure usable on both configurations
(common Linux API and RTDM). Fulfilling such a constraint led me to
redefine the kernel driver API. Before integrating the code into
Xenomai's trunk, I decided to drop the common Linux interface while
keeping in mind that the RTDM-native module would allow the new
Comedi core to run on common kernels (maybe that was a
mistake). That is why, the driver API still have the context notion;
I should remove it.
Then I did my best to design a coherent layer. There are still many
flaws to be improved. Notably at the driver level, the API is too
closed. I (and/or anyone interested) should find a way to provide more
freedom to drivers developers.
Concerning the library API, I just thought there were too many
functions in comedilib, and some were redundant with each other. I
tried to propose an alternative like the native skin API was an
alternative to the RTAI API. Maybe I was wrong.
All that work relied on my assumption that upstream Comedi was not
very active anymore. Then, it was an opportunity for me to have fun
trying to deliver an RTDM port based on a new architecture.
That was the reason why, I was really suprised to find Comedi
integrated into the mainline kernel. What strikes me more is that
Comedi seems to be left as is. Do you think, it will be cleaned up or
reworked ?
Another fact I shouldn't have omitted:
* The Xenomai/Comedi layer is very well documented and allows anyone to learn
from it, even the upstream maintainers.
* Seen from my little device driver knowledge, the technical implementation
looks ok for synchronous/asynchronous reading and writing. Memory mapped IO
is
not available, it seems, and the classical comedi_config, inp,outp,... family
isn't complete yet either.
I thought comedi_buf_prepare/commit functions were OK to implement
memory mapped IO. Could you explain me what must be added?
For comedi_config, could you tell me what is missing?
I believe Alexis can defend his design better than anyone else, and it's not
the design I wanted to tackle. It's how he plans to maintain it.
Once Philippe told me: one never knows.. a misunderstanding could
make it work ;)
Seriously, I thought the Xenomai/Comedi could be an interesting
alternative for the original Comedi to keep on providing open source
drivers for data acquisition cards. I understand that the API breakage
is a critical issue which threatens its interest. I will reconsider
the
Re: [Xenomai-core] Comedi drivers in Xenomai porting/integration status ?
Hi, Hello all! I would like to know what is the current status of the Comedi port to Xenomai. Should all the specific Comedi drivers (ni_pcimio, ni_mite) be available for testing (by me or someone with a supported DAQ card) and (if ok) for futher integration ? I am still working on that port. It is a long work and I am wondering at each line whether I should rewrite any part of code which does not comply with common coding constraints. Unfortunately, I currently do not have a lot of spare time. Anyway, most of the ni subdevices drivers have been ported (mite, tio, mio, 8255). I am trying to finalize the global driver port. By the way, in the middle of january, I noticed that the legacy Comedi branch found its way into the mainline (through the staging tree). I do not know what will be the future of such a package in mainstream. I assume the main goal is the definition of a global framework for acquisition boards like V4L2 is for video cards. Starting from here, I have been thinking on some alternatives so as to benefit from the kernel code. But I am a bit perplexed as the code does not seem to evolve a lot (the 2.6.29-rc5 patch still contains some rtlinux/rtai/fusion related code). I was unable to notice any significant work on the framework to reach main kernel standards. Since the beginning of January, there was only one mail thread which dealt with Comedi on the lkml (which is, by the way, interesting): http://lkml.org/lkml/2009/2/9/335 I would be very interested in opening a discussion on that issue so as to define Comedi's next steps in Xenomai. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/2] RTDM in user mode
Hi, I already created some local branch with your patches and compiled them. Only minor issues visible: please check for pointer-int conversion warnings on 64-bit - and please add spaces after if, while, for etc. :). I will look into this in more details soon. OK. Did you already tried to build or even run some existing single-user driver against your extension? I'm thinking of the 16550A e.g. (it even has a test case). Also the irqbench driver could be a candidate. Is there some standard how-to-convert/build procedure? OK. I will try to port these drivers into user-space. Before doing that, I just have to develop the framework for common kernel API (lists, ioremap, test_*_bit, etc.). Many thanks for having a look at these patches. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 2/2] RTDM in user mode
Patch 2: examples.
Makefile | 94
test01_task.c | 62 ++
test02_event_sem.c | 160 +++
test03_timer.c | 60 +
test04_mutex.c | 86 +
test05_nrtsig.c| 82
test06_spinlock.c | 84 +
test07_heap.c | 76 ++
test08_device.c| 131 +++
test09_driver.c| 150
test10_mmap.c | 177 +
11 files changed, 1162 insertions(+)
Index: examples/rtdm/user-api/Makefile
===
--- examples/rtdm/user-api/Makefile (revision 0)
+++ examples/rtdm/user-api/Makefile (revision 0)
@@ -0,0 +1,94 @@
+
+## CONFIGURATION ##
+
+### List of applications to be build
+APPLICATIONS = test01_task test02_event_sem test03_timer \
+ test04_mutex test05_nrtsig test06_spinlock test07_heap \
+ test08_device test09_driver test10_mmap
+
+### Note: to override the search path for the xeno-config script, use make XENO=...
+
+
+### List of modules to be build
+MODULES =
+
+### Note: to override the kernel source path, use make KSRC=...
+
+
+
+## USER SPACE BUILD (no change required normally) ##
+ifeq ($(KERNELRELEASE),)
+ifneq ($(APPLICATIONS),)
+
+### Default Xenomai installation path
+XENO ?= /usr/xenomai
+
+XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config 2/dev/null)
+
+### Sanity check
+ifeq ($(XENOCONFIG),)
+all::
+ @echo Invoke make like this: \make XENO=/path/to/xeno-config\
+ @echo
+endif
+
+
+CC=$(shell $(XENOCONFIG) --cc)
+
+CFLAGS=$(shell $(XENOCONFIG) --xeno-cflags) $(MY_CFLAGS)
+
+LDFLAGS=$(shell $(XENOCONFIG) --xeno-ldflags) $(MY_LDFLAGS) -lrtdm_user
+
+# This includes the library path of given Xenomai into the binary to make live
+# easier for beginners if Xenomai's libs are not in any default search path.
+LDFLAGS+=-Xlinker -rpath -Xlinker $(shell $(XENOCONFIG) --libdir)
+
+all:: $(APPLICATIONS)
+
+clean::
+ $(RM) $(APPLICATIONS) *.o
+
+endif
+endif
+
+
+
+## KERNEL MODULE BUILD (no change required normally) ##
+ifneq ($(MODULES),)
+
+### Default to sources of currently running kernel
+KSRC ?= /lib/modules/$(shell uname -r)/build
+
+OBJS := ${patsubst %, %.o, $(MODULES)}
+CLEANMOD := ${patsubst %, .%*, $(MODULES)}
+PWD := $(shell if [ $$PWD != ]; then echo $$PWD; else pwd; fi)
+
+### Kernel 2.6
+ifeq ($(findstring 2.6,$(KSRC)),2.6)
+
+obj-m:= $(OBJS)
+EXTRA_CFLAGS := -I$(KSRC)/include/xenomai -I$(KSRC)/include/xenomai/posix $(ADD_CFLAGS)
+
+all::
+ $(MAKE) -C $(KSRC) SUBDIRS=$(PWD) modules
+
+### Kernel 2.4
+else
+
+ARCH?= $(shell uname -i)
+INCLUDE := -I$(KSRC)/include/xenomai -I$(KSRC)/include/xenomai/compat -I$(KSRC)/include/xenomai/posix
+CFLAGS += $(shell $(MAKE) -s -C $(KSRC) CC=$(CC) ARCH=$(ARCH) SUBDIRS=$(PWD) modules) $(INCLUDE)
+
+all:: $(OBJS)
+
+endif
+
+## Target for capturing 2.4 module CFLAGS
+modules:
+ @echo $(CFLAGS)
+
+clean::
+ $(RM) $(CLEANMOD) *.o *.ko *.mod.c Module*.symvers Module.markers modules.order
+ $(RM) -R .tmp*
+
+endif
Index: examples/rtdm/user-api/test01_task.c
===
--- examples/rtdm/user-api/test01_task.c (revision 0)
+++ examples/rtdm/user-api/test01_task.c (revision 0)
@@ -0,0 +1,62 @@
+/*
+ * Copyright (C) 2005 Joerg Langenberg joerg.langenb...@gmx.net.
+ * Copyright (C) 2008 Alexis Berlemont alexis.berlem...@free.fr.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include stdio.h
+#include sys/mman.h
+
+#include rtdm/rtdm_driver.h
+
+void task_proc(void *arg)
+{
+ int i;
+
+ printf(test01_task[RT]: task started\n);
+
+ for(i = 0; i 10; i++) {
+ rtdm_task_sleep(10);
+ printf(test01_task[RT]: task awoken (i=%d)\n, i);
+ }
+
+ printf(test01_task: leaving task\n);
+}
+
+int main(int argc, char *argv[])
+{
+ rtdm_task_t task;
+ int err;
+
+ mlockall(MCL_CURRENT|MCL_FUTURE);
+
+ err = rtdm_task_init(task,
+ TEST TASK,
+ task_proc, NULL, RTDM_TASK_HIGHEST_PRIORITY, 0);
+
+ if(err != 0) {
+ printf
[Xenomai-core] [PATCH 1/2] RTDM in user mode
Patch 1: user-side code.
Alexis.
Makefile.am | 15 +
device.c| 569 +
drvlib.c| 636
init.c |6
internal.h | 119 +++
wrappers.c | 95
wrappers.h | 26 ++
7 files changed, 1463 insertions(+), 3 deletions(-)
Index: src/skins/rtdm/Makefile.am
===
--- src/skins/rtdm/Makefile.am (revision 4513)
+++ src/skins/rtdm/Makefile.am (working copy)
@@ -1,4 +1,4 @@
-lib_LTLIBRARIES = librtdm.la
+lib_LTLIBRARIES = librtdm.la librtdm_user.la
librtdm_la_LDFLAGS = -version-info 1:0:0 -lpthread
@@ -9,3 +9,16 @@
librtdm_la_CPPFLAGS = \
@XENO_USER_CFLAGS@ \
-I$(top_srcdir)/include
+
+librtdm_user_la_LDFLAGS = -version-info 1:0:0 -lpthread
+
+librtdm_user_la_SOURCES = \
+ init.c \
+ drvlib.c \
+ device.c \
+ wrappers.c \
+ wrappers.h
+
+librtdm_user_la_CPPFLAGS = \
+ @XENO_USER_CFLAGS@ \
+ -I$(top_srcdir)/include
Index: src/skins/rtdm/device.c
===
--- src/skins/rtdm/device.c (revision 0)
+++ src/skins/rtdm/device.c (revision 0)
@@ -0,0 +1,569 @@
+/*
+ * Copyright (C) 2005 Joerg Langenberg joerg.langenb...@gmx.net.
+ * Copyright (C) 2008 Alexis Berlemont alexis.berlem...@free.fr.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include stdio.h
+#include stdarg.h
+#include stddef.h
+#include string.h
+#include errno.h
+
+#include rtdm/rtdm.h
+#include rtdm/rtdm_driver.h
+#include rtdm/syscall.h
+#include asm-generic/bits/sigshadow.h
+#include asm-generic/bits/current.h
+
+#include internal.h
+
+#define DEV_MAX_COUNT 16
+#define FD_MAX_COUNT 32
+#define MAP_MAX_COUNT 16
+
+#define SET_DEFAULT_OP(device, operation)\
+ (device).operation##_rt = (void *)rtdm_no_support; \
+ (device).operation##_nrt = (void *)rtdm_no_support
+
+#define SET_DEFAULT_OP_IF_NULL(device, operation) \
+ if (!(device).operation##_rt) \
+ (device).operation##_rt = (void *)rtdm_no_support; \
+ (device).operation##_nrt = (void *)rtdm_no_support
+
+struct map_entry {
+ unsigned long map_addr;
+ void *vm_private_data;
+ struct vm_operations_struct *vm_ops;
+};
+
+static atomic_tab_t reg_cxts = {
+ .count = FD_MAX_COUNT,
+ .elements = { [0 ... FD_MAX_COUNT - 1] = { {0}, NULL} }
+};
+
+static atomic_tab_t reg_devs = {
+ .count = DEV_MAX_COUNT,
+ .elements = { [0 ... DEV_MAX_COUNT - 1] = { {0}, NULL} }
+};
+
+static atomic_tab_t reg_maps = {
+ .count = MAP_MAX_COUNT,
+ .elements = { [0 ... DEV_MAX_COUNT - 1] = { {0}, NULL} }
+};
+
+int rtdm_no_support(void)
+{
+ return -ENOSYS;
+}
+
+int rtdm_select_bind_no_support(struct rtdm_dev_context *context,
+struct xnselector *selector,
+unsigned type,
+unsigned index)
+{
+ return -EBADF;
+}
+
+int rtdm_dev_register(struct rtdm_device *device)
+{
+ unsigned int idx = 0;
+ int err = 0;
+
+ if(device-struct_version != RTDM_DEVICE_STRUCT_VER)
+ return -EINVAL;
+
+ switch (device-device_flags RTDM_DEVICE_TYPE_MASK) {
+ case RTDM_NAMED_DEVICE:
+ SET_DEFAULT_OP_IF_NULL(*device, open);
+ SET_DEFAULT_OP(*device, socket);
+ break;
+ case RTDM_PROTOCOL_DEVICE:
+ SET_DEFAULT_OP_IF_NULL(*device, socket);
+ SET_DEFAULT_OP(*device, open);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!device-ops.close_rt)
+ device-ops.close_rt = (void *)rtdm_no_support;
+
+ SET_DEFAULT_OP_IF_NULL(device-ops, ioctl);
+ SET_DEFAULT_OP_IF_NULL(device-ops, read);
+ SET_DEFAULT_OP_IF_NULL(device-ops, write);
+ SET_DEFAULT_OP_IF_NULL(device-ops, recvmsg);
+ SET_DEFAULT_OP_IF_NULL(device-ops, sendmsg);
+
+ device-ops.select_bind = rtdm_select_bind_no_support;
+
+ err = atab_try_add(reg_devs, idx);
+ if(err 0)
+ return err;
+
+ return atab_do_add(reg_devs, idx, (void *) device);
+}
+
+int rtdm_dev_unregister(struct rtdm_device *device, unsigned int poll_delay)
+{
+ int i = 0, fnd = 0, err = -EINVAL;
+
+ do {
+
+ err = atab_lock(reg_devs, i);
+ if(err 0)
+ return err;
+
+ if(reg_devs.elements[i].element == (void *)device)
+ fnd = 1;
+
+ err = atab_unlock(reg_devs, i);
+ if(err 0)
+ return err;
+
+ } while( fnd == 0 ++i DEV_MAX_COUNT);
+
+ err = atab_try_remove(reg_devs, i);
+ if(err 0)
+ return err
Re: [Xenomai-core] Unstable driver integration policy
Hi Philippe, Hi Jan, Many thanks for your answers. I would like to find a way to populate the Comedi drivers set. However, I am stuck by a simple fact: I have no acquisition board to validate a least driver... Starting from here, I am trying to find out what should be the proper method to provide non-validated drivers to anybody inclined to test them. Do you think creating a specific subversion branch for this stuff would be a good idea ? I don't think so. Moving that code away from the focal point where people are expected to find new code to test and work with won't help. You could decide instead to implement drivers for a small set of very popular acquisition cards; whether that implementation is eventually fully validated or not depends on other people to have enough interest in that work to give you access to some hw, or to validate the driver themselves. As Jan pointed out, experimental is a convenient sticker to tell people about the exact state of this work. You spark the effort (this is _always_ the hardest and most demanding part of the job), they help finalize it if they want to get serious about this. OK. I thought adding unstable drivers into the trunk was too risky. I forgot about using the experimental flag. Regards, Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Unstable driver integration policy
Hi, I would like to find a way to populate the Comedi drivers set. However, I am stuck by a simple fact: I have no acquisition board to validate a least driver... Starting from here, I am trying to find out what should be the proper method to provide non-validated drivers to anybody inclined to test them. Do you think creating a specific subversion branch for this stuff would be a good idea ? Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Comedi buffer management.
Hi Gilles, Sorry for answering so late. I was unable to regularly check my private mails the last week; I missed yours. I commited in trunk a fix of Xenomai heap management for the highmem case. What the patch does is essentially replacing __va_to_kva (which does not work correctly with highmem) with vmalloc_to_page, which is available on all linux versions Xenomai supports. However, I found that comedi buffer management also uses __va_to_kva. We can fix SetPageReserved and ClearPageReserved easily to use vmalloc_to_page, however, I do not see what pg_list is used for, so do not really know how to fix it. Here is a proposed patch: If I remember well, pg_list may be used by some PCI/PCIe DMA components which can dump acquired data to physically non-contiguous buffers. In such cases, the driver has to provide a list of the pages addresses into which the DMA controller can trigger shots. Many thanks for your fix. Alexis. Index: ksrc/drivers/comedi/buffer.c === --- ksrc/drivers/comedi/buffer.c (revision 4211) +++ ksrc/drivers/comedi/buffer.c (working copy) @@ -46,7 +46,7 @@ void comedi_free_buffer(comedi_buf_t * b unsigned long vaddr, vabase = (unsigned long)buf_desc-buf; for (vaddr = vabase; vaddr vabase + buf_desc-size; vaddr += PAGE_SIZE) - ClearPageReserved(virt_to_page(__va_to_kva(vaddr))); + ClearPageReserved(vmalloc_to_page(vaddr)); vfree(buf_desc-buf); buf_desc-buf = NULL; } @@ -73,7 +73,7 @@ int comedi_alloc_buffer(comedi_buf_t * b for (vaddr = vabase; vaddr vabase + buf_desc-size; vaddr += PAGE_SIZE) - SetPageReserved(virt_to_page(__va_to_kva(vaddr))); + SetPageReserved(vmalloc_to_page(vaddr)); buf_desc-pg_list = comedi_kmalloc(((buf_desc-size) PAGE_SHIFT) * sizeof(unsigned long)); @@ -85,7 +85,7 @@ int comedi_alloc_buffer(comedi_buf_t * b for (vaddr = vabase; vaddr vabase + buf_desc-size; vaddr += PAGE_SIZE) buf_desc-pg_list[(vaddr - vabase) PAGE_SHIFT] = - __va_to_kva(vaddr); + (unsigned long) vmalloc_to_page(vaddr); out_virt_contig_alloc: if (ret != 0) Cheers. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] application porting to Comedi4RTDM
Hi, Sorry for answering so late (not at home, no access to my private mails, not even able to answer your mail properly). Even if the Comedi API has been slightly modified, the Comedi principles remain the same. Consequently, I think you will be able to port your application to Comedi4RTDM. Which kernel driver are you using for your application? The first step would be the porting of the driver on Comedi4RTDM. I am very interested on porting legacy Comedi drivers to the new framework; unfortunately, I have no hardware to validate the new drivers... Concerning the user application, maybe the best way to get familiar with the changes in the user API would be thanks to the doxygen documentation. This documentation is available in the subversion trunk but you will have to generate it yourself. Regards. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems using rt_intr_wait on PowerPC
Hi, Based on the user_irq.c I created a simple test program for my PPC405GPr board. We have a FPGA which generates an interrupt every millisecond. It seems to work as simple test (fire it once and assure that it sets the interrupt-bit). When I connect it to the irq_server however (letting the main task sleep 1 second) I get around 2321964 error and not a single OK from rt_intr_wait. Also my debug LED flicker very fast. The FPGA is connected to the External Interrupt 0, which has the number 25. I think that I either got the polarity/level/edge register wrong or I am playing with the wrong interrupt. Could anybody tell me, whether I used the correct interrupt number? I think you are OK on that point. Just beware that your 405GPr can work in two modes: - 7 external interrupts and x GPIO lines - 13 external interrupts and x-6 GPIO lines However, I think the IRQ 25 is the external interrupt 0 in both cases. That issue is detailed in the AMCC user manual. Does Linux somewhere overwrite the values for the UIC polarity/level, etc settings written by U-Boot (e.g. for my board in board_early_init_f) That may be the case. Have a look at the header linux/include/asm-ppc/ppc4xx_pic.h (if you are using the old ppc branch). If you are using the powerpc branch, check whether the function uic_set_irq_type() is called. For example, if you are using the sycamore eval board (and the old ppc branch), all the external interrupts are configured in level mode with negative polarity (arch/ppc/platforms/4xx/sycamore.c). Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] skin RTDM in user mode
Hi, - Or do you expect a more complete solution like fuse or fusd ? There are a few tricky parts when you want a seamless driver API, allowing to test or even use RTDM drivers in userspace: - IRQ handling (means: forwarding, acknowledging, sharing). You won't be able to achieve 100% equivalent functionality here, of course. On that point I thought about some hidden dedicated task(s) / thread(s): either one task per interrupt or one task per CPU for all interrupt (the second alternative may seem better). The issue is to be as close as possible from the functioning in kernel mode: - This task must work with the highest priority as an IRQ handler cannot be preempted (yet...). - The spinlock mechanism could be emulated thanks to an interrupt lock (to emulate irq masking and a common mutex. Thus, by taking the interrupt lock, any RT task can indirectly prevent the IRQ user-handler execution. - Managing the driver context. When in kernel space, driver code can run in RTDM tasks (that trivial to port), in IRQ context (= probably some carrier task then) or caller context - and here the problem starts. Single-user drivers could simply run as library within the context of the user, but for shared drivers we need some framework that deals with accessing user data which we could easily in kernel space, but not when the driver has its own process or should run within multiple user space contexts. The driver code would be executed by a process but this driver context would be hidden behind the context of the application which uses the driver. Here are the cases, I have in my head: - one application uses one device managed by one kernel module (like misc device); = the simplest case: with one thread inside the driver user-process, we emulate the application context; - many applications uses the same device managed by one kernel module = if we are on a SMP config, we might need one thread per CPU-core inside the driver user-process; - many applications uses many devices managed by the the same kernel module (common char devices) = In this configuration, a driver thread must wait for commands coming many contexts; however, this issue could easily be handled by the kernel module devoted to redirect syscall. Therefore I think such a development could be divided in two steps: - the first one would be the extension of a part of the RTDM API in user-mode (most of the functions located in drvlib.c) - the second one would be the syscall redirection. The second part can be implemented in two ways: - the RTDM kernel skin is extended; - an RTDM kernel driver is developed (this driver would handle ioctl coming from the user-driver (copy_from_user, register_device, wait_command, etc.) and the user-application (open, read, write, close). Which one do you think is the best? On my side, I started the first alternative (kernel skin extension) so as to check that my ideas could be translated in code lines (it is just a POC which does not work yet). Alexis. P.S.: I sent the first mail sunday night, I don't know why it took more than one day to reach its destination. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] comedi: Fix include for do_div
Hi, Sorry for answering so lately, I was not at home the last four days. Required with 2.6.26 where there is no more calc64. And asm/div64.h is what you actually want. Thanks. PS: Kernel-style reformatting would be nice - one day... :- Today or tomorrow, that sould be done. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Comedi4xenomai (Was: Re: [Orocos-Dev] [Bug 115] [Project] Move device drivers to orocos-components)
Hi, This could change fast with e.g. comedi4xenomai in the pipeline... Do you have more information about this? [putting Alexis Berlemont in cc:, as he is probably the one who can answer this question] I haven't seen anything on the xenomai MLs lately. AFAIS from http://svn.gna.org/viewcvs/xenomai/branches/ there hasn't been a lot of activity on the branch lately. Sorry for answering so late, I was on holiday. comedi-over-rtdm is currently undergoing deep modifications. I am trying to redefine an architecture more suitable for RTDM. That implies I am rewriting a big chunk of the Comedi code and its drivers without commiting into SVN. I thought it was a bad idea to commit broken code (It does not even compile). Tell me if I'm wrong. This is one of the two reasons why you did not notice any change on the comedi branch in the SVN trunk the last two months. The other reason is private, bought a little flat = moved out = moved in = working on the appartment = all this stuff took and is still taking a lot of my spare time ;) Eventually, if anyone is interested in the new comedi4xeno architecture, I will try to commit a reduced version in two or three weeks. I don't know if that means the comedi-over-rtdm code is already in a usable state as is? The code available in the trunk is a proof of concept, it does not contain real drivers, you can just find test drivers. Regards. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: LTTng intergration roadmap
Hi, the need for a high-level tracing tool constantly increases with the growing code base of Xenomai applications. Yesterday I started a short discussion with Alexis about the status of his LTTng combo patch, the Xenomai integration, and the advances of LTTng itself. But there are certainly more people interested in this topic and may contribute ideas, comments, or even concrete code. Daniel, you once said that some of your students would start to work on this topic. In which domain precisely, more at patch level or rather on tools? What is the scheduled beginning and/or deadline for this thesis? Moreover, does anyone on this list recently tried LTTng on standard Linux? Can we consider it reasonably stable and usable? One new thing about LTTng internals which Alexis brought up were changes in the custom tracing event interface. As this is a rather crucial point with respect to the Xenomai instrumentation, we certainly do not want to change it back and forth until LTTng stabilises. Here is a little quotation from the LTTng Quickstart guide, I used it to define the LTT events for Xenomai: * Add new events to the kernel with genevent su - cd /usr/local/share/LinuxTraceToolkitViewer/facilities cp process.xml yourfacility.xml * edit yourfacility.xml to fit your needs. cd /tmp /usr/local/bin/genevent /usr/local/share/LinuxTraceToolkitViewer/facilities/yourfacility.xml cp ltt-facility-yourfacility.h ltt-facility-id-yourfacility.h \ /usr/src/linux-2.6.16-lttng-0.x.xx8/include/linux/ltt cp ltt-facility-loader-yourfacility.c ltt-facility-loader-yourfacility.h \ /usr/src/linux-2.6.16-lttng-0.x.xx/ltt * edit the kernel file you want to instrument - Add #include linux/ltt/ltt-facility-yourfacility.h at the beginning of the file. - Add a call to the tracing functions. See their names and parameters in /usr/src/linux-2.6.16-lttng-0.x.xx/include/linux/ltt/ltt-facility-yourfacility.h So, In order to test the combo patch adeos + LTTng I made: - I wrote xenomai.xml (cf. attached file) which defines all the Xeno-LTT events; - I used genevent so as to generate the sources and the headers relative with my events; - Instead of copying them in the kernel, I integrated the sources in Xenomai. I was considering that the Xeno events was independant from Linux. As a matter of fact, the last point should be rethought as the Xeno build procedure is now integrated in the kernel. Things are simpler now, we could create an I-pipe aware LTTng patch which could contain : - the modifications in Relayfs (for a proper functioning with Adeos); - the LTTng core stuff adapted for Adeos (not much work to do on this part); - the Xenomai events in include/linux/ltt, and the loading code in ... This patch would be applied after the I-pipe patch (in the same way as the I-pipe tracer patch). So there would be no need to make combo patches, an arch-independant additionnal patch would be easier to maintain. What do you think of that ? Eventually, concerning LTTng stabilisation status, I had a look a their mailing-list (I am lurking on it since the beginning of LTTng) and at their roadmap: starting from now, their TODO list contains integration and ports, therefore undertaking an integration of LTTng with Xenomai (rigth now or next month) does not seem too risky, does it? Jan, Yesterday I told you that that Matthieu Desnoyers proposed a new way of defining custom events since my last patch proposal. That was false: MD proposed his new method before my patch proposal; however, the genevent features kept on evolving. Sorry that was not very clear. Best regards. Alexis. facility name=xenomai descriptionThe Xenomai facility has events related to Xenomai process execution./description event name=xeno_timer_tick descriptionXenomai timer tick/description field name=runthreadstring//field /event event name=xeno_irq_enter descriptionXenomai irq enter/description field name=irquint size=4//field /event event name=xeno_irq_exit descriptionXenomai irq exit/description field name=irquint size=4//field /event event name=xeno_resched descriptionXenomai reschedule event/description /event event name=xeno_smpsched descriptionXenomai smp schedule event/description /event event name=xeno_fastsched descriptionXenomai fast schedule event/description /event event name=xeno_switch descriptionXenomai process switch/description field name=fromstring//field field name=tostring//field /event event name=xeno_fault descriptionXenomai fault/description field name=threadstring//field field name=locationpointer//field field name=trapuint size=4//field /event event name=xeno_callout descriptionXenomai callout/description field name=typestring//field field name=threadstring//field /event event name=xeno_finalize descriptionXenomai finalize/description
[Xenomai-core] Re: COMEDI over RTDM (was: rtdm_event_timedwait hang-up)
Hi,
But there are plenty of things I am not happy with :
- the original comedilib version is not really well suited for rtdm. In
this library for many reasons; for example, you can find calls to
malloc/free
Oops, not so nice.
functions. If I stick to the original implementation, I have to either to
ask for adding alloc stuff in user mode in rtdm skin or use another skin
to manage allocations. None of these solutions seems interesting for me
for many reasons. A lot of people must be thinking I am overkill, it is
true that the comedilib allocations should be done at init time
(comedi_open, comedi_close) then no need to fulfull real-time constraints
but I think comedi should be fully rtdm compliant; this would avoid
tricky corner cases for
developpers/users. The best and simplest solution for me would be some
slight modifications in the comedilib API but I doubt everyone is OK with
that.
Could you give some concrete use cases of the comedilib where dynamic
allocation is involved? I don't know that library actually. What does it
manage beyond calling the driver core?
In the function comedi_open() :
if(!(it=malloc(sizeof(comedi_t
goto cleanup;
memset(it,0,sizeof(comedi_t));
if((it-fd=rt_dev_open(fn,0))0)
{
fprintf(stderr, comedi_open: rt_dev_open failed (ret=%d)\n,
it-fd);
goto cleanup;
}
if(comedi_ioctl(it-fd, COMEDI_DEVINFO,
(unsigned long)it-devinfo)0)
goto cleanup;
it-n_subdevices=it-devinfo.n_subdevs;
get_subdevices(it);
...
We can see an allocation for a structure which will contain the result (fd)
of rt_dev_open(). And this is not over, the function get_subdevices() will
make another allocation to keep info about the driver (subdevice, number of
channels, etc.). And this function get_subdevices() will trigger more
allocations by calling get_rangeinfo(). In fact, malloc() is called eight
times.
All disallocations are done in comedi_close().
Starting from here, we have two alternatives:
- preallocate enough structs the first time comedi_open() is called. mmh...
- modify the comedilib API to let the developper handle the allocations.
- I think the comedi structures organization (comedi_device, subdevice,
async, etc.) should be reviewed considering the rtdm architecture. Of
course, these modifications should not induce big changes in the comedi
drivers source.
Please also give concrete examples here. RTDM devices should be
manageable by the user via file descriptors, just like normal devices.
There is a little difference with normal devices and classical drivers. The
link between a device and a driver is not direct. The comedi layer affects a
comedi device (/dev/comedi0..9 or comedi0..9) to a specific driver at runtime
thanks to a specific ioctl (cf. comedi_config in comedilib). This is the
comedi attach stuff.
At this level, I may think it would be interesting to consider quite precisely
the layer organization. I have not well understood the architectural border
between what must be done by the driver and what must be done by the abstract
layer.
For example, here is a description of the attaching procedure:
1) the devconfig ioctl is received by the abstract comedi layer;
2) the abstract layer (in comedi/drivers.c) calls do_devconfig_ioctl() which
makes some allocations and a few setups in the structure comedi_device, the
the function comedi_device_attach() is called;
3)In comedi_device_attach(), we check if the proper driver whether available
(insmoded), if so a driver specific function is called;
4) in this driver function, we have access to the structures of the abstract
layer and we modify them (comedi_subdevice);
5) back in the abstract layer, the function postconfig() is called to setup
the struct comedi_async (this struct belongs to a comedi_subdevice).
To sum up:
- comedi_device { (managed by the abstract layer)
- comedi_subdevice { (managed by the driver)
- comedi_async (managed by the abstract layer)
}
}
I am not sure I am clear (it is quite hard to explain without source code),
but I think the drivers should not get direct access to the structures of the
abstract layer.
You may find this points useless, all this stuff is not directly related with
rtdm functionnalities, I just thought the rtdm port would be a good
opportunity to think about that.
What is different, what extra information is needed?
. I just think some fields could be removed or grouped in comedi_subdevice
(lock, busy, etc.) and we could integrate in comedi_async the nonblocking
info. This is minor.
I may have some more points to share with you but I have to keep them for
tomorrow night.
Release early, release often ;). I would offer to have a look, maybe it
will clarify where the RTDM-specific problems are.
OK sorry for tonight, hard day...
Alexis.
___
Xenomai-core mailing list
[Xenomai-core] Ipipe xenomai and LTTng
Hi, The patch available at http://download.gna.org/adeos/patches/v2.6/i386/combo/adeos-ipipe-2.6.14-i386-1.1-00-lttng-0.5.0a.patch is a Ipipe + LTTng patch for the 2.6.14.5-i386 kernel release. In order to trace LTTng events in Xenomai, the patch xenomai-2.1-rc1-lttng-05.patch.bz2 is necessary, this patch replaces the former LTT code with calls to LTTng tracing functions. This Xenomai patch is an experimental ugly try, it does not contain any filter facilities. All Xeno events are recorded. I have used the tool genevent' (available on the LTTng site) to generate all C tracing functions. If anyone is OK to test this stuff, please use the QUICKSTART file available at http://ltt.polymtl.ca/svn/ltt/branches/poly/QUICKSTART (just replace the LTTng patches by our Ipipe + LTTng patch). This patch has been created and tested with the folloving patches and packages: - adeos-ipipe-2.6.14-i386-1.1-00.patch - patch-2.6.14-lttng-0.5.0a.tar.bz2 - lttng-modules-0.4.tar.gz - LinuxTraceToolkitViewer-0.8.0-17122005.tar.gz - genevent-0.3.tar.gz The Ipipe patch comes from the Adeos download area and the LTTng stuff is available at the following address : http://ltt.polymtl.ca/ This patch has only been tested on a UP machine. Alexis. xenomai-2.1-rc1-lttng-05.patch.bz2 Description: BZip2 compressed data
[Xenomai-core] Ipipe xenomai and LTTng
Hi, The patch available at http://download.gna.org/adeos/patches/v2.6/i386/combo/adeos-ipipe-2.6.14-i386-1.1-00-lttng-0.5.0a.patch is a Ipipe + LTTng patch for the 2.6.14.5-i386 kernel release. In order to trace LTTng events in Xenomai, the patch xenomai-2.1-rc1-lttng-05.patch.bz2 is necessary, this patch replaces the former LTT code with calls to LTTng tracing functions. This Xenomai patch is an experimental ugly try, it does not contain any filter facilities. All Xeno events are recorded. I have used the tool genevent' (available on the LTTng site) to generate all C tracing functions. If anyone is OK to test this stuff, please use the QUICKSTART file available at http://ltt.polymtl.ca/svn/ltt/branches/poly/QUICKSTART (just replace the LTTng patches by our Ipipe + LTTng patch). This patch has been created and tested with the folloving patches and packages: - adeos-ipipe-2.6.14-i386-1.1-00.patch - patch-2.6.14-lttng-0.5.0a.tar.bz2 - lttng-modules-0.4.tar.gz - LinuxTraceToolkitViewer-0.8.0-17122005.tar.gz - genevent-0.3.tar.gz The Ipipe patch comes from the Adeos download area and the LTTng stuff is available at the following address : http://ltt.polymtl.ca/ This patch has only been tested on a UP machine. Alexis. xenomai-2.1-rc1-lttng-05.patch.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
