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