| Electronics > Projects, Designs, and Technical Stuff |
| Please recommend a VGA to parallel LCD board or IC |
| << < (77/78) > >> |
| Tantratron:
--- Quote from: avst on December 27, 2024, 02:25:46 pm --- --- Quote from: Tantratron on December 27, 2024, 12:08:35 pm ---It is clear that I need to put much more effort and focus to learn porch, APLL and DPPL modification programming --- End quote --- The steps these firmwares take are more or less: * Detect the signal (activity on sync signals) * Measure availabe data: Vtotal, Hor. frequency, Ver. frequency, sync polarity and sync width * Lookup or calculate missing values, Htotal, Hstart and Vstart. Mostly done with a large lookup table. If there is not perfect match, take something similar * With the Htotal value, the sampling clock can be determined to setup the source pll. * From the values obtained, the input capture area (position and size) can be setup * With the horizontal and vertical active, the scaling can be calculated * From the scaling the pixel clock for the output can be calculated to setup the output pll * Now the output interface can be setup and the LCD enabled. Note that the output timing varies depending on the input timing, and there are cases, where the output timing would be outside the LCD specs. * Most often, the table or calculated values will not be perfect, so some fine tuning has to be done (HTotal, sampling phase and position).This is the auto adjust most firmwares offer. These differ from chip to chip, but all are image dependent, which is not 100% bulletproof. E.g. horizontal/vertical position may be deduced from the first non black pixel. * Sometimes the ADC range can be auto adjusted, provided a suitable image is displayed. * After everything is finished, the firmware monitors the input timing, to start the whole cycle again, if a significant change occurs --- End quote --- I've been following these different steps but for a few days, i'm stuck near going nuts regarding the first step detect the signal. As i've posted back, I thought to have easily found the instruction to identify if there is signal, what type of signal by reading the specific register/scaler 0x4C (see page 46 of the RTD2660) datasheet. When the RTD board boots, no problem it will either work with RGBS 1264x525 15 KHz or VGA 1024x768 48 KHz or VGA 800x480 31 KHz so I enter into ISP mode via arduino I2C command, still no problem where I can read register 0x4C to extract the 3 bits (6:4) after checking bit 7 states Type Detection auto Run ready. The problem which i'm bumping my head, if I do stay in ISP mode (8051 is halted) then if I do change live the signal input type (i.e. VGA becomes RGBS or vice-versa) or no signal then the register 0x4C is never updated. It will keep the last former values found when 8051 did boot prior being halted by ISP mode. I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe danyaPostfactum and specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst. The positive side of things, my reading many source files from these 3 repo kind of help me now clearly understand some concept, the key steps like once you capture some input frame info then you look for a database table to match close the values then find typical missing value. Of course my problem wether with the Advantest or the tektronix, bad luck where the resolution is not so standard but that is OK. |
| avst:
--- Quote from: Tantratron on December 30, 2024, 05:15:26 pm ---The positive side of things, my reading many source files from these 3 repo kind of help me now clearly understand some concept, the key steps like once you capture some input frame info then you look for a database table to match close the values then find typical missing value. Of course my problem wether with the Advantest or the tektronix, bad luck where the resolution is not so standard but that is OK. --- End quote --- Maybe you could patch the mode into the modetable (modetable.h) in flash, the mode is prersent in YPbPr.h, but probably that is not enabled in your firmware. The values in that table are not used, if YPbPr is not enabled. In YPbBr.h: --- Code: --- { // Mode 1 : 720 x 480i x 60 Hz 0 | _SYNC_HN_VN | _SYNC_HP_VN | _SYNC_HN_VP | _SYNC_HP_VP, // Polarity Flags, 704-20, 224+8, // InputWidth, InputHeight, 157, 600, // HFreq in kHz, VFreq in Hz, _HFREQ_TOLERANCE, _VFREQ_TOLERANCE, // HFreqTolerance in kHz, VFreqTolerance in Hz, 858, 262, // HTotal, VTotal, 129+20, 22,//27, // HStartPos, VStartPos, }, --- End code --- Locating the table in the binary and patching the values shouldn't be to difficult. But you should not used the first few modes, because these get a special treatment in the firmware, as there are multiple valid resolutions for the same measurements (old legacy stuff). Maybe use the _MODE_640x480_66HZ entry, as this is another not very common resolution. --- Code: ---enum PresetModeDef { _MODE_640x350_70HZ = 0, // Mode 00: 640x350_70Hz, 720x350_70Hz _MODE_640x400_56HZ, // Mode 01: 640x400_56Hz _MODE_640x400_70HZ, // Mode 02: 640x400_70Hz, 720x400_70Hz _MODE_720x400_70HZ, // Mode 03: 640x400_70Hz, 720x400_70Hz _MODE_640x400_701HZ, // Mode 04: 640x400_70.1Hz _MODE_640x480_60HZ, // Mode 05: _MODE_640x480_66HZ, // Mode 06: .... --- End code --- |
| avst:
--- Quote from: Tantratron on December 30, 2024, 05:15:26 pm ---I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe danyaPostfactum and specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst. --- End quote --- The firmware seems to do following steps (sync.c): * Start a stable measurement by setting bit 0 of reg 0x4F and wait 5ms * Check if hsync is present by looking at hsync counter overflow, reg 0x4E, bit 7 * if no overflow, wait another 60ms, then check if signals are stable in reg 0x4F, bit 7 * if stable, reads the hsync counter, and programs it into reg 0x4C and 0x4D (some special cases are used here) * Stops a stable measurement by resetting bit 0 of reg 0x4F * Starts the auto measurement by resetting, and then setting bit 6 of reg 0x47 |
| Tantratron:
First of all, I wish everybody a Happy New year 2025. Hello @avst thanks for your last 2 posts, in particular the 2nd one which helps me to clarify and understand the sequence of calling, polling to say self-detect signal presence then detects what type of VGA signal. I'll try later to code your findings and suggestions in my arduino sketch then will share the outcome. One serious difficulty is how to absorb, understand the different source files. Some are the Realtek leaked files which seems very heavy, lot of cases, lot of lines and not so much comments inline. Then some person mainly from Russia on GitHub have tried to reverse engineer or understand or simplify the leaked source file to go after some autonomous source file. However many times, they offer even less comments or will cover only special case of signal (i.e. HDMI). I believe you have mainly read the alien files section of KerJoe which seems close from Realtek leaked files. As for mapping or patching some modes into my OpenRTD2662 running firmware, maybe it could solve the other issue of the RGBs deinterlacing firmware to hopefully solve the image cropping and less clear the more we go to the right of the LCD (i.e. vertical grid lines ddisappearing progressively). If only more projects were known to address specifically the 15 KHz deinterlacing or YPbPr modes versus more project doing VGA input or HDMI input. Albert |
| Tantratron:
--- Quote from: avst on January 01, 2025, 03:42:17 pm --- --- Quote from: Tantratron on December 30, 2024, 05:15:26 pm ---I initially thought that register 0x4C is kind of always detecting HSYNC input type (co-processor or scaler slave) but unless I miss some additional programming, I was wrong. Before asking help here, maybe @KerJoe knows the answer, I've read different github repo (KerJoe danyaPostfactum and specadmin). It seems more complex than what I thought, do you know a simple sequence of commands to update and detect type of input signal, what is necessary to do prior accessing valid detection from register 0x4C. Something similar to RestoreVGA() subroutine provided by KerJoe a while ago except here is to say restart steps described by avst. --- End quote --- The firmware seems to do following steps (sync.c): * Start a stable measurement by setting bit 0 of reg 0x4F and wait 5ms * Check if hsync is present by looking at hsync counter overflow, reg 0x4E, bit 7 * if no overflow, wait another 60ms, then check if signals are stable in reg 0x4F, bit 7 * if stable, reads the hsync counter, and programs it into reg 0x4C and 0x4D (some special cases are used here) * Stops a stable measurement by resetting bit 0 of reg 0x4F * Starts the auto measurement by resetting, and then setting bit 6 of reg 0x47 --- End quote --- Ok it works now, many thanks again, see my source code extract (needs to be written more clearly and pro...) but works --- Code: ---int8_t AutoDetectInput(void) { uint8_t timeout_i, timeout=90; // Reset auto sync detection ScalerWriteBit(0x4F, 0, 0b0); ScalerWriteBit(0x4F, 0, 0b1); delay(5); // wait 5 ms //check if Hsync is present looking at hsync counter overflow if(ScalerReadBit(0x4E,7)) { Serial.println("No Input"); return(-1); } else { delay(60); // wait another 60 ms if(ScalerReadBit(0x4F,7)==0) { Serial.println("No stable measurement"); return(-2); } Serial.println("Signal present"); ScalerWriteBit(0x4F, 1, 0b1); // pop up stable value } Serial.print("Stable Hysnc period => ");Serial.println(((ScalerReadByte(0x50) & 0x7) << 8) + ScalerReadByte(0x51),DEC); ScalerWriteByte(0x4C, (ScalerReadByte(0x4C) & 0xF8) | (ScalerReadByte(0x50) & 0x07)); ScalerWriteByte(0x4D,ScalerReadByte(0x51)); ScalerWriteBit(0x4F, 0, 0b0); // stop stable measure ScalerWriteBit(0x47, 6, 0b0); ScalerWriteBit(0x47, 6, 0b1); // enable hysnc type detection auto run // Polling bit 7 of 0x4C for (timeout_i = 0; (timeout_i <= timeout) && (ScalerReadBit(0x4C, 7) == 0); timeout_i++) if (timeout != timeout_i) delay(1); // wait 1 ms else { Serial.println("Time-out hysnc type detection"); return -3; } Serial.print("HSync type detection ready => ");Serial.println(ScalerReadBit(0x4C,7),BIN); Serial.print("HSync type detection auto run => ");Serial.println((ScalerReadByte(0x4C) & 0x70) >> 4,BIN); return(0); } --- End code --- Now some Serial monitor testing data log where the RTD2660H board will either have NO INPUT or VGA input or RGBS input disconnected live (code 110 is for VGA and code 101 is for RGBS with XOR hsync-vsync) --- Code: ---ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 558 HSync type detection ready => 1 HSync type detection auto run => 110 ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 559 HSync type detection ready => 1 HSync type detection auto run => 110 ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 559 HSync type detection ready => 1 HSync type detection auto run => 110 ISP mode entered - DW8051 reset No Input ISP mode entered - DW8051 reset No Input ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 1705 HSync type detection ready => 1 HSync type detection auto run => 101 ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 1705 HSync type detection ready => 1 HSync type detection auto run => 101 ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 1705 HSync type detection ready => 1 HSync type detection auto run => 101 ISP mode entered - DW8051 reset No Input ISP mode entered - DW8051 reset No Input ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 559 HSync type detection ready => 1 HSync type detection auto run => 110 ISP mode entered - DW8051 reset Signal present Stable Hysnc period => 558 HSync type detection ready => 1 HSync type detection auto run => 110 --- End code --- |
| Navigation |
| Message Index |
| Next page |
| Previous page |