[SOLVED] VU7C drives me crazy

[zyssai]

Hi everyone!

I really need help, as I absolutely don't know what is this annoying problem



Sorry for my poor English, as you can see, after the Hardkernel logo (I replaced it with Android 13 logo), vu7c screen does not initialize properly.

I need to unplug N2+, and plug it again, to make it work.
Sometimes I need to do it 2 or 3 times.
Unplugging HDMI cable does nothing.

I hope this is not a temperature related issue as it is cold now where I live.

Is there something to do with uboot?

It drives me crazy, as this is the end of my GPIO'4'Cars project if it doesn't work.

Best regards.
Jc

[mad_ady]

What OS are you running? Hardkernel's Android or voodik's build?
Does the initialization problem happen when you boot a different OS? What about booting the os you have with the vu7 on the bench?

Let's try to isolate the problem and see if it's causes by hardware or software. Since it displays the splash screen, I'd say it's software...

[zyssai]

Thanks for your help I appreciate

I'm using latest LOS20 from voodik and I have not tried another OS as I have only one emmc (but I can backup if needed).

Unfortunately I cannot reproduce it on the bench, even with the exact same configuration.
Only differences are HDMI cable, length of the 40pin ribbon cable and USB devices attached.

I can add that my overlays are actually set to spi0 pwm_ef display_vu7c_no_dai keymatrix

[mctom]

Let me collect the symptoms in one place:
- The HK logo is always displayed correctly.
- After that, the image is distorted beyond use, however backlight seems to work fine.
- Reset resolves the problem, but sometimes more than one is needed - so it happens randomly regardless of the time of day,
- The problem occurs only when installed in the car

The difference between bench tests and target application are:
- Longer cables
- lower temperature
- Different power supply (less stable)

Unfortunately I don't know how exactly it all works, but here's my wild speculation: The display receives bad configuration data via I2C.

Longer ribbon cable could be the cause. I2C signals are very fragile to parasitic capacitance, and long ribbon is exactly a bunch of capacitors.
If the I2C communication is unreliable due to capacitance, the only way to solve it is to either use shorter cables, or slow down I2C.

I suspect that I2C config is sent twice to the display, before and after HK logo is shown, and it seems it doesn't do it the same way. What's the difference here? Perhaps the transmission speed.

If there was a way to control the speed of I2C, I'd make it really slow. I2C has no minimum speed in theory. Is this something that could be changed in overlays?
Display's chip datasheet says it supports I2C at 100kHz max, but I'd even try 50kHz or 20kHz if possible.

[zyssai]

Thanks mctom as always for your good advices.

It is possible that the problem comes from a too long ribbon cable. I cannot make it smaller in the car, but I can test a longer one at home, but I'm not sure I will face parasitic issues (does childrens count? )

