Same with me. I didn’t feel the need to choose or confirm something every boot on day to day use. If I need to boot somewhere else, then I could always go to the BIOS/UEFI

“Cut two slices of bread” not that you have to slice it twice. It means by the end of the cutting process you should have two of it

Yes, that is called a pacman hook. As you expect, it is easy enough to add. You’re welcome to discuss your pull request to the arch maintainer.

Because it adds something that is not essential, so it is not “simple”. If package A depends on package B with an incompatible license then it needs to provide a means to specify alternate packages. Arch follows upstream with best effort possible, so changing dependency could be seen as breaking that. However, pacman already supports choosing alternate packages during installation so technically they could add it, but how many percentage of users are needing that convenience? Not to mention the arch team will need to maintain said list of alternatives for every dependencies. If you want, you can add it yourself via pacman hook to prevent you from accidentally installing non free software, or write a wrapper for pacman, or use other distro like Parabola.

Well, because Arch tries to be simple and pragmatic. The way the official repo is organized speaks volumes about its philosophy. Just read their FAQs

My bad, not FAQs, but their explanation page

Phone processors do post processing when taking a picture, even with the “no filter” selection. So yeah, it is understandable sometimes people can mistake a picture as “AI” since the artifact from said processing can become apparent

Poor Evil Neuro

Never seen yt before. That would be confusing af since both are noun

The cat is more famous than the monk lol

Where does it normally plug into? If it plugs into some sort of computing device, then yeah, one of them MAY be signal (probably LIN). If it could function with a simple switch however, then as the other said, try every combination possible.

Read about multiplexing. There are various ways to achieve it, the easiest way is to just arrange it on a grid. Let’s say 5×5. So with 10 pins, you can address 25 doors. For the lock, the easiest would be a solenoid / magnetic lock. You can also use a motor, but that would require a more complex addressing to reverse the rotation for opening and closing

Edit for more clarity about the simple method: Think of every door as a solenoid connected to GND. You only need VCC to open it. You can use relay module to switch the row and column to connect the VCC of the solenoid. But you need to wire every solenoid in “AND” switch configuration so it only turns on if and only if both row and column switch are closed

Arch does not have official FOSS only repo. And IIRC, that is by design

If your lithium battery has BMS, it should be fine since a lot of BMS will have a lot of protection including over current. If your raw dog the cell, then as the other said, any voltage and current into the battery should be capped. Ideally, you should monitor each cell as well to prevent an over voltage of any of the cells in the pack. If you want to be safe without monitoring every cell, then just make sure nothing gets back into the battery. Nothing goes in = can’t get overcharged by accident from back emf.

There is a lot to unpack here. But my suggestion is “cheap” esp32 devboard. At least where I live, going with older / raw MCU (not a “devboard”) will ended up more expensive. I’ll give an example. The STM32F103C8T6 “Blue Pill” cost the same as ESP32 DOIT Devkit (around USD 3). BUT the bare MCU of both cost around 1-5 cent more due to the economy of scale. So unless you plan to design a custom board in bulk/size constraint, buying the devkit and making a daughter board can ended up cheaper

I did not know nyarch is a thing. Nice

Why does it sounds like pop manga title

What’s the occasion kind internet stranger?

Yeah, CTS and RTS is useful for the module since you may overflow the module buffer (instead of the module overflowing your UART buffer). With proper HW flow control, hopefully your device UART respects the signal and pauses the tx until it is clear again without you having to code the pause yourselves. It can happen when the GSM bandwidth is lower than the UART bandwidth.

The module suddenly talking should also be handled by your device UART gracefully. When your rx buffer is full for whatever reason (not reading it for a long time?), the module won’t be sending anymore data until you read your rx buffer. Theoretically, no data should be lost that way.

Since the posts are about SIM7600, and the example shows, it’s probably AT Command. So always newline delimited (either \r or \r\n)

I assume you mean RXD to TX0. As for sporadic packets like that, I’d honestly check for the signal integrity. Maybe somehow the data line is picking up noise high enough to cause disturbance. It could be caused by a lot of things, but the most likely culprit are the connector/cable. Any connection going into/out of pcb should be checked. Or check your timing. Make sure the baud and other config (start, data, stop, parity) are matched. Small drift in baudrate is usually tolerable. UART is designed for async communication after all, meaning that any device may send anytime so CTS and RTS isn’t usually needed provided that it is a hardware UART (not bit banging). You can check out Ben Eater video about it. In short, the TX is usually held high, the RX then can detect a falling edge which is a signal that a packet is starting. The UART hardware then processes the signal according to the config that you give it and is usually able to do a DMA transfer.

Edit: Ahh, after reading the code I suspect that your code processes the data faster than the module can send the full reply. The first loop that you are waiting for the first data to arrive, you immediately process everything in the buffer until it is empty, not knowing that maybe the module has not yet finished transmitting. CTS and RTS would not help since they are used to signal if both devices would like to (or probably could) send / receive data. Not signalling end of data transfer

Edit 2, the solution: Either parse the received packet until the expected end, or wait until timeout before returning.