[ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues

  • From: Jose Granados Vergara <jose.granados@xxxxxx>
  • To: "ell-i-developers@xxxxxxxxxxxxx" <ell-i-developers@xxxxxxxxxxxxx>
  • Date: Sun, 01 Jun 2014 00:35:41 +0000

It looks like you need to rebuild the .so libraries as 64 bits.

El 31/05/2014, a las 22:43, Asif Sardar 
<engr.asif.sardar@xxxxxxxxxxxxxx<mailto:engr.asif.sardar@xxxxxxxxxxxxxx>> 
escribió:

Hi again,

While loading shared library from test scripts, I got following error:

[ ERROR ] Error in file 
'/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
 Importing test library 
'/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py'
 failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32
Traceback (most recent call last):
  File 
"/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py",
 line 8, in <module>
    emulator = CDLL("../libemulator.so")
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)

I tried to compile a 32 bit version of python (aliasing 
python=/path/to/32/bit/python), install the robotframework using this python. 
Still same problem ...

Some kind of problem as 32 bit vs 64 bit incompatibility -> 
http://askubuntu.com/questions/398929/unable-to-load-shared-object-wrong-elf-class-elfclass32

Am I still using (default 64 bit python from /usr/bin/python/) for installing 
robotframework ? Shall I try manually building the robotframework from source 
code configuring it for 32-bit.

I don't want uninstall the default python, because some system scripts might 
depend on that.

Any suggestions please ...


On Sat, May 31, 2014 at 10:21 PM, Asif Sardar 
<engr.asif.sardar@xxxxxxxxxxxxxx<mailto:engr.asif.sardar@xxxxxxxxxxxxxx>> wrote:
Hello all,

Trying to load a shared library such as 'libemulator.so' using ctypes modules 
and running the test cases such as DigitalRead resulted in the following error:

[ ERROR ] Error in file 
'/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
 Importing test library 
'/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py' 
failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32
Traceback (most recent call last):
  File 
"/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py", 
line 9, in <module>
    emulator = CDLL("../libemulator.so")
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)

---------------------------------------------------------------

@Pekka ---
Besides that problem. Can you please check the emulator.mk<http://emulator.mk> 
and app.mk<http://app.mk> files attached to this e-mail. I messed my ubuntu 
system on Thursday and Friday while struggling with shared emulator library to 
start working with python scripts ... which resulted some lost files and 
crashes.

So, if you can again guide me making shared library please... i get following 
error after applying patch for shared emulator library that you sent last week 
...

make PLATFORM=emulator -f ../make/app.mk<http://app.mk> all
make[1]: Entering directory 
`/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'
g++ -m32 -march=i386 -m32 -demangle -march=i386 -Xlinker -T -Xlinker 
../scripts//elf_i386.xc -o sketch  main.o sketch.o ellduino.o "-L." 
"-L../variants/ellduino" "-lstm32f0" -lstdc++
/usr/bin/ld: skipping incompatible ../variants/ellduino/libstm32f0.a when 
searching for -lstm32f0
/usr/bin/ld: cannot find -lstm32f0
collect2: error: ld returned 1 exit status
make[1]: *** [sketch] Error 1
make[1]: Leaving directory 
`/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'
make: *** [all] Error 2





On Mon, May 26, 2014 at 7:39 PM, Asif Sardar 
<engr.asif.sardar@xxxxxxxxxxxxxx<mailto:engr.asif.sardar@xxxxxxxxxxxxxx>> wrote:
Hello all,

Instead of using python C API to implement C libraries, it is often easier to 
interact with C code from Python libraries using ctypes module.

Please have a look at 
https://github.com/Ell-i/ELL-i-PyBot-Tests/blob/master/test-scripts/DigitalRead.py

This approach leaves much of the coding stuff to python. We can load the shared 
library and call the C functionality easily using the ctypes module's primitive 
C compatible fundamental data types.





