-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building for Linux #2
Comments
Please try again. I pulled some fix. |
I'm afraid that's only partial, since you're using library facilities that the upstream project avoided: # Linux gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl In file included from src/system/system.c:5, from src/dwdebug.c:3: src/system/SerialPort.c: In function ‘MakeSerialPort’: src/system/SerialPort.c:81:9: warning: implicit declaration of function ‘ioctl’ [-Wimplicit-function-declaration] 81 | if (ioctl(*SerialPort, TCGETS2, &config)) {Close(*SerialPort); *SerialPort = 0; return;} | ^~~~~ I'm very hesitant about my C and unix system programming, but I believe the "correct" fix involves replacing that header with sys/ioctl.h, which (according to pengutronix/microcom#30 ) that introduces some nasty side-effects. |
Can you be more specific about "you're using library facilities that the upstream project avoided:" Also "replacing that header", which header? |
I'm sorry, you're absolutely right: I didn't take on board that the ioctl() declaration was being handled as implicit and that the program was actually building successfully. I can run it, but so far am not confident that it can see the 552... or am I reading too much into your "The dwire-debug binary in this repo was compiled with this branch"? I'll continue tinkering... Apropos your
I was referring to the "doctrine" in my first message. |
First of all you need to confirm the firmware on CH552 is working or not. Can "lsusb" see the device? Can you use it to flash bootloader or firmware to a AVR? |
lsusb and dmesg definitely see it as 1781:0c9f. I'm working on a cable for an Arduino Uno and will report back. For completeness, the hardware I'm using is https://github.com/WeActStudio/WeActStudio.CH552CoreBoard, the same people have also cloned your ch55xduino. An interesting thing about WCH chips is that they don't always run well at more than USB "low speed" and might benefit from being attached to a low-speed USB hub. In the case of this CH552T, it's fine with either the as-shipped or your firmware, but needs to be on a low-speed hub for the loader mode to even be visible to Linux. |
I've got a precarious lashup comprising a cheap logic analyser and cheaper probes in front of me, I'd rather not get my better one out since the probes are adorning a development board. What I'm seeing is that there's a train of RST signals 200 mSec period 50% ratio. After those have completed the Arduino emits 2x break on its Tx. Roughly 3 sec after that there's activity on SCK (which is trivially visible as LED flickers), but I've not caught anything on other signals. I've been poking around a bit inside the code without finding anything obvious, I've not yet tried stretching those pulses but I've got a vague recollection of some timing dependencies when looking in the startup code a few years ago. Edited: That should have read "looking in the Arduino startup code". Which of course raises the issue that there are multiple versions and variants of the loader firmware floating around, even on the Uno, and they might not all behave the same as far as timeouts etc. behave. |
I've been able to program a CH552T on (Debian) Linux using
I'm not yet running the Arduaino v2 IDE, but have been trying to build your https://github.com/DeqingSun/dwire-debug/tree/ArduinoProIDEAlphaTest with limited success. The problem is that in src/system/SystemServices.c doctrine appears to have it that #include <stropts.h> needs to be replaced by #include <sys/ioctl.h>, but this triggers a redefinition which is beyond my wit to resolve.
The text was updated successfully, but these errors were encountered: