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.
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.
- The primary exception is for anyone using the DE0-NANO-Soc or Zynq as a Mesa 5i25 replacement
In practice, this simply means editing your hal file driver instantiation line from
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME config=[HOSTMOT2](CONFIG)
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
The binary SD card image for the DE0-NANO-Soc has been updated with a new
pull of Machinekit, containing Multicore available from
- The multicore concept relies upon atomic operations in the C11++ standard and newer
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.)
hal_ring_detach(char *name, ringbuffer_t *rb)