Feature/reorganise library

[humphrey-xmos]

Building host apps would require a lot of copy-paste, adding cmakes for variants to assist building specific host apps.

• Cmake now handles finding and linking libraries with cmake INTERFACE library per transport (I2C, SPI, USB, XSCOPE)

Plus,

• Moved header files in src folder to inc
• Moved host source from lib_device_control/host/ to host/
• Moved examples' "shared" resources to shared folder (were duplicated).
• Moved examples xcore code to device folder,
• Extracted USB transport to library functions from endpoint0, created transport_usb.xc
• Extracted I2C transport to library, create transport_i2c.xc

[Copilot]

Pull request overview

Copilot reviewed 59 out of 96 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[xross]

Not part of the changes in this PR, but looks to be quite a few generically named header files and defines which might be inconvenient if/when they clash with other items.

[xross]

this loop not ideal, assumes host will send the amount of data it said it would. Should be loop while received packet size == max packet size.

[xross]

We should be checking for bus resets too I guess - for example, a badly timed unplug is going to break this protocol

[humphrey-xmos]

We should be checking for bus resets too I guess - for example, a badly timed unplug is going to break this protocol

Well as far as I understand thats why it checks for (loop_result == XUD_RES_OKAY), so any status changes reported can be handled. Am I wrong here?

[humphrey-xmos]

this loop not ideal, assumes host will send the amount of data it said it would. Should be loop while received packet size == max packet size.

Please clarify? Whats the case you are trying to catch?

So the the cases I see are:

• host sends to much data, the loop has already exited and the host will wait and then timeout, can this happen?
• host sends too little data, waits on respond and times out, and probably a bus reset, so returns XUA_RES_UPDATE,

What am I missing here?

[xross]

We should be checking for bus resets too I guess - for example, a badly timed unplug is going to break this protocol

Well as far as I understand thats why it checks for (loop_result == XUD_RES_OKAY), so any status changes reported can be handled. Am I wrong here?

Sorry, yes, missed that. Any bus events should be handler by the calling function.

[xross]

this loop not ideal, assumes host will send the amount of data it said it would. Should be loop while received packet size == max packet size.

Please clarify? Whats the case you are trying to catch?

So the the cases I see are:

• host sends to much data, the loop has already exited and the host will wait and then timeout, can this happen?
• host sends too little data, waits on respond and times out, and probably a bus reset, so returns XUA_RES_UPDATE,

What am I missing here?

Its the second bullet from the spec I'm trying to capture (5.5.3 Control Transfer Packet Size Constraints)

The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of
the following:
• Has transferred exactly the amount of data specified during the Setup stage
• Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet

[xross]

Note, this also catches the "too much" data case you mention (just need to guard not overrunning a buffer in this case..)

[humphrey-xmos]

So do we need to test for, which I think to mentioned, recLength != wMaxPacketSize?

Should be loop while received packet size == max packet size.

Was you comment.

[xross]

yeah so continue to receive packets whilst recLength == wMaxPacketsize

If you get a packet size < wMaxPacketSize (including the 0 length case) then exit loop.

Im surprised there isn't such a receive loop function in lib_xud, looks like we only have the sending case covered there.

[xross]

Spotted a couple of things, the usb protocol I think is a debug session waiting to happen ;)

[ed-xmos]

Really nice update and cleanup. Some minor comments - I think Ross's ones are more "request changes" than mine which are mostly advisories/questions