Add bit-aligned / sub-byte PDO entry support to the emulator

[leducp]

Lets the emulator host slaves that declare sub-byte PDO entries (e.g.
4 BOOL GPIOs at 1):

• EmulatedESC honors FMMU logical/physical bit offsets via a per-bit slow path; byte-aligned mappings keep the memcpy fast path. FMMUs targeting addresses < 0x1000 (e.g. mailbox-status) now work.
• CoE::Entry gains data_bit_offset; addEntry/EsiParser allocate (bitlen+7)/8 bytes (was 0 for BOOL/BIT2..7). New copyBits / read/writeEntryBits helpers.
• SDO upload/download/complete-access switched to bit-accurate payload positioning. Sub-byte entries travel as 1 octet per ETG1000.5 §5.3.1; CA packs entries by bitoff per ETG2000.

[leducp]

ping @phamnhatha090805 this PR should enable bit support for the emulator and the stack in general

[leducp]

!!! Need proper testing before merge !!!

[github-actions]

File	Coverage	Lines	Branches
All files	78%	81%	76%	✅
lib/include/kickcat/Error.h	91%	100%	83%	✅
lib/include/kickcat/SBufQueue.h	80%	98%	63%	✅
lib/master/include/kickcat/SIIParser.h	91%	100%	83%	✅
lib/master/src/Bus.cc	91%	92%	89%	✅
lib/master/src/CoE.cc	61%	71%	51%	❌
lib/master/src/Link.cc	98%	100%	97%	✅
lib/master/src/MailboxSequencer.cc	97%	100%	94%	✅
lib/master/src/MasterOD.cc	99%	99%	100%	✅
lib/master/src/Prints.cc	95%	95%	95%	✅
lib/master/src/Slave.cc	27%	42%	12%	❌
lib/master/src/dc.cc	0%	0%	0%	❌
lib/slave/src/AbstractESC.cc	92%	100%	84%	✅
lib/slave/src/AbstractEmulatedEEPROM.cc	0%	0%	0%	❌
lib/slave/src/ESMStates.cc	96%	98%	94%	✅
lib/slave/src/ESM.cc	95%	100%	90%	✅
lib/slave/src/PDO.cc	91%	97%	85%	✅
lib/slave/src/ESC/EmulatedESC.cc	61%	68%	55%	❌
lib/slave/src/ESC/Lan9252.cc	0%	0%	0%	❌
lib/src/Frame.cc	98%	100%	97%	✅
lib/src/Mailbox.cc	89%	93%	85%	✅
lib/src/SIIParser.cc	40%	50%	30%	❌
lib/src/protocol.cc	94%	92%	96%	✅
lib/src/CoE/EsiParser.cc	92%	95%	89%	✅
lib/src/CoE/OD.cc	98%	98%	97%	✅
lib/src/CoE/protocol.cc	93%	93%	94%	✅
lib/src/CoE/CiA/DS402/StateMachine.cc	93%	94%	92%	✅
lib/src/CoE/mailbox/request.cc	80%	84%	76%	✅
lib/src/CoE/mailbox/response.cc	92%	96%	88%	✅
lib/src/EoE/protocol.cc	0%	0%	0%	❌

Minimum allowed coverage is 75%

Generated by 🐒 cobertura-action against f55d29f

[phamnhatha090805]

I have tested this on my side. However, there's still same Invalid SM cfg error. Also, if I simulate the official Beckhoff EL1002 which is only 2 inputs (each is 1 BIT), and the thing works without any errors.

[leducp]

I have tested this on my side. However, there's still same Invalid SM cfg error. Also, if I simulate the official Beckhoff EL1002 which is only 2 inputs (each is 1 BIT), and the thing works without any errors.

Thanks for the feedback! I'll do a pass to try to understand why :)

[leducp]

OK so I may have found the bug: I didn't handle the padding properly (that's the difference I saw between EL1002 and EL1004). Can you give it a shot? If it fail again, I propose that you give me the setup that fail and the setup that works so I can try to test on my side properly (even if I don't have TwinCAT)

[trns1997]

ping @phamnhatha090805 can you test again please. Thank you for your help and contributions, your insights are super helpful

[phamnhatha090805]

ping @phamnhatha090805 can you test again please. Thank you for your help and contributions, your insights are super helpful

I run the test again and now the custom EtherCAT device got stuck in SAFEOP. Also, I enable the -DDEBUG_ESI_INFO=ON when I do the cmake but how to see the debug results. I haven't got much experience in this.

[leducp]

ping @phamnhatha090805 can you test again please. Thank you for your help and contributions, your insights are super helpful

I run the test again and now the custom EtherCAT device got stuck in SAFEOP. Also, I enable the -DDEBUG_ESI_INFO=ON when I do the cmake but how to see the debug results. I haven't got much experience in this.

You can play with theses options:

• DEBUG_COE_ERROR
• DEBUG_COE_WARNING
• DEBUG_COE_INFO
• DEBUG_SLAVE_ERROR
• DEBUG_SLAVE_WARNING
• DEBUG_SLAVE_INFO
• DEBUG_ESI_INFO
• DEBUG_ESI_WARNING
• DEBUG_ESI_ERROR

Enabling all of theses should give us a better understanding of what's happening :)

[leducp]

@phamnhatha090805 can you redo a try with the last version? I managed to reproduce something similar with the emulator (stuck in safeop). I introduced a regression in the ESI parser for the ARRAY type by fixing the RECORD type (I though they were handled the same but it is not).
Now my emulator can go to OP with the latest patch.

[phamnhatha090805]

I don't know why but my thing still stuck in the SAFEOP. But anyway, I want to finish the ESI improvement first and make pull request before diving into this bit_support

[trns1997]

@leducp what do we do with this PR? Wait for the esi parser rework? or this is functional and we merge?

[leducp]

I think it is better to properly rework the ESI parser first, then address bit support in the stack. Switch it to draft