For debugging I am using gdb/stlink. Compile a sketch and then upload it via gdb/stlink.gato_ wrote: ↑Tue Sep 19, 2017 9:57 amActually, the onReceive() call doesn't seem to have any problems. And I am having some doubts about what happens with the onRequest() one. Are you using any environment to check the registers? if so, which one? what pins are employed for debugging? Thank you. Otherwise, the core is great
I think with your discovery of _tx_active the code should perform mostly as all the other implementations do (whether that's good or bad, I don't know). There are only really 2 issues that needs to be addressed (again to be compatible). One is to send dummy data subsequence to a onRequest() callback if there is more data requested than buffered from the first onRequest() callback. And the other one is to send a NACK if the peer sends more data than can be buffered for a single onReceive() callback ... If you have your code setup so that those conditions are not hit, you should be fine.
IMHO the real issue is the API itself (AVR and SAMD cores). If you have a onRequest() callback, you need to stuff in all the data you think might be read, up to the buffer size (which is 32 bytes for AVR). The callback will not be called again. And worse, there is no way telling how many bytes had be transferred to the peer.