Jump to content
OMRON Forums

lmckay

Members
  • Posts

    3
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

lmckay's Achievements

Newbie

Newbie (1/14)

  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. It seems I can compile C++ code, linking against libppmac and libxenomai, and eliminating all the __wrap_xxxx directives from the Makefile without problems. It's libppmac.so that has undefined calls to __wrap_xxxx functions, requiring libxenomai (and friends), so when not wrapping at the linker level all other source files/shared libs should use the standard Linux/Posix calls. When I do this, it appears that only the thread calling InitLibrary() is listed in /proc/xenomai/stat and sched as I would hope. Other threads are normal Linux threads and the xenomai mode switch counters stay at 1 each while I read/write shared memory and call normal Linux (non-wrapped) functions. As I get this functionality built into a larger test application I may yet encounter problems with this approach -- I'll update here with interesting results. I do expect that if I need to change the xenomai thread priority, or make xenomai FIFO's, etc I'll need to call out the __wrap functions explicitly in my code. (These functions can be listed from the shared objects in the /usr/local/xenomai/lib folder, I use 'nm *.so | grep wrap') - Luke
  2. Google Test is a unit testing framework, yes. I'm using it in a rather simple way, and on a small part of my codebase -- for now. Here's an example test function I've used just to test my compile/link/runtime of the libppmac bits (breaking several Test-Driven Development "rules"): TEST(SHM_Test, SetAndClearMotor1ServoCtrl) { ASSERT_THAT(InitLibrary(), Eq(0)); // gplib init must return 0 to proceed struct SHM *pshm = GetSharedMemPtr(); // get pointer to SHM pshm->Motor[1].ServoCtrl = 1; // set ServoCtrl to 1 ASSERT_THAT(pshm->Motor[1].ServoCtrl, Eq(1)); // Check that the value is now 1 pshm->Motor[1].ServoCtrl = 0; // set ServoCtrl to 0 ASSERT_THAT(pshm->Motor[1].ServoCtrl, Eq(0)); // Check that the value is now 0 CloseLibrary(); // clean up in gplib } Here's the main() function which is used to run the tests: // includes , , , ... int main(int argc, char **argv) { std::chrono::time_point time_point; time_point = std::chrono::system_clock::now(); std::time_t ttp = std::chrono::system_clock::to_time_t(time_point); std::cout << "Start time: " << std::ctime(&ttp) << "\n"; ::testing::InitGoogleTest(&argc, argv); RUN_ALL_TESTS(); time_point = std::chrono::system_clock::now(); ttp = std::chrono::system_clock::to_time_t(time_point); std::cout << "End time: " << std::ctime(&ttp) << "\n"; return 0; } And the output from running it (with one other test defined): ./shmtest.out Start time: Tue Sep 29 01:05:59 2015 [==========] Running 2 tests from 1 test case. [----------] Global test environment set-up. [----------] 2 tests from SHM_Test [ RUN ] SHM_Test.SetAndClearMotor1ServoCtrl [ OK ] SHM_Test.SetAndClearMotor1ServoCtrl (22 ms) [ RUN ] SHM_Test.ReadsMotor1ActPos -- Motor[1] Position: 3963 [ OK ] SHM_Test.ReadsMotor1ActPos (21 ms) [----------] 2 tests from SHM_Test (46 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (51 ms total) [ PASSED ] 2 tests. End time: Tue Sep 29 01:05:59 2015 There was quite a bit of muddling to get here, and some things I still don't completely understand (all the xenomai stuff as a start). Note also I'm not cross-compiling here, everything is being built directly on the PMAC Debian Sid chroot. This should be easy to improve, using schroot and debootstrap on a Debian/Ubuntu workstation with crossbuild-essential-powerpc. Compiling on the PMAC is sloooow. Also note the tests above take >20ms each to run. That time includes Google Test creating a new thread, running InitLibrary, running the tests, and then CloseLibrary. I will be doing performance testing and figuring out where the slowdowns are in my actual application classes. If it takes that long to InitLibrary, that will certainly help determine how and when I use the shared memory! - Luke
  3. A quick note in case others are working on similar projects. I'm in the early stages of integrating a Power Clipper in my development/test environment. I've been using some existing code rather than rewriting in C as a Capp -- mostly C++11 code already written for some degree of portability and with few external dependencies. Debian Wheezy doesn't have GCC 4.8+ (and associated glibc/libstdc++ versions) which is needed for full c++11 support, and doing anything too drastic to the base PMAC image scares me! Perhaps others have already worked out better ways to handle these limitations. I have created a chroot environment on external storage, using debootstrap to install the Debian Sid base system which comes with GCC 5.2. With the correct set of mount --bind commands and Makefile juju, I'm able to compile a simple test program which uses c++11 features, standalone ASIO for network handling, and can access the PMAC shared memory from Linux threads. All this without very many changes/extra software installed on the base PMAC filesystem. I've also been using Google Test in my code, to do quick checks of what may have broken when running on the PowerPC chip versus on my development machines (so far, I've noticed only that starting threads takes a little longer). There was no problem getting Google Test compiled and installed in the Sid chroot, I didn't try under the base image. If anyone is interested, I'll be happy to share configurations and/or code examples. I'll post updates here if I encounter anything noteworthy or potentially useful to others -- I plan on wringing things out extensively over the next few months and will likely find some interesting ways of breaking things! - Luke
×
×
  • Create New...