2024年8月6日 星期二

ADB

Source Android Debug Bridge (adb)  |  Android Studio  |  Android Developers

  • A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.
  • A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.
  • A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.

2024年8月4日 星期日

Experience of STM32

STM32MP157A-DK1

ST-LINK v2

    VCOM

        Baud = 115200bps



2024年7月25日 星期四

USB Type-C and USB-PD

USB Type-C and USB Power Delivery (USB-PD) FAQs (infineon.com)

1. What is the difference between USB Power Delivery (USB PD) and USB Type-C?

 

USB-Power Delivery (USB PD) is a specification standard that supports power delivery up to 100 W while transmitting data over the same cable at same time. USB Type-C is a new reversible USB connector specification that can support a number of new standards including USB 3.1 (Gen 1 and Gen 2), Display Port, and USB PD. The USB Type-C ports, by default, can support the power of 5 V up to 3A. If the USB Type-C port is implemented with USB PD, it can support up to 100 W as defined in the USB PD specification. Therefore, having a USB Type-C port does not mean that it supports USB PD.

2. Is the USB Type-C connector mandatory for USB3.1 Gen1 or Gen2 specifications? Is USB Type-C identical to USB 3.0/3.1?

 

No. The USB Type-C specification is independent of the USB3.1 Gen1 or Gen2 specification. For now, we can have USB systems with Type-A or Type-B legacy connectors supporting Gen1 or Gen2 specification. The USB Type-C specification is a new connector specification defined by USB-IF, which supports reversible connection with power delivery up to 100W. Any USB 3.1 Gen1 or Gen2 products can be designed with a USB Type-C connector.

3. What do DFP, DRP, and UFP stand for?

 

Downstream Facing Port (DFP) is a USB Type-C port on a host or a hub to which devices are connected. Upstream Facing Port (UFP) is a USB Type-C port on a device or a hub that connects to a host or DFP of a hub. Dual Role Port (DRP) is a USB Type-C port that can operate as a DFP or UFP.

Note: DRP and USB-PD DRP differ from each other. USB-PD DRP refers to the port’s power role that can act as Power Source (Provider) and Sink (Consumer). For example, a laptop’s USB Type-C port supports USB-PD DRP that can act as a power source (when connected to a device such as a flash drive or mobile phone) and as a sink (when connected to a monitor or power adaptor).

4. What is the difference between Infineon’s USB-PD 2.0 and Qualcomm®’s Quick Charge™ (QC)?

 

USB-PD 2.0 is a USB-IF defined protocol, which provides a standardized mechanism for power delivery between USB devices at up to 100 W (20 V at 5 A) while simultaneously supporting both USB and non-USB data signals on the USB Type-C port. It enables the host and peripheral to dynamically negotiate power direction.

QC is a Qualcomm-defined proprietary charging protocol used for charging devices that support the Qualcomm Quick Charge protocol using a custom charger, which also supports the protocol. Quick Charge 2.0 delivers up to 60 W but, unlike USB-PD, does not support simultaneous power and data transfer or dynamic selection of the power direction during charging.

For more details on USB-PD 2.0, refer to the USB-PD 2.0 specification.

5. What is the maximum number of source power delivery objects (PDOs) supported by a Infineon USB-PD controller? What are the supported power profiles?

 

Infineon USB-PD implementation supports up to seven PDOs for source and sink applications.

There is no mandate by the USB-PD spec on what power profiles need to be supported by an application. The source and sink PDOs depend on design requirements. Section A.1 of the USB Type-C specification defines a standardized set of voltages with different current ranges. Note that the power profiles defined in Section A.1 are only recommended power profiles and are not mandatory. However, there should be at least one source PDO supporting 5 V.

6. Can you use a USB Type-C port for only USB and standard 5 V on VBUS?

 

Yes, you can use USB Type-C ports with USB-only capability and standard 5-V VBUS support.

For Host: The host Type-C port can provide 5 V with either 3 A or 1.5 A, default port current for USB 2.0 (500 mA) or USB 3.0 (900 mA). The USB Type-C host indicates its current capabilities by advertising an appropriate pull-up resistor, Rp, on both the CC lines - CC1 and CC2.

For Client / Device: The USB Type-C only devices need to advertise a pull-down resistor Rd of 5.1K on its CC line. If the device has a USB Type-C receptacle, it needs to advertise Rd on both CC1 and CC2 lines. However, for devices with Type-C plugs, the Rd is connected only to the CC line.

