I’m trying to add serial output to a project of my own. That was failing, so I went back to the tutorials. I’ve created a new project in Alchitry Labs and copied the code from the tutorial “ROMs and FSMs” locally. It builds fine and appears to load on the board.
It does not respond to the ‘h’ key as described in the tutorial. When I press ‘h’ nothing happens at all.
More details:
My board does show as an option when I open “Serial Terminal” in Alchitry Labs (2.0.25-BETA). The baud rate in the terminal is 1000000, which matches the rate in the code in the tutorial. When I click the chain link icon to connect the “Device” and “Baud Rate” boxes gray out, which seems to be by design so that they aren’t changed while connected, and the chain gets a slash through it for “disconnect” instead of “connect”. There’s no response to typing though. I tried clicking in different places in the window to ensure that that the cursor is in an active location. I also tried resetting the board while the connection is active, which had no apparent effect.
I have a Cu V2 connected to Windows 10. I’m using the open-source build tools.
Is this known to work with the current Labs and the V2 boards?
A new project using the hello world template shows the same behavior.
On the other hand, I was able to copy the code from the website for the Serial Interface tutorial, and that seems to work. What I type is echoed into the Serial Terminal in Lab in that case.
I am able to load code over the USB no problem (as demonstrated by the Serial Interface tutorial result and some simple programs that I wrote to flash the LEDs), so the cable and general connection are good.
Seems like it’s not possible to copy from the Serial Terminal window, but it’s repeating lines (good!) of characters that include non-letters like a box. Seems like maybe something about the coding is off, but I’m not sure what that would be for this type of pattern.
If I set the led array to match rx.data, I get what I think should be a binary representation of the last letter typed. What I actually get is b | 0b10000000 where b is the binary representation of the character. That’s to say that the most significant bit is always set, whereas it should not be set in the range of characters that I’m typing.
If I set the led array to 0 except for led[0] = rx.new_data, the leds never light. From that I infer that rx.new_data never goes high.
If I go back to the Serial Interface tutorial code and set the led array to rx.data, then I I get the same (incorrect) binary representation on the leds as in the first bullet above, but I get the correct character echoed into the Serial Terminal in Labs.
I think there must be something wrong with the uart_tx and uart_rx modules, but I haven’t dug deeply enough into those to understand what they are doing. Can you replicate this on a Cu V2?
It seems to be caused by something weird with D2XX in Windows. I updated the serial port code to use the COM port instead of the D2XX device on Windows and this seems to fix the issue. It’ll be live in 2.0.27.
I also improved the uart_rx module and added the missing “!” to the “Hello World!” string in the template project. (this was causing weird issues as there were only 13 characters but the tutorial assumed 14)