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: RTEMS Support in IPAC 2.14 for Acromag IP520? |
From: | Laurence <[email protected]> |
To: | [email protected] |
Date: | Wed, 30 Nov 2016 19:54:54 +0800 |
Hi, We have several IP521 on AVME-9668 IP carrier, running RTEMS.First I tried a modified version of tyGSOctal driver, but it does not work well. When there are many IP module trying to send data at the same time (in our case, 32 power supply), the communication fails from time to time. It's because the driver have to enter interrupt handler every time to write a byte, and this introduce some latency by VME bus access.
Our workaround was to write an asynPortDriver that do direct registers access and release the mutex when a complete message was sent. Maybe a better OSI solution could be sub-classing asynPortDriver and utilizing the FIFO?
Regards, Liwen Feng On 2016/11/30 18:11, Williams Jr., Ernest L. wrote:
Hi everyone, We now have a need to use the IP520 from Acromag. Since the GreenSprings/SBS IP Octal UART is now obsolete The good news is we found support for the Acromag IP520 in ipac 2.14 for vxWorks. However, we need a version for RTEMS. Has anyone already provided support for RTEMS? In this case, we are also using an Acromag VME IP Carrier (XVME-9670) which works well :) In general, we are thinking: The IP520 module could be used not only on a VME Acromag Carrier with VxWorks but the following example combinations are also possible: (1) Acromag VME IP Carrier, running RTEMS (2) Acromag PCIe IP Carrier, running Linux (3) Hytec uTCA IP Carrier, running Linux (4) There are also other combinations. What we have done at SLAC in the past is to use the provided RTEMS version of the source file for "tyGSOctal" like so, < ....>/modules/ipac/ipac-R2-11_1-2/tyGSOctal/tyGSOctal_RTEMS.c I am hoping that we can instead make this an OSI implementation for IP520? What is the recommended approach for future IP Octal support? Cheers, Ernest
-- Liwen Feng Superconducting Radio Frequency Group State Key Laboratory of Nuclear Physics and Technology Peking University, 302 Chengfu Road Beijing 100871 China