7. How do USB Type-C devices handle VBUS voltages other than 5 V?

 

If a device needs to sink any voltage other than 5 V, it should be capable of USB PD communication. The USB PD source sends its power profiles in the source capabilities to the device. The device requests for one of the advertised power profiles depending on its sink capabilities. After a contract is established, the host provides the requested voltage on VBUS.

8. What data can a Type-C cable carry?

 

The full-featured USB Type-C cable can carry USB2.0, USB3.1 Gen1, and USB3.1 Gen2 data in standard mode. When the port partners enter an alternate mode, the full-featured USB Type-C cable can carry the alternate mode data (such as Display Port and Thunderbolt) as well.

9. What is the maximum power a Type-C cable can deliver?

 

The power capability of the USB Type-C cable is defined in terms of its current carrying capability. The USB Type-C cable can carry maximum of 5A current and only EMCA cables can support more than 3A current.

10. Is it possible to design a Type-C cable that carries more power than that supported by Type-C and PD specifications?

 

Yes. But the design vendors must decide whether to qualify such non-standard designs. The USB Type-C connectors are designed to carry power up to 100 W (20 V, 5 A). Hence USB Type-C and USB-PD compliant cables can only carry power up to 100 W (20 V, 5 A). The power delivery of either more than 20 V or 5 A over the USB Type-C port is not defined by USB-IF and it is not recommended.

11. How many EZ-PD CCG2 USB Type-C controllers are required for a USB Type-C cable?

 

The USB Type-C passive cable assembly requires an E-marker IC at one end of the cable. The USB Type-C active cable designs that have different functions at each end of the cable require an E-marker IC at both ends of the cable. The downstream facing port (DFP) will query the cable to know the features supported at each end of the cable.

For more details, refer to AN95615 - Designing USB 3.1 Type-C Cables Using EZ-PD™ CCG2.


https://www.kamera.com.tw/blogs/power-z_area/98986

超詳細USB Type-C引腳信號及PCB佈局佈線介紹

 

當前智慧終端機市場形成了以 USB-C 介面為主,多種介面及充電技術並存的格局。使用者更換設備後,原有充電器、資料線大多閒置,造成巨大浪費。大力推進充電介面、技術融合,有利於降低電子垃圾,提高資源利用效率。”未來USB Type-C一統江湖勢不可擋。

Type-C科普

USB Type-C是USB連接器系統的規範,在智慧手機和移動設備上越來越受歡迎,並且能夠進行電力傳輸和資料傳輸。USB-C是一種相對較新的標準,目前的版本為USB4,USB4規範使用雙鏈路通道,傳輸頻寬最高達到40Gbps及高達240W的功率。這些功能可以使USB-C成為現代設備的真正通用連接標準。

USB Type-C主要功能介紹之信號圖示

USB Type-C連接器有24個引腳。圖1和圖2分別顯示了USB Type-C插座和插頭的插針。

USB Type-C的PCB設計佈線要求

USB Type-C的供電和備用模式

使用USB Type-C標準的設備可以通過介面協商並選擇合適的功率。這些功率協商是通過稱為USB Power Delivery的協定實現的,該協定是上面CC線上的單線通信。下面的圖顯示了一個示例USB供電,其中接收器向源發送請求並根據需要調整VBUS電壓。首先,要求提供9 V匯流排。在源穩定匯流排電壓為9 V後,它會向接收器發送“電源就緒”消息。然後,接收器請求一個5V匯流排,並且源提供它並再次發送“電源就緒”消息,值得注意的是,“USB供電”不僅僅涉及與供電相關的談判,其他談判,例如與備用模式相關的協商,都是使用標準CC線上的供電協議完成的。

USB Type-C的CC1和CC2針腳

