Yes... I see you beat me to it:
@@ -778,6 +792,8 @@ void ec_fsm_foe_state_data_read(
if (opCode == EC_FOE_OPCODE_BUSY) {
if (ec_foe_prepare_send_ack(fsm, datagram)) {
ec_foe_set_rx_error(fsm, FOE_PROT_ERROR);
+ } else {
+ fsm->state = ec_fsm_foe_state_sent_ack;
}
return;
}
(except for the PacketNo issue). Sorry I missed that one.
My stack is configured to test this at the moment, so its no
problem to combine and test for me.
Best regards - Dave
On 2014-01-22 18:13, Gavin Lambert wrote:
Mere moments ago, quoth I:Did you see my other patch specifically for FoE busy? My slave is working fine for busy reads with both of my patches applied. (There was a third patch included in the same email as the busy patch, but that's optional and just increases debug logging.) My patch also fixes handling of error packets.These are at http://lists.etherlab.org/pipermail/etherlab-dev/2013/000324.html, if you're having trouble finding it.As for incrementing the packet number or not, it's been a while since I looked at that so I don't remember whether it increments or not with my patches applied, but I think I remember making it do whatever the SSC was expecting.I had a quick look at my SSC patches, so now I think I remember -- my version would continue incrementing the packet number (which is partly why I ran into the 256 packet limit that prompted the other patch). You're correct that ETG.1020 indicates that the packet number should not be increasing though; I missed that part. (It worries me a bit when both master AND slave code have to be changed to make something fundamental like this work, and it makes me wonder about existing devices -- but I guess FoE read is not implemented all that often.) One of us should probably make a combined patch set that fixes all three issues, for ease of future players (and maybe even merging, one of these days). I'll probably get to it in a few days when I (hopefully) get back to EtherCAT-related work, if you don't beat me to it. :)
<<attachment: dave_page.vcf>>
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
