touchscreen@14 {
compatible = "goodix,gt911";
reg = < 0x14 >;
interrupt-parent = < 0x0c >;
interrupts = < 0x04 0x0a 0x02 >;
pinctrl-names = "default";
irq-gpios = < 0x0c 0x04 0x0a 0x00 >;
reset-gpios = < 0x0c 0x04 0x09 0x00 >;
status = "disabled";
};
Oh, and you'll enter the dangerous infinite loop of "Plz do this for me" and "Your FW is crap, why doesn't do what a $2000 DSO can?"
Here's the F1C200s pinout asignment:QuotePIN GPIO NAME FUNCTION CONNECTED TO
6 GPIO96 PD0 TWI0_SDA(I2C) U9 5, LemonTree 118
7 GPIO97 PD1 LCD_D3 LCD
8 GPIO98 PD2 LCD_D4 LCD
9 GPIO99 PD3 LCD_D5 LCD
10 GPIO100 PD4 LCD_D6 LCD
11 GPIO101 PD5 LCD_D7 LCD
12 GPIO102 PD6 LCD_D10 LCD
13 GPIO103 PD7 LCD_D11 LCD
14 GPIO104 PD8 LCD_D12 LCD
15 GPIO105 PD9 LCD_D13 LCD
16 GPIO106 PD10 LCD_D14 LCD
17 GPIO107 PD11 LCD_D15 LCD
18 GPIO108 PD12 TWI0_SCK(I2C) U9 6, LemonTree 117
19 GPIO109 PD13 LCD_D19 LCD
21 GPIO110 PD14 LCD_D20 LCD
23 GPIO111 PD15 LCD_D21 LCD
24 GPIO112 PD16 LCD_D22 LCD
25 GPIO113 PD17 LCD_D23 LCD
26 GPIO114 PD18 LCD_CLK LCD
27 GPIO115 PD19 LCD_DE LCD
28 GPIO116 PD20 LCD_HSYNC LCD
29 GPIO117 PD21 LCD_VSYNC LCD
37 GPIO140 PE12 PWM0 LCD BACKLIGHT
38 GPIO139 PE11 Input R196, V USB detect from computer
39 GPIO138 PE10 SPI_MISO LemonTree 87
40 GPIO137 PE9 SPI1_CLK LemonTree 15
41 GPIO136 PE8 SPI1_MOSI LemonTree 90
42 GPIO135 PE7 Output LemonTree 88
43 GPIO134 PE6 Input Buzzer signal from LemonTree 21, R19
44 GPIO133 PE5 Output LemonTree 20, R101
45 GPIO132 PE4 EINTE4 LemonTree 22, R278
48 GPIO129 PE1 UART0_TX UART0
49 GPIO128 PE0 UART0_RX UART0
59 GPIO64 PC0 SPI0_CLK SPI NAND FLASH U2
60 GPIO65 PC1 SPI0_CS SPI NAND FLASH U2
61 GPIO66 PC2 SPI0_MISO SPI NAND FLASH U2
62 GPIO67 PC3 SPI0_MOSI SPI NAND FLASH U2
63 GPIO3 PA3 UART1_TX UART1
64 GPIO1 PA2 UART1_RX UART1
65 GPIO1 PA1 TP_X2 ?_?
66 GPIO0 PA0 Output V OTG enable
GPIOC
PC0 SPI0_CLK SDC1_CLK
PC1 SPI0_CS SDC1_CMD
PC2 SPI0_MISO SDC1_D0
GPIOD
PD18 LCD_CLK SPI0_CS EINTD18
PD19 LCD_DE SPI0_MOSI EINTD19
PD20 LCD_HSYNC SPI0_CLK EINTD20
PD21 LCD_VSYNC SPI0_MISO EINTD21
GPIOF
PF0 SDC0_D1 DBG_MS
PF1 SDC0_D0 DBG_DI
PF2 SDC0_CLK UART0_RX
PF3 SDC0_CMD DBG_DO
PF4 SDC0_D3 UART0_TX
PF5 SDC0_D2 DBG_CK
# devmem 0x01C208B4 32
0x00373733
RESV DGB_CK RESV DIS RESV DGB_DO RESV DIS RESV DBG_DI RESV DBG_MS
000000000 011 0 111 0 011 0 111 0 011 0 011
# devmem 0x01C208B4 32 0x222222
28 GPIO116 PD20 LCD_HSYNC LCD
29 GPIO117 PD21 LCD_VSYNC LCD
...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)
Why I don't know, but it means they can only clock this shift register when the TR signal is high
...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)
Why I don't know, but it means they can only clock this shift register when the TR signal is highCould this be some kind of 50-60 Hz PWM for the LEDs in the display board?
Talking about battery power conversions, I remember somebody posted on one of the other threads that, in the absence of the 50-60 Hz signal from the power supply, the scope wasn't working correctly. Maybe it's related to this strange use of the signal. But I also remember that I experimented with disconnecting the TR from the power supply to the main board and didn't notice any misfunctioning...
P.S: Here is the post where crysti reported the problem and here is the post where I said I did that experiment. The previous post includes a simplified power supply schematic
The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to.
The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to.Don't have a clue - could it possibly be the 20MHz bandwidth limit?
devmem 0x01C20874 32 0x00772222
LCD kept working normally, so you can keep going.devmem 0x01C20874 32 0x00227222
Then LCD_CLK :devmem 0x01C20874 32 0x00222722
...The fact that the scope hangs when a USB to serial interface is connected, probably has to do with the boot loader. I have seen this happen on a Lichee nano too, when I was playing around with linux on a F1C100s. Not sure why this happens. Was in the time I was starting with the reverse engineering of the FNIRSI-1013D. Did not investigate it further since the FNIRSI scope does not use linux.
But good to know this, because I was thinking of integrating a CH340 USB to serial module in the scope, but if it would need to be connected to a PC to allow the scope to start is not what one wants
Also check there's a tiny via just over R32, in the trace going to the CPU.
It must be going somewhere else, your schematic seems to be lacking this.
I checked that back in the day, but can't remember, perhabs it also goes to the fpga reset pin (RECONFIG)?
I've also verified that if you connect it to the PC with the scope "hanged", the dialog that appears is the same that when you hit a key at the beginning of the boot procedure to stop it (see attached images, first one connecting USB after powering the scope and the second one keeping a key pressed during boot) so yes, it's the boot procedure that stops when USB is not connected (apparently this is equivalent to hit a key...).
Also check there's a tiny via just over R32, in the trace going to the CPU.
It must be going somewhere else, your schematic seems to be lacking this.
I checked that back in the day, but can't remember, perhabs it also goes to the fpga reset pin (RECONFIG)?
It might well be that I missed that. I will see if I can trace it on the photos I have of the PCB. Not going to open up the scope though if it is not doable from the photos
Is it me, or the AWG output protection diode D5 placement was a VERY bad idea?
External peaks will go right away into the +-5V analog voltage without any limitation, potentially killing a lot of stuff.
The diode and/or traces/pcb will burn in no time, and if the diode opens the voltage will reach the amplifier anyways.
Such stupid design. Should be placed at the pin 6 of the amplifier, so R9, R11, R143 limit the current, yet protecting the amp.
In the worst case, the damage will be just a burnt resistor.
Am I looking at a modified schematic? What you think it should be? If so, I agree.
Am I looking at a modified schematic? What you think it should be? If so, I agree.
Yep that is a modified schematic. The original is here: https://github.com/pecostm32/Hantek_DSO2000/blob/main/Schematics/Mainboard/Waveform%20Generator.png
External: External trigger input, it is on the front panel of the oscilloscope. The external trigger signal must be a 0-3.3V [CMOS] waveform.
but 50 ohms is not going to make much diference really
destroying your frontend
The TR signal in power supply adapter is the synchronization with the AC network. I would like to power scope from a LiPo battery. Is it necessary ?