這些引腳是通道配置引腳。它們執行許多功能,例如電纜連線和移除檢測、插座/插頭方向檢測和當前廣播。這些引腳也可用於Power Delivery和Alternate Mode所需的通信。下面的圖顯示了CC1和CC2引腳如何顯示插座/插頭方向。在此圖中,DFP代表下游面向埠,該埠充當資料傳輸中的主機或電源。UFP表示上游面向埠,它是連接到主機或電力消費者的設備。DFP通過Rp電阻上拉CC1和CC2引腳,但UFP通過Rd將它們拉低。如果沒有連接電纜,則源在CC1和CC2引腳處看到邏輯高電平。連接USB Type-C電纜可創建從5V電源到地的電流路徑。由於USB Type-C電纜內只有一根CC線,因此只形成一條電流路徑。例如,在圖中,DFP的CC1引腳連接到UFP的CC1引腳。因此,DFP CC1引腳的電壓低於5 V,但DFP CC2引腳仍處於邏輯高電平。因此,監控DFP CC1和CC2引腳上的電壓,我們可以確定電纜連線及其方向。

除電纜方向外,Rp-Rd路徑還用作傳遞源電流能力資訊的方式。為此,功耗(UFP)監視CC線上的電壓。當CC線上的電壓具有其最低值(約0.41 V)時,源可以分別為USB 2.0和USB 3.0提供500 mA和900 mA的默認USB電源。當CC線電壓約為0.92 V時,源可提供1.5 A的電流。最高CC線電壓約為1.68 V,對應於3A的源電流能力

USB Type-C的VCONN引腳

USB Type-C旨在提供超快的資料傳輸速度以及高水準的功率。這些特徵可能需要使用通過在內部使用晶片進行電子標記的特殊電纜。此外,一些有源電纜利用重新驅動晶片來加強信號並補償電纜等引起的損耗。在這些情況下,我們可以通過施加5 V、1 W電源為電纜內部的電路供電提供給VCONN引腳。有源線纜使用Ra電阻來下拉CC2引腳。Ra的值與Rd不同,因此DFP仍然可以通過檢查DFP CC1和CC2引腳上的電壓來確定電纜方向。確定電纜方向後,與“有源電纜IC”對應的通道配置引腳將連接到5 V,1 W電源,為電纜內部的電路供電。例如,在下圖中,有效的Rp-Rd路徑對應於CC1引腳。因此,CC2引腳連接到VCONN表示的電源。

 

USB Type-C的SBU1和SBU2針腳&RX和TX引腳

SBU1和SBU2針腳

這兩個引腳對應於僅在備用模式下使用的低速信號路徑。

RX和TX引腳

有兩組RX差分對和兩組TX差分對。

這兩個RX對中的一個以及TX對可用於USB 3.0 / USB 3.1協議。由於連接器是可翻轉的,因此需要多工器通過電纜正確地重新路由所採用的差分對上的資料。

請注意,USB Type-C埠可以支援USB 3.0 / 3.1標準,但USB Type-C的最小功能集不包括USB 3.0 / 3.1。在這種情況下,USB 3.0 / 3.1連接不使用RX / TX對,並且可以被其他USB Type-C功能使用,例如備用模式和USB供電協定。這些功能甚至可以利用所有可用的RX / TX差分對。

USB Type-C的電源和接地引腳

VBUS和GND引腳是電源和信號的返回路徑。預設的VBUS電壓為5V,但標準允許器件協商並選擇VBUS電壓而不是預設值。最新的PD3.1的協議,電源傳輸允許VBUS具有高達48V的電壓,目前USB4最大電流也可以升高到5A。因此,USB Type-C可以提供240W的最大功率。當為諸如筆記型電腦的大型設備充電時,大功率是有用的。

USB Type-C的USB 2.0差分對

D +和D-引腳是用於USB 2.0連接的差分對。插座中有兩個D +引腳和兩個D-引腳。但是,這些引腳相互連接,實際上只有一個USB 2.0資料差分對可供使用。冗餘設計只是為了提供可翻轉的連接器。

Type-C相關產業鏈備受關注

Type C介面具有小巧纖薄、高速傳輸、正反可用、一口多用、供電提升等許多優勢,它的普及將是指日可待的。然而,這種Type C連接器產品必須在有限的空間內發揮做出更加精細化功能繁多的產品,而且必須承受較高的電流並進行高速資料傳輸,因此它的技術難度要求非常高,挑戰與機遇並存。

2024年5月10日 星期五

[Handbook] ubus

/ # ubus call SIMAgent lst

{

        "tot": true,

        "cnt": true,

        [

                {

                        "cls": false,

                        "stt": false,

                        "cid": "98000000000000000021",

                        "spn": "Rohde & Schwarz",

                        "nam": "R&S CMW500 3G_XOR"

                }

        ],

        "res": 0

}

 

