Hi Florian,
Just looking at the code it seems OK.
The ADProsilica driver implements asynPortDriver::connect and it it works OK.
https://github.com/areaDetector/ADProsilica
However, when I tried to compile your module I ran into a number of problems. First, src/Makefile did not actually compile the driver? Once I added that I got the following errors:
make -C O.linux-x86_64 -f ../Makefile TOP=../../.. \
T_A=linux-x86_64 install
make[1]: Entering directory `/home/epics/scratch/drvAsynI2C/drvAsynI2CApp/src/O.linux-x86_64'
/usr/bin/g++ -c -D_GNU_SOURCE -D_DEFAULT_SOURCE -D_X86_64_ -DUNIX -Dlinux -O3 -g -Wall -m64 -fPIC -MMD -I. -I../O.Common -I. -I.. -I../../../include/os/Linux -I../../../include -I/usr/local/epics/base/include/os/Linux -I/usr/local/epics/base/include -I/home/epics/devel/asyn/include ../drvAsynI2C.cpp
In file included from ../drvAsynI2C.cpp:54:0:
../drvAsynI2C.h:56:18: error: ISO C++ forbids declaration of 'timeout' with no type [-fpermissive]
../drvAsynI2C.h: In member function 'int drvAsynI2C::timeout()':
../drvAsynI2C.h:56:39: warning: no return statement in function returning non-void [-Wreturn-type]
../drvAsynI2C.cpp: In member function 'virtual asynStatus drvAsynI2C::readOctet(asynUser*, char*, size_t, size_t*, int*)':
../drvAsynI2C.cpp:100:79: error: 'maxchars' was not declared in this scope
../drvAsynI2C.cpp:139:14: error: 'nbytes' was not declared in this scope
../drvAsynI2C.cpp: In member function 'virtual asynStatus drvAsynI2C::writeOctet(asynUser*, const char*, size_t, size_t*)':
../drvAsynI2C.cpp:250:55: error: a function-definition is not allowed here before '{' token
../drvAsynI2C.cpp:359:1: error: expected '}' at end of input
../drvAsynI2C.cpp:359:1: warning: control reaches end of non-void function [-Wreturn-type]
../drvAsynI2C.cpp: At global scope:
../drvAsynI2C.cpp:62:27: warning: 'i2c_timerQueue' defined but not used [-Wunused-variable]
../drvAsynI2C.cpp:69:13: warning: 'void timeoutHandler(void*)' defined but not used [-Wunused-function]
make[1]: *** [drvAsynI2C.o] Error 1
make[1]: Leaving directory `/home/epics/scratch/drvAsynI2C/drvAsynI2CApp/src/O.linux-x86_64'
make: *** [install.linux-x86_64] Error 2
corvette:drvAsynI2C/drvAsynI2CApp/src>
Am I missing something?
Are you sure the ::connect method is not being called, and it is not just a problem with the asynTraceMask?
Mark
________________________________________
From: Florian Feldbauer [[email protected]]
Sent: Tuesday, January 12, 2016 8:58 AM
To: Mark Rivers; 'Pete Jemian'; [email protected]
Subject: Re: Device Support for I2C and GPIO
Hey,
the current version of my code can be found here:
http://www.ep1.rub.de/~florian/drvAsynI2C.tar.gz
The value for the writeOctet and readOctet is expected to be
a bitstream.
Currently I tried to use StreamDevice as the interface between records
and asynPortDriver...
Florian
On 01/12/2016 01:22 PM, Mark Rivers wrote:
> Your derived method's connect function should be called. Can you send your code? I'll take a look and see if I can spot anything wrong.
>
> Mark
>
> ________________________________________
> From: Florian Feldbauer [[email protected]]
> Sent: Tuesday, January 12, 2016 4:38 AM
> To: Mark Rivers; 'Pete Jemian'; [email protected]
> Subject: Re: Device Support for I2C and GPIO
>
> Hey Marc, hey all!
>
> unfortunately, I did not had the time to write and test the I2C device
> support last year.
> But now I have the time and I'm currently facing a problem:
> My I2C device support is written as a class derived from the asynPortDriver,
> reimplementing writeOctet, readOctet, connect and disconnect.
>
> When calling the ctor of asynPortDriver I set the "autoConnect" flag to 1,
> but the connect function of my class is never called, thus the file
> handle for the
> I2C interface is never opened.
>
> Is there something I'm missing?
> I thought autoConnect means that the connect function is automatically
> called?
>
> Cheers
> Florian
>
> On 11/25/2015 06:24 PM, Mark Rivers wrote:
>> The I2C asyn driver could be considered for going into asyn itself, since it is conceptually similar to the serial, IP, GPIB, USBTMC, and VXI11 drivers.
>>
>> Note that "ip" is really not for software related to Industry Pack modules any more. Most industry pack drivers now have their own modules (ip330, ipUnidig, dac128V, softGlue, ipac for ipOctal). "ip" is really now software for asynOctet devices (serial, GPIB, TCP) that do not have another home like "vac" and "delayGen". "ip" is no longer a good name for it.
>>
>> Similarly "std" was originally the home for a lot "standard" beamline control stuff. Most of this has now been moved to other modules (calc, busy, optics, sscan), so "std" is more like "misc" now.
>>
>> Mark
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of Pete Jemian
>> Sent: Wednesday, November 25, 2015 11:10 AM
>> To: [email protected]
>> Subject: Re: Device Support for I2C and GPIO
>>
>> Michael describes a good procedure for completely new functionality.
>> New modules should provide support distinct from other modules.
>>
>> This _might_ have a place in one of the existing synApps modules. This
>> is not "ip" functionality (related to Industry Pack modules), not
>> "calc", not "optics", perhaps "std" is the catchall module for new
>> synApps support?
>>
>> On 11/25/2015 9:08 AM, Michael Davidsaver wrote:
>>> On 11/25/2015 03:08 AM, Florian Feldbauer wrote:
>>>> I would like to upload the sources to github. Is it possible to upload
>>>> it to the "epics-modules" group?
>>> At this point there isn't any established criteria for when/if
>>> repositories in this group are created.
>>> It would suggest starting with a repository under your own account (what
>>> I do), then think about moving to epics-modules at some later date,
>>> which isn't difficult.
>>>
>>> That said, if you want to go straight to epics-modules I'm inclined to
>>> just add it. Let me know if you want to do this and I'll do this in a
>>> day or so, assuming no one objects. Of course, first you need to solve
>>> the hard problem, the repository name ;)
>>>
>>>
>>> Michael
>>>
> --
> ----------------------------------------
> | Dr. Florian Feldbauer |
> | |
> | Helmholtz-Institut Mainz / |
> | Johannes Gutenberg-Universität Mainz |
> | Johann-Joachim-Becher-Weg 36 |
> | D-55128 Mainz |
> | |
> | Office: SB1 / 00-213 |
> | Phone: (+49)6131 / 39-29605 |
> ----------------------------------------
>
--
----------------------------------------
| Dr. Florian Feldbauer |
| |
| Helmholtz-Institut Mainz / |
| Johannes Gutenberg-Universität Mainz |
| Johann-Joachim-Becher-Weg 36 |
| D-55128 Mainz |
| |
| Office: SB1 / 00-213 |
| Phone: (+49)6131 / 39-29605 |
----------------------------------------
- References:
- Re: Device Support for I2C and GPIO Florian Feldbauer
- RE: Device Support for I2C and GPIO Mark Rivers
- Re: Device Support for I2C and GPIO Florian Feldbauer
- Navigate by Date:
- Prev:
Re: mrfioc2 loading error at vxWorks 6.9 Bjorklund, Eric A
- Next:
RE: Device Support for I2C and GPIO Mark Rivers
- 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
- Navigate by Thread:
- Prev:
Re: Device Support for I2C and GPIO Florian Feldbauer
- Next:
RE: Device Support for I2C and GPIO Mark Rivers
- 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
|