Benjamin Franksen wrote:
> Timo Korhonen wrote:
> >
> [...]
> > I also had a similar problem with GPIB support (we are using the HPE2050 LAN
> > gateway support
> > from Benjamin Franksen at BESSY) when porting device support modules. When I
> > removed the "static"
> > keyword in devGpib.h :
> > /*static*/ struct devGpibParmBlock devSupParms;
> > the drivers started to work. When declared static, the data that was supposed
> > to be in the structure was
> > not correctly passed from the init routine to the records.
> >
> > These changes seemed to work, but does somebody have an explanation why?
>
> This is a compiler bug of gcc in the version that is shipped with
> VxWorks 5.3.1. See the thread starting with
> http://www.bessy.de/MailLists/b-tech-talk.1998/frm00696.html (in which I
> stated wrongly that it would be ok to change static to extern, Marty
> convinced me otherwise).
>
I tested the example that was in Marty's posting and it seems that our
cross-compiler
(gcc 2.8.1) does not have that bug. So the explanation (in our case) must be
elsewhere.
> > On the other hand, this seems sort of logical because static variables are
> > valid only within a program
> > unit (according to my textbook), but why does this then work with a 68k cpu?
>
> Well, the static variable 'devSupParms' never used _directly_ by other
> modules, so it can and in principle should be private (ie 'static'). It
> furthermore _must_ be private at least if you have more than one GPIB
> device support, lest you get a name clash.
Here I was pointing more to the OMS58 driver problem. Sorry for mixing two
different things, but I thought the origin probably is the same and I was looking
for
enlightment on that issue. And I did get a reply ;-)
The name clash I had (painfully) noticed, with the two GPIB devices I have on my
desk.
But I had missed the proposed fixes, although I had seen those postings (on my
own,
I arrived at individually naming the devSupParms individually per device, which I
did
not like at all).
> > I will submit the full patches (diffs) if people agree that these changes
> > make sense. Or is there a better way to fix this problem?
>
> Well, yours will work only with one GPIB device support, so I think you
> have to stay with the above 'solutions', even though I dislike both of
> them.
For the GPIB, we clearly have to stay with those solutions. Now that the problems
are
more clear, I can go ahead with GPIB (although I share your disliking).
What I was more referring to was the motor control patch. There I dont see a
similar problem
with name clashes (experts, please correct me if I am missing something crucial
!), because the
called function is unique and handles any number of OMS58 cards. In this sense,
the motor
driver patch seems to be a more valid solution, although it would be cleaner to
keep the
function static, if there was a way to make it work.
Timo
--
Timo Korhonen PSI (Paul Scherrer Institut), SLS
CH-5232 Villigen PSI
tel + 41- 56 3103262 fax + 41 - 56 310 4413
e-mail: [email protected]
- References:
- Calling all Power PC EPICS sites Andrew Johnson
- Re: Calling all Power PC EPICS sites Timo Korhonen
- Re: Calling all Power PC EPICS sites Benjamin Franksen
- Navigate by Date:
- Prev:
RE: Need an EPICS supported "peak sensing" ADC Mark Rivers
- Next:
workQPanic! Oh no! Mark M. Ito
- 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: Calling all Power PC EPICS sites Benjamin Franksen
- Next:
Build problems Dave Reid
- 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
|