c4ev3/EV3-API

What does OutputInstance.Owner do?

Davester47 opened this issue · 4 comments

Davester47 commented

I'm interested in doing a rewrite of ev3_output.c, and I noticed that some of the functions took an owner parameter, but I have no idea what this does. They set OutputInstance.Owner to whatever is passed to the function, but the only defined value for this to be is OWNER_NONE which resolves to zero. Can this be safely removed from the API?

JakubVanek commented

I don't remember the code anymore, however I believe two mechanisms could make use of it:

  • Daisy-chaining on the"real" EV3 software. Portions of the code were taken from there, but I don't think that it works with C4EV3 anymore. The owner field could represent the index of the brick that is currently accessing the motor. There are also some Magic Cookies (4pcs) to be found 😄 , however that one could be hidden in the lms2012's USB code
  • Execution slot switching done by the LEGO LMS2012 VM. There are at least three slots (menu, user program and direct commands) that (maybe?) can be scheduled/executed in parallel. Maybe the owner field represents the slot that is controlling the motor.

In any case, I'd recommend looking also in the lms2012 EV3 sources, as that could contain more context: https://github.com/mindboards/ev3sources

Davester47 commented

I read through the c_output.c source code, and as best as I can tell, c4ev3 shouldn't be concerned with the OutputInstance.Owner values. The owner value seems to be used for JakubVanek's 2nd idea, which is execution slot switching in the VM. We're not using a VM, and OutputInstance.Owner isn't in the shared memory, so I am cutting it out of my rewrite.

Davester47 commented

I'm having a hard time rewriting c_output.c and having it still work, so I'm going to shift my focus to my own native c library, that I'm writing from scratch, and hopefully without an API with too much compatibility. If anyone's interested, its at https://github.com/Davester47/legoev3

a3f commented

Stuff like an owner member that did nothing before can be removed, even at the expense of API-stability, because user code that set the member is ok to break.

Just functions that have so far been provided should continue to exist. Adding new more general functions and migrating the old ones to call into them is what I would prefer.

Best of luck for your endeavor nevertheless.

Cheers