Regarding I2C bus speed, that would be great if there was a way to reduce speed.
The HK logo (let's say the boot logo) is always displayed correctly, so there is a difference. Is it the speed? That's the question.

Another method would be to make a shield around the ribbon cable. But I'm not sure this will work.

Edit: I have found an interesting thread
viewtopic.php?p=67469#p67469

Don't know if it works the same with N2. I will check asap.

[mad_ady]

Another method would be to make a shield around the ribbon cable. But I'm not sure this will work.

Try wrapping your cable in tin foil. It should reduce outside em interference.

And - are you using petitboot? If yes, try without it, since it may force another round of initializations.

[zyssai]

Try wrapping your cable in tin foil. It should reduce outside em interference.

And - are you using petitboot? If yes, try without it, since it may force another round of initializations.

Thanks.
I only have aluminum foil, don't know if it can work.
I can add that during tests, engine is not started, and there is no ignition, so I'm surprised that there is so much parasitic.

I'm not using petitboot, OS is booting directly to emmc.

[mctom]

Nooooo

One thing at a time:

1. Parasitic capacitance occurs when two big conductors are close to each other. A capacitor is literally made from two sheets of metal close together, but not touching. Cables also have parasitic (unintended) capacitance, because they have long wires parallel to each other.
Adding another slab of metal won't help at all. It will make the capacitance even worse.

If it's connected to anything, which brings me to another point..

2. Electromagnetic interference
Shielding does work, but only when it's connected to ground.


If you're willing to take your system back home and test with long ribbon, that could answer some questions hopefully.
And the I2C should be slower than 400kHz, definitely!

[mad_ady]

Sorry for suggesting tin foil hats as a solution for everything

For just a few wires (i2c) it looks like twisted pairs in an ethernet cable (cat5 or cat6) may be a solution for lengths up to 5m. https://electronics.stackexchange.com/q ... tyle-cable
There are also ethernet cables that have metal shielding.

Not sure if it is worth it to use rj45 jacks and sockets or try to attach the wires with a punchdown tool (step 3.3 in here: https://www.wikihow.com/Install-an-Ethe ... -in-a-Wall). Note that off-the-shelf cables with rj45 jacks are wired according to r-568b code: https://www.google.com/search?q=t-568b+ ... Pz2ocXEp_M

[mctom]

Nooooooooo!
Twisting a pair of wires makes capacitance wooorse

Here's why I2C struggles with excessive capacitance.
Both I2C lines (data and clock) have pull up resistors. All devices connected to I2C can only pull voltage down, to 0V, counteracting on the resistor with a much smaller resistance.
So when any device on I2C bus pulls a wire low, every other device see 0V. If none pulls the wire low, then everybody see high voltage.

But! If there is also a capacitance, it has to be charged to change the voltage on a wire. And since the pull-up resistor is a resistor, it charges up slowly.

As a result, it can be observed that pulling down is always quick, but recovering back to 3.3V takes time (picture below, Data on top, Clock on bottom)
The higher capacitance, the slower response.
It may get so slow it won't even reach halfway up before it's pulled down again by the transmitter... That's where the errors come from.

So what do we do? Slow down the transmission, so the capacitive line has more time to charge up.
OR lower the pull-up resistance to charge the parasitic capascitance faster (ie. add another pair of pull-up resistors)
OR reduce parasitic capacitance.

========

The I2C repeaters / amplifiers are very complicated, because the data line is bidirectional. Some of those ideas in that stackexchange thread are plain awful..

[mad_ady]

I love being wrong! It means I'm learning something new!

So - let me get this straight - the parasitic capacitance is generated mostly by having parallel conductors and increases with the wire length? Or is it the impedance of a long transmission line (https://en.m.wikipedia.org/wiki/Telegra ... _equations)? I remember calculating such impedances in college, but I recalled being signifficant at high frequencies or high lengths...

Is it the same problem the old parallel IDE cable suffered from and that caused the old 40 wire ribbon cable to be replaced by an 80 wire ribbon cable (https://www.rigacci.org/docs/biblio/onl ... e80-c.html)?

Perhaps a similar cable might help and be easy to source/replace.

[mctom]

Forget transmission lines and characteristic impedance, that's a 100kHz signal, not PCI-e.

Capacitance exists between any two conductors, but it gets greater the closer they are to each other, and the bigger surface they share.
Actually the capacitance formula is exactly that: Area divided by distance. (Times dielectric constant of whatever is separating them).

So two wires parallel to each other have significant mutual capacitive coupling, because the distance is rather small, and the surface area, well, it adds up linearly with length. Extra resistance doesn't help either, but let's stick to a simple model.

The 80-wire PATA ribbon addressed a problem of cross talk, which somewhat is caused by capacitive coupling indeed. Cross talk means that changes of voltage on one wire can be seen on a neighboring wire too (because they're coupled).
The parasitic capacitors are not removed with extra 40 wires in 80-wire ribbon. If you think about it, au contraire! Now they are twice as close to each other, so capacitance is greater!
But the signal wires are not coupled with each other anymore, but with extra wires, connected to ground.

But anyway, it won't help @zyssai, because these cables are custom made, with extra 40 wires connected to a specific pin which is ground in PATA standard - I doubt it's the same pin as in N2+.
And this will not reduce parasitic capacitance at all!

Speaking of which, I just suggested parasitic capacitance as one of the possible causes, I wouldn't assume that's correct just yet.

[zyssai]

I'm sorry I firstly thought about electromagnetic interferences, my bad.

Problem with ribbon cable, it is also not easy to fit inside the car, and if I add shield or something else, this will end in a massacre

So, yes I can test at home with longer cable.
The cable inside the car ils around one meter, I will try with 3 or 4 meters.

Regarding 80pin ribbon cable, you're right, wiring is not compatible, I already faced it when I make my first attempt of N2 into the car while wiring gpio. The 40 added wires are connected to ground I presume, and so it will make shorts with other pins as N2 have not the same pinout as IDE/PATA pinout which these ribbon cables where designed to.

For sure I need to find how to reduce I2C speed.
I think there is something to do with dtbo file.

Thanks to you guys

[zyssai]

@mctom, you are talking about pull-up resistors, what If I add one resistor for each I2C pin? I presume some 10k, this way I will probably divide by half (don't know if wattage matter, if I use 1206).

[mad_ady]

I love it! I'm wrong on so many levels! Thank you for taking the time to educate me! I enjoy a good detective story.

[zyssai]

I love it! I'm wrong on so many levels! Thank you for taking the time to educate me! I enjoy a good detective story.

You're not alone
This guy is impressive

[zyssai]

So thanks to voodik's GitHub, I have found dts file of vu7c screen

https://github.com/voodik/android_kerne ... no_dai.dts

There is an interesting line clock-frequency = <100000>; in fragment@0, it seems to be related to HDMI chip
And a second one clock-frequency = <400000>; in fragment@3, seems related to touch screen. Touchscreen works perfectly in car, even if I faced some strange behaviors on my bench table tests some months ago.

I don't know when I will have time to manage with this.

Code: Select all

/*
 * arch/arm64/boot/dts/amlogic/overlays/odroidn2/display_vu7c.dts
 *
 * Copyright (C) 2022 Hardkernel, Inc. All rights reserved.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 */

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/meson-g12a-gpio.h>
#include <dt-bindings/gpio/gpio.h>

#include <dt-bindings/pwm/meson.h>
#include <dt-bindings/pwm/pwm.h>

/{
	fragment@0 {
		target = <&i2c1>;
		__overlay__ {
			status = "okay";
			pinctrl-names = "default";
			pinctrl-0 = <&i2c1_master_pins1>;
			clock-frequency = <100000>;	/* default 100k */

			lt8619c: hdmi-bridge@32 {
				compatible = "lt8619c";
				reg = <0x32>;
				reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_LOW>;
			};
		};
	};
	fragment@1 {
		target = <&pwm_ef>;
		__overlay__ {
			status = "okay";
			pinctrl-names = "pwm_pins";
			pinctrl-0 = <&pwm_e_pins>;
		};
	};
	fragment@2 {
		target-path = "/";
		__overlay__ {
			backlight: backlight {
				compatible = "pwm-backlight";
				pwms = <&pwm_ef MESON_PWM_0 40000 0>;
				brightness-levels = <
					  0   1   2   3   4   5   6   7
					  8   9  10  11  12  13  14  15
					 16  17  18  19  20  21  22  23
					 24  25  26  27  28  29  30  31
					 32  33  34  35  36  37  38  39
					 40  41  42  43  44  45  46  47
					 48  49  50  51  52  53  54  55
					 56  57  58  59  60  61  62  63
					 64  65  66  67  68  69  70  71
					 72  73  74  75  76  77  78  79
					 80  81  82  83  84  85  86  87
					 88  89  90  91  92  93  94  95
					 96  97  98  99 100 101 102 103
					104 105 106 107 108 109 110 111
					112 113 114 115 116 117 118 119
					120 121 122 123 124 125 126 127
					128 129 130 131 132 133 134 135
					136 137 138 139 140 141 142 143
					144 145 146 147 148 149 150 151
					152 153 154 155 156 157 158 159
					160 161 162 163 164 165 166 167
					168 169 170 171 172 173 174 175
					176 177 178 179 180 181 182 183
					184 185 186 187 188 189 190 191
					192 193 194 195 196 197 198 199
					200 201 202 203 204 205 206 207
					208 209 210 211 212 213 214 215
					216 217 218 219 220 221 222 223
					224 225 226 227 228 229 230 231
					232 233 234 235 236 237 238 239
					240 241 242 243 244 245 246 247
					248 249 250 251 252 253 254 255>;
				default-brightness-level = <200>;
			};
		};
	};
	fragment@3 {
		target = <&i2c3>;
		__overlay__ {
			status = "okay";
			pinctrl-names = "default";
			pinctrl-0 = <&i2c3_master_pins2>;
			pinctrl-1 = <&i2c3_to_gpioa>;
			clock-frequency = <400000>; /* default 400k */

			touch: gt9xx@14 {
				compatible = "goodix,gt911";
				status = "okay";
				reg = <0x14>;
				reset-gpios = <&gpio GPIOX_15 0x00>;
				irq-gpios = <&gpio GPIOX_14 0x00>;
			};
		};
	};
};

[mctom]

And I do enjoy the audience like both of you.

You're right on many levels, @zyssai.

If you prove that super long ribbon cable is the cause of the problems, that would indicate I2C link capacitance as a probable cause.
Three solutions I already mentioned are: Slow down, less capacitance, or less resistance.

Less capacitance is out of question because we can't shrink Laguna, but pull-up resistance can be reduced by adding extra resistors from SDA to 3V3, and SCL to 3V3 - anywhere on the link, could be on GPIO'4'Cars.
There is a limit though - if we reduce the pull-up resistance too much (below 1k or so?), we may draw too much current from N2 GPIO when it tries to pull it low, not to mention the display driver.
I don't know what is the "default" pull-up resistance on both ends - Vu7C and N2+, but adding the third one should not give a result below 1.7k ( about 2mA).
But let's worry about that when the experiment is positive.

Since you're asking about power dissipation of the resistors, 0603 resistors usually have 0.15W or 0.125W rating. Taking the lower one, and working voltage 3.3V, and one of the resistor power formulae: P = U * U / R...
We can work out ~88 Ohms. That is the minimum resistance, above which it will not break down. So 1k or 10k will be safe.

And giving that there is another, touch I2C link that works reliably even though it's clocked faster, well, that destroys my argument, isn't it.
Well, I'm not digging a trench, I may be completely wrong, but on the other hand I can see the reason why two I2C lines can have different capacitances, with I2C0 being more severely affected (it's surrounded by DC voltage pins exclusively).

[mctom]

The Vu7C HDMI receiver chip initialization code exists in the uboot.
It seems to be worth to lower the I2C bus clock speed to 100Khz from 400Khz if the I2C wire connections are too long in an electrically noisy environment.
https://github.com/hardkernel/u-boot/bl ... dn2.c#L238

[zyssai]

... so longgg quote ...

Thanks, that will be interesting to test with longer cable, I will try at end of the week.
If I can reproduce this bad behavior then I'll try to add resistors to see if there is improvement, this to confirm you're the boss

Thanks for all these explanations.

The Vu7C HDMI receiver chip initialization code exists in the uboot.
It seems to be worth to lower the I2C bus clock speed to 100Khz from 400Khz if the I2C wire connections are too long in an electrically noisy environment.
https://github.com/hardkernel/u-boot/bl ... dn2.c#L238

Thanks Odroid.
I know nothing about uboot, this is why I would try first with modified dts file of vu7c, if it's a good way to go.
According to this dts file, it seems 100kHz frequency is used by the HDMI chip, and another 400kHz frequency by the touch panel. But probably I'm wrong.

Anyway I will firstly try the above solution.

This reminds me to the first vu7c dead screen I own, the behavior is the same, as the difference that even directly plugged to N2 it does not work, like if the I2C bus is not responding. There is possibly some dead resistors (even if I don't understand how it is possible), I have checked it by the past, but I will do it again.

[zyssai]

So, I tried with a long ribbon cable, probably 2 to 3 meters.



It is not the same behavior. I have some strange stuff but it ends by working.

I tried to add 10k pull-up resistors to the 23 and 24 pins, according to the vu7c schematic. It seems there is already 4.7kOhm resistors.
Unfortunately there is no change, same behavior.

I will try to learn how to manage with uboot.

[mctom]

Well, at least it shows the long ribbon cable can distort the picture even though it doesn't transmit picture data (HDMI cable does), so it wasn't a completely pointless experiment.
It probably ends up working because OS sends the I2C configuration data again at that point, and it works this time. I guess?

Still, if you could slow down I2C transmission and improve performance of your home setup, that would give you a high chance of improving behavior in a car too.

I'm starting to think there might be a problem with a ground loop in your car setup, but no matter what the cause is, slowing down I2C may help. Or repeating the I2C setup sequence 5 times, if it was possible.

[zyssai]

Well, at least it shows the long ribbon cable can distort the picture even though it doesn't transmit picture data (HDMI cable does), so it wasn't a completely pointless experiment.
It probably ends up working because OS sends the I2C configuration data again at that point, and it works this time. I guess?

Still, if you could slow down I2C transmission and improve performance of your home setup, that would give you a high chance of improving behavior in a car too.

I'm starting to think there might be a problem with a ground loop in your car setup, but no matter what the cause is, slowing down I2C may help. Or repeating the I2C setup sequence 5 times, if it was possible.

Thanks mctom.

I don't really know where to search for a ground loop, as the screen is powered directly by N2, so they share the same ground, for HDMI and for ribbon cable.

I tried to manage with dts file, but unfortunately, trying 20, 50, and 400kHz doesn't change behavior.

My last attempt would be to manage with uboot, but I know nothing about it. Wiki is not really clear.

@Odroid, you shared a uboot link coming from Hardkernel Github, is it the same used with LOS20?

Thanks for all the help

Edit: So I managed to compile voodik's uboot with modified i2c speed.
Will test soon.

Edit2: unfortunately fastboot does not recognize device. Will try tomorrow to manage with petitboot but not sure it will work.

[zyssai]

So I hardly managed to upload uboot.
It wasn't detected by fastboot, so after scratching my head because I have no USB to emmc reader, I used petitboot to mount as USB device, and moved all my stuff to the garage where is my Linux server, then I was able to upload uboot with sd-fuse.

I modified this line of voodik's uboot, to .master_i2c_speed = AML_I2C_SPPED_100K,

The behavior is now the same as in the car, once the HK logo is properly displayed, screen comes like the car video I posted.

I really don't know where to search now and my wife will divorce soon if I continue to work on it day and night

[mctom]

It appears those are the valid speeds for I2C in N2:

https://github.com/voodik/u-boot/blob/9 ... i2c.h#L222

But for whatever reason you've made things worse by slowing it down?
I think whatever you did, broke the I2C in uboot altogether. But investigating that code I can't see why would that happen. Not that I understand all of it :/

I can't help you with software unfortunately.

But seeing the code that you changed, perhaps it would make sense to increase intervals mentioned a few lines above. Unfortunately I can't see any documentation about what they are, but would make sense to increase them by a factor of 4 if you slowed down the I2C speed four times?

Also, this line:

Code: Select all

		printf("lt8619c hdmi_to_lcd device not found.!\n");

Suggests such error should be displayed if LCD initialization via I2C fails - but where? In logs? On the display?

At least we can assume with high confidence that I2C is the problem.

[mad_ady]

Suggests such error should be displayed if LCD initialization via I2C fails - but where?

It should be displayed in serial console.
Adding printf's might help extract more information.
Can't help with the wife, though, but how about taking a 1 week break and taking her out?

[zyssai]

Thanks to you guys, you're absolutely right mctom, I done the same conclusions, the lines above I don't find any documentation about these. So don't really know how to manage with it.

The printf line interpellate me too, that can't be directly to the display, so probably into log, but don't know which one.
As you say mad_ady, certainly into serial console.

I also tried to lower pull-up resistors with 2.7k, no change.

No wife isn't a problem, but this takes me time for sure. And report the purchase of the project.

[zyssai]

So thanks to reddit I have found a GitHub file, it seems there is some details about the behavior of the wait acknowledge.

And I have found this interesting thing:



https://www.adafruit.com/product/4756

The description is really helpful to understand exactly what is the problem. But mctom already did this
This can possibly help me if I don't find how to resolve this.

Edit: and it is open source, wonderful
https://github.com/adafruit/Adafruit-LTC4311-PCB

[mctom]

Better go right to the source, the chip's datasheet.
https://www.analog.com/media/en/technic ... 4311fa.pdf

Nice one, didn't know it existed. I think the best description would be "active pull-up".
Like I said, one of the solutions could be adding a smaller pull-up resistance, but not too small for a variety of reasons. This chip pulls up with a very small resistance, but only when it's safe. Brilliant.

However this chip is not in stock on Mouser, but you certainly could add that module in parallel to your existing circuits, preferably close to the I2C slave.

Good job looking for a possible solution!

[zyssai]

This is already done



But, just for fun, because I have opened schematics of Adafruit (thanks to us). I followed like you did, with the datasheet.
This chip is available at Alie.
My god, SC-70 is f*ckin' small Hot air will be the only solution I think.

But for the moment I will keep testing with uboot. Probably some free time tomorrow.

[mctom]

I bought SC70 components once, thinking it was SOT23. It IS small! But didn't get a chance to solder it yet. I think it should be doable without hot air.
Recently I'm designing all my PCBs with SMD components on one side only, so I can also order stencil, and solder everything on a hot bed that I got for $10 or so.
Here's a short video in case you're not familiar with this method: https://www.youtube.com/watch?v=sOZ_Bry957k
I often order one stencil for a few projects to save money.

OR you can order an assembled PCB in JLC I think

But for the moment I will keep testing with uboot. Probably some free time tomorrow.

Would be nice to prove once and for all that this is a I2C performance problem.
If you had a scope you'd already know.. Unfortunately the Arduino based scope would be too slow.

[zyssai]

So while you are soldering, the PCB is kept at hot temperature?
Isn't too long for components?
Didn't know this stuff.

But I recently, I found this:
https://youtu.be/r0csHZveVvY

I I have been really surprised about it.
What a gain of time!
I can effectively order already mounted board but... I love to mount it myself

So I can find a used scope I think, but I have already spend some money on the project, would be nice to keep it calm now

[zyssai]

So, I not believe it myself....

But, it's finally working!!



I took time to play again with uboot, get back to 400k because it was the only one working at the best, 50 and 100k was worst, and modified this line, tried a lot of values, from 500 to 5000, and get the better results with 1000.

I tried to change the other 3 lines from 5 to 10, but get back to a non working initialization.

So, finally I'm done!! And the bonus is that it is working also with a short cable

[joerg]

Congratulations. I was too busy with my project to help here...

[mctom]

That value has been changed before in the code, so I noticed when I explored github history.. It probably has been lowered because it took too much time to boot when the display was not present (just guessing).
I'm super glad you made it work! Congratulations!

The chip that you added to the board design yesterday, I think it may stay, can be optionally mounted or left unpopulated if not needed.

So while you are soldering, the PCB is kept at hot temperature?
Isn't too long for components?
Didn't know this stuff.

But I recently, I found this:
https://youtu.be/r0csHZveVvY

I I have been really surprised about it.
What a gain of time!
I can effectively order already mounted board but... I love to mount it myself

Both techniques are essentually the same, the use of stencil and solder paste, just like machines mount all mass produced electronics.
The only difference is how to heat it up to. Factories use ovens that bake the whole board for a specified time (less than 1 minute).
I use a small heat plate, 7x12cm, that I bought for some $10. I unplug it from mains when the solder melts, because it has no temperature control.
But as that youtuber shows, you can also pay so much more for extra layers in PCB and make it self-heating. (That project is a joke, please don't do that).

You're asking about the component stress - all components are specified exactly what soldering conditions they can survive. Almost all components can survive oven for 30-60s for mass production. So why not a heat plate for a similar time.

About the oscilloscope, keep an eye out for second hand Rigol DS1054Z, a model vastly popular among hobbyists, the price is low for its capabilities. It has many functions that can be unlocked with a "riglol" hack tool.
That of course, if and when you've got a budget for a new tool. As you can see it's not mandatory but surely helps a lot in many situations.

[zyssai]

That value has been changed before in the code, so I noticed when I explored github history.. It probably has been lowered because it took too much time to boot when the display was not present (just guessing).
I'm super glad you made it work! Congratulations!

Thanks!
This value seems to be clock times and not microseconds as I thought. It is possible that this value has been decreased due to too much boot time. I'm not sure, I need to compare videos, but it is possible that since I have modified it, the boot time is longer, I will check.

The chip that you added to the board design yesterday, I think it may stay, can be optionally mounted or left unpopulated if not needed.

I thought about the same, and already added footprints to the PCB. This way, if the board is intended to be used for other OS's, it will be functional. I will order soon PCB (as I know everything is working now) with some 4311 chips, to test it, and let you know.
For information, I measured my ribbon cable and it is 3 meters (around 10ft) long.

Both techniques are essentually the same, the use of stencil and solder paste, just like machines mount all mass produced electronics.
The only difference is how to heat it up to. Factories use ovens that bake the whole board for a specified time (less than 1 minute).
I use a small heat plate, 7x12cm, that I bought for some $10. I unplug it from mains when the solder melts, because it has no temperature control.
But as that youtuber shows, you can also pay so much more for extra layers in PCB and make it self-heating. (That project is a joke, please don't do that).

You're asking about the component stress - all components are specified exactly what soldering conditions they can survive. Almost all components can survive oven for 30-60s for mass production. So why not a heat plate for a similar time.

I will keep traditional soldering, probably mixed with hot air, but I just found this interesting to share, as I didn't know it. But, for sure, it is more expensive, just to save time.

About the oscilloscope, keep an eye out for second hand Rigol DS1054Z, a model vastly popular among hobbyists, the price is low for its capabilities. It has many functions that can be unlocked with a "riglol" hack tool.
That of course, if and when you've got a budget for a new tool. As you can see it's not mandatory but surely helps a lot in many situations.

Only one in France second hand, but it seems to be a great tool for the price
Good to know, I will keep an eye on it.

Thanks again to all of you for the help here, I can now focus on the PCB itself and have fun with it