[Handbook] MingW

Building Windows DLLs with MinGW (transmissionzero.co.uk)


2024年5月2日 星期四

高內聚,低耦合 (high cohesion、low coupling)

Source 中鳥階段-高內聚,低耦合。 - iT 邦幫忙::一起幫忙解決難題,拯救 IT 人的一天

高內聚,低耦合 (high cohesion、low coupling) 的意思是,物件的程式碼應該要有很高的比率只和物件內其他有關的程式碼有關聯,而對外部的程式碼,物件或元件等的關聯度要愈低愈好 (最佳的狀態是零耦合)。這樣做的用意是讓物件可以獨立的發展,而無須依賴外部的任何程式碼,如此一來,物件本身可以在不影響其他程式的情況下自由的修改與變化,而外部程式的任何修改也不會影響到物件本身的功能與運作。

2024年4月29日 星期一

Linux grep handbook

Q. How to grep multiple patterns/keyworks?

A. grep -E 'pattern1|pattern2' file

2024年4月20日 星期六

192.168.1.0 subnet

Source: Understanding the Host Addresses in the 192.168.1.0 Subnet : Call +1-800-413-3531 | Medium

The 192.168.1.0 Subnet
The 192.168.1.0 subnet is part of a private IP address range defined by RFC 1918. It falls within the Class C IP address space, which is commonly used for smaller networks like home networks or small businesses. The subnet mask associated with this range is typically 255.255.255.0, which means the first three octets (192.168.1) represent the network address, and the fourth octet (0) is used for host addresses.
  1. Network Address (192.168.1.0): This address is used to identify the entire subnet. It cannot be assigned to any specific device on the network.
  2. Host Addresses (192.168.1.1 to 192.168.1.254): These are the IP addresses that can be assigned to individual devices within the subnet. Each device on the network must have a unique host address within this range.
  3. Broadcast Address (192.168.1.255): This address is used to broadcast messages to all devices within the subnet simultaneously. When a device sends data to the broadcast address, every device on the subnet receives it.

2024年4月1日 星期一

Cygwin vs MinGW vs Msys

Quote Cygwin、Msys、MinGW、Msys2的區別與聯繫_msys2和mingw-CSDN博客

區別:
  • Cygwin是類比 POSIX 系統,源碼移植 Linux 應用到 Windows 下
  • MinGW 是用於開發 Windows 應用的開發環境。
  • Msys
  • Msys2

聯繫:
  • 均提供了部分 Linux 下的應用,多跑在 Windows 上
  • MinGW 作為 Cygwin 下的軟體包,可以在 Cygwin 上運行

Cygwin,原 Cygnus 出品(已被紅帽收購),目前是 RedHat 名下的專案。 專案的目的是提供運行於 Windows 平臺的類 Unix 環境(以 GNU 工具為代表),為了達到這個目的,Cygwin 提供了一套抽象層 dll,用於將部分 Posix 調用轉換成 Windows 的 API 調用,實現相關功能。 這裡面最典型的,最基本的類比層就是那個 cygwin1.dll。 除此之外,隨著Linux系統的發展壯大,目前的 Cygwin 已經不僅僅提供POSIX相容,因此也順帶多了更多類比層的依賴關係。

Cygwin 的目錄結構基本照搬了 linux 的樣子,但同時,也相容了 Windows 的許多功能:大部分應用使用 Unix 風格的路徑,Windows的盤符通過類似掛載點的方式提供給 Cygwin 使用;Cygwin 中既可以運行 Cygwin 的應用(依賴模擬層),又可以運行 Windows 應用,而傳遞給應用的路徑會經過它的類比層變換,以此保證程式運行不會出錯。

由於它的類比層實現了相當良好的 Posix 相容,人們試著將許多重要的 Linux/BSD 應用移植到了Cygwin下,使得Cygwin越來越大,功能也越來越豐富,以至於目前很多人直接把將Linux應用移植到Windows平臺的任務都交給了Cygwin(當然,這種移植並非原生)。 事實上,Cygwin誕生之初,本就是想通過GCC編譯出Windows應用來,因為bootstrap GCC而順帶搞了一坨別的東西過來,最後發展到現在的。

