Please add any notes/corrections here, before they go into wiki pages intended for the general public/documentation proper.
Charles already found two issues:
- the hal_gpiomap driver wasnt adapted to the new rtapi_bitops.h operations. This has been corrected, please pull from above branch. - the libmodbus-dev package in Wheezy and Precise is perfectly fine. It is lacking on Lucid, which is the only use case for the linuxcnc.org libmodbus-dev package.
for those who accidentially already installed libmodbus from source, this removes the local edition:
$ sudo rm -rf /usr/include/libmodbus/ $ sudo rm /usr/lib/*modb*
so, on Ubuntu >= 12.04 and Debian sid onwards, this should do fine: sudo apt-get install libmodbus-dev
Note on beaglebone white:
The compile with standard CC flags stresses the limits of the 256MB bbw considerably you might try with 'make OPTS=-O0' if you run out of patiences
contrary to notes in http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup, swapping to an NFS-mounted file seems to work fine with the 3.8.13-xenomai kernel
the open runtests issues should have been resolved - please report any failures.
below is the notes from my initial limited-distribution announcement:
Subject: RF evaluation: consolidated RTOS branch
As announced here http://tinyurl.com/mhmfgco, I've consolidated the various 'RTOS something' branches under a single master-based umbrella
I think we have a viable candidate branch but before I burn the bridges behind I want to make sure the one ahead is solid
this branch http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/rtos-master-v0 contains current as of today:
- the rtos-integration-preview3 base - all of v2.5_branch and master - Charles work branch, http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-tasks - Ian's hal_bb_gpio driver - my fork on an earlier version of Charles' branch(es) which brings in emcweb: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-module-emcweb - getting rid of the last leftovers of assembly code with these 2 new commits: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/rtapi-bitops-gcc-intrinsics-rc - GP Orcullo's picnc code is not yet included - yess! another license issue, its GPL3, but he'll downgrade and then I'll pull it in too
I've built and runtest'ed every single merge commit, so I dont think there any merge turds carried along, but you never know - this brings together a lot of code.
I've run a few configs. I also got a PRU example to work provided the right device tree overlay is loaded, so it should not have broken anything fundamental. I havent tried building docs yet.
--
At this point I would ask you to give it a try, and switch any development work to this branch. This will also be the base for merging the unified binary branch.
Provided feedback is encouraging, I suggest to switch to this branch exclusively and deprecate the rest of the forest. That eventually will need wiki work too, but only after it's known to be solid; the new SD image will be based on this; no more v2.5 based rtos branch.
Prerequisites:
sudo apt-get install libboost-python-dev libboost-serialization-dev libboost-thread-dev libtool
the libmodbus3-dev package from the linuxcnc.org stream is needed - which is i386 and x86_64 only:
sudo apt-get install libmodbus3-dev
for other architectures, build like so:
git clone git://github.com/stephane/libmodbus cd libmodbus/ sh autogen.sh ./configure --prefix=/usr make sudo make install
-- from there on, you should be good to go - autogen.sh, configure etc.
Status:
compile:
On the beaglebone you need active swapspace to compile - emcweb and taskmodule.cc use c++ templates and that's too much without VM.
Please report any runtests failures, any platform. AFAICT RTAI, Xenomai 3.5.7 on i386 and x86_64 are clean. I havent tested on rt-preempt (any arch). I have tested on beaglebone 3.8.13xenomai with Ubuntu precise and Debian wheezy.
There are in total three runtests failures altogether varying by platform and flavor:
- rtapi_printf on userland builds - irrelevant to userland functionality, I'll fix that eventually - mux - Andy's new mux comp, which is _very_ new and I rather pass the buck to Andy on this one - overrun - observed only on BB, obviously has to do with leftover shm segments, looks fixable but harmless
Work still outstanding:
We need a runtest for the Beaglebone which verifies that the PRU support code works - assemble, load, execute PRU code, report succes, unload, package as a runtest; can I ask for a volunteer to wrap up some ledblink PRU assembly code as such a test?
The overrun runtest failure is likely a deficiency in scripts/realtime.in; however, since startup and shutdown will be wildly revamped with the unified binary branch there's not a whole lot of sense in fixing this right away
The situation where Xenomai gives up on hard RT scheduling and relegates a thread to linux scheduling is not handled very well now (which is a roundabout way of saying 'crash'). I think it should cause an estop, likely meaning pins and a halcomp for rtapi_app.
- Michael
![[Home]](/chips.gif)