589573 玖:、發明說明 (發明說明應敘明··發明所屬之技術領域、先前技術、內容、麵方式及圖式簡單說明) 一、發明所屬之技術領域 本發明係關於一種系·統映像製作方法，尤指一種適 用於可調整嵌入式系統開機速度之系統映像製作方法， 其適用範圍包括應用於嵌入式系統之技術領域中。 一、先前技術 、按，在嵌入式系統中，通常係以快閃記憶體（flash) 作為系統軟體的存放媒體，而存放在快閃記憶體中之系 統軟體則統稱為系統映像（systeni image)。 .............π丨务叼乃沄λ蚁写分為 種，第一種方法係將所有系統軟體的檔案皆儲存於快 閃忒憶體中，而不經過任何檔案處理程 以最快的速度讀取標案並完成開機作業，然而，先= ，是快閃錢體容量必社於或㈣於上述㈣軟體才 I運作’但此舉將佔帛過多快閃記憶體$間，極易造成 貝源浪費。第二種方法則是將所有系統軟體的檔案皆經 過壓縮處理’如此一來，壓縮後的擋案内容將不會佔用 =夕快閃記憶體空間，然而，卻會延長開機時間，因為 二統必須先一一將壓縮過的檔案解壓縮後、才能加以讀 來進行開機作業，亦非十分理想。 因此習知發展出第三種方法，係採用部分檔 以將某些檔案以壓縮格式存放，而其餘則以L 式存放，一方面可減少快閃記憶體的使用，另— 則由於部分檔案未壓縮，開機時間會比全部壓縮來得 6 h ,、、、而t知技術部缺乏一可根據需求調整開機速度 的方法，而有予以改進必要。 三、發明内容 本發明之主要目的係在提供—種可調整嵌人式系統 開機速度之系統映像製作方法，制貞測嵌人式系統於開 機中所開啟標案之記錄’以將開機過程不需使用到 之檔案加以壓縮，俾能同時提高開機速度、並減少所使 用之快閃記憶體空間。 之另-目的係在提供_種可調整後入式系統 =機速度之系統映像製作方法，係能根據需求以計算出 最佳化之檔案壓縮比例及開機時間。 办本七明之再一目的係在提供-種可調整嵌入式系統 速度之系統映像製作方法，俾供作為系統成本分析 /、執行效率最佳化之依據。 /為達成上述之目的，本發明所提出之可調整後入式 糸統開機速度之系統映像製作方法，係應用於—後入式 其包括有—快閃記憶體用以健存—系統軟體以 八/行瓜入式系統之開機程序及複數個後續作業程序， 系、洗♦人體包括有複數個檔案及_檔案監督程式。首 :執行系統軟體並呼叫檔案監督程式；檔案監督程式 2測於執行系統軟體時所有#開啟檔案之檔案名稱及 一山時間、並將其儲存至_歷史記錄檑中；接著，將執 2入式系統之開機程序中所開啟的最後_個檔案定義 …分界U自歷史記錄檔中擷取出此分界檔、及所 有開啟時間早於分界檔之開啟時㈣㈣，以將所擷取 589573 出的檔案定義為開機檔案，並將其他檔案定義為非開機 槽案；最後，係將所有非開機檔案壓縮後、併同開機檔 案以製作出一系統映像並儲存至嵌入式系統的快閃記憶 體中。 °心 四 貫施方式 為能讓貴審查委員能更瞭解本發明之技術内容，裝 舉二較佳具體實施例說明如下。589573 玖: Description of the invention (the description of the invention should be stated ... the technical field to which the invention belongs, the prior art, the content, the surface mode, and the drawings are briefly explained) 1. The technical field to which the invention belongs Method, especially a method for making a system image suitable for adjusting the booting speed of an embedded system, and its application range includes applications in the technical field of embedded systems. I. Previous technology. In embedded systems, flash memory is usually used as the storage medium for system software, and system software stored in flash memory is collectively referred to as the system image. . ............. π 丨 Services are written by λ ants. The first method is to store all system software files in the flash memory without passing through. Any file processing process reads the project at the fastest speed and completes the boot operation. However, first = is the capacity of the flash money. The software must work with or in the above software. But this will take up too much time. Flash memory $, it is easy to cause waste of Beiyuan. The second method is to compress all the system software files. In this way, the compressed file content will not take up = flash memory space, but it will extend the boot time, because the two systems The compressed files must be decompressed one by one before they can be read for boot operation, which is also not ideal. Therefore, a third method has been developed in which some files are used to store some files in a compressed format and the rest are stored in an L-type, which can reduce the use of flash memory on the one hand, and because some files are not Compression, the boot time will be 6 hours longer than all compression, and know that the technical department lacks a method that can adjust the boot speed according to demand, and it is necessary to improve it. 3. Summary of the Invention The main purpose of the present invention is to provide a system image production method that can adjust the booting speed of the embedded system. The files you need to compress will not increase the boot speed and reduce the amount of flash memory used at the same time. The other purpose is to provide _ a kind of system image making method with adjustable post-entry system = machine speed, which can calculate the optimized file compression ratio and boot time according to the requirements. Another goal of this book is to provide a system image production method that can adjust the speed of the embedded system, and use it as a basis for system cost analysis and optimization of execution efficiency. / In order to achieve the above-mentioned purpose, the method for making a system image of the adjustable boot-in system boot speed proposed by the present invention is applied to the -post-in system which includes-flash memory for health preservation-system software to The startup procedure of the eight / line melon-type system and a plurality of subsequent operation procedures are related to washing and washing. The human body includes a plurality of files and a file supervision program. First: Run the system software and call the file supervision program; the file supervision program 2 measures all #open files when the system software is executed and saves the file name and time in _history; then, it will execute 2 The last _ file definitions opened during the boot process of the embedded system ... Boundary U extracts this Boundary file from the history file and all opening times earlier than the time when the Boundary file is opened, in order to retrieve the retrieved 589573 files It is defined as a boot file, and other files are defined as non-boot slots. Finally, all non-boot files are compressed and combined with the boot file to create a system image and stored in the flash memory of the embedded system. In order to allow your review committee to better understand the technical content of the present invention, two preferred embodiments are described below.
本發明可調整嵌入式系統開機速度之系統映像方沒 係應用於一嵌入式系統中，用以將系統軟體製作為系叙 映像（system image)以儲存至嵌入式系統的快閃記憶選 中，其中，系統軟體係包括有複數個用以執行開機程片 之檔案及複數個後續作業程序。請參閱圖丨之流程圖，為 了兼顧增加開機速度與減少快閃記憶體使用量之目的，’ 因此將在系統軟體中插入一段檔案監督程式，故在啟鸯 甘入入式系統時，將執行系統軟體並呼叫其中之檔案於售 程式(步驟S101)，檔案監督程式則在嵌入式系統二于二 中债測攔截於執行系統軟體時所冑f開㉟過的播案名 稱、檔案大小、及開啟時間，並將上述資訊建立:二如 圖2所示之歷史紀錄檔(步驟S102)，而在收集完關於 啟檔案之相關資訊後，將移除用以收集資 程式碼（步驟S103)。 W 由於系統軟體除了可供執行開機程序外， =業程序’因此權案監督程式係能掏取出於開機: 序中最後所開啟的標案’並將其定義為 議)’於本實施例中，分界檔係為檔案F4。以’驟 8 589573 如圖2所示’顯示根據開啟時間之先後順序加以排序 之歷史紀錄檀中，開啟時間早於槽㈣的㈣包括⑽ 案F〇、細、播案F2、及播案F3，亦即上述檔案為完 成開機程序所必須執行之播案，故將檔㈣至檔案料定 義為開機㈣’並將開啟時間晚於檀訊的播案定義為 非開機檔案（步驟S105)，即檔案F5至檔案FN。 由於非開機檔案不會影響到開啟嵌入式系統的開機 速度’因此對非開機標案進行I缩處理將可減少快閃記 憶體的使用量。而在開機檔案方面，則可根據對開機速 度之快慢需求來選擇性地決定開機檔案是否需要進行壓 · 縮處理。 於本貫施例中，係依照歷史紀錄槽之内容，並使用 内插法來計算出應壓縮之檔案資料量與開機速度之關連 I*生（步驟S106)，請參閱圖3，本實施例計算出經壓縮的檔 案：料量與開機時間係成正比，亦即當已壓縮的檔案資 料，為1300KB時，開機時間為2〇秒，當已壓縮的稽案資 料量為2600KB時，開機時間為3〇秒，餘此類推。這是因 ,當壓縮的開機檔案資料量越多時，嵌入式系統在開機 φ 私序時必須對越多的樓案進行解壓縮處理，因而會梢微 延長開機時間’但將可節省快閃記憶體之使用量。 右甘入入式糸統欲在一制訂之開機速度内完成 開機程序（步驟S1G7)，便必須找出對庳於此開機速度之應 壓=之=案資料量（步驟議），並找出㈣大小總和近似 於仏案身料量之複數個開機播案（步驟S109)，以將找出之 開機槽案與所有非開機槽案進行壓縮處理後、併同未壓 9 589573 縮之開機檔案製作出系統映像，並將系統映像儲存至快 閃記憶體中（步驟s 11 〇)。 請參閱圖4第一實施例將系統軟體製作為系統映像 之樓案配置圖，並併同圖1流程圖之說明，其係要求喪入 式系統之開機速度為最快，相當於要求嵌入式系統在1〇 秒内完成開機程序（步驟S107)，故應壓縮之檔案資料量為 0ΚΒ(步驟S108)，顯示系統將不會對系統軟體2中的開機 檔案（即檔案F0至檔案F4)進行壓縮處理（步驟sl〇9)，而會 將其直接存放到快閃記憶體丨中（即無壓縮檔案丨丨），並且 將把所有不會影響開機速度之非開機檔案加以壓縮後同 樣存放到快閃記憶體1中（即壓縮檔案12),以由無壓縮檔 案11與壓縮檔案12製作成一系統映像3(步驟S110)。 而在第二實施例中，請參閱圖5，亦併同圖丨流程圖 之說明，其係要求嵌入式系統之開機時間為2〇秒（步驟 S107) ’因此根據圖3以内插法所計算出之關連性找出需 要作壓縮處理的檔案資料量為13〇〇1<：]6(步驟sl〇8)，再依 開啟順序累計檔案資料量得到檔案F〇、檔案F1、及檔案 F2的資料量總和為1300〖]3(步驟sl〇9)，因此這三個檔案 即為需要進行壓縮處理的檔案，故在步驟311〇中，將對 檐案F0 田案fi、檔案η、及非開機檔案加以壓縮（即壓 縮標案12’）’並併同未壓縮之檔案ρ3、及標案F4(即無壓 縮檔案11，）製作出系統映像3,以儲存至快閃記憶體i，中。 同,，若要求開機速度最慢，且耗用最少快閃記憶 體使用里’則將會把所有開機檔案與非開機檔案皆加以 壓縮處理後製作成系統映像。 10 根據上述之說明，本發明可調整嵌入式系統開機速 度之系統映像製作方法，主要係將所有不影響開機速度 之非開機檔案進行壓縮處理，而開機檔案則根據所制訂 之開機速度來彈性選擇欲加以壓縮之檔案。俾當選擇最 快之開機速度時，不壓縮開機檔案；選擇最慢之開機速 度時，壓縮所有開機檔案；而當開機速度介於最快與最 慢之間時，則視使用者對開機速度與快閃記憶體使用量 的考量而彈性壓縮開機檔案，亦可作為系統成本分析與 執行效率最佳化之依據，實為一大進步。 上述貫施例僅係為了方便說明而舉例而已，本發明 所主張之權利範圍自應以申請專利範圍所述為準，而非 僅限於上述實施例。 五、圖式簡單說明 圖1係本發明實施例之流程圖。 圖2係本發明實施例歷史記錄檔之示意圖。 圖3係本發明實施例應壓縮之檔案資料量與開機速度之 關連示意圖。 圖4係本發明第一實施例將系統軟體製作為系統映像之 檔案配置圖。 圖5係本發明第二實施例將系統軟體製作為系統映像之 檔案配置圖。 圖號說明 快閃記憶體1 無壓縮檔案11 壓縮檔案12The system image capable of adjusting the booting speed of the embedded system of the present invention is not applied to an embedded system, and is used to make system software as a system image to be stored in the flash memory of the embedded system. Among them, the system software system includes a plurality of files for executing the boot film and a plurality of subsequent operation procedures. Please refer to the flowchart in Figure 丨, in order to take into account the purpose of increasing the boot speed and reducing the amount of flash memory usage, so a file monitoring program will be inserted into the system software, so when the system is started, it will run The system software calls the files in the selling program (step S101), and the file monitoring program intercepts the broadcast name, file size, and file size opened during the execution of the system software in the embedded system II or II. Open the time and establish the above information: Second, the historical record file as shown in Figure 2 (step S102), and after collecting the relevant information about the open file, the code for collecting data will be removed (step S103). W Since the system software can be used to execute the boot process, the == industry process' therefore, the rights supervision program can extract the boot process: the last item opened in the process' and defines it as a negotiation) 'in this embodiment The demarcation file is file F4. "Step 8 589573 as shown in Figure 2" shows the history records sorted according to the sequence of the opening time, the opening time is earlier than the slot, including the case F0, fine, broadcast case F2, and broadcast case F3 That is, the above file is a broadcast file that must be executed to complete the boot process, so the file is defined as a boot file, and the broadcast file whose opening time is later than Tanxun is defined as a non-boot file (step S105), that is, Files F5 to FN. Since the non-boot file will not affect the boot speed of the embedded system ’, shrinking the non-boot project will reduce the use of flash memory. As for the boot file, you can selectively decide whether the boot file needs to be compressed or compressed according to the speed of the boot speed. In the present embodiment, the correlation between the amount of compressed file data and the startup speed is calculated according to the content of the historical record slot and interpolation is used (step S106). Please refer to FIG. 3, this embodiment Calculate the compressed file: the amount of material is directly proportional to the boot time, that is, when the compressed file data is 1300KB, the boot time is 20 seconds, and when the compressed audit data is 2600KB, the boot time 30 seconds, and so on. This is because, when the amount of compressed boot file data is more, the embedded system must decompress more building cases when booting φ private sequence, so it will prolong the boot time slightly, but it will save flash Amount of memory used. If you want to complete the boot process within a specified boot speed (step S1G7), you must find the pressure that corresponds to the boot speed = = = case data amount (step discussion), and find out The sum of the size is approximately the same as the case size of the boot case (step S109). After compressing the boot case and all non-boot cases, the boot file is compressed with the uncompressed 9 589573. Create a system image and store the system image in flash memory (step s 11 〇). Please refer to the first embodiment of FIG. 4 for making the system software a system image layout plan, and the same description as the flowchart of FIG. 1. It requires the fastest startup speed of the funnel system, which is equivalent to the embedded The system completes the boot process in 10 seconds (step S107), so the amount of file data to be compressed is 0KB (step S108), which indicates that the system will not perform boot files (ie, files F0 to F4) in system software 2. Compression process (step 109), and it will be directly stored in the flash memory (that is, uncompressed files 丨 丨), and all non-boot files that will not affect the boot speed will be compressed and stored in In the flash memory 1 (that is, the compressed file 12), a system image 3 is created from the uncompressed file 11 and the compressed file 12 (step S110). In the second embodiment, please refer to FIG. 5 and also the description of the flow chart of FIG. 丨, which requires that the boot time of the embedded system is 20 seconds (step S107). Therefore, it is calculated according to the interpolation method of FIG. 3 The correlation is found to find that the amount of file data that needs to be compressed is 13001 <: 6 (step s108), and then accumulate the amount of file data in the order of opening to obtain file F0, file F1, and file F2. The total amount of data is 1300 [] 3 (step sl09), so these three files are the files that need to be compressed. Therefore, in step 3110, the eaves case F0, the field case fi, the file η, and the non- Boot file is compressed (that is, compressed project 12 ')', and system image 3 is created with uncompressed file ρ3 and project F4 (that is, uncompressed file 11,) to be stored in flash memory i, medium . At the same time, if the boot speed is the slowest and the least flash memory is used, all boot files and non-boot files will be compressed and made into a system image. 10 According to the above description, the system image production method for adjusting the boot speed of an embedded system according to the present invention is mainly to compress all non-boot files that do not affect the boot speed, and the boot files are flexibly selected according to the formulated boot speed. The file to be compressed.选择 When the fastest boot speed is selected, the boot file is not compressed; when the slowest boot speed is selected, all boot files are compressed; and when the boot speed is between the fastest and slowest, the user's response to the boot speed is determined. Considering the use of flash memory and compressing boot files flexibly, it can also be used as a basis for system cost analysis and optimization of execution efficiency, which is a great improvement. The above-mentioned embodiments are merely examples for the convenience of description. The scope of the claims of the present invention shall be based on the scope of the patent application, rather than being limited to the above-mentioned embodiments. V. Brief Description of Drawings Figure 1 is a flowchart of an embodiment of the present invention. FIG. 2 is a schematic diagram of a historical record file according to an embodiment of the present invention. FIG. 3 is a schematic diagram showing the relationship between the amount of file data to be compressed and the booting speed according to the embodiment of the present invention. FIG. 4 is a file configuration diagram of system software made as a system image according to the first embodiment of the present invention. FIG. 5 is a file configuration diagram of system software created as a system image according to the second embodiment of the present invention. Drawing number description Flash memory 1 Uncompressed file 11 Compressed file 12
系統軟體2 系統映像3 檔案F 11System software 2 System image 3 File F 11