[Home]RtosConsolidated

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Difference (from prior major revision) (no other diffs)

Added: 54a55
<KARnote: On a freshly installed Ubuntu 12.04LTS virtual machine on an x86 host, I pulled from master at about 1500EDT on 20130607, checked out rtos-master-v0, configured for a simulator, and built both the LinuxCNC simulator and all the docs---PDF and HTML---without incident. Well, there was a complaint at the end that checklink was not found but this is a problem introduced upstream. />

This page is intended to collect built information for the consolidated RTOS branch http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/rtos-master-v0 .

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 mentioned below 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.

<KARnote: On a freshly installed Ubuntu 12.04LTS virtual machine on an x86 host, I pulled from master at about 1500EDT on 20130607, checked out rtos-master-v0, configured for a simulator, and built both the LinuxCNC simulator and all the docs---PDF and HTML---without incident. Well, there was a complaint at the end that checklink was not found but this is a problem introduced upstream. /> --

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:


packages:

sudo apt-get install libboost-python-dev libboost-serialization-dev libboost-thread-dev libtool libmodbus-dev

In case the libmodbus-dev package is not available, 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 (late edit: this should be resolved by now, see above)

- 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


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited June 7, 2013 5:42 pm by CNCDreamer (diff)
Search:
Published under a Creative Commons License