TTL RGB OUTPUT Normallly High during VSYNC

[coucouillu]

Hi @KerJoe

On RTD2660, and with TTL mode , I try to get all RGB output normally HIGH while now they are normally LOW. I am turning around since weeks now without finding a solution. Could someone help me to find the correct REGISTER setting from the RTD2660 It should be like an INVERSION setting like I did for the VSYNC and HSYNC signals but cant' find it for the RGB outputs.

See in the example here, RED signal is currently normally LOW from my RTD2660 (first picture) I need to obtain HIGH output like that (signals RED and GREEN) captured for the source I need to reproduce (second picture).

I tried to tweak Address 29 bit0 but without success. Any advise? Thank you for your help

[KerJoe]

Have you tried the following sequence?

ScalerWriteBit(S_VDISP_CONTROL, 1, 0b0) // Clamp data bus to 0
ScalerWriteBit(S_VDISP_CONTROL, 6, 0b1) // Enable data bus inversion
ScalerWriteBit(S_VDISP_CONTROL, 1, 0b1) // Restore normal data bus output

[coucouillu]

Hi @KerJoe This sequence does not seems to work. no impact on RGB output. Seems weird. I will try more deeper before coming back to you. Thank you for your reply.

[coucouillu]

Hi @KerJoe I was not initially on your code but on another relying on KeilV5.

So, I switched to your code and I am now able to compile and flash through Windows.

As your code is not structured like the previous I was working on, could you please precise where to put the sequence in your code please?

My goal is to put at the start of the power of the screen with a background screen in order to sniff signals with the USB analyser without need to input signal to the board (VGA, HDMI etc..).

ScalerWriteBit(S_VDISP_CONTROL, 1, 0b0) // Clamp data bus to 0
ScalerWriteBit(S_VDISP_CONTROL, 6, 0b1) // Enable data bus inversion
ScalerWriteBit(S_VDISP_CONTROL, 1, 0b1) // Restore normal data bus output

thanks

[KerJoe]

You can try inserting those 3 lines after InitScaler() call in core/main.c. And add the while loop (while(1);) after SetOverlayColor() to stay in the background output mode.

[coucouillu]

Hi @KerJoe,

Unfortunately, I compared before the new settings and after the new settings : these settings have no effect. I worry that this RTD2660 can't manage RGB normally High during VSYNC Period . If it is confirmed, my project is down. Same results as the other source code for RTD2660 that I tried since weeks

