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

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sun, 1 Jun 2014 18:38:58 +0300

I'm afraid the emulator may not work as a 64-bit version.  Most probably it 
won't.  There are just too many 32-bit dependencies in the Runtime code.

Are there any 32-bit Python builds available for Linux?  

If not, then I'm afraid that this way won't work, but we have to treat the 
emulator more like the real device:  either build a separate 32-bit 
Linux-binary that has a Lua interpreter in it, or build separate binaries that 
spit out the register accesses, just like so far.

--Pekka

On 2014–06–01, at 3:35 , Jose Granados Vergara <jose.granados@xxxxxx> wrote:

> 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> 
> 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> 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 and 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 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> 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> 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> 
>> 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
>> 
>> 
>> 
>> -- 
>> With Best Regards,
>> Asif Sardar.
>> +358 43 8265795
>> 
>> 
>> 
>> -- 
>> With Best Regards,
>> Asif Sardar.
>> +358 43 8265795
>> 
>> 
>> 
>> -- 
>> With Best Regards,
>> Asif Sardar.
>> +358 43 8265795

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts: