EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  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  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Device Support for I2C and GPIO
From: Mark Rivers <[email protected]>
To: Florian Feldbauer <[email protected]>, "'Pete Jemian'" <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 14 Jan 2016 14:42:25 +0000
OK, so that says connected:Yes.  So at that point asynManager thinks the port is connected.

Mark

________________________________________
From: Florian Feldbauer [[email protected]]
Sent: Thursday, January 14, 2016 8:17 AM
To: Mark Rivers; 'Pete Jemian'; [email protected]
Subject: Re: Device Support for I2C and GPIO

Hey,

the output of `asynReport 1 I2C` is
epics> asynReport 1 I2C
I2C multiDevice:No canBlock:Yes autoConnect:Yes
     enabled:Yes connected:Yes numberConnects 1
     nDevices 0 nQueued 0 blocked:No
     asynManagerLock:No synchronousLock:No
     exceptionActive:No exceptionUsers 1 exceptionNotifys 0
     traceMask:0x8 traceIOMask:0x8 traceInfoMask:0x1
Port: I2C
   Timestamp: <undefined>
   Input EOS[0]:
   Output EOS[0]:
Parameter list 0
Number of parameters is: 0

Florian

On 01/14/2016 03:01 PM, Mark Rivers wrote:
> Hi Florian,
>
> If you set autoConnect=1 then after iocInit please send the output of
>
> asynReport 1 I2C
>
> Your driver printed this:
> 2016/01/14 13:11:54.967 I2C: wrote 1 bytes to /dev/i2c-1, return asynError
>
> Why is it returning asynError if the write was successful?
>
>> I have a question concerning the asynRecord.
>> To read out the control register of my ADC I have to send the two bytes 0x42 0x02.
>> Is this possible using the asyn record with OFMT="Binary" ?
>> How would the corresponding put to the BOUT field look like?
> Yes, this is possible.  If you are doing the put from a programming language (C, Python, etc.) you would just send a byte array of length 2 containing those bytes.
>
> >From the command line you can do this with caput.  I don't think you can use hex notation, but the following appears to work using decimal notation:
>
> corvette:~>caput -a quadEMTest:TetrAMM:Asyn.BOUT 2 66 2
> Old : quadEMTest:TetrAMM:Asyn.BOUT 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> New : quadEMTest:TetrAMM:Asyn.BOUT 80 66 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> Mark
>
> ________________________________________
> From: Florian Feldbauer [[email protected]]
> Sent: Thursday, January 14, 2016 7:33 AM
> To: Mark Rivers; 'Pete Jemian'; [email protected]
> Subject: Re: Device Support for I2C and GPIO
>
> Hey,
>
> concerning the compiler error, I uploaded the unfinished version from my
> desktop PC instead of
> the one used on the Beagle Bone...I now uploaded the correct version.
> Link is still the same.
> Sorry for the mistake!
>
> I also tested the asynRecord. This is my record:
> record( asyn, "TEST" ) {
>     field( DTYP,  "asynRecordDevice" )
>     field( PORT,  "I2C" )
>     field( ADDR,  "0" )
>     field( IFACE, "asynOctet" )
>
>     ## AsynOctet output
>     field( OEOS,  "" )
>     field( OFMT,  "Binary" )
>
>     ## AsynOctet input
>     field( IEOS,  "" )
>     field( IFMT,  "Binary" )
> }
>
> in the IOC I checked the following:
> iocRun: All initialization complete
> dbgf TEST.PCNCT
> DBR_STRING:          "Connect"
> dbgf TEST.CNCT
> DBR_STRING:          "Connect"
> dbgf TEST.ENBL
> DBR_STRING:          "Enable"
> dbgf TEST.AUCT
> DBR_STRING:          "autoConnect"
> dbgf TEST.ERRS
> DBR_CHAR[100]:       "" +      ""
> dbpf TEST.NOWT 1
> DBR_LONG:           1         0x1
> dbpf TEST.BOUT B
> DBR_CHAR[2]:         "B"
> dbgf TEST.ERRS
> DBR_CHAR[100]:       "error  nread 0 I2C: /dev/i2c-1 disconnected:" +  ""
>
> "I2C: /dev/i2c-1 disconnected:" is the error message when
> asynOctet->read is called,
> but the file handle (drvAsynI2c::_fd) is negative, so either ::connect()
> was not called,
> or the connect failed without printing the error message.
>
> I set autoConnect to false in my code, and tried it again:
> dbgf TEST.PCNCT
> DBR_STRING:          "Connect"
> dbgf TEST.CNCT
> DBR_STRING:          "Disconnect"
> dbgf TEST.ENBL
> DBR_STRING:          "Enable"
> dbgf TEST.AUCT
> DBR_STRING:          "noAutoConnect"
> dbpf TEST.CNCT "Connect"
> 2016/01/14 13:11:54.957 I2C: Open connection to /dev/i2c-1
> DBR_STRING:          "Connect"
> dbgf TEST.ERRS
> DBR_CHAR[100]:       "" +      ""
> dbpf TEST.NOWT 1
> DBR_LONG:           1         0x1
> dbpf TEST.BOUT B
> 2016/01/14 13:11:54.964 I2C: read 0 bytes from /dev/i2c-1, return asynError
> 2016/01/14 13:11:54.965 drvAsynI2C::writeOctet: trying to send 2 bytes
> drvAsynI2C::writeOctet: sending: 0x420x00
> 2016/01/14 13:11:54.967 I2C: wrote 1 bytes to /dev/i2c-1, return asynError
> 2016/01/14 13:11:54.969 I2C: read 0 bytes from /dev/i2c-1, return asynError
> DBR_CHAR[2]:         "B"
> dbgf TEST.ERRS
> DBR_CHAR[100]:
>    "error  nread 0 I2C: /dev/i2c-1 read error: Remote I/O error" +       ""
>
> So with this second test, writing works, but reading not. The beaglebone
> doesn't continue the clock for reading...
> I will further study the problem...
>
> I have a question concerning the asynRecord. To read out the control
> register of my ADC I have to send
> the two bytes 0x42 0x02.
> Is this possible using the asyn record with OFMT="Binary" ? How would
> the corresponding put to the BOUT field look like?
>
> Cheers
> Florian
>
>
> On 01/12/2016 09:02 PM, Mark Rivers wrote:
>> You can also load an asynRecord in your IOC.  With that you can turn AutoConnect on and off, and you can manually force calls to ::connect() and ::disconnect() from medm.  If you do that then do you see your methods being called?
>>
>> 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         |
>> ----------------------------------------
>>
> --
> ----------------------------------------
> | 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
RE: Device Support for I2C and GPIO Mark Rivers
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: 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  <20162017  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 Florian Feldbauer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·