What is data[8] in your structure? Is that a string that StreamDevice could construct for you?
Will it work to send one of your can_frame structures to your hardware using the underlying devAsynSerialPort driver or devAsynIPPort driver?
If so, then I think the asynInterpose interface may be the simplest way to do it.
Writing a full asynDriver is more useful when the complexity of the device is beyond what StreamDevice can easily handle. This might be the case, or example if the device has different "modes" and the state information is easiest to code in a driver. It would also be the case if the device does not use "strings" to communicate, but rather registers, a vendor API, etc.
Perhaps writing a full driver still makes sense, I don't know enough about your particular device to say for sure.
Mark
-----Original Message-----
From: Florian Feldbauer [mailto:[email protected]]
Sent: Tuesday, September 18, 2012 3:06 PM
To: Mark Rivers
Cc: EPICS tech talk
Subject: Re: ISEG EHS device support on the Raspberry Pi Computer
Hi Mark,
Am 18.09.2012 18:57, schrieb Mark Rivers:
> Hi Florian,
>
> I am not sure I fully understand what you are trying to do.
>
> Is the following correct?
>
> 1) StreamDevice writes strings on the asynOctet interface. All device support could be done with StreamDevice.
This is true.
> 2) These strings are not directly compatible with your hardware. You need to modify these strings before sending them to your hardware.
my hardware uses CAN frames. So I have to convert the strings from
StreamDevice to this:
struct can_frame {
uint32_t can_id; // 11/29 bit identifier + RTR, IDE and Error flags
uint8_t dlc;
uint8_t data[8];
};
> 3) Your hardware is compatible with the drvAsynSerialPort and/or drvAsynIPPort asyn drivers at the lowest level.
I guess my hardware is not compatible to drvAsynSerialPort and/or
drvAsynIPPort, but this I have to check.
What I'm currently trying to do is writing an asynPortDriver for my
hardware, because in your first mail you wrote:
> If you use asynPortDriver as your base class most of the details asyn are hidden from you. You don't need to worry about
> registering the port, registering the interfaces, how to do callbacks, etc."
Therefore I thought this would be a good approach...
Best regards,
Florian
>
> If all 3 of these statements is true, then this is a perfect candidate for implementation as an "asynInterpose" layer. You write an asynInterpose driver that takes asynOctet strings from StreamDevice, modifies those strings, and passes them on to the underlying serial or IP driver.
>
> This is exactly what is done with the Modbus driver. It takes protocol-independent strings from the Modbus driver layer and adds the protocol headers for the Modbus TCP, Modbus RTU, or Modbus ASCII protocols. These strings are then passed to the standard asyn serial or TCP drivers. On input it strips these headers before passing the strings up to the Modbus driver.
>
> Mark
>
>
> -----Original Message-----
> From: Florian Feldbauer [mailto:[email protected]]
> Sent: Tuesday, September 18, 2012 3:54 AM
> To: Mark Rivers
> Cc: EPICS tech talk
> Subject: Re: ISEG EHS device support on the Raspberry Pi Computer
>
> Hi Mark,
>
> I started writing my asyn Driver using asynPortDriver as base class.
>
> StreamDevice uses asynOctet to interface the driver, so I guess I need
> to implement the methods readOctet and writeOctet and I also need (at
> least) one
> Octet-parameter for my class, right?
>
> I'm still thinking a custom device support for our iseg hv would be more
> feasible than using StreamDevice. So I'd like to continue this approach
> as well.
>
> From the first look I would say the best way to interface the asyn driver
> would be asynGenericPointer.
> Is it possible to use this interface for asynPortDriver?
> I guess I would have to implement set and get methods for this parameter
> type
> for the paramList class asynPortDriver uses?
>
> Best regards,
> Florian
>
>
>
> On 09/10/2012 04:53 PM, Mark Rivers wrote:
>> Hi Florian,
>>
>> I would encourage you to consider whether you should write device support at all. I am copying Bruno on this as well, because I meant to respond to his earlier thread "aiRecord conversion" with a similar comment.
>>
>> Instead of writing device support you should really consider writing an asyn driver. If you do that then device support is done for you, and you don't need to worry about all the details of how records interact with device support. Writing an asyn driver is actually quite easy. There are many advantages:
>>
>> - Support for synchronous and asynchronous devices requires a single-bit change in your driver's registration.
>> - Support for I/O Intr scanned records is easy.
>> - The device support is already debugged.
>> - You get the asynTrace capabilities for standard debugging support.
>> - You free the developer to use whatever records they want, rather than only the records you support in your device support.
>> - If you use asynPortDriver as your base class most of the details asyn are hidden from you. You don't need to worry about registering the port, registering the interfaces, how to do callbacks, etc.
>>
>> In your case you might also be able to use StreamDevice. I don't know enough about the CAN interface to know if this is feasible or not.
>>
>> There are lots of examples of asyn drivers, including testAsynPortDriverApp in the asyn package, the Modbus driver, and many other drivers in the synApps package.
>>
>> Mark
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of Florian Feldbauer
>> Sent: Monday, September 10, 2012 6:24 AM
>> To: EPICS tech talk
>> Subject: ISEG EHS device support on the Raspberry Pi Computer
>>
>> Dear all,
>>
>> at Bochum university, we have developed a CAN bus interfacefor the
>> Raspberry Pi computer [1]
>> using the SJA1000 stand-alone CAN controller.
>>
>> We are using this interface to control the high voltage power supply modules
>> EHS 8 620p-F and EHS 8 210p-F from ISEG [2] via the crate controller ECH238.
>>
>> I have programmed a device support for these high voltage modules based
>> on our Raspberry Pi Can interface.
>> You can find the sources for the device support as well as the schematic
>> of our CAN interface on github:
>> https://github.com/ffeldbauer/epics_RPi_can
>>
>> I will upgrade this repository with a device support for our Wiener VME
>> crate, and some custom hardware.
>> The VME crate has an CAN interface which can be used to read out
>> voltages, currents, temperature and status of the crate.
>>
>> Up to now the driver support in EPICS is only synchronous. Is there any
>> documentation on how to program an
>> asynchronous driver support? For some other devices we would need an
>> asynchronous support.
>>
>> Best regards,
>> Florian
>>
>> [1] http://www.raspberrypi.org/
>> [2] http://www.iseg-hv.com/en/products/product-details/product/21/
>>
>
- Replies:
- Re: ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- References:
- ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- RE: ISEG EHS device support on the Raspberry Pi Computer Mark Rivers
- Re: ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- RE: ISEG EHS device support on the Raspberry Pi Computer Mark Rivers
- Re: ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- Navigate by Date:
- Prev:
Re: ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- Next:
Re: ISEG EHS device support on the Raspberry Pi Computer 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
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: ISEG EHS device support on the Raspberry Pi Computer Florian Feldbauer
- Next:
Re: ISEG EHS device support on the Raspberry Pi Computer 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
2016
2017
2018
2019
2020
2021
2022
2023
2024
|