Serial.write() are such powerful tools that I can’t understand why the Daisy Seed makes bidirectional sending of arbitrary data so difficult for beginners. I did some investigations, which I will list below.
Straight up googling for “Daisy Seed serial write” might lead a curious beginner to this getting started article. This approach calls itself “Serial printing”, while a quick look into the schematic reveals that the
D- lines are basically directly connected to the MCU’s pins B15 and C15 respectively. While the “S” in “USB” means “serial” as well, the term is usually used in the context of the UART protocoll, which can’t be the case with the Seed, as the USB-to-UART converter present on many other dev boards is missing here. This is also clear when looking at a device manager, as no COM-port (under windows) or RS232-emulator (under Linux) is visible.
While I can flash code via an external JTAG debugger, it remains a mystery to me how I can access the ports described in the mentioned getting started guide. Connecting the Seed to my machine doesn’t register any device associated with a COM-connection, although running
dfu-util displays this:
Found DFU: [0483:df11] ver=0200, devnum=10, cfg=1, intf=0, path="1-11", alt=1, name="@Option Bytes /0x5200201C/01*128 e", serial="200364500000" Found DFU: [0483:df11] ver=0200, devnum=10, cfg=1, intf=0, path="1-11", alt=0, name="@Internal Flash /0x08000000/16*128Kg", serial="200364500000"
…which tells me that a) my Seed is working and b) I installed the
dfu-util correctly as described in the wiki.
Interestingly, the actual UART connection is on pins 13 and 14, which is fine as a backup solution, but requires an extra connection and a dedicated USB-to-UART converter.
After some digging, I found a very promising project which acts as a CLI for the Seed from a windows host machine. In the code on the Seed, line 83 in
SeedComServer.cpp utilizes the
usb_handle.TransmitInternal() function to send messages via the USB line connected to the micro-USB jack on the board. Similarly, line 210 registers a user callback for the handling of incoming data. On the host side, a COM port is opened (see line 274 in
SeedCom.c) which again tells me that I should see a COM port (loosely using this term for Linux as well) from the Seed, which I don’t.
How is this handled? Should the Seed appear as COM-port as long as
RESET are not pressed and then disappear and only be visible to the
dfu-util? Apart from this issue (which is probably just on my side due to driver problems and the usual stuff) I really would have loved to see some examples for stuff like this because a simple, bidirectional communication is just so helpful for all sorts of things, especially when getting started as a beginner.