On Mon, Apr 28, 2014 at 2:05 PM, Asif Sardar 
<engr.asif.sardar@xxxxxxxxxxxxxx<mailto:engr.asif.sardar@xxxxxxxxxxxxxx>> wrote:
> The first thing is to get the c-python modules in the 
> arduino-functions/Digital-I-O to include the right subdirectories from the
> Runtime.  The following in setup.py seems to work as a first approximation:

> ---------------
> from os import path

> runtime='/my/path/to/Runtime'

> arduelli   = path.join(runtime, 'cores/arduelli')
> system_inc = path.join(runtime, 'system/stm32/inc')
> cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
> variant    = path.join(runtime, 'variants/ellduino')

> include_dirs=[arduelli, system_inc, cmsis, variant]

> setup(name='digitalRead', version='1.0',
   >   ext_modules=[Extension('
> digitalRead',
>                          ['Digital-I-O/digitalRead.c'],
>                        include_dirs=include_dirs)])
> --------------------

> The key there is the include_dirs in creating the Extension. See

>   https://docs.python.org/2.7/distutils/setupscript.html

> for more information.

> With that you can include <wiring_digital.h> in digitalRead.c, but note that 
> it must be included *before* including <Python.h>.
> That then allows you to call the actual Runtime functions, and it compiles.  
> Python also tries to load the resulting shared library, > but that fails.

With above paths included into the extension modules, we can compile the 
c-python modules. But, we also need the libraries or executable code for these 
functions at runtime. When I run the test cases with c-python modules compiled 
with above setup.py script, the test suite exits with segmentation fault.


> The next step would then be to actually add the emulator functions to the 
> python runtime.  That I don't know yet how to do
> exactly, but I imagine that it would be best to compile the emulator into a 
> shared library, through adding a new make target in
> Runtime/stm32/make, and then including the shared library into the 
> (DY)LD_LIBRARY_PATH.  That might suffice.

I think the shared library for emulator functions might help eliminating the 
above weird problems at runtime ...



On Sun, Apr 27, 2014 at 4:42 PM, Pekka Nikander 
<pekka.nikander@xxxxxx<mailto:pekka.nikander@xxxxxx>> wrote:
> May I get some help regarding linking the c-python modules against the 
> emulator? I cannot call the Arduino functions directly from c-python code 
> files without linking against emulator and stm32 cores.

I had a brief look at this today.  While I cannot present a full solution, I 
think I made some progress.

The first thing is to get the c-python modules in the 
arduino-functions/Digital-I-O to include the right subdirectories from the 
Runtime.  The following in setup.py seems to work as a first approximation:

---------------
from os import path

runtime='/my/path/to/Runtime'

arduelli   = path.join(runtime, 'cores/arduelli')
system_inc = path.join(runtime, 'system/stm32/inc')
cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
variant    = path.join(runtime, 'variants/ellduino')

include_dirs=[arduelli, system_inc, cmsis, variant]

setup(name='digitalRead', version='1.0',
      ext_modules=[Extension('digitalRead',
                             ['Digital-I-O/digitalRead.c'],
                             include_dirs=include_dirs)])
--------------------

The key there is the include_dirs in creating the Extension. See

  https://docs.python.org/2.7/distutils/setupscript.html

for more information.

With that you can include <wiring_digital.h> in digitalRead.c, but note that it 
must be included *before* including <Python.h>.  That then allows you to call 
the actual Runtime functions, and it compiles.  Python also tries to load the 
resulting shared library, but that fails.

The next step would then be to actually add the emulator functions to the 
python runtime.  That I don't know yet how to do exactly, but I imagine that it 
would be best to compile the emulator into a shared library, through adding a 
new make target in Runtime/stm32/make, and then including the shared library 
into the (DY)LD_LIBRARY_PATH.  That might suffice.

--Pekka




--
With Best Regards,
Asif Sardar.
+358 43 8265795<tel:%2B358%2043%208265795>



--
With Best Regards,
Asif Sardar.
+358 43 8265795<tel:%2B358%2043%208265795>



--
With Best Regards,
Asif Sardar.
+358 43 8265795<tel:%2B358%2043%208265795>



--
With Best Regards,
Asif Sardar.
+358 43 8265795

Other related posts: