I'm interested but have been holding off on any work until the i.mx8 silicon is less buggy. https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-8-processors:IMX8-SERIES
It's similar to the AM335x (2x PRU's, cores for real time and non-real time, integrated NIC, etc) only with a GPU that has open Linux drivers for a local GUIat HD res at 30+ fps. -Bari On 09/11/2018 11:17 PM, Chris Morley wrote: > So far I have got more response from MK developers then Linuxcnc developers. > > Seb, Chris, Andy, Jeff - anyone else....? > > Opinion? > > Dead set against? > > Don't care? > > Go for it? > > > hey maybe your busy right now - life happens... > > But If our core guys don't respond at all - what does that mean? > > looking forward to some feedback! > > > Chris M > > ________________________________ > >> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]<https://github.com/machinekit> >> >> machinekit · GitHub<https://github.com/machinekit> >> github.com >> GitHub is where people build software. More than 28 million people use >> GitHub to discover, fork, and contribute to over 85 million projects. >> >> It also seems they have updated HAL considerably, >> >> They were working on RT multicore support, anytime instantiation of HAL >> components >> >> cython support.. probably other stuff - I'm not sure if it includes ARM or >> FPGA upgrades. >> >> >> I was thinking that maybe linuxcnc should discuss if that is something that >> would be of interested. >> >> >> pros I see: >> >> -chance to break HAL out of cnc stack >> >> -seemingly an upgrade in capability >> >> -someone else has done a lot of work/testing already >> >> -might allow more cross work of developers between the projects >> >> >> cons: >> >> -surely a lot of work to incorporate (though it does support legacy code, if >> I understand right) >> >> -lack of experience with concepts/code - will take time to become comfortable >> >> -we'd have to admit they are not bad people :) >> >> >> Ok that last one was meant as fun. >> >> >> There are very smart and hard working people on both projects, it would be >> nice to benefit both >> >> projects. >> >> >> I have not really looked at the code, nor am qualified to give indepth >> opinion of the code. >> >> I have watched the video of the multicore idea. >> >> https://www.youtube.com/watch?v=brT0bEkJLSY >> >> There are more videos (including one about the trajectory planner that we >> now use) >> >> >> Thoughts? >> >> >> Chris M > 【I accidentally sent this from the wrong address, and it was bounced...] > > Thanks for raising this topic, Chris, it would be great to see more > cooperation between the LCNC and MK projects. > > I'd also like to bring the more actively maintained EMC application from > the LCNC project together with the new features in HAL from the MK > project. Another way to achieve that is to update LCNC so that EMC can > be built against an external MK HAL. That might be an easy way to get > something started where we could start exploring the problem early. If > it were successful, this approach could also be a conservative way to > give users the option of using MK HAL from mainline LCNC branches while > still maintaining the current HAL as the default. > > [Chris M replied to ask what's new in MK HAL that's not in LCNC HAL, and > I replied...] > > TBH, at some point I lost track of what was added to MK HAL. I think > you're right, connecting LCNC EMC with MK HAL would be an all-or-nothing > affair, since the major restructuring would make it difficult to pick > out individual features, if they're even separable at this point. I > still think that LCNC could be taught to build against MK HAL, though, > without committing to throwing away current HAL. > > Also, IMO, the MK project's splitting HAL and EMC was a good move, since > HAL is awesome on its own: I've used it to build dumb things like an > incubator and autoclave, and smart things like a ros_control hardware > interface (dig through my GH repos to find these). Splitting these not > only dumps a huge amount of build complexity and unnecessary > dependencies for HAL-only projects, but also exposes HAL as something > that can gain its own following. > > Off the top of my head, here are the MK HAL-specific features I am > familiar with: > - `rtapi_msgd` runs alongside `rtapi_app` and relays log messages over > ZeroMQ > - "HAL talk" passes signals over ZeroMQ, enabling remote components > (I've used this extensively in combination with Alexander Roessler's > QtQuickVCP remote GUI; my incubator and autoclave are public examples) > - "Instantiable components" allow adding new comp instances on the fly; > useful when e.g. including a HAL file so you don't have to declare all > instances at the first `loadrt` > - Cython bindings to HAL enable replacing traditional `.hal` files with > Python code; this has been useful to me when writing configurations for > robots that have several variants: the flexibility of Python greatly > simplifies the HAL config > - Multi-core: enables running HAL threads with CPU affinity; I recently > found that combined with `rtpart`, a `latency-test` that normally has > 40us jitter (on a J1900) has 6us when the HAL thread is given a > dedicated core (this may help solve some chronic EtherCAT "missed > datagram" issues we've been suffering) > - Ring buffer API: Currently only used by HAL talk AFAIK, a > standardized way of passing blocks of data into/out of HAL in a RT-safe way > - (Not sure how much in HAL and how much in the hm2 firmware, but) > Support for hm2 on Zynq SOCs > > ...and probably other things I'm unaware of or have forgotten. I have > never seen documentation for these things, but I may not have looked in > the right place. > > NML is part of EMC, and connects the UIs (status, command, error) and > motion/io to task, so MK HAL is completely independent. My > understanding is weak here, but Alexander Roessler wrote some sort of > NML wrapper called "machine talk" that delivers UI messages to a remote > GUI, and he has two QtQuickVCP GUIs "Cetus" and "Machineface" for a CNC > mill and 3D printer (respectively, or possibly vice-versa) to go along > with that. He posted here maybe a year ago asking whether there was > interest in porting that to LCNC. > > [My apologies; I meant to keep this on-list, but I'm still getting used > to a new email setup after switching to M$ infrastructure that's not > blocked here in China, where I'll be for a while.] > > John > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