In details : I took your code I switched from LVDS to TTL (#define PANEL_TYPE TTL) in (panel_config.h) I add the settings you shared. compile+load+scan

What i get :

[KerJoe]

By the way, why do you need the data bus to be high during the VSYNC period?

[coucouillu]

Hi @KerJoe The panel I need to connect has an exotic signal. It is a proprietary signal without any datasheet available. I succeed to reverse engineer the signal with a logic analyser and generate a video test picture with an ESP32-S3 and then with a FPGA TANG NANO 9 to confirm the expected signal. Now I need to switch to RTD266x in order to have the VGA/HDMI inputs. My current code that I branched from yours generate a signal at 80% OK except the High level of RGB during BACK_PORCH+VSYNC+FRONT_PORCH period (you notice that currently VSYNC signal during "BACK_PORCH+VSYNC+FRONT_PORCH" period is not good too but it is not a matter because I was able to generate it correctly with another code. So I know that VSYNC signal issue is feasable. But for High RGB, I have no clue yet.

Could we go further together with tests on your side for the RGB output matter ? Do the settings have effect on your side? This is weird that they change nothing on my signal. And again thank you for your time

Reminder what i get :

what I need to generate ("VSYNC PERIOD" on the picture may include the PORCHS) :

[KerJoe]

Ok, I'll see what I can do on my board. If all else fails maybe you can try using some high speed logic gates on the output... just a thought.

[Coucouillu2009]

For the high speed logic gates I thought about it but I conclude that will not work during the 2 PORCH periods. Without a firmware solution, my project is dead :( In still continue to search on my side but I explorered all ideas without success. And again, fornme the weird thing is that I do not understand why your proposal settings have no effect. It is like they are inhibited. Are you able to exchange with the RTD through a serial terminal for debugging ? I would like use some PRINTF functions to monitor values but don't know how.

[KerJoe]

Ok, I've managed to recreate the output. The starting and ending hsync pulses in data bits are slightly cut short, but hopefully that won't be a problem.

1. VSYNC
2. Data bus bit
3. TCON[0] (Data inversion)
4. HSYNC

Here's the code:

    InitScaler();
    SetOverlayColor(0xff, 0xff, 0xff);

/////////////////////////////////////    

    // TODO: Modify scaler_registers.h to use these macro names
#   define SP_TCON_VSTA_LO(n)       (0x08 + n * 8) // TCON[n] Vertical Start LByte
#   define SP_TCON_VEND_VSTA_HI(n)  (0x09 + n * 8) // TCON[n] Vertical End/Start HByte
#   define SP_TCON_VEND_LO(n)       (0x0A + n * 8) // TCON[n] Vertical End LByte
#   define SP_TCON_HSTA_LO(n)       (0x0B + n * 8) // TCON[n] Horizontal Start LByte
#   define SP_TCON_HEND_HSTA_HI(n)  (0x0C + n * 8) // TCON[n] Horizontal End/Start HByte
#   define SP_TCON_HEND_LO(n)       (0x0D + n * 8) // TCON[n] Horizontal End LByte
#   define SP_TCON_CONTROL(n)       (0x0E + n * 8) // TCON[n] Control

#   define TCON_VSTA (PANEL_V_SYNC_WIDTH + PANEL_V_BACK_PORCH)
#   define TCON_VEND (PANEL_V_SYNC_WIDTH + PANEL_V_BACK_PORCH + PANEL_V_ACTIVE)
#   define TCON_HSTA (0x000)
#   define TCON_HEND (0xFFF)

    SetGPIOShare(PIN097, 0b100); // DVS on pin 97
    ScalerWritePortBit(S_TCON_PORT, SP_TCON_CONTROL0, 7, 0b1); // Enable timing controller function    

    // Vertical timings for TCON[0]
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VSTA_LO(0), TCON_VSTA); // Set signal start line number low
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VEND_VSTA_HI(0),
        ((TCON_VEND & 0xF00) >> 4) | // Set signal stop line number high
        (TCON_VSTA >> 8));   // Set signal start line number high
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VEND_LO(0), TCON_VEND); // Set signal stop line number low
    // Horizontal timings for TCON[0]
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HSTA_LO(0), TCON_HSTA); // Set signal start pixel number low
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HEND_HSTA_HI(0), 
        ((TCON_HEND & 0xF00) >> 4) | // Set signal stop pixel number high
        (TCON_HSTA >> 8));   // Set signal start pixel number high
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HEND_LO(0), TCON_HEND); // Set signal stop pixel number low
    // Control register for TCON[0]
    ScalerWritePortBit(S_TCON_PORT, SP_TCON_CONTROL(0), 7, 0b1); // Enable TCON
    ScalerWritePortBits(S_TCON_PORT, SP_TCON_CONTROL(0), 0, 3, 0b100); // Invert data bus when TCON[0] is 0

/////////////////////////////////////  

    // On screen display example
    OSDInit();
    char* entries[]= { "scaling", "other" };
    OSDCreateMenu("Settings", entries, 2);
    SetOverlayColor(0xaa, 0xaa, 0xaa);

[KerJoe]

As for my debugging setup I compile for PC using make native, afterwards I use VS Code (with gdb backend) to step through and send values to the scaler. The PC communicates with the scaler using the I2C interface used for programming and DDC+EDID. The communication code is in core/i2c_native_iface.c, it is Linux specific though.

[Coucouillu2009]

Hi @KerJoe. I am reading you during a job travel. I am impatient to go back home and be able to test your code this weekend.

For the debug, I understand that you work under linux, do you? If not, how do you use core/i2c_native_iface.c? Through Windows WSL?

Thanks a lot. Please share to me your paypal account, I woukd be pleased to offer you a beer/softdrink/whatever_you_drink.

[coucouillu]

Hi @KerJoe, Your code helped a lot and get now a satisfying RGB signal. A big step done! Unfortunately, the screen does not accept yet the global signal (no image on the screen). The signal should miss something. I guess that it is caused by the signal on CLK pin (GPIO52, PIN096 = GPIO52). The signal I catch does not seem to be a pixel clock, but a horizontal clock. Have you any advise? thanks

What I get

What I should get

[KerJoe]

Sorry, I forgot about the clock output. The pin 96 should be assigned to the display clock signal just like the vsync pin.

SetGPIOShare(PIN096, 0b100); // DCK on pin 96
SetGPIOShare(PIN097, 0b100); // DVS on pin 97

I've also created a separate branch for this issue here.

[KerJoe]

As for debugging, the core/i2c_native_iface.c relies on i2cdev Linux kernel module, so it can't be used in WSL (because the WSL's kernel does not have full access to the hardware). However there is an #if 0'ed code there, that can use interface classes written in python from RTDMultiProg. Windows, unlike Linux, does not have a unified i2c api, so separate code has to be written for each device. So far you can use mcp2221, ch341 or nvidia gpu to connect to the scaler.

[KerJoe]

