On 28 April 2017 11:59, quoth Graeme Foot: > First off, I also prefer #3. I use buildroot to create my Linux environment and > buildroot applies patches in alphabetical order (at least in my version which is > now pretty old), so the number at the front is important. Buildroot also > requires that the patch starts with the name of the package (and optionally a > revision number), but that is easy for me to prefix.
FWIW, it looks like buildroot does follow a series file if one is present, so you could just take the series file that's supplied with the patchset and comment or delete from it the patches you're uninterested in, and add additional ones of your own. > When I tried to use your patchset (and the EtherCAT revision they were for) > the computer would freeze just after starting my application and going > realtime. We use RTAI and I read your notes re that it wasn't tested with > RTAI. I didn't have much time to look into problem but I suspect there may > have been a lock that ended up in a call from the realtime context that was > blocked due to be held in the master thread. I suspect this is probably either patch 0007, patch 0011, or patch 0030. If you do get a chance to look into it, it'd be good to confirm that. I'm considering wrapping one or more of these in a configure --enable (or otherwise disabling them when RTDM is enabled). > I ended up cherry picking the changes I needed (patch 0054 (sdo requests > via slave fsm) and 0038 (sdo write request)). That could be a little dangerous; the 005x patches are highly dependent on prior patches and it's probably very bad to run 0054 without 0050-0053. > As to other potential patches (Note: my patches are against 2526 > (2eff7c993a63) on the stable-1.5 branch): Thanks, I'll look at including these too. > 2) Your 0054 patch successfully moved the slave sdo request processing from > the master fsm's idle state to be called every cycle of the master thread. > However, I have my Linux environment set to run at 100Hz, so this thread > would only fire once every 10ms. Each SDO read/write request would take > approx. 30ms to complete. I didn't want to change Linux to run at 1000Hz so I > created patch "etherlabmaster-0010- > allow_app_to_process_sdo_requests_from_realtime.patch". Maybe I'm missing something about how the RTAI version works, but all I did was to move the logic from inside fsm_master to inside fsm_slave; AFAIK both of these execute on the same thread (either the master IDLE or master OPERATION thread). This is independent of the application realtime loop either way, so this should not have changed how frequently they run; it just allows multiple slave requests to run in parallel rather than forcing them to execute sequentially, so it should be a net performance gain. Though it does seem reasonable in your use case to want to run the slave FSMs more often. I don't see how you could do that safely, though -- you can't run ec_master_exec_slave_fsms outside of the master_sem lock, and your RTAI task might interrupt Linux while it's still holding that lock, which will deadlock your RTAI task. _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
