細的記錄JLink-V8仿真器刷固件的具體過程，照著做即可成功。持續(xù)更新，原創(chuàng)不易！
目錄：
一、簡述
二、刷固件方法
1、 segger官方網(wǎng)址Software Development Tools by SEGGER – The Embedded Experts下載JLink驅(qū)動程序
1）輸入網(wǎng)址選擇Downloads，選擇J-Link/J-Trace 2）點Download 3）勾選5處
2、ATMEL官方網(wǎng)址http://www.atmel.com下載AT91-ISP下載軟件
1）輸入AT91-ISP搜索 2）點Download 3）下拉進度條，點光盤
3、修改原固件
4、擦除芯片并進入編程模式
5、ATMEL AT91XXXX Test Board提示
6、SAM-PROG v2.4燒錄軟件的設(shè)置
7、通過SAM-PROG v2.4刷寫固件
8、通過J-Link Commander修改序列號
三、問題總結(jié)
1、打開KEIL下載程序時，報“發(fā)現(xiàn)新固件”
----------------------------------------------------
完整的內(nèi)容來自：CSDN的“愛上電路設(shè)計”
--------------------------------------------------------------------------------------------------
“使之工作，工作得正確，工作得快速”，Kent Beck（極限編程的創(chuàng)建者和《測試驅(qū)動開發(fā)：實戰(zhàn)與模式解析 》的作者）如是說。
因此，在介紹了創(chuàng)建運行時和應(yīng)用程序鏡像（甚至跨操作系統(tǒng)）的細節(jié)之后，我們將轉(zhuǎn)向優(yōu)化。這可以極大地減小鏡像尺寸，并略微提高運行時性能，特別是啟動時間。
在jlink中，優(yōu)化由插件處理。因此，在使鏡像更小和更快之前，有必要先討論一下插件架構(gòu)。
jlink的核心是它的模塊化設(shè)計。除了選擇正確的模塊并生成鏡像的基本步驟之外，jlink將鏡像的進一步處理留給了插件。你可以通過jlink --list-plugins查看可用的插件，或者查看表14-1（我們將在后文中查看每個插件）。
表14-1 字母序的jlink插件列表，指明插件是減小鏡像大小還是提高
運行時性能
注意 文檔和jlink本身也列出了vm插件，讓你能從幾個HotSpot虛擬機（客戶機、服務(wù)器或最小虛擬機）中選擇一個，并包含在鏡像中。
理論上這是可行的，因為64位JDK只與服務(wù)器VM一起發(fā)布。大多數(shù)情況下，你只有一個選擇。
01. 為jlink開發(fā)插件
在本書出版時，只有支持的插件是可用的，但當(dāng)添加更多的實驗功能時，這一點在未來可能發(fā)生改變。優(yōu)化鏡像的工作還處在開發(fā)早期，很多工作仍在進行中。由于沒有標(biāo)準(zhǔn)化，也沒有在Java 9及以上版本中導(dǎo)出，因此插件的API將來可能會改變。
這使得為jlink開發(fā)插件變得非常復(fù)雜 ，也意味著在社區(qū)真正開始貢獻插件之前，你必須等待一段時間。這樣做的意義是什么？
首先，編寫jlink插件有點像編寫代理程序或構(gòu)建工具插件，而不是在開發(fā)典型的應(yīng)用程序。對類庫、框架和工具的支持是一項專門的任務(wù)。
但是讓我們回到社區(qū)提供的插件可以做什么的問題上。一個用例來自profilers，它使用代理將性能跟蹤代碼注入正在運行的應(yīng)用程序中。
使用jlink插件，你可以在鏈接的時候完成注入，而不是在執(zhí)行應(yīng)用程序時將時間花費于此。如果你需要快速加載，那么這可能是一個明智的選擇。
另一個用例是增強Java Persistence API（JPA）實體的字節(jié)碼。例1如，Hibernate已經(jīng)使用代理來跟蹤哪些實體發(fā)生了變化［所謂的臟檢查（dirty checking）］，而不必檢查每個字段。
這在鏈接時而非啟動時是有意義的，這就是為什么Hibernate已經(jīng)為構(gòu)建工具和IDE提供了可以在它們構(gòu)建過程中實現(xiàn)這些功能的插件。
最后一個例子是一個非常好的、有潛力的jlink插件，此插件在鏈接時索引注解并使該索引在運行時可用。這將大大減少應(yīng)用程序的啟動時間，這些應(yīng)用程序?qū)呙枘K路徑以查找?guī)ё⒔獾?/span>bean實體。
02. 使用jlink插件
定義：插件命令行選項--${name}
掌握了理論知識，現(xiàn)在讓我們真正使用一些插件吧。插件的使用非常簡單：jlink根據(jù)每個插件的名稱自動創(chuàng)建一個命令行選項--${name}。進一步的參數(shù)傳遞取決于插件，并在jlink--list-plugins中進行了描述。
去除調(diào)試符號是減小鏡像尺寸的好方法，為此，使用--stripdebug來創(chuàng)建鏡像。
這樣就可以了：lib/modules中的基本模塊大小從23 MB壓縮到了18MB（在Linux上）。
通過把重要文件放在前面來對lib/modules中的內(nèi)容進行排序可以減少啟動時間（盡管我懷疑效果是否明顯）。
這樣，首先是模塊描述符，然后是java.lang包中的類。
既然你已經(jīng)知道了如何使用插件，現(xiàn)在就該測試一些插件了。我們將分兩個部分進行講解，第一部分關(guān)注縮減尺寸，第二部分關(guān)注性能改進。
因為這是一個不斷演變的特性，同時也是相當(dāng)專業(yè)的特性，所以我不會詳細介紹官方的jlink文檔和jlink --list-plugins，而是盡量用盡可能少的文字進行講解，但更精確地展示它們的用法。
讓我們逐個檢查縮小尺寸的插件并測量它們的效果。我本想在應(yīng)用程序鏡像上測試它們，但ServiceMonitor只有大約12個類，所以減小它的尺寸毫無意義。
我找不到一個可以免費使用且完全模塊化的應(yīng)用程序，包括它的依賴。（在鏡像中沒有自動模塊，還記得嗎？）相反，我將對這3個不同的運行時鏡像上的工作量進行衡量（括號中為變更前的尺寸）：
1）base——僅包含java.base（45 MB）；
2）services——java.base加上所有的服務(wù)提供者（150 MB）；
3）java——所有java.*和javafx.*模塊，但不包括服務(wù)提供者（221MB）。
有趣的是，java相對于services具有更大的尺寸并不是由于更多的字節(jié)碼（lib/modules在java中比在services中更小一些），而是由于本地庫，尤其是為JavaFX的WebView所捆綁的WebKit代碼。這將在試圖減小鏡像尺寸時幫助你理解插件的行為。（順便提一下，我正在為Linux做這件事情，但是其他操作系統(tǒng)的比例應(yīng)該也差不多。）
01. 壓縮鏡像
定義：壓縮插件
壓縮插件意在減小lib/modules的尺寸。它通過--compress=${value}選項來控制，包含3個合法值：
1）0——不壓縮（默認(rèn)）；
2）1——去重并且共享字符串內(nèi)容（意為String s="text";中的"text"）；
3）2——利用Zip對lib/modules進行壓縮。
可以通過--compress=${value}:filter=${pattern-list}來包含一個可選樣式列表，用來僅壓縮匹配這些樣式的文件。
該命令創(chuàng)建了一個僅包含基礎(chǔ)模塊的壓縮后的運行時鏡像。
很明顯，你不需要嘗試0。對于1和2，我得到了以下結(jié)果：
1）base——45 MB → 39 MB (1) → 33 MB (2)
2）services——150 MB → 119 MB (1) → 91 MB (2)
3）java——221 MB → 189 MB (1) → 164 MB (2)
可以看到，壓縮率對于每個鏡像是不一樣的。services鏡像尺寸可以被減小將近40%，但更大的java鏡像只減小了25%。
這是由于compress插件僅對lib/modules有效，正如我們所討論的，它在兩個鏡像中幾乎都是相同的尺寸。因此，減小的絕對尺寸是相近的：對于每個鏡像都是大約60 MB，超過lib/modules初始尺寸的50%。
注意 通過--compress=2指定的Zip壓縮會增加啟動時間——總的來說，鏡像越大，增加的時間越多。如果啟動時間對你來說很重要，那么請確保關(guān)注它所帶來的影響。
02. 排除文件和資源
定義：exclude-files與exclude-resources插件exclude-files和exclude-resources插件允許將文件從鏡像中排除。
相應(yīng)的選項--exclude-files=${pattern-list}和--exclude-resources=${pattern-list}接受一個樣式列表，用來匹配要排除的文件。
如同我在比較services和base鏡像的初始尺寸時所指出的，主要是JavaFX WebView的二進制字節(jié)碼導(dǎo)致了java的尺寸變大。
在我的機器上，它是一個73 MB的lib/libjfxwebkit.so文件。下面演示了如何通過--exclude-files將它排除。
這實現(xiàn)了將鏡像減小73 MB的效果。下面是兩個告誡：
1) 這與人工將它們從鏡像中刪除有著相同效果；
2) 這使得只包含WebView的javafx.scene.web模塊幾近于無用，所以更好的選擇是不要包含這個模塊。
除了實驗和學(xué)習(xí)，排除來自于平臺模塊的內(nèi)容是糟糕的實踐。一定要對任何這樣的決定進行深入研究，因為這有可能影響JVM的穩(wěn)定性。
對這些插件更好的用法是，將應(yīng)用程序或依賴JAR所包含但在應(yīng)用程序鏡像中不需要的文件進行排除。可以是文檔、不需要的源代碼文件、不需關(guān)心的針對操作系統(tǒng)的二進制字節(jié)碼、配置或者任何被別具匠心的開發(fā)者放入歸檔文件中的東西。對于壓縮尺寸的比較也是沒有意義的：被排除文件所占的空間會被節(jié)省出來。
03. 排除不需要的語言環(huán)境
語言環(huán)境確實是值得刪除的來自于平臺模塊的內(nèi)容。正如你在上文所發(fā)現(xiàn)的，基礎(chǔ)模塊僅能在英語語言環(huán)境中工作，而jdk.localedata模塊包含了Java所支持的所有其他語言環(huán)境。
很不幸，這些語言環(huán)境加在一起大約有16 MB。如果你只需要一個或者幾個非英語語言環(huán)境，那這個尺寸還是有點大。
定義：include-locales插件
include-locales插件的作用是這樣的——通過--includelocales=${langs}選項生成的鏡像將僅包含它所指定的語言環(huán)境，其中${langs}是一個逗號分隔的BCP 47語言標(biāo)簽（類似于en-US、zh-Hans和fi-FI）列表。
該插件只在某個語言環(huán)境被jdk.localedata模塊放入鏡像時才有效果，所以它不會包括除基礎(chǔ)模塊所附帶的語言環(huán)境之外的其他語言環(huán)境，這是因為它會排除jdk.localedata中的所有其他語言環(huán)境。
代碼清單14-4創(chuàng)建了一個ServiceMonitor的應(yīng)用程序鏡像，其包含了所有的jdk.localedata，因為該應(yīng)用程序在輸出中使用了芬蘭語格式。
這使得鏡像尺寸額外增加了16 MB，而你清楚如何將它減小回來。代碼清單14-7通過使用--include-locales=fi-FI來達到此目的。
相對于沒有使用jdk.localedata的鏡像，由此創(chuàng)建的鏡像的尺寸只進行了最小限度的增加（準(zhǔn)確地說，168 KB）。成功！代碼清單14-7 創(chuàng)建帶有芬蘭語語言環(huán)境的ServiceMonitor應(yīng)用程序鏡像
通過排除語言環(huán)境能夠減少多少鏡像尺寸依賴于你需要多少種語言環(huán)境。如果是將一個國際化的應(yīng)用程序交付給一個全球性的客戶，那么將無法節(jié)省太多尺寸，但我認(rèn)為這種情況并不常見。如果應(yīng)用程序只支持少數(shù)或者甚至十幾種語言，那么將其他語言排除會節(jié)省幾乎16 MB。這個努力是否值得由你做主。
04. 剝離調(diào)試信息
當(dāng)你用IDE調(diào)試Java代碼時，通常會看到精致的被格式化、命名甚至注釋過的源代碼。這是由于IDE獲取了相應(yīng)的真實源文件，將它們綁定到當(dāng)前正被執(zhí)行的字節(jié)碼，并且適宜地顯示了出來。這是最佳場景。
在沒有源文件時，如果除了字段和方法參數(shù)名（必定存在于字節(jié)碼中）還能看到變量名（不是必須存在于字節(jié)碼中），也許你仍然可以看到具有良好可讀性的代碼。
如果反編譯代碼包含調(diào)試符號，就會出現(xiàn)這種情況。這個信息使得調(diào)試更容易，但當(dāng)然也會占用空間。而jlink允許你將這些符號剝離。
定義：strip-debug插件
如果通過--strip-debug選項激活jlink的strip-debug插件，那么它將從鏡像的字節(jié)碼中刪除所有的調(diào)試信息，進而減小lib/modules文件的尺寸。此選項沒有其他參數(shù)。
我在上面中使用過--strip-debug選項，所以在此就不贅述了。來看一下它是如何減小鏡像尺寸的：
1) base——45 MB → 40 MB
2) services——150 MB → 130 MB
3) java——221 MB → 200 MB
這相當(dāng)于鏡像總尺寸的10%，但是請記住，這只影響了lib/modules，其減小了大約20%。
要點 一點警告：在沒有源文件和調(diào)試符號的情況下調(diào)試代碼是一件非常可怕的事情。也許你偶爾會通過遠程調(diào)試連接到一個正在運行的應(yīng)用程序，并且分析出現(xiàn)的問題，如果放棄了那些調(diào)試符號，你則不會很開心，尤其是當(dāng)節(jié)省的那幾兆字節(jié)對你來說并不重要的時候。小心考慮--strip-debug！
05. 將這些選項放在一起
雖然將文件和資源排除對于應(yīng)用程序模塊來說會更好，但其他選項在純運行時鏡像中運行良好。讓我們把它們放在一起，并且嘗試為挑選出來的這3個模塊創(chuàng)建最小的鏡像。下面僅是java.base的命令行。
這是執(zhí)行的結(jié)果：
1）base——45 MB → 31 MB
2）services——150 MB → 75 MB（我同時刪除了除fi-FI之外的所有語言環(huán)境）
3）java——221 MB → 155 MB（或者82 MB，如果去除JavaFXWebKit的話）
這個結(jié)果不壞，是吧？
如你所見，減小應(yīng)用程序或運行時鏡像尺寸的方法有很多。我的猜測是，大多數(shù)開發(fā)者在急切地盼望著性能的提高，尤其是在Spectre和Meltdown搶走了一些CPU周期后。
要點 很不幸，在這個領(lǐng)域我沒有太多好消息：基于jlink的性能優(yōu)化仍然處于早期階段，而已有的大多數(shù)或者已經(jīng)預(yù)期的優(yōu)化集中于提升啟動時性能，而非長期運行時的性能。
一個現(xiàn)有的插件是system-modules。它默認(rèn)被打開，會預(yù)先計算系統(tǒng)模塊圖并且將之存儲，以便快速訪問。這樣，JVM就不需要在每次啟動時都解析和處理模塊聲明以及驗證可靠配置了。
另一個插件是class-for-name，它用some.Type.class來替換諸如Class.forName("some.Type")這樣的字節(jié)碼，進而相對昂貴且基于反射的按名稱對類進行的搜索則可以避免。我們簡要地看過orderresources，其并沒有對性能有較大的改善。
目前，唯一支持的其他性能相關(guān)的插件是generate-jli-classes。合理配置后，它可以將初始化lambda表達式的代價從運行時移動到鏈接時，但需要對方法句柄有很好的理解后，才能有效對它進行學(xué)習(xí)，所以我不會在此過多涉及這個話題。
這就是性能提升相關(guān)的所有內(nèi)容。如果你對于在此領(lǐng)域沒有獲得太多幫助而很失望，對此我表示理解。
但是請讓我指出，JVM已經(jīng)優(yōu)化的非常徹底了。所有低垂的果實（以及一些相對較高的果實）都已經(jīng)被摘掉了，而要摘取剩下的果實還需要精巧的設(shè)計、大把的時間以及專業(yè)的工程能力。
jlink工具仍然年輕，我相信JDK開發(fā)團隊和社區(qū)會在適當(dāng)?shù)臅r候?qū)λ右岳谩?/span>
Java 10的應(yīng)用程序類數(shù)據(jù)共享。
Java 10引入了一個與jlink間接相關(guān)的優(yōu)化：應(yīng)用程序類數(shù)據(jù)共享。2實驗證實，它可以使得應(yīng)用程序啟動加快10%到50%。有趣的是，你可以在應(yīng)用程序鏡像中應(yīng)用這項技術(shù)，創(chuàng)建一個更加優(yōu)化的部署單元。
方便起見，表14-2列出了本書討論的所有jlink命令行選項。更多信息可以參見官方文檔，或者使用jlink --help和jlink --listplugins。
表14-2 經(jīng)篩選的jlink字母序選項列表，包括插件。描述列基于官方文檔，引用列指向本書中詳細解釋如何使用這些選項的章節(jié)
1）命令行工具jlink基于指定的平臺模塊創(chuàng)建運行時鏡像（使用jdeps來確定應(yīng)用程序需要哪些平臺模塊）。要從這個工具中受益，應(yīng)用程序需要運行于Java 9及以上版本，但模塊化不是必需的。
2）一旦應(yīng)用程序和依賴被完全模塊化（而非利用自動模塊），jlink就可以為它創(chuàng)建應(yīng)用程序鏡像，其中包含應(yīng)用程序的模塊。
3）所有對jlink的調(diào)用都需要指定以下參數(shù)。
1.--module-path，從哪里查找模塊（包括平臺模塊）。
2.--add-modules，所解析的根模塊。
3.--output，生成鏡像的輸出目錄。
4) 注意jlink如何解析模塊。
1.不會默認(rèn)綁定服務(wù)。
2.requires static指定的可選依賴不會被解析。
3.不允許使用自動模塊。
4.確保通過--add-modules單獨地增加依賴的服務(wù)提供者或者可選依賴，或者通過--bind-services綁定所有服務(wù)提供者。
5) 當(dāng)心那些無須實現(xiàn)就可以隱式依賴的平臺服務(wù)。比如字符集（jdk.charsets）、語言環(huán)境（jdk.localedata）、Zip文件系統(tǒng)（jdk.zipfs）以及安全提供者（多個模塊）。
6) 由jlink生成的運行時鏡像。
1.綁定到通過--module-path選擇的平臺模塊構(gòu)建所針對的操作系統(tǒng)。
2.與JDK和JRE有相同的目錄結(jié)構(gòu)。
3.將平臺和應(yīng)用程序模塊（統(tǒng)稱為系統(tǒng)模塊）融合進lib/modules。
4.僅包含所需模塊的二進制文件（在bin目錄中）。
7）使用bin/java --module ${initial-module}（無須模塊路徑，因為系統(tǒng)模塊被自動解析）或者通過--launcher${name}=${module}/${main-class}創(chuàng)建的啟動器來啟動應(yīng)用程序鏡像。
8）利用應(yīng)用程序鏡像，模塊路徑可以用來增加額外的模塊（尤其是那些提供服務(wù)的模塊）。模塊路徑中與系統(tǒng)模塊同名的模塊會被忽略。