I was trying to get the USB CDC example to work so that I could use the serial console to let the Daisy know when I’m ready for it to run a test.
I simplified my code to just check for any activity on the UsbCallback. As far as I can tell, it is never called. I’ve tried on Linux using cu “cu -l /dev/ttyACM0 --baud=115200”, and Mac using CoolTerm. Both work fine to display from the Daisy USB CDC transmit. Just won’t receive.
I tried it. After some editing (#includes) to get it to compile, I got the same result. I also tried simplifying the callback to only increment the counter, still doesn’t appear to be called.
Thanks for trying it out! Looks like I hit an html issue when pasting the system level includes.
I think I’ve seen others saying that USB CDC receive was working, so what am I missing? Has something changed in libdaisy that breaks this recently? Or am I missing something from the code?
Confirmed it doesn’t work. It’s definitely build/linker related. I’ll try to get it sorted in the next few days.
Basically, malloc() isn’t working so the ClassData for USB isn’t getting allocated, causing all Transfer/reception from working. (This also affects using rand() from the standard library).
I had seen this issue come up a long time ago (but only in the Visual GDB build), and had fixed it at one point.
@hexcode you mentioned that you’re still able to do Tx – are you on an up to date version of libdaisy? Also, are you building with the project’s Makefile, or using an IDE with different build settings?
Didn’t pull libdaisy that long ago, looks like it is pointing at this:
git ls-tree -r HEAD | grep commit
160000 commit ddaa1588c793e115f9e0ca915069376caf2e120a DaisySP
160000 commit b92e4be7f7ce87769b90e2b7c4c10f1fabb347eb libdaisy
I’m building on Linux. Just copied DaisyExamples/seed/USB_CDC completely and changed the source. Using make at command line to build.
Alright, I think I’ve tracked down the issue. It looks like a lot of the USB initialization is done asynchronously. So if you call SetReceiveCallback immediately after init the callback will get overwritten as it takes several milliseconds before the actual USB Init is completed and the default empty callback is set.
A temporary band-aid is to add large delays between the UsbHandle::Init, and the UsbHandle::SetReceiveCallback functions. I’m going to clean up the existing code a little and add a status function to the API to make this a bit more straight forward.
This code works on my end with libdaisy unchanged:
I know this is old, but is there any progress on a status flag/function to see if the USB is ready to transmit more? I’m putting delays in, but that doesn’t seem a very good solution. Thanks.