[etherlab-dev] [PATCH] FoE support for read BUSY (ETG.1020 Section 15)

[Dave Page]

     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. :)
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave_page.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140122/c6824519/attachment-0004.vcf>