The RTD2662 also supports switching to UART instead of the first i2c channel, which means you can't program through it or use it for EDID, after the switch. The code for it is in peripherals/uart.c, I can reenable it if you need it.

[coucouillu]

Sorry, I forgot about the clock output. The pin 96 should be assigned to the display clock signal just like the vsync pin.

SetGPIOShare(PIN096, 0b100); // DCK on pin 96
SetGPIOShare(PIN097, 0b100); // DVS on pin 97

I've also created a separate branch for this issue here.

Hi @KerJoe I think it is nit just a declaration issue because declaring PIN96 still give the same result. I think it is more due to settings on the CLK pin. Currently, it does not clock at pixel. It clocks currently at HSYNC. It should also cock during VSYNC+xPORCHS periods

Any new Idea?

[KerJoe]

No, what you are meassuring is just noise from the data pins. I've missed enabling the clock output in the register SP_VDISP_TIMING. Here is the fix.

[coucouillu]

Hi @KerJoe First good result. I recover hope for my project. 😘

The code is looping with the while(1) just after OSDInitand SetOverlayColorin order to have a unic frame but the screen is flickering a lot. I will try to check the clock signal that seems very high voltage and never goes below 1.5Volts

[coucouillu]

Hi @KerJoe Next step, I try to make the HDMI input working but no success ; the code seems to loop in the while(1); of the # ifdef __SDCC

My goal is to input any HDMI resolution (1080p, 720p, etc..) and let the scaler scale the good resolution according to the panel settings. Is it possible?

[KerJoe]

By the time the execution reaches this line, it should have already setup the HDMI input, measured it and set the appropriate scale up/down factors. Are you sure you are setting up the correct TMDS and I2C channels, what scaler pins do the HDMI port video and I2C pins connect to? Is the scaler detected by the computer as a video output?

[KerJoe]

Can you send me the video of what the "screen flickering" looks like, and also a photo of the screen with HDMI connected.

[coucouillu]

Hi @KerJoe I remind you that I am on PCB900099_V9 board while you created your own. Perhaps a pinout issue? The board is recognized by the PC (windows sound). I kept te original EDID from your code and I can see several resolution defined under PC display parameters.

For the rest of the code, I also kept yours, I just adapted only few lines to fit my screen. Exemple: from FALSEto TRUE the values of PANEL_INVERT_DCLK, PANEL_INVERT_DHS, and PANEL_INVERT_DVS I also modified from ScalerWritePortBit(S_VDISP_PORT, SP_VDISP_TIMING, 0, 0b1); to ScalerWritePortBit(S_VDISP_PORT, SP_VDISP_TIMING, 1, 0b1);

