Wednesday, February 15, 2017

Multicore merged into Machinekit

This is to advise users, that a major merge has occurred in the Machinekit repo.

The work christened 'multicore', has been finalised and tested for the last few months and as of 3rd Feb 2017 is now part of Machinekit.

What is multicore?
This talk from 2015 gives the full details.
https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo

What do you need to do?

With 3 particular exceptions, nothing at all, the aim has been to make it backwardly compatible,
so all your configs should work as before.

Please report any problems via the tracker at https://github.com/machinekit/machinekit/issues/1123

Once any teething problems are sorted, the capabilities and enhancements available within the code, will be rolled out, documented and advised for any users wishing to make use of them.

Exceptions

  • The primary exception is for anyone using the DE0-NANO-Soc or Zynq as a Mesa 5i25 replacement
Improvements to the hm2_soc_ol driver now make use of a different string argument handling mechanism.

In practice, this simply means editing your hal file driver instantiation line from
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME config=[HOSTMOT2](CONFIG)
to
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME -- config=[HOSTMOT2](CONFIG)

The 2 dashes route the config string to the driver via a safer mechanism.
Any integer instanceparams such as 'debug=1' are passed as previously, so remain to the left side of the delimiter

If interested, this gives more details
https://github.com/machinekit/machinekit-multicore/issues/20

The binary SD card image for the DE0-NANO-Soc has been updated with a new
pull of Machinekit, containing Multicore available from
http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/


  •  The multicore concept relies upon atomic operations in the C11++ standard and newer
These are supported sufficiently in gcc 4.7.2 and above in x86, which means the code will build under Wheezy with backports installed


Originally there were problems building for wheezy-armhf.
This was because all embedded toolchains have effectively deprecated gcc-4.7.

Builds had to be done on gcc-4.9 but ABI peculiarities meant that even linking with 4.9 left an unmet dependency that shouldn't have really been there.

Charles battled this for several days and has now sorted it and armhf packages for Wheezy are being built.

Users are however encouraged to upgrade from Wheezy, which is almost 'end of life' and no longer receiving new backports from Debian in any case.
All support will end in 2018.



  • Something that will only affect users who have written their own C components which use ringbuffers.  (We have no idea if there are any out there.)
An API change sees
hal_ring_detach(char *name, ringbuffer_t *rb)
become
hal_ring_detach(ringbuffer_t *rb)