1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: ~kernel/driver message |
From: | Rod Nussbaumer <[email protected]> |
To: | Sebastian Matkovich <[email protected]> |
Cc: | [email protected] |
Date: | Sat, 11 May 2013 08:23:17 -0700 |
Sebastion:Since you say 'accessed as root' I will assume your OS is Linux. You haven't said what GPIB hardware (hence, what driver) you're using. Quite possibly, there is no need to develop device support. If your hardware is compatible with NI hardware or otherwise supported by the open source Linux GPIB drivers, then using those in conjunction with Asyn & StreamDevice is likely to be a recipe for success, especially if the power supply uses a SCPI style language. The only code you'll have to write doing this will be a protocol file that defines how EPICS records send and receive string data. Just using asyn (and asynRecord; highly under-appreciated) adds a great deal of value to the system and contributes greatly to the development process.
Rod Nussbaumer ISAC Controls, TR|IUMF Vancouver, Canada Sebastian Matkovich wrote:
hey, does this kernel message say you anything? kernel: gpib: need to hold board lock to perform ioctl; i found the sourcecode writing this: if( current->pid != board->locking_pid ){ printk( "gpib: need to hold board lock to perform ioctl %i\n", cmd & 0xff ); retval = -EPERM; goto done; }what i try is to build device support for a powersupply connected through a gpib interface. someone told me it might be because two different processes try to access the board, or maybe it isn't accessed by root (but i executed the ioc as root), has anyone got an idea?^^