So here are my tests through 2 videos With HDMI connected > Edit : during my first tests, I good picture appears (I recognized on the LCD the icons on desktop from the PC). but now the picture is vertical bars generated from the signal (you can recognize the color of the icon in vertical.

Without HDMI connected > the screen flickers (OSD included) BUT is stable when the HDMI cable is connected to PC

I still not well equiped for the debugging so I used the OSD_menu+delay in order to display the different step of the code. The picture appears on screen after the line SetFIFOWindow(hact, vact);

[KerJoe]

Can you please attach the video in the comment and not the google drive.

[coucouillu]

EDIT : videos are too big. I shared to all in my GDrive

I will try to attach videos in the comment

In the meantime, I just shared the links "to all" in my GDrive

I try to display the values of hact and vact in the OSD for debugguing but without success to convert values to strings

    char* valuesToMenu[]= { "hact-vact", hact, vact };
        OSDCreateMenu("PostSetFIFOWin", valuesToMenu, 3); 

[KerJoe]

char hact_str[11], vact_str[11];
sprintf(hact_str, "%i", (int)hact);
sprintf(vact_str, "%i", (int)vact);
char* valuesToMenu[] = { "scaling", hact_str, vact_str };

[KerJoe]

1.webm

2.webm

[coucouillu]

char hact_str[11], vact_str[11];
sprintf(hact_str, "%i", (int)hact);
sprintf(vact_str, "%i", (int)vact);
char* valuesToMenu[] = { "scaling", hact_str, vact_str };

Well done

[KerJoe]

It's getting late here, I'll try things on my board tomorrow, meanwhile... Can you post results from ScalerReadByte(S_STATUS0), ScalerReadByte(S_STATUS1) and values from other members of InputMeasData. Does the image on the panel change when you move the cursor? Try manually specifying InputMeasData.HFreq, hact and vact. Comment out ScaleUp and ScaleDown and feed the native resolution to the scaler.

[coucouillu]

OK @KerJoe Does the image on the panel change when you move the cursor? Yes it move. It looks like first lines repeated on each lines. I will try the rest you asked for and post it ASAP but I am not sure to be able, as I have no setup to debug via terminal right now. I am only debuging by pronting through the screen with the OSD. Have a good night

[KerJoe]

OK, I've pushed a new commit, try it.

[coucouillu]

Hi @KerJoe

1. I tested your new commit but I get a black screen when HDMI is detected. I analyzed the signal to understand what happened. I noticed that after HDMI input the clock rate and RGB signal are no longer as expected as we [did](https://github.com /KerJoe/ORTD2662/issues/3# issuecomment-2226777557) with the first step with a “while” just after the OSD display) -We see the analog CLK change, the corresponding digital CLK scan changed the frequency to 27.xxMhz and -We see that the RGB during VSYNC is higher than LOW. It seems that some screen settings are no longer taken into account when switching to HDMI mode.

Here is the analysis of the signals:

2. But in the meantime I did some tests and I got the beginning of an image on the screen but like a Picasso with different pieces of the image repeated horizontally. how?:

• I commented out a lot of functions like you proposed (ScaleUp, ScaleDown, SetFIFOWindow, SetDPLLFrequncy, ...)
• set the value of hact = 800, vact = 480;
• and play with the arguments of the SetCaptureWindow function with different values

    uint32_t hact = 800, vact = 480; //resolution of my screen
[...]
    // Adjust HStart, VStart, HDelay, VDelay if picture is shifted
    //SetCaptureWindow(0, 0, hact, vact, 1, 1);     //test 1
    //SetCaptureWindow(-12, 10, hact, vact, 1,1); //test 2
    //SetCaptureWindow(-12, 40, hact, vact, 1,1); //test 3
    //SetCaptureWindow(-12, 80, hact, vact, 1,1); //test 4
    SetCaptureWindow(-120, 100, hact, vact, 1,1); //test 5

Maybe this could help you understand the problem. Next step I will try to scan the signal frequencies to check how it is possible for the screen to get an image.

3. Before continuing, I will make sure with you that what I need is achievable. I explain: I need the RTD to manage the Clock_signal at the X_Mhz frequency of the screen independently of the Clock_signal Y_Mhz of the input (from HDMI, VGA etc.). Is this possible or is the RTD only capable of transferring the frequency from the input to the screen requiring me to have a source in the same frequency of my screen? (so the project would be KO :( )

[coucouillu]

@KerJoe I did it wrong! Forget the point "1." from my previous message. I tested again and it works partially. It displays a picture but offset horizontally.

Points "2." and "3." of previous message are still valid.

(on picture : PC source above / Screen below)

[coucouillu]

@KerJoe in addition to make your code working like picture above, I was obliged to comment out some lines because like a conflict between MeasureSignal(0); and SetDPLLFrequncy causing black screen. I need to comment out one of the both or both of them.

working codes :

 // Measure in analog mode for Frequencies
 // MeasureSignal(0); //causes black screen if activated
[..]
SetDPLLFrequncy((PANEL_H_SYNC_WIDTH + PANEL_H_BACK_PORCH + PANEL_H_ACTIVE + PANEL_H_FRONT_PORCH) *
              InputMeasData.HFreq / vact * PANEL_V_ACTIVE);

or

 // Measure in analog mode for Frequencies
  MeasureSignal(0); //causes black screen if activated
[..]
//SetDPLLFrequncy((PANEL_H_SYNC_WIDTH + PANEL_H_BACK_PORCH + PANEL_H_ACTIVE + PANEL_H_FRONT_PORCH) *
 //             InputMeasData.HFreq / vact * PANEL_V_ACTIVE);

or

 // Measure in analog mode for Frequencies
 // MeasureSignal(0); //causes black screen if activated
[..]
//SetDPLLFrequncy((PANEL_H_SYNC_WIDTH + PANEL_H_BACK_PORCH + PANEL_H_ACTIVE + PANEL_H_FRONT_PORCH) *
   //           InputMeasData.HFreq / vact * PANEL_V_ACTIVE);

[coucouillu]

So when I get a picture on screen (offset horizontally) and the the source put in standby of if I remove the hdmi cable, the RTD can't recover the good timig causin flickering. analysis shows that the CLK freq is kept but the VSYNC is not at the good frequency anymore.

[KerJoe]

1. To make the display align you need to adjust HStart, VStart, HDelay, VDelay in SetCaptureWindow.
2. You should also try different frequencies around the native panel frequency in SetDPLLFrequncy.
3. The firmware doesn't handle input disconnects, so the internal circuit responsible for syncing input and output signals times out, resulting in sparse output vsyncs and flickering.
4. The firmware also only measures the signal once, so a resolution change requires a reset. While points 3 and 4 are easy to fix, the points 1 and 2 are much harder, as I haven't really figured out how to measure and calculate these parameters programmatically.

[coucouillu]

Thanks @KerJoe. Clear explanations. But I don't understand the purpose of the functions SetCaptureWindow/SetDPLLFrequncy because we already define the panel settings in the config/panel_config.h file. And the firmware uses these config/panel_config.h parameters well because it can display the OSD well. But when it receives an input signal, why should we set the parameters again via SetCaptureWindow/SetDPLLFrequncy? Why is the firmware still not using the config/panel_config.h settings?

I thought the purpose of the scaler in the firmware was to "scale" AN INPUT whatever the resolution (480, 720, 1080, etc.) whatever the frequency (60hz, 50h etc.) into one DEFINED OUTPUT for the panel (example TTL 800x480 33Mhz etc. in file "config/panel_config.h") In my mind, the panel settings (the OUTPUT settings) should never change while the firmware is running.

I am wrong?

(and thank you again for all your support)

[KerJoe]

The SetCaptureWindow function sets up the INPUT signal parameters. The second SetDPLLFrequncy fine tunes the OUTPUT clock, so it more closely matches the timings of the INPUT signal. It does it so that (afaik) the internal FIFO video buffer does not experience over- or underruns, due to the difference of horizontal frequency between the input and the output.

[KerJoe]

Also, I've been meaning to ask, please post the modified files in the config/ directory.

[coucouillu]

Also, I've been meaning to ask, please post the modified files in the config/ directory.

Here they are config.zip

[coucouillu]

The SetCaptureWindow function sets up the INPUT signal parameters. The second SetDPLLFrequncy fine tunes the OUTPUT clock, so it more closely matches the timings of the INPUT signal. It does it so that (afaik) the internal FIFO video buffer does not experience over- or underruns, due to the difference of horizontal frequency between the input and the output.

So What I need is not possbile if I undersand well?

I thought the purpose of the scaler in the firmware was to "scale" AN INPUT whatever the resolution (480, 720, 1080, etc.) whatever the frequency (60hz, 50h etc.) into one DEFINED OUTPUT for the panel (example TTL 800x480 33Mhz etc. in file "config/panel_config.h") In my mind, the panel settings (the OUTPUT settings) should never change while the firmware is running.

[KerJoe]

So What I need is not possbile if I undersand well?

It may be, it may be not. Have you actually tried to check whether the changes to the capture window stabilise the image? Changing the clock may not even be necessary, if these are set correctly.

If that doesn't work, modify the EDID to more closely match the timings of the panel, most importantly, the horizontal frequency: 33MHz / (41 + 82 + 800 + 4) ≈ 35.59870550 kHz ≈ 35.6 kHz.

My panel allows ±20MHz of clock difference, I understand your panel is proprietary and may not be so accomodating of the wide clock differences, but it should still be possible to modify the frequency in some, if limited, range.

[Coucouillu2009]

DEBUGGING

As for my debugging setup I compile for PC using make native, afterwards I use VS Code (with gdb backend) to step through and send values to the scaler. The PC communicates with the scaler using the I2C interface used for programming and DDC+EDID. The communication code is in core/i2c_native_iface.c, it is Linux specific though.

As for debugging, the core/i2c_native_iface.c relies on i2cdev Linux kernel module, so it can't be used in WSL (because the WSL's kernel does not have full access to the hardware). However there is an #if 0'ed code there, that can use interface classes written in python from RTDMultiProg. Windows, unlike Linux, does not have a unified i2c api, so separate code has to be written for each device. So far you can use mcp2221, ch341 or nvidia gpu to connect to the scaler.

As for debugging, the core/i2c_native_iface.c relies on i2cdev Linux kernel module, so it can't be used in WSL (because the WSL's kernel does not have full access to the hardware). However there is an #if 0'ed code there, that can use interface classes written in python from RTDMultiProg. Windows, unlike Linux, does not have a unified i2c api, so separate code has to be written for each device. So far you can use mcp2221, ch341 or nvidia gpu to connect to the scaler.

Hi @KerJoe I really need to debug in order to go further to catch values of IF-THEN-ELSE loop the program run is going. I am doing a lot of loops : EDIT_SOURCE_CODE>COMPILE>RECOVER_BIN_FILE>FLASH_THE_RTD >>REPEAT. I need my bench set up as easiest to use as possible but on WINDOWS. switching to Rasberry Linux through USB flash to retreive .bin files etc.. would be too long at each loop.

Currenlty, I use VS code on Windows to EDIT_SOURCE_CODE and COMPILE generating the BIN_FILE then I use Floppes method (= a Windows executable + a bootloaded Arduino) to flash BIN to the RTD MCU.

Connecting
The communication between display and Arduino is done via I²C which is accessible on the
VGA and HDMI ports of RTD266x **[I AM CURRENLY USING THE SDA/SCL FROM THE VGA PORT]**. Connect SCL, SDA and GND with the
corresponding Arduino pins.
For an Arduino Uno and an HDMI connector type A, this would be:
There are no additional pull-ups required, they are already on the RTD266x PCB.

The connection is on Pins 56 & 57 or PIN58 & 59 (depending of using VGA PORT or HDMI port). I could use the mutlimeter to deermine exactly which ones I am using.

I just bought a ch341 flasher hopping it would be good enough for the debbug

Do you think I could mount a setup to more easily develop/debug on WINDOWS ?

[KerJoe]

Hello, I've pushed some changes to the issue-3 branch, that should allow you to debug via the CH341 programmer. You will need to clone RTDMultiProg into the parent folder of ORTD2662 project. Compile for PC: make native; then you can try running the resulting binary: output_native/native.exe. You should be able to debug in VSCode through the task Debug Native Build defined in .vscode/launch.json

According to this schematic I found: You need to bridge pins 1 & 2, and connect the SDA & SCL signals from the ZIF socket to pins 59/123/122 & 58/124/121, respectively (pins 56 & 57 are AFAIK master only) .

[Coucouillu2009]

Hello @KerJoe

• I applied a MOD on CH341A PCB in order it to operate on 3.3V instead of 5V.
• SDA & SCL signals from the ZIF socket connectec to pins 123 & 124 respectively
• I made a fresh folder workspace with your last issue-3 + MultiProg folder as parent.
• I am stucking in an issue with #include "Python.h" in i2c_native_iface.c file inside VSCode while I have plenty of installation of "Python.h"

VSCode terminal :

PS C:\cygwin64\home\NUCi7\ORTD2662-issue-3> make native
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
gcc ./core/i2c_native_iface.c -I. -I/include -MMD -ggdb3 -o output_native/i2c_native_iface.o -c
./core/i2c_native_iface.c:11:10: fatal error: Python.h: No such file or directory
   11 | #include "Python.h"
      |          ^~~~~~~~~~
compilation terminated.
make: *** [Makefile:48: output_native/i2c_native_iface.o] Error 1
PS C:\cygwin64\home\NUCi7\ORTD2662-issue-3> 

I think I made a mess with VSCode settigns and PATHs forte includes because it never find easily the include files.

If I try to copy all include files inside the workspace C:\cygwin64\include, I pass the #include "Python.h" issue but generate plenty of others issues :

PS C:\cygwin64\home\NUCi7\ORTD2662-issue-3> make native
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
gcc output_native/adjust_.o output_native/adjust_customer_.o output_native/audio_.o output_native/auto_.o output_native/closecaption_.o output_native/eeprom_.o output_native/framesync_.o output_native/func_.o output_native/gmiosdfunc_.o output_native/guartsend_.o output_native/hdmi_.o output_native/i2c_.o output_native/int_.o output_native/ir_nec_.o output_native/key_.o output_native/key_pcb2660_003_5key_.o output_native/main_.o output_native/mcu_.o output_native/memory_.o output_native/misc_.o output_native/mode_.o output_native/osd_fac_.o output_native/osdmenufunc003_.o output_native/osdproc003_.o output_native/osdres003_.o output_native/osdtable003_.o output_native/power_.o output_native/rtdaccess_.o output_native/scaler_.o output_native/source_.o output_native/struct_.o output_native/sync_.o output_native/timer_.o output_native/uart_.o output_native/vbi_.o output_native/vchip_.o output_native/video_.o output_native/videodec_.o output_native/ypbpr_.o output_native/debug.o output_native/i2c_native_iface.o output_native/main.o output_native/misc.o output_native/composite.o output_native/hdmi.o output_native/vga.o output_native/1bit_font_vlc.o output_native/osd.o output_native/osd_ui.o output_native/adc.o output_native/ddc.o output_native/pins.o 
output_native/timer.o output_native/uart.o output_native/measure.o output_native/mode_tables.o output_native/scaler.o output_native/scaler_access.o output_native/scaler_tables.o output_native/scaling.o -I. -I/include -MMD -ggdb3 -L -lpython3 -o output_native/native.exe
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: output_native/i2c_native_iface.o: in function `_Py_DECREF':
/home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:430:(.text+0x32): undefined reference to `_Py_Dealloc'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: output_native/i2c_native_iface.o: in function `XSFRWriteByte':
/home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:27:(.text+0xda): undefined reference to `PyObject_CallMethod'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:27:(.text+0x109): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: output_native/i2c_native_iface.o: in function `XSFRReadByte':
/home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:33:(.text+0x154): undefined reference to `PyObject_CallMethod'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:33:(.text+0x183): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:34:(.text+0x1ae): undefined reference to `PyObject_CallMethod'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:34:(.text+0x1dd): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:35:(.text+0x21a): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:36:(.text+0x22b): undefined reference to `PyList_GetItem'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:36:(.text+0x25a): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:37:(.text+0x297): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:38:(.text+0x2a3): undefined reference to `PyLong_AsLong'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: output_native/i2c_native_iface.o: in function `begin_i2c_native_iface':
/home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:50:(.text+0x2e1): undefined reference to `Py_Initialize'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:52:(.text+0x2f0): undefined reference to `PyImport_ImportModule'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:53:(.text+0x307): undefined reference to `PyObject_GetAttrString'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:54:(.text+0x31a): undefined reference to `PyUnicode_FromString'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:55:(.text+0x32e): undefined reference to `PyList_Append'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:61:(.text+0x361): undefined reference to `PyUnicode_FromString'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:61:(.text+0x390): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:62:(.text+0x3a6): undefined reference to `PyImport_Import'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:62:(.text+0x3d5): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:63:(.text+0x3eb): undefined reference to `PyModule_GetDict'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:63:(.text+0x41a): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:64:(.text+0x437): undefined reference to `PyDict_GetItemString'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:64:(.text+0x466): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:65:(.text+0x47c): undefined reference to `PyCallable_Check'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:65:(.text+0x4a4): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:66:(.text+0x4bf): undefined reference to `PyObject_CallObject'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:73:(.text+0x525): undefined reference to `PyObject_CallMethod'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:73:(.text+0x554): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: output_native/i2c_native_iface.o: in function `end_i2c_native_iface':
/home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:87:(.text+0x5d3): undefined reference to `PyObject_CallMethod'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:87:(.text+0x602): undefined reference to `PyErr_Print'
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: /home/NUCi7/ORTD2662-issue-3/./core/i2c_native_iface.c:91:(.text+0x629): undefined reference to `Py_Finalize'
collect2: error: ld returned 1 exit status
make: *** [Makefile:45: output_native/native.exe] Error 1
PS C:\cygwin64\home\NUCi7\ORTD2662-issue-3> 

[KerJoe]

I've not been successful in compiling the program under cygwin (the binary errors out in python initialization code with Bad file descriptor from Windows OS).

I recommend you use MSYS2:

1. Install it from https://www.msys2.org
2. Run msys2.exe shell
3. Install packages pacman -S git make gcc pkgconf python
4. Clone repositories git clone https://github.com/KerJoe/ORTD2662; git clone https://github.com/KerJoe/RTDMultiProg
5. Compile cd ORTD2662; git checkout issue-3; make native
6. Run the program output_native/native

You can then add C:\msys64\usr\bin to the begining of the PATH environmental variable to allow VSCode to use it for compilation.

P.S. Technically you should only use msys2 shell when compiling for msys2 environment and ucrt64/mingw64/... when compiling your own programs, but the newer mingw headers in ucrt shell have a bug in a _mingw.h file (you can easily suppress it by commenting out the line 605), which is not present in the older version found in msys2 shell, so I decided not to bother using it.

[coucouillu]

All OK until step 6 At step 5, compilation for "native.exe" generation is OK under msys2 (no blocking error messages) and the program is present in the folder. I also added C:\msys64\usr\bin to the begining of the PATH environmental variable.

At step 6, I ran the program output_native/native but I get an error message and a dump file under both msys2 and VSCode. The dump files are a littel different so I post both.

Dump file from msys2.exe

Exception: STATUS_ACCESS_VIOLATION at rip=0001004246DC
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=00006FFFFFF7B060 rsi=0000000000000003 rdi=0000000000000002
r8 =000000052C6831A0 r9 =0000000000000000 r10=0000000800000000
r11=000000052C5E9E89 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
rbp=00000007FFFFCB30 rsp=00000007FFFFCB30
program=C:\msys64\home\NUCi7\ORTD2662\output_native\native.exe, pid 1019, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame         Function      Args
0007FFFFCB30  0001004246DC (000100436C20, 000000000023, 000000000000, 000000000001) native.exe+0x246DC
0007FFFFCB90  0001004248CF (000100426F81, 00018023081E, 000800024C1F, 000000000001) native.exe+0x248CF
0007FFFFCBC0  000100427195 (000100437102, 000000000000, 000A000003A0, 000800025178) native.exe+0x27195
0007FFFFCC40  000100424D60 (0001800455E0, 000000000000, 00000000013C, 000000000000) native.exe+0x24D60
0007FFFFCD30  000180047ED1 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x7ED1
000000000000  000180045AC3 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x5AC3
0007FFFFFFF0  000180045B74 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x5B74
End of stack trace
Loaded modules:
000100400000 native.exe
7FFA71010000 ntdll.dll
7FFA704B0000 KERNEL32.DLL
7FFA6DCD0000 KERNELBASE.dll
00052C480000 msys-python3.11.dll
000180040000 msys-2.0.dll
000430B30000 msys-intl-8.dll
0005E8160000 msys-gcc_s-seh-1.dll
0005603F0000 msys-iconv-2.dll
7FFA709F0000 advapi32.dll
7FFA70AA0000 msvcrt.dll
7FFA70670000 sechost.dll
7FFA70710000 RPCRT4.dll
7FFA6E660000 bcrypt.dll
7FFA6D570000 CRYPTBASE.DLL
7FFA6E100000 bcryptPrimitives.dll

Dump file from VScode :

Exception: STATUS_ACCESS_VIOLATION at rip=0001004246DC
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=00006FFFFFF7B060 rsi=0000000000000003 rdi=0000000000000002
r8 =000000052C6831A0 r9 =0000000000000000 r10=0000000800000000
r11=000000052C5E9E89 r12=00000007FFFFCC86 r13=0000000000000000
r14=0000000000000000 r15=00000007FFFFCC50
rbp=00000007FFFFCAF0 rsp=00000007FFFFCAF0
program=C:\msys64\home\NUCi7\ORTD2662\output_native\native.exe, pid 1045, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame         Function      Args
0007FFFFCAF0  0001004246DC (000100436C20, 000000000023, 000000000000, 000000000001) native.exe+0x246DC
0007FFFFCB50  0001004248CF (000100426F81, 00018023081E, 000A0000171F, 000000000001) native.exe+0x248CF
0007FFFFCB80  000100427195 (000100437102, 000000000000, 000A00000450, 000A000003A0) native.exe+0x27195
0007FFFFCC00  000100424D60 (0007FFFFCC50, 0007FFFFCD30, 000000000000, 000000000000) native.exe+0x24D60
0007FFFFCD30  000180047ED1 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x7ED1
000000000000  000180045AC3 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x5AC3
0007FFFFFFF0  000180045B74 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x5B74
End of stack trace
Loaded modules:
000100400000 native.exe
7FFA71010000 ntdll.dll
7FFA704B0000 KERNEL32.DLL
7FFA6DCD0000 KERNELBASE.dll
00052C480000 msys-python3.11.dll
000180040000 msys-2.0.dll
000430B30000 msys-intl-8.dll
0005E8160000 msys-gcc_s-seh-1.dll
0005603F0000 msys-iconv-2.dll
7FFA709F0000 advapi32.dll
7FFA70AA0000 msvcrt.dll
7FFA70670000 sechost.dll
7FFA70710000 RPCRT4.dll
7FFA6E660000 bcrypt.dll
7FFA6D570000 CRYPTBASE.DLL
7FFA6E100000 bcryptPrimitives.dll
7FFA66E90000 netapi32.dll
7FFA63AA0000 SAMCLI.DLL
7FFA6E240000 ucrtbase.dll
7FFA69F50000 SAMLIB.dll
7FFA6E000000 NETUTILS.DLL
7FFA6F0B0000 user32.dll
7FFA6E510000 win32u.dll
7FFA70DB0000 GDI32.dll
7FFA6E540000 gdi32full.dll
7FFA6E010000 msvcp_win.dll
7FFA70640000 IMM32.DLL

[KerJoe]

Can you run it in gdb (pacman -S gdb) or VSCode, to know what line it fails at?

[KerJoe]

I've just checked it appears to happen in XSFRReadByte when the ch341 is unplugged. git pull in the RTDMultiProg folder and check the output of RTDMultiProg/rtdmultiprog.py -i ch341 -l.

[coucouillu]

Can you run it in gdb (pacman -S gdb) or VSCode, to know what line it fails at?

Error in function "begin_i2c_native_iface" at line 63 ModuleNotFoundError: No module named 'interfaces' Error in function "XSFRWriteByte" at line 28 SystemError: null argument to internal routine

[...] x ten of time

Error in function "XSFRWriteByte" at line 28 SystemError: null argument to internal routine Error in function "XSFRWriteByte" at line 28 SystemError: null argument to internal routine Error in function "XSFRReadByte" at line 34 SystemError: null argument to internal routine Error in function "XSFRReadByte" at line 35 SystemError: null argument to internal routine 0 [main] native 1060 cygwin_exception::open_stackdumpfile: Dumping stack trace to native.exe.stackdump