看了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 48Mbit/s
结论
1. 由于以太网驱动和IP层协议没有写mac分包，所以一个udp包的最长大小在1472字节以内
2. 大数据包发送效率高，处理效率高
3. 对于小包应用场景，能保证CPU占用的帧频率需要限制在40Kf/s以下
4. 必须开cache才能保证性能，但使用DTCM存储区并没有加速，可能是cache已经很快了
5. 必须注意内存对齐，sram3上memcpy或者直接访问非对齐的u32会hard fault