小結:Cygwin是運行於Windows平臺的POSIX“子系統”,提供Windows下的類Unix環境,並提供將部分 Linux 應用“移植”到Windows平臺的開發環境的一套軟體。 按照我經常開玩笑的話來講,Cygwin 基本上就是傳說中的 GNU/NT 系統(對照 GNU/Linux,GNU/BSD,GNU/HURD)。



MinGW, Minimalist GNU for Windows,開發原生(32位) Windows 應用的開發環境。 它主要提供了針對 win32 應用的 GCC、GNU binutils 等工具,以及對等於 Windows SDK(的子集)的頭文件和用於 MinGW 版本 linker 的庫檔(so、a等,而不是 VC 的 lib)。

MinGW 能夠替代 cl 用於編譯不包含 MFC 的、以 WinSDK 為主的 Windows 應用,並且編譯出來的應用不依賴於第三方的模擬層支援,其運行時為大部分 Windows 標配的 msvcrt(故稱原生 Windows 應用)。 除此之外,MinGW 也支援 GCC 支援的其他語言。

因為這些原因,MinGW 被許多 Linux 上發展起來的開發工具選擇為 Windows 版本的預設編譯器,例如 CodeBlocks,例如 DevC++。

小結,MinGW 是用於進行 Windows 應用開發的 GNU 工具鏈(開發環境),它的編譯產物一般是原生 Windows 應用,雖然它本身不一定非要運行在 Windows 系統下(是的 MinGW 工具鏈也存在於 Linux、BSD 甚至 Cygwin 下)。



MSYS,由於 MinGW 本身僅代表工具鏈,而在 Windows 下,由於那個shi一樣的cmd,以及配套的命令行工具不夠齊全(也不舒服),因此,MinGW 開發者從曾經比較舊的 Cygwin 創建了一個分支,也用於提供類 Unix 環境。 但與 Cygwin 的大而全不同,MSYS 是衝著小巧玲瓏的目標去的,所以整套 MSYS 以及 MinGW,主要以基本的 Linux 工具為主,大小在 200M 左右,並且沒有多少擴展能力。

MSYS 是用於輔助 Windows 版 MinGW 進行命令行開發的配套軟體包,提供了部分 Unix 工具以使得 MinGW 的工具使用起來方便一些。 如果不喜歡龐大的 Cygwin,而且使用不多,可以試試。 不過喜歡完整體驗、不在乎磁碟佔用等等,還是推薦 Cygwin 而不是 MSYS。



MinGW-w64,前面提到的MinGW,是針對32位 Windows 應用開發的。 而且由於版本問題,不能很好的支援較新的 Windows API。 MinGW-W64 則是新一代的 MinGW,支援更多的 API,支援 64 位應用開發,甚至支援 32 位 host 編譯 64 位應用以及反過來的“交叉”編譯。 除此之外,它本身也有 32 位和 64 位不同版本,其它與 MinGW 相同。



MSYS2,由於 MinGW 萬年不更新,MSYS 更是,Cygwin的許多新功能 MSYS 沒有同步過來,於是 Alex 等人建立了新一代的 MSYS 專案。 仍然是 fork 了 Cygwin(較新版),但有個更優秀的包管理員 pacman,有活躍的開發者跟使用者組,有大量預編譯的軟體包(雖然肯定沒有Cygwin多)...... 對於不喜歡龐大的 Cygwin 的使用者而言,推薦試試 msys2。

Cygwin vs WSL

Cygwin : CYGnus WINdows
WSL : Windows Subsystem for Linux

Quote

Cygwin is a POSIX compatibility layer that runs on top of the Win32 subsystem. It has approximately nothing to do with Linux; it can broadly be treated as "just another Unix-like" where porting programs requires recompilation and possibly source modification, and anything that requires non-POSIX Linux-specific features probably won't work.

WSL 1 is designed to be ABI-compatible with Linux proper. It does not use the real Linux kernel, but is compatible such that programs compiled for Linux can run on it without recompilation or translation. WSL is part of the NT kernel, so exists independently of the Win32 subsystem. This is similar to the older SUA, though that was a POSIX (not Linux!) subsystem on top of the NT kernel.

WSL 2, runs a real Linux kernel on a lightweight VM. It promises similar Windows integration as WSL 1 but with a real Linux kernel (so kernel modules, filesystems, etc., should work). It also has proper GUI support (on Windows 10 Build 19044+ or Windows 11) but has reduced I/O performance when accessing Windows filesystems compared to WSL 1.