200933486 九、發明說明： 【發明所屬之技術領域】 本發明有關於通用串列匯流排（universal serial bus， USB)介面，尤有關於一種具USB介面之人性化介面裝置 (human interface device，HID )的勃體（firmware)更新方 . 法。 【先前技術】 傳統上’電腦主機（h〇st)若要對一 USB HID進行韌 ® 體更新有二種實施方式：第-種方式是，必須先將作業系 統（operating system)所提供的標準驅動程式卸載 (uninstall )，作業系統再掃描該欲更新韌體之USB HID， 以執行一次匯流排列舉（enumerati〇n );接著，安裝一個 燒錄用之驅動程式，最後，透過該燒錄用驅動程式對該 USB HID進行所有燒錄動作。利用此種方式的好處是，該 燒錄用驅動程式可以完全掌控該USB HID，並藉由控制型 傳輸（control transfer)、中斷型傳輸（interrupttransfer) © 或巨ϊ型傳輸（bulk transfer)來傳遞燒錄之讀寫指令。 二而在部分實作與應用上，該燒錄用驅動程式與個人電 - 知（或作業系統）間會有相容性的問題產生。 第二種方式主要是利用作業系統所提供的標準USB HID驅動程式來進行燒錄動作，此種方式雖然可避免相容 性的問題，但如果該連接的USB HID是滑鼠或鍵盤的話， 則用來控制該USB HID的控制處置器（contr〇1 handler)會 被某些作業系統（例如Windows XP以及Windows Vista等） 給阻擋。此時，程式開發者只能宣告（declare )另一個不 5 200933486 屬於滑鼠及鍵盤的介面，而這也意謂著有至少—個端點 (endpoint)被消耗掉了。 另一方面，對一般USB HID之韌體流程而言，從普 通工作模式（general working mode)切換到燒錄模式 system programming mode)時，必須再重作一次匯流排列 舉，理由如下。第一：韌體運作在燒錄模式時，連接的主 機而要女裝另一個USB驅動程式來進行燒錄動作。第二： ❹ 燒錄模式所使用的傳輸管線（t]：ans如pipe) &法和普通 工作模式所使用的傳輸管線並存。由於執行一次匯流排列 舉大約需費時幾百個毫秒（millisec〇nd),無形中拉長了整 個燒錄韌體的總時間，若量產時仍採用此方式來更新韌 體’則匯流排列舉時間就會佔據整個更㈣體時間中很大 的比重’大幅增加時間成本。為解決上述問題，因此提 本發明。 【發明内容】 有鑑於上述問題，本發明一 更m a ^糸 疋鈥供—種韌體 =新方透過標準USBHID驅動程式來絲 hid裝置，更可以膝外ΤΤΓ1ΤΛ usb 亥⑽HID裝置從普通工作糍十如 、至燒錄模式，而無須作軟體或硬體之重置。、’ 為達成上述目的，本發明之勤體更新方法 —電腦主機（host)與一人|# 保應用於 具有一庫用程二性化介面裝置之間，該電腦主機 有應用程式並透過一通用序列匯流排 人性化介面裝置，兮/ 人 面連接至該 衣置該人性化介面裝置具有— 肩第一韌體，該 6 200933486 方法包含以下步驟：—啟動步驟，係經由該應用程式呼叫 二寫入報告請求（Set_R一），以傳遞—輸出特徵報告 (feature report)給該第一韌體， ^ 笛〜師疋步驟，係根據該 第-勤體接收到的該特徵輸出報告内容，決定是否要從一 普通工作模式切換至-燒錄模式，·以及，—燒錄步驟，庵 該第-知體切換至該燒錄模式後，該應用程式呼叫該寫: 報告請求，用以藉由該輸出特徵報告的裝载，對該乂性化 介面裝置進行燒錄。 φ 本發明另-目的是提供一種刪裝置的知體架構，包 含：-燒錄模組，具有- USB傳輸功能，並利用一㈣ 介面實現-燒錄功能，其令’當接收到一寫入報告嘖长 (Set_Report)時，根據該寫入報告請求之—第一報主之 内容進行燒錄；-普通工作模組，具有_⑽傳輸功 並利用該USB傳輸功能實現—特定產品特性，其中，舍 接收到-報告内容等於一預設值時，該普通工作模組心 一⑽狀態並禁能所有與職無關之中斷，並切換至該 燒，模組；以及一模式判斷模組，用以根據-模式旗標: 決定啟動該普通工作模組或該燒錄模組。 茲配合下列圖示、實施例之詳細說明及申請專利範 圍，將上述及本發明之其他目的與優點詳述於後。 【實施方式】 本說明書中之作業系統係以wind〇ws χρ作為範例說 明，唯本發明之韌體更新方法亦可應用於其他作業系統， 7 200933486 只要能支援或符合USB的規範即可。 第1圖係顯示一電腦主機與一 hid之間的資料流。參 考第1圖，有關電腦主機110與HID 120之間的通信架 構’在電腦主機110内分為二層：應用程式U1與標準 USB HID驅動程式112,在HID 120内亦區分為二層：USB ' 引擎121與韌體122。其中，USB通信的實際執行者是驅 動程式112與USB引擎121’它們負責建立傳輸封包、解 封包及檢驗通訊協定。 在習知USB的規範中’ Set__Report與Get—Report皆屬 於類別特定請求（class-specific request)指令，應用程式 111呼叫Set-Report指令之後，被允許傳遞一報告給hid 12〇。而當應用程式111呼叫Get_Report指令之後，HID 1 2 0 被允许藉由控制型管線（c〇ntr〇l pipe )傳遞一報告給主機 110。其中的報告共有三種型態：輸入（丨叩^)報告、輸 出（output)報告與特徵（feat ure) 報告。 ⑩ 本發明之特色是利用標準USB HID驅動程式所提供 - 或支援的請求：Set_Report(Feature)以及 Get Report(Feature)， 用以在主機110與HID 120之間傳遞韌體更新所需之燒錄 程式與資料，如第1圖所示。換言之，本發明利用上述二 個請求作為一組輸出/輸入管道，將下載之程式與資料偽 裝成特徵報告’以進行HID之韌體更新動作’即可成功地 迴避Windows XP以及Windows Vista等作業系統的攔截，而 無須再安裝額外的驅動程式，大大增加了韌體更新的便利 性0 8 200933486 為方便稍後應用程式 111 能順利利用 Set_Report(Feature)以及 Get_Report(Feature)所傳遞的特 徵報告來裝載程式與相關資訊，以進行後續之燒錄動作， 對HID 120而言，為符合USB的規範與協定，有一些相 關的資訊（如特徵報告的長度等），必須事先宣告於報告描 述元（report descriptor)内的報告尺寸（Report Size)項目 (item)與報告計數值（Report c〇unt)項目，例如：假設特 徵報告的長度等於8位元組（bytes)，則報告尺寸項目内之 ❹ 資料與報告計數值項目内之資料必須宣告為8,也就是：200933486 Nine, invention description: [Technical field of invention] The present invention relates to a universal serial bus (USB) interface, and more particularly to a human interface device (HID) with a USB interface. The firmware update method. [Prior Art] Traditionally, the computer host (h〇st) has two implementations for the firmware update of a USB HID: the first way is to first set the standard provided by the operating system. The driver uninstalls (uninstall), and the operating system scans the USB HID of the firmware to be updated to perform a queue arrangement (enumerati〇n); then, installs a driver for burning, and finally, through the programming. The driver performs all burning operations on the USB HID. The advantage of this approach is that the programming driver can fully control the USB HID and pass it via control transfer, interrupt transfer © or bulk transfer. Read and write instructions for burning. Second, in some implementations and applications, there is a problem of compatibility between the programming driver and the personal power-aware (or operating system). The second method mainly uses the standard USB HID driver provided by the operating system to perform the burning operation. Although this method can avoid the compatibility problem, if the connected USB HID is a mouse or a keyboard, then The control handler (contr〇1 handler) used to control the USB HID is blocked by certain operating systems (such as Windows XP and Windows Vista). At this point, the programmer can only declare another interface that belongs to the mouse and keyboard, and this means that at least one endpoint is consumed. On the other hand, for the firmware flow of the general USB HID, when switching from the general working mode to the system programming mode, the bus arrangement must be repeated again for the following reasons. First: When the firmware is in the burning mode, the connected host needs another USB driver for the burning operation. Second: 传输 The transmission pipeline used in the programming mode (t): ans such as pipe) & method and the transmission pipeline used in the normal working mode coexist. Since it takes about a hundred milliseconds (millisec〇nd) to perform a bus arrangement, the total time of the entire firmware is invisibly elongated. If mass production is used to update the firmware, then the bus is arranged. Taking time will take up a large proportion of the total (four) body time 'significantly increase the time cost. In order to solve the above problems, the present invention has been made. SUMMARY OF THE INVENTION In view of the above problems, the present invention has a more ma ^ 糸疋鈥 — firmware = new party through the standard USBHID driver to wire hid device, and can also kneel ΤΤΓ 1 ΤΛ usb hai (10) HID device from ordinary work 糍 ten For example, to the programming mode, there is no need to reset the software or hardware. In order to achieve the above object, the method for updating the body of the present invention - the host computer and the one person | # is applied between a device having a library and a user interface, and the computer host has an application and a general purpose The serial bus is arranged in a humanized interface device, and the human/personal interface is connected to the device. The humanized interface device has a shoulder first firmware. The method of 200933486 includes the following steps: - a startup step, calling a second write via the application Into the report request (Set_R one), to pass a feature report to the first firmware, the flute to the teacher step, according to the feature received by the first object to output the report content, determine whether To switch from a normal working mode to a programming mode, and, - a burning step, after the first body is switched to the programming mode, the application calls the writing: a report request for The load of the feature report is output, and the user interface device is burned. φ Another object of the present invention is to provide a physical structure of a deletion device, comprising: a programming module, having a USB transmission function, and implementing a programming function by using a (four) interface, which enables 'when a write is received When the report is set to (Set_Report), the content of the first report owner is written according to the write report request; the normal work module has _(10) transfer function and is realized by the USB transfer function-specific product characteristics, wherein Receiving - when the report content is equal to a preset value, the normal working module is in a state of 10 (10) and disables all interrupts irrelevant to the job, and switches to the burn, module; and a mode judging module According to the mode flag: decide to start the normal working module or the programming module. The above and other objects and advantages of the present invention will be described in detail with reference to the accompanying drawings. [Embodiment] The operating system in this manual uses wind〇ws χρ as an example. Only the firmware update method of the present invention can be applied to other operating systems. 7 200933486 It is only necessary to support or conform to the USB specification. Figure 1 shows the data flow between a computer host and a hid. Referring to FIG. 1, the communication architecture between the computer host 110 and the HID 120 is divided into two layers in the computer host 110: the application U1 and the standard USB HID driver 112 are also divided into two layers in the HID 120: USB 'Engine 121 and firmware 122. Among them, the actual executors of USB communication are the driver 112 and the USB engine 121' which are responsible for establishing transmission packets, decapsulating packets, and verifying communication protocols. In the conventional USB specification, 'Set__Report and Get-Report belong to the class-specific request command, and after the application 111 calls the Set-Report command, it is allowed to deliver a report to hid 12〇. When the application 111 calls the Get_Report command, the HID 1 2 0 is allowed to pass a report to the host 110 via the control pipeline (c〇ntr〇l pipe). There are three types of reports: input (丨叩^) reports, output reports, and feature (feat ure) reports. 10 The invention features a request provided by a standard USB HID driver - or a supported request: Set_Report (Feature) and Get Report (Feature), which are used to transfer the firmware update required between the host 110 and the HID 120. Program and information, as shown in Figure 1. In other words, the present invention successfully evades operating systems such as Windows XP and Windows Vista by using the above two requests as a set of output/input pipes and disguising the downloaded program and data as a feature report 'for HID firmware update action'. The interception without the need to install additional drivers greatly increases the convenience of firmware update. 0 8 200933486 To make it easier for the application 111 to successfully load the feature reports passed by Set_Report(Feature) and Get_Report(Feature) Program and related information for subsequent burning actions. For HID 120, in order to comply with USB specifications and agreements, there is some relevant information (such as the length of feature report, etc.), which must be declared in advance in the report description element (report) Report Size item (Report) item and report count value (Report c〇unt) item, for example, if the length of the feature report is equal to 8 bytes, then the data in the report size item is reported. The information in the item with the report count value must be declared as 8, ie:
Report Size(8) ’ Report c〇unt(8)。依此，在稍後 HID 12〇 連上主機110所執行的匯流排列舉令，主機11〇就可以取 得HID iZO之屬性與運作方式，且稍後應用程式iu就能 順利呼叫 Set_ReP〇rt(Feature)以及 Get—Rep〇rt(Feat㈣。 為避免混淆，應靠式⑴呼叫Set_Rep(m(feature)時由 主機！ΗΜ專遞至HID120之特徵報告，以下稱之為輸出特 徵報告。而應用程式⑴呼叫Get—以㈣加⑽）時由㈣ © 120回傳至主機11〇之特徵報告，以下稱之為輸入特徵報 •告，如第1圖所示。在應用上，輸出特徵報告與輸入特徵 •報告的長度m相同’當然也必須在励報告描述 元中分開宣告以玆分辨。 圖 第 。第 2::二 程 在本發明第一實施例開始進行之前， 所處的狀態。假設hid 120的為一支滑 首先介紹目前HID 120 鼠，係已連接上主機 9 200933486 110並在正常使用（即在普通工作模式）中，故目前是處 於執行普通工作模式USB程式的狀態（步驟S322，第3A 圖）。當然，在進入步驟S322之前，HID 12〇的微控器（圖 未不）已執行過模式旗標判斷（步驟S3丨〇，模式旗標MF 的初始值為普通工作模式）、普通工作模式初始化（步驟 • S320 )與普通工作模式匯流排列舉（步驟S321)的工作。 *步驟S322中普通上作模式USB程式具有傳輸功能， 並且能利用該USB傳輪功能實現滑鼠之所有特性，同時，也會 ® 回應應用程式U1呼叫之標準請求（standard request)與 類別特定請求。 以下，以第2圖為主，第3A圖與第3B圖為輔，說明本發 明韌體更新方法。 步驟 S210:應用程式 U1 呼叫 Set_Report(feature)， 以傳遞特定内容之輸出特徵報告（假設長度為8個位元 組），來啟動整個韌體更新程序❶作業系統收到此請求後， 會透過USB HID驅動程式112檢查HID 120是否有輸出 ® 特徵報告的宣告以及其宣告之長度是否正確。若成功，由於輸出 特徵報告是透過控制型傳輸（Control Transfer)來傳送，作業系 統再透過下層之USB HID驅動程式120，將此請求在設定階 段(Setup Stage)傳送至USB介面130，接著，再將8個位元組之預 設值作為輸出特徵報告的内容，在資料階段(Data Stage)傳送至 USB 介面 130。 步驟S220 : HID 120接收前述請求與輸出特徵報告。 步驟S230 : HID 120決定是否切換至燒錄模式。對照 200933486 f 3A圖來看，此時HID120的微控器（圖未示）會連續判斷 是否有接收到Set_Report(feature)請求（步驟s323 )，以及 接收到的輸出特徵報告内容是否正確。若都正確的話 跳到步驟S240，否則，回到步驟S22〇。 、步驟S240:切換至燒錄模式。對照第3a圖來看，從 普通工作模式進人燒錄模式之前，微控ϋ會進行USB的狀Report Size(8) ’ Report c〇unt(8). According to this, at a later time, the HID 12 is connected to the bus arrangement command executed by the host 110, and the host 11〇 can obtain the attribute and operation mode of the HID iZO, and the application program iu can call the Set_ReP〇rt (Feature later). And Get-Rep〇rt (Feat (4). To avoid confusion, you should rely on the formula (1) to call Set_Rep (m (feature) when the host! ΗΜ specializes to the HID120 feature report, hereinafter referred to as the output feature report. And the application (1) call Get—(4) plus (10)) The feature report of (4) © 120 back to the host 11〇, hereinafter referred to as the input feature report, as shown in Figure 1. In the application, output feature report and input features • The length m of the report is the same 'of course, it must also be separately declared in the excitation report description element to distinguish it. Figure 2. 2: The state before the start of the first embodiment of the present invention, the state in which the hid 120 is assumed For the first slide, the current HID 120 mouse is connected to the host 9 200933486 110 and is in normal use (that is, in the normal working mode), so it is currently in the state of executing the normal working mode USB program (step S32). 2, FIG. 3A). Of course, before proceeding to step S322, the HID 12〇 micro controller (not shown) has performed the mode flag determination (step S3, the initial value of the mode flag MF is normal work). Mode), normal working mode initialization (step S320) and normal working mode flow arrangement (step S321). * Step S322, the normal upload mode USB program has a transmission function, and can use the USB transfer function to achieve sliding All the features of the mouse, at the same time, will respond to the standard request and category-specific requests of the application U1 call. The following is based on Figure 2, supplemented by Figures 3A and 3B, illustrating the toughness of the present invention. Step S210: The application U1 calls Set_Report(feature) to deliver the output feature report of the specific content (assuming a length of 8 bytes) to start the entire firmware update process, after the operation system receives the request The USB HID driver 112 checks whether the HID 120 has an output® signature report and whether the length of the announcement is correct. If successful, due to the output feature report It is transmitted through Control Transfer. The operating system then transmits the request to the USB interface 130 through the lower layer USB HID driver 120, and then 8 bytes. The preset value is transmitted as the output feature report to the USB interface 130 in the data stage. Step S220: The HID 120 receives the foregoing request and output feature report. Step S230: The HID 120 decides whether to switch to the programming mode. According to the 200933486 f 3A diagram, the HID 120's microcontroller (not shown) continuously determines whether a Set_Report (feature) request has been received (step s323), and whether the received output feature report content is correct. If it is correct, the process goes to step S240, otherwise, the process returns to step S22. Step S240: Switch to the programming mode. Looking at Figure 3a, the micro-controller will perform a USB shape before entering the normal programming mode.
態2始化（步驟S325 )，其内容包含：保存進入燒錄模式 之則的USB狀態以及禁能（disable)所有與usb無關之中斷 (interrupt)。其中，需保存的USB狀態包含：輸出特徵報 告的長度、輸入特徵報告的長度、特徵報告識別碼㈣州 ID)存在於否、每—端點（endp〇int )之致能狀態與暫停 (halt)狀態、咖位址以及址態狀態（c〇nfig_dst 等等。 本發明藉由保存上述的USB狀態，HID 12〇的微控器 可以在主機110不知情的狀況下順利地從普通工作模式進 、λ>錄模式大約需t幾個微秒（microsecond)的時間， ❹相較於傳統作法還須重新執行燒錄模式初始化（步驟 • S330 )以及燒錄模式匯流排列舉（步驟s34〇)，大大縮減 了整個韌體更新的總時間。 步驟S250 .進行燒錄動作。這裡的燒錄動作包含有關 進行勃體更新之所有燒錄命令，例如：「取得勒體版本」、 「比較密碼」、「切換工作模式」、「冑除快閃記憶體(f i a s h erase)」、「區段清除（sect〇r⑽⑷」、「程式化（卩叫_)快 閃心It體」'「讀取快閃記憶體」冑等燒錄命令。由於輸出 特徵報告的8個位元組内容由接收之腦引擎i2i負責 11 200933486 解譯（也就是製造商自行定義），因此， 告的内容可以視需要由應用軟體⑴ 錄特徵報 關資料。應用程式⑴根據_待更新勒體;^錄命令或相 料翻主从且更新勒體的長度與輸出特 徵報口的長度（在此假設是8位元組），可重複The state 2 is initialized (step S325), and the content thereof includes: saving the USB state entering the programming mode and disabling all interrupts irrelevant to usb. The USB state to be saved includes: the length of the output feature report, the length of the input feature report, the feature report identification code (4) state ID), the presence status of each end point (endp〇int), and the pause (halt). State, coffee address, and address state (c〇nfig_dst, etc.. By storing the USB state described above, the HID 12〇 microcontroller can smoothly enter the normal working mode without the knowledge of the host 110. The λ> recording mode requires about a few microseconds of time, and the programming mode initialization (step S330) and the programming mode bus arrangement (step s34〇) must be re-executed compared to the conventional method. , greatly reducing the total time of the firmware update. Step S250. Perform the burning action. The burning action here includes all the burning commands for the body update, for example: "Get the version of the font", "Compare the password" , "Switch mode", "Fash erase", "Section clear (sect〇r(10)(4)", "Stylized (卩叫_) Flash Heart It""" Read flash memory胄 烧 烧 。 。 。 。 。 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于 由于Record the customs declaration data. The application (1) repeats the length of the lexicon and the length of the output feature quotation (in this case, an octet) according to _waiting to update the lexicon;
Set_Rep〇n(feature)，藉由該輪出特徵報告的㈣將 更新勃體載入到励120的非揮發性記憶體⑽未示）中。 ❹ :要讀取HID120的相關資料或狀態時，則應用程 ^ 11呼叫Get_RepGrt(feature)，藉由輸人特徵報 載’將資料或狀態回傳到主機110中。 裝 對照第圖來看，從普通工作模式進入燒錄模式之 後，微控益開始執行燒錄模式刪程式（步驟^ η式uSB程式也具有刪傳輸功能，並可利用usb : 來實現韌體更新功能。當微控器收到 e—RePcm(feature)請求後（步驟S36〇)，會去掏取 的燒錄命令，判斷是否要程式化_(步驟Μ⑴， 二：的洽，跳到步驟S364,以進行程式化動 :二驟S3“，以處理…令。當微控器收I】 /rt(feature)請求後（步驟S370)，會去判斷是否要 身:資料輕態（㈣助），若是的話，跳到步 以回庫^進仃資料或狀態讀取；否則，跳到步驟S376’ 在燒錄過程中，微控器會判斷是否勤體更新 t束（步驟S372)，若是的話，跳到步驟S382，以 二SB卸栽（步驟S382 );否則，回到步驟SW，繼續 ΗΐΓΤΖΜ2所進行的咖卸载’主要是將 的硬體USB功能禁能，讓主機11〇以為Ηΐ]) 12〇 12 200933486 已斷線。之後，微控器再將硬體USB功能致能（enaMe)， 讓主機110以為HID 120已重新連接，微控器就可回到普 通工作模式，重新執行一次普通工作模式初始化（步驟 S320 )與普通工作模式匯流排列舉（步驟)，同時， 也完成整個㈣更新程序，使用者即能享受最新更新的勤 體功能。Set_Rep〇n(feature), by the (4) of the round-out feature report, loads the updated body into the non-volatile memory (10) of the excitation 120 (not shown). ❹ : When the relevant data or status of the HID 120 is to be read, the application ^ 11 calls Get_RepGrt (feature), and the data or status is returned to the host 110 by the input feature report. According to the figure, after entering the programming mode from the normal working mode, the micro-control will start to execute the programming mode to delete the program (step ^ η-type uSB program also has the delete transmission function, and can use usb : to achieve firmware update. Function: When the micro controller receives the e-RePcm (feature) request (step S36〇), it will go to the captured programming command to determine whether to programmatically _ (step Μ (1), two: contact, skip to step S364 To programmatically: two steps S3 "to handle the ... order. When the microcontroller receives I] / rt (feature) request (step S370), it will determine whether it is necessary: the data is light ((four) help) If yes, skip to step to return to the library to enter the data or status read; otherwise, skip to step S376' During the burning process, the microcontroller will determine whether the body is updating the t bundle (step S372), and if so , skip to step S382, unload with two SBs (step S382); otherwise, return to step SW, continue to 咖2 the coffee unloading 'mainly disable the hardware USB function, let the host 11 think it is Ηΐ]) 12〇12 200933486 has been disconnected. After that, the microcontroller will then use the hardware USB function. (enaMe), let the host 110 think that the HID 120 has been reconnected, the micro controller can return to the normal working mode, and re-execute a normal working mode initialization (step S320) and the normal working mode convergence arrangement (step), meanwhile, After completing the entire (four) update process, the user can enjoy the latest updated work function.
攸上述整個韌體更新過程可以看到本發明的二大優 點：第-個優點是省肖，本發明#由直接從普通工作模式 切換到燒錄模式，彳以大幅節省硬體的重置與插拔、以及 軟體的初始化與匯流排列舉的時間。第二個優點是使用的 便利性，無須額外安装驅動程式，就可一次安裝完成。 另一方面，本發明韌體更新方法不但可應用於hid 120已連接至主機11〇且已進入普通工作模式的情況，也 同樣可應用在HID 12〇與主機u〇尚未連接的情況。 第4圖為本發明韌體更新方法之第二實施例的流程 圖以下參考第4圖說明本發明第二實施例之所有步驟。 步驟S41〇 :將HID 120連接至主機11〇。 乂驟S420’^7體進入燒錄模式。對照第3B圖’HID 120 開機之後會判斷模式旗摞肿是否為燒錄模式（步驟 s3l〇y若是，跳到步驟S32〇，韌體進入燒錄模式並進行 乂 f松式初始化工作。例如在量產階段，上述模式旗摞仰 可預設等於燒錄模式’以方便載入韌體。 步驟S430 :執行燒錄模式匯流排列舉。如上所述，此 時，HID 120必須將輸出特徵報告與輸入特徵報告的長 度，宣告於報告；^、+、_ , 」 m σ钿迷TO (report descriptor)内的報告尺寸 13 200933486 (Report Size)項目（item)與報告計數值（Rep〇rt c〇un〇 項 目中，主機110就可以取得HID 120之屬性與運作方式。 步驟S440 :進行燒錄動作。根據一待更新韌體的長度 與輸出特徵報告的長度’應用程式111可重複呼叫 Set一ReporUfeature)，以藉由該輸出特徵報告的裝載，將燒 錄命令或相關資料傳入HID 120，USB引擎121再負責解 譯並執行之。當然，若要讀取HID 120的資料或狀態時， 應用程式111呼叫Get_Rep〇rt(feature)，藉由輸入特徵報 φ 告的裝載，將資料或狀態回傳到主機110中。詳細狀況已 在上述步驟S250中討論，這裡不再贅述。 如上所述，利用第3A圖與第3B圖之韌體架構，主機 110與HID 120之間進行燒錄動作時，透過攸 The above-mentioned whole firmware update process can see the two advantages of the present invention: the first advantage is that the invention is omitted, and the invention # switches from the normal working mode to the burning mode, thereby greatly saving the hardware reset and Plug-in, and the initialization of the software and the time of the bus arrangement. The second advantage is the ease of use, which can be installed in one installation without the need to install additional drivers. On the other hand, the firmware updating method of the present invention can be applied not only to the case where the hid 120 is connected to the host 11 but has entered the normal working mode, but also the case where the HID 12 is not connected to the host u. Fig. 4 is a flow chart showing a second embodiment of the firmware updating method of the present invention. Referring to Fig. 4, all the steps of the second embodiment of the present invention will be described below. Step S41: The HID 120 is connected to the host 11A. Step S420'^7 body enters the programming mode. After comparing the 3D picture 'HID 120', it will judge whether the mode flag is swollen or not. (Step s3l〇y If yes, skip to step S32〇, the firmware enters the programming mode and performs the 松f loose initialization. For example, In the mass production stage, the above mode flag can be preset to be equal to the programming mode 'to facilitate loading of the firmware. Step S430: Execute the programming mode bus arrangement. As described above, at this time, the HID 120 must report the output characteristics. Enter the length of the feature report, declared in the report; ^, +, _, ” m σ TO TO ( TO (report descriptor) report size 13 200933486 (Report Size) item (item) and report count value (Rep〇rt c〇 In the un〇 project, the host 110 can obtain the attributes and operation modes of the HID 120. Step S440: Perform a burning operation. According to the length of the firmware to be updated and the length of the output feature report, the application 111 can repeatedly call Set-ReporUfeature. The USB engine 121 is responsible for interpreting and executing the programming command or related data to the HID 120 by the loading reported by the output feature. Of course, if the HID 120 data or the like is to be read In the state, the application 111 calls Get_Rep〇rt(feature), and returns the data or status to the host 110 by inputting the loading of the feature report φ. The detailed situation has been discussed in the above step S250, and details are not described herein again. As described above, when the firmware is executed between the host 110 and the HID 120 by using the firmware structures of FIGS. 3A and 3B,
Get—Report(feature)與 Set_Rep〇rt(feature)二個管道來上傳 與下傳資料’就可避免控制HID 120的控制處置器被 Windows XP給阻擋。請注意，當第3A圖與第3B圖之韌 體架構應用在一般的USB裝置時，就沒有作業系統阻擋的 • 問題。因此，在主機110與一般的USB裝置之間進行燒錄 . 動作時’除了可以透過Get一Report(feature)與 Set_Report(feature)的這一組管道之外，也可以透過另一組 管道：即 Get_Report(IN)與 Set—Report(OUT)來上傳與下 傳資料’如第5A圖的步驟S523、S524與第π圖的步驟 S560、S570 所示。 在較佳實施例之詳細說明中所提出之具體實施例僅 用以方便說明本發明之技術内容，而非將本發明狹義地限 制於上述實施例’在不超出本發明之精神及以下申請專利 14 200933486 範圍之情況，所做之種種變化實施，皆屬於本發明之範圍。The Get-Report(feature) and Set_Rep〇rt(feature) two pipes are used to upload and transmit data' to prevent the control handler of the HID 120 from being blocked by Windows XP. Please note that when the firmware of Figures 3A and 3B is applied to a general USB device, there is no problem with the operating system blocking. Therefore, the host 110 and the general USB device are burned. In addition to the set of pipes of the Get-Report (feature) and the Set_Report (feature), the action can also pass through another set of pipes: Get_Report(IN) and Set_Report(OUT) are used to upload and download the data as shown in steps S560 and S570 of steps S523, S524 and π of FIG. 5A. The specific embodiments described in the detailed description of the preferred embodiments are merely used to illustrate the technical content of the present invention, and the invention is not limited to the above-described embodiments, without departing from the spirit of the invention and the following claims. 14 200933486 Scope of the scope, the implementation of various changes, are within the scope of the present invention.
15 200933486 【圖式簡單說明】 第1圖係顯示—電腦主機與一 HID之間的資料流。 第2圖為本發明韌體更新方法之第一實施例的流程 圖。 第3A圖與第3B圖為本發明HID之勃體流程圖。 . 第4圖為本發明韌體更新方法之第二實施例的流輕 圖0 第5A圖與第5B圖為本發明USB裝置之韌艚流择圖 ❸ 【主要元件符號說明】 110電腦主機 ill應用程式 112標準USB HID驅動程式 120人性化介面裝置 121 USB引擎 122韌體 130 USB介面15 200933486 [Simple description of the diagram] Figure 1 shows the data flow between the computer host and an HID. Fig. 2 is a flow chart showing the first embodiment of the firmware updating method of the present invention. 3A and 3B are flow charts of the HID of the present invention. 4 is a flow chart of the second embodiment of the firmware updating method of the present invention. FIG. 5A and FIG. 5B are diagrams showing the toughness of the USB device of the present invention. [Main component symbol description] 110 computer host ill Application 112 standard USB HID driver 120 user interface device 121 USB engine 122 firmware 130 USB interface
1616