Discussion:
[etherlab-dev] fsm_slave buggy?
William Ledda
2018-02-08 16:54:20 UTC
Permalink
Dear developers,
I was looking into the code of the stable-1.5 branch and It seems there is some bugs in fsm_slave. As far as I understand from the documentation of the following functions:


* ec_fsm_slave_action_process_sdo,
* ec_fsm_slave_action_process_reg,
* ec_fsm_slave_action_process_foe,
* ec_fsm_slave_action_process_soe

they should return 1 in case of success (i.e. request processed) 0 otherwise. They return instead 1 even in case of requests are aborted. I see new commits on the sable version branch but nothing about this. In the default branch they have been instead fixed long time ago (2597:0e145bb05859 2014-11-12 14:42 ?)

Which is the correct one?

Kind regards

William
Gavin Lambert
2018-02-08 21:53:40 UTC
Permalink
The documentation is not entirely up to date, so it can be misleading at
times.



Returning 1 does not indicate success or failure, it indicates whether the
datagram has been populated and needs to be sent (and thus whether the state
machine needs to continue). Success or failure of the request is indicated
by the state member of the request itself.



Having said that, there are some inconsistencies in these state machines,
which have been addressed in the unofficial patchset. Have a look at
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme.



From: William Ledda
Sent: Friday, 9 February 2018 05:54
To: etherlab-***@etherlab.org
Subject: [etherlab-dev] fsm_slave buggy?



Dear developers,

I was looking into the code of the stable-1.5 branch and It seems there is
some bugs in fsm_slave. As far as I understand from the documentation of the
following functions:



* ec_fsm_slave_action_process_sdo,
* ec_fsm_slave_action_process_reg,
* ec_fsm_slave_action_process_foe,
* ec_fsm_slave_action_process_soe



they should return 1 in case of success (i.e. request processed) 0
otherwise. They return instead 1 even in case of requests are aborted. I see
new commits on the sable version branch but nothing about this. In the
default branch they have been instead fixed long time ago (2597:0e145bb05859
2014-11-12 14:42 ?)



Which is the correct one?



Kind regards



William

Loading...