Hi All,

back on the forum with brand new questions !!

I was working with a proview version for ARM based on proview v4.8.6 since years now
I needed to upgrade my ARM linux distribution for some reason not related to proview.
Renewing this linux system requires for me to change my cross tool chain and consequently to rebuild proview from source.

I plan to benefit from this new build to also upgrade proview version but at the moment I just wanted to re validate everything with the existing v4.8.6. build.

Rebuilding v4.8.6 release proview went very smooth and I have now a (nearly) working target and development station.

I have dumped my original application and reload it (reload.sh -> loaddb) into my new proview development station installation.

I was able to build the volume / node and create a proview package smoothly.

Now I'm testing the behavior of the new application and the weird thing started there.
Indeed, all the basic modules codes is working find and also all my external drivers that I linked to proview using a BuildOptions module and specifying in ObjectModules my compiled drivers.

Every thing is working fine except the proview native driver !! Indeed I make use of GPIO modules to make some led flash on my electronic board and this is not working anymore. The board is same and GPIO are accessible through sysfs if I do it manually. The only thing is that with the new kernel the mapping of gpio is changed from gpio85 to pioB11 (example) so I will need to modify proview source code for this reason but at the moment I even don't call any function from rt_io_gpio.c

There start my investigation in uderstanding how proview is linking the object file because:
My application looks configured normally with a GPIO module below the Node object and a GPIO_modules one level below. (Again this come from a working dump so I guess there is no mistakes in the application itself). I double checked the "process" attribute as well as the thread attribute and they are both fine.

The RackInit method is not even called because on the target I can only get a:
IO Init: No read or write action found for this process
No error returns by the RackInit function indicating initialization failed.

I volountary made a change in the RackInit method name (modified in RackInite method) to look for build issue but it never appears. the libpwr_rt.a file was updated correctly after my proview rebuild but building the application went smooth (looks like IoRackInit is never found in the application or no call to the IOMethod is processed).

What can I forget ? I spent all my day on that issue and don't know where the link is done between the otherio GPIO IOMethods and the application or the library itself.

Any help would be very much appreciated

Thank you
Snarf

Additionnal try with a built in Modbus_Master modules and also this one is giving me a: No Read or Write action found for this process

It looks like all proview built in other modules are not working on my proview build.

Must be a very visible mistake but I can't figure out what it is.

Thank you for your help

Snarf

Hi all,

New try today: I recreated a similar Modbus_master object in my own library with a copy paste of the rt_io_m_mb_master.c

Replacing all modbus_master object by my similar one make all my I/O working.

Definitely I can't use every proview internal io class.

Claes, would you have an idea what could be missing in my setup ?

Thank you in advance
Snarf

Hi Snarf,

The GPIO and Modbus IO methods is located in the otherio module, so you can see if this module is built by looking in the libpwr_rt.a archive in $pwrb_root/os_linux/hw_arm/exp/lib with

> ar -tvf $pwrb_root/os_linux/hw_arm/exp/lib/libpwr_rt.a

Here you should see the object modules, eg rt_io_m_gpio.o and rt_io_m_mb_master.o.

You can also see which IO methods are build with rt_io_comm by starting with the -m option.

> rt_io_comm -m
...
ModbusMaster IoAgentInit IoAgentRead IoAgentWrite IoAgentClose
GPIO IoRackInit IoRackClose
...

In V5.4 the -m option is also implemented for the plc executable.

If I should try to make a description of how the methods in otherio are linked, they are first compiled and put in the archive $pwre_broot/os_linux/hw_arm/otherio/lib/libpwr_rt.a. This is done for example with the command

> pwre module otherio
> pwre build lib rt

The a module merge is done with

> pwre merge

where all the libpwr_rt.a archives are merged to the common libpwr_rt.a archive under ..hw_arm/exp/lib. At the same time a data structure is generated from the file otherio/lib/rt/src/rt_io_otherio.meth, that contains a string for the class and method name with a pointer to the method. This is compiled and stored in rt_io_base_methods.o that also should be present in the libpwr_rt.a archive (on exp/lib). It is this data structure that is displayed with the "rt_io_comm -m" command. When initiating the plc executable, it calls io_init() that finds the pointers to the methods from the class name and IO method names in the class description.

/Claes

Hi Claes,

Thanks a lot for your explanation.

As I am using the "plc" process and not the "IoComm" process, is the rt_io_comm relevant in my case ?

I was thinking that everything was inside the plc executable which according to your reply is not fitted with the -m option in V4.8 version ; correct ?

Snarf

Hi Claes,

Here is the procedure I used to cross compile proview (based on 1 year old post on this forum):
www.proview.se/v3/index.php/forum/4-prov...-proview-5-2-for-arm

The main steps are:
pwre init v521_arm (or equivalent v486_arm release)
pwre configure
pwre create_all_modules
pwre import rt
pwre import java
pwre ebuild rt


I guess this includes your mentionned commands:

> pwre module otherio
> pwre build lib rt
> pwre merge

As I can see some libpwr_rt.a line related message info during the ebuild rt phase but please confirm if I need to enter your three commands above in addition to my procedure ?

Previously on my electronic ARM board rt_io_comm file was even not present because I only used "plc" process and this worked without issue as far as I can see. Please confirm this is useless for "plc" process driven I/O.

Thank a lot for your help
much appreciated !!
Snarf