看了stm32h750系列的介紹，其模擬性能、運算性能和通信功能都很強，並且作為一款新的MCU，迅速在市場上普及，價格也可以接受，所以很快入手了一塊stm32h750VBT6開發板，進行實驗。
與之前一樣，完全不使用st的固件庫，只借鑒啟動文件：startup_stm32h750xx.s和系統定義：stm32h750xx.h，並將其中定義的固件庫相關信息刪除。
CPU沒有跑滿480MHz，而是是用一般例程中的400MHz。
由於項目只是用udp通信，就不用lwip那么麻煩的協議棧了，自己寫一個就夠了，只需實現arp、icmp、ip、udp協議。當然，udp協議是簡化的，最大支持包長1472字節，就是沒有實現ip層在以太網幀的分包，整個網絡協議含頭文件不到500行
由於單片機比較新，一開始調試時還是遇到了很多問題：
1、使用jlink調試stm32H750，無法識別，使用的是6.40的dll，下載6.8的jlink驅動后，能夠識別，但無法下載，一下載就報錯，然后必須給芯片下電后才能再次識別。然后插上了電源適配器，就沒問題了。說明是瞬間大電流導致下載失敗了。
2、在AD的時鍾選擇，需要在RCC處選擇時鍾，時鍾需分頻
3、h750以太網調試時，接收緩存使用硬件的sram3原位操作，發生hard fault。
//memcpy(yip_buf,p,n); //收發互斥，使用同一個緩存 （這是之前可以用的代碼）
u32 arp_desIP;
//memcpy(&arp_desIP,&(arp.desIP),sizeof(arp_desIP)); //錯誤代碼
int i;
for(i=0;i<4;i++) ((u8*)&arp_desIP)[i]=((u8*)&(arp.desIP))[i]; //正確代碼
if((eth.type==CHANGE_END16(ETH_TYPE_ARP)) && arp_desIP==ipaddr)//若是ARP
{
………………
后來的代碼是直接使用輸入指針p，就是sram3的內存，經MPU保護。為了提高效率，讓協議棧在此內存處原位操作。
但在訪問arp.desIP時發生錯誤，於是做臨時變量arp_desIP，通過memcpy將sram3的內容復制到棧空間，但memcpy過程發生hard fault
所以改成for循環，按字節復制，可以通過，進而在后續處理時，memcpy的過程錯誤。
懷疑是內存對齊問題，必須將sram3的內容挪到帶cache的內存中，就不會出現對齊問題了。
在調試中也逐漸解決了一些疑問：
1、sram3的使用是否需要開時鍾？不需要
2、eth的發送描述符是否需要在sram3中？接收緩存是否需要在sram3中？也可以在D2域的其他存儲器中
3、描述符中兩個buf，應該是對於數據包頭和數據域分離的情況，如果不使用減荷，不使用
4、環形描述符列表，尾指針和頭指針怎們用，可否固定，發送尾指針移動，DMA才會取
5、在調試模式下，當前主機發送器或接收器描述符地址指針的值可在 ETH_DMACCATxDR 和 ETH_DMACCARxDR 中讀取
最后，附以太網udp測試的結果：
使用猛禽的H750開發板進行以太網實驗，單片機端做echo服務，udp方式。CPU空閑tick=9947
pc端連續發送udp包，每秒打印發送包數和接收包數，並查看任務管理器的網絡流量
小包測試
發送包長32字節，發送2000000（2百萬）包時，接收1999445包，丟555包，丟包率萬分之3
數據通信速度3.8MB/s，而任務管理器中的網絡流量達到78Mbit/s，說明數據包小，幀頭開銷很大。
幀頻率為118Kf/s
CPU空閑tick=2600，CPU占用率為73%
大包測試
使用1000字節大包重復實驗：
任務管理器的網絡流量達到了97.5Mbit/s，基本達到百兆網極限。數據速率11.7MB/s，效率很高
發送1百萬包時，丟13包，丟包率萬分之0.013，比小包低兩個數量級
幀頻率為11.7Kf/s
CPU空閑tick=5313，CPU占用率為46%
cache性能測試
不開cache，CPU空閑tick=1935，遠遠低於開cache，使用小包測試，CPU100%占用，且回復速度下降了將近一半: 78 -> 48Mbit/s
結論
1. 由於以太網驅動和IP層協議沒有寫mac分包，所以一個udp包的最長大小在1472字節以內
2. 大數據包發送效率高，處理效率高
3. 對於小包應用場景，能保證CPU占用的幀頻率需要限制在40Kf/s以下
4. 必須開cache才能保證性能，但使用DTCM存儲區並沒有加速，可能是cache已經很快了
5. 必須注意內存對齊，sram3上memcpy或者直接訪問非對齊的u32會hard fault