页次: 1
太湖飞人 说:这个芯片很好,但有一个缺点就是一种电压搞不定,也就是核电压和IO电压不一样
现在这个已经停产了,用AG32的CPLD模式——AGRV2K
https://whycan.com/files/members/14582/c390ad3c4f35964a6ab035da1e9a943.png
停产会给客户带来很多麻烦,ALTERA很多产品十几年甚至几十年都能买到。
@echo
厂家和开发者是合作关系,互相依赖互相获益。你这说法满满的对立关系啊,这样的厂家恐怕真不应该活着
你这话没问题,但是有个前提,必须是合格的开发者,起码应该看过datasheet和usermanual,会用搜索引擎搜索问题。即使提问,也不应该问已有文档上的内容。事实上这个行业充满了新手、小白,伸手党,半桶水,他们会把datasheet上的已经写了的问题一个个问你,把你搞到崩溃,别问我怎么知道的。
合格的开发者可能连10%都没有,这里面大多数还是在公司上班的,可以拿到厂家的技术支持。合格的个人开发者可能连2%都没有。
所以厂家选择不公开资料虽然合格的个人开发者觉得不爽,但是从厂家的角度来考虑完全可以理解。
@echo
少在那误导了。
https://baike.baidu.com/item/Rtems/6985412
https://baike.baidu.com/item/vxworks?fromModule=lemma_search-box
看看哪个不是用在可靠性极高的地方。
你自己多踩一些坑就明白了
USBHS 集成了 HS PHY,,牛啊,,这点比 STM32H7 强多了
还好吧,CH32V307早都支持了
也不知道 CAN CAN_STAT RS 问题 修了没
参考:
https://zhuanlan.zhihu.com/p/453181148
https://bbs.21ic.com/icview-3190724-1-1.html
你这两个链接,都是我的文章
兆易创新推出GD32H737/757/759系列Cortex®-M7内核超高性能MCU
中国北京(2023年5月11日)——业界领先的半导体器件供应商兆易创新GigaDevice (股票代码 603986) 今日宣布,正式推出中国首款基于Arm® Cortex®-M7内核的GD32H737/757/759系列超高性能微控制器。
GD32H7系列MCU具备卓越的处理能效、丰富连接特性及多重安全机制,以先进工艺制程和优化的成本控制,全面释放高级应用的创新潜力。全新产品组合包括3个系列共27个型号,提供176脚和100脚BGA封装,176脚、144脚和100脚LQFP封装等五种选择,将于5月底陆续开放样片和开发板卡申请,10月起正式量产供货。
GD32H7可广泛用于数字信号处理、电机变频、电源、储能系统、无人机、音频视频、图形图像等各类应用。得益于超高主频以及大存储容量,该系列MCU也适用于机器学习和人工智能等诸多高端创新场景。
GD32H759xx_Datasheet_Rev1.0.pdf
GD32H737xx_Datasheet_Rev1.0.pdf
趁下班时间画了一版,大家猜猜这是什么方案😏
https://whycan.com/files/members/1510/AQUA-Lite.png
为啥你们都喜欢用TypeC,USB2.0 HS也只需要D+D-两个信号,MicroUSB足够了,TypeC多出来一堆无用管脚,焊接麻烦,体积还大。
补充一下,普冉的这个FLASH技术叫做SONOS,来自Cypress,和华邦兆易他们的不一样。下面是两篇介绍文章:
@海石生风
普冉的这个FLASH烧录按页来编程,速度很快。像传统的STM32那样4字节编程速度就慢很多了。为此我专门重写了自己的固件升级算法。以下是一些朋友提供的消息,真假自辩,感觉没啥问题。
Puya用了一种新的工艺,和传统的NorFlash不同,cypress授权的,国内很多Flash小厂在用。
erase时间短,program时间长,page program的时间应该是2ms,小于一个page的,比如写
1个字节,时间也是2ms。
仔细看手册你会发现WCH的MCU内置FLASH都提供快速编程功能,就是页编程,和PY32的内置闪存一样,PY32甚至手册上只提到支持页编程。
用GCC 12的时候提示找不到csrrw这些指令,查了下,原来20191213版本的spec把csr相关指令放到Zicsr扩展中了。原文如下:
While CSRs are primarily used by the privileged architecture, there are several uses in unprivi-
leged code including for counters and timers, and for floating-point status.
The counters and timers are no longer considered mandatory parts of the standard base
ISAs, and so the CSR instructions required to access them have been moved out of the base ISA
chapter into this separate chapter.
问题是,CSR中不光有计数器和定时器呀,还有别的寄存器,比如mstatus、mepc、mcause、mtvec等等,这些寄存器都是必不可少的。
扩展的意思是可以不用,难道不用Zicsr指令能构建一颗能用的MCU?退一步来说即使是定时器和计数器作为强制部分也没什么不妥,隔壁ARM的SysTick计数器也是核心的一部分。
RISC-V这个CSR感觉和51的SFR有点神似,标准定义访问这段空间的指令和一些通用的寄存器,厂家再根据自己的需要进行扩展,增加一些寄存器,但是访问这些寄存器的指令肯定是必不可少的,不太理解CSR访问指令为什么要作为扩展。大家怎么理解?
@echo
真的假的,8脚的无法恢复了吗?这设计有点...
avr的tiny13a可以任意使用io,并不影响isp下载
也能恢复,用户固件做个自杀功能就行了,比如开启读保护然后再解除读保护,固件就自杀了,闪存为空,默认启用SWD接口可以烧录。
我曾经SO-8的固件开启了读保护,没法解除,因为找不到他们那个PY-LINK,又没有BOOT0,没法用ISP工具,后来用我自己的GDLink手动解除了读保护。最后给固件做了自杀功能,就没有问题了。
CH32V003也有个坑,没有他们那个LinkE是没法烧录的,芯片为空片的时候,CH32V003并不会停在内置bootloader等待连接,而是跳转APP,导致没法使用ISP。因为没有boot0,ISP也依赖用户程序跳转到内置bootloader,我目前测试还有问题,跳转内置bootloader以后ISP工具没法连接,不知道是WCHISPTool 3.4的问题还是芯片的问题。
两颗芯片,感觉还是PY32F003更好一些,虽然价格稍微贵一些,但是存储容量大得多,能做的事情多的多,M0+比RV32EC好多了,后者连乘法器都没有,现在比较感兴趣的是CH32V003这个RV32EC核心面积能有多小。CH32V003内置的2+16k实在是太小了,要是能出4+32k的版本应用场合能多很多。
手头的CH32V003盘完了,几个要注意的地方说一下:
中断向量表要对齐到1kB地址,如果要设计bootloader就要非常注意
这颗芯片只支持机器模式,虽然启动文件设置mstatus为0x80,但是实际运行以后读取mstatus为0x1888
不支持硬件乘法器,这一点就不如M0了
2+16kB的存储太有限了,只能做非常简单的任务
linkE调试器的单线调试模式挺好用,WCHISPTool暂时还没支持CH32V003
-flto选项可以大大减小代码体积,接近M0的LTO优化体积,不过开启-flto以后代码运行还是有问题,是gcc 8.2.0的问题,不知道WCH什么时候能更新gcc
附CH32V003的CSR列表:
marchid = 0xDC68D841
mimpid = 0xDC688001
mstatus = 0x00001888
misa = 0x40800014
mtvec = 0x08000003
mscratch = 0x00000000
mepc = 0x0800205C
mcause = 0x8000000C
mvendorid = 0x00000000
mhartid = 0x00000000
还有几个样片,有想玩的朋友可以送一片,这颗芯片和STM8S003封装和电源脚位置都一样,直接把STM8S003拆了换上去就行。
由于邮费远大于芯片价值,所以从我这里买东西的朋友报whycan暗号可以送一片,淘宝或者闲鱼都可以。
国产的RISC-V还是得看WCH,这不又丢了个王炸出来CH32V003,介绍链接:
https://www.wch.cn/products/CH32V003.html
说它是王炸不是因为性能有多强,而是性价比爆炸,据说只要五毛钱,你没听错,是五毛钱,还是RMB,某些人发个帖子就能赚到一颗。
性能方面,核心是RISC-V最高48M,RV32EC指令集,性能就不指望了,只希望代码密度能表现好一点。
存储方面,2kB SRAM和16kB FLASH,闪存要是能到32kB使用范围能更广一些。
电源方面,支持3.3V和5V,简单的应用场合可以不用LDO了。
外设方面,1个10位ADC,1个运放,1个DMA,1个高级定时器,1个通用定时器,还是蛮全的。
通讯接口方面,USART、SPI、I2C各一个,接口挺全,数量都是1个。这个价格下USB和CAN这种复杂接口就不用奢望了。
调试接口方面,和STM8那个SWIM接口类似的串行单线。
封装方面提供了SO-8、SO-16、QFN-20、TSSOP-20四种封装,其中QFN-20封装为3x3mm,0.4mm间距,尺寸非常小。
竞品方面:
TSSOP-20对标STM8S003F3P6,N76E003AT20,复位、电源、调试这些管脚布局相同,可以直接P2P替换。
SOP-8对标STM8S001J3M3,电源脚布局完全一样,可以直接P2P替换,还去掉VCAP那个管脚多了个IO。
最后说一下开发工具,他们提供的那个MounRiver还是挺好用的,要是能把gcc赶紧升级一下就好了,目前的8.2.0还是有些问题。
清理了一下旧固件,放个最新的。
CH552_Blaster_v22.2.27.7z
偶尔用的话,用这个CH552版本的USB-Blaster就足够了。经常用的话建议买CH546或者CH571版本的USB-Blaster,速度要快得多。
:)用楼主的固件做了个迷你版的USB Blaster
https://whycan.com/files/members/3241/mmexport1656044754257.jpg
随便用个CH552开发板就可以
@metro
这些10MB+的bitstream本来就是极少的场景。调试器上完全派不上用场。SignalTapII这类片上逻辑分析仪用USBFS也足够了,我用CH552做的USB-Blaster也可以胜任。这些调试器一边是USB,另外一边是JTAG或者SWD,也是单端串行时钟,并且要使用杜邦线或者排线连接,TCK时钟频率不可能太高,十几M最多几十M撑死了。频率越高兼容性可靠性越差,用户越容易骂娘。使用480M的USBHS完全就是大炮轰蚊子,没有任何必要。
另外TCK和SWCLK这边如果软件IO模拟时序,那速度完全不行,要喂饱USBFS必须硬件SPI+DMA来优化,这个还是有一定难度的,做得好的并不多。
高速USB的最佳应用是各种USB逻辑分析仪,这些设备对USBHS的带宽使用比较充分。
echo 说:@zhang235hai
我这里版本更新的3.3.3.5781不支持,奇怪得很。方便共享一下McgsPro 3.3.2.6187版本吗?
好大的附件,还是用网盘分享吧,给晕哥节省一点带宽费用。附件3.3.2.6187版本和更新的3.3.3.5781都在网盘中了。
链接: https://pan.baidu.com/s/1zw1reH_mrnzAA1aDxHDVrA?pwd=uuc2 提取码: uuc2
这款示波器,
https://www.micsig.com.cn/product5/
SoC用的是RK3568,4xA55@2.0G,这个4小核配置广泛用在目前的手机SoC上。
2GB DDR4内存,32GB eMMC,SOC+DDR4+eMMC在一片核心板上。
看RK3568发布时间也就一年而已,产品上市还挺快的。
STC32G性能提升主要是内存架构优化带来的,在同样的22.1184M主频和速度优化时:
STC8G用时235ms,成绩0.109DMIPS/MHz
STC32G用时67ms,成绩0.384DMIPS/MHz,相对提升0.384/0.109=3.523倍
STC32G内存模型切换为Large后用时189ms,成绩0.136DMIPS/MHz,相对提升0.136/0.109=1.248倍
https://zhuanlan.zhihu.com/p/482337395
这款号称32位的8051,实际上就是Intel的C251架构,向下兼容8051,地址空间扩展到了24位,堆栈空间扩展到了16位共64kB,扩大了内部SARM(edata)数据复制速度也有了很大提高,解决了8051架构的一些弊端。
STC花了很大力气宣传,芯片刚刚到手不久,板子打好测一下性能,看看是不是和他们宣传的一样好。
软件还是使用Dhrystone,编译器C251.exe 版本v5.60.0.0,速度优化,使用标准库。
第一次测试结果376ms,奇怪,怎么比8位的8051还慢?查了好久,原来WTST寄存器搞的鬼,复位值是最大值7,加了7个等待,手册建议35M主频以下改为0,修改为0重新测试,速度果然快了很多,结果如下。
结论就是大约0.38DMIPS/MHz,这个结果和ARM在 https://www.keil.com/benchmarks/c251_bmark.asp 这个文章中的测试结果是一致的。这就是C251架构的性能了,比8051提高很多,然而在现代一众32位MCU中显然不算入流。
其实我对这个来自古代的C251核心一点兴趣都没有,现代的Cortex-M和RISC-V比它要好得多,买这个芯片主要是想看看它的USB和两个CAN表现如何,尤其是两个CAN,从寄存器接口来看,就是内置了两片SJA1000控制器,光这两个CAN都值回票价了,具体如何,有待以后分解。
最后再吐槽下这个C251编译器,不知道是因为用户太少还是什么原因,真的是不太好用,很多标准C库函数没有实现,比如strstr,strtok,strtoul,都要自己实现。
一个结构体中定义的一个函数指针,指向实际的函数,它也分析不出来,然后报L57警告,实际呢又能运行,也就是函数并没有被优化掉,让人困惑。
*** WARNING L57: UNCALLED FUNCTION, IGNORED FOR OVERLAY PROCESS
@Blueskull WCH官方人员确认了GCC的这个问题。他们也是“持续关注GCC对此类问题的更新情况”
https://bbs.21ic.com/icview-3204494-1-1.html
而且有朋友也用7.2.0版本的GCC发现了同样的问题。
https://zhuanlan.zhihu.com/p/478423323
-flto选项对RISC-V还是很重要的,因为RISC-V的代码密度本身就非常拉胯
使用某个双向端点来通讯,比如端点2,我们记为EP2_OUT和EP2_IN,分别处理主机的OUT和IN请求。设备收到主机OUT请求以后,应答ACK,然后设置EP2_OUT的TF中断标志,中断延迟大约6us或者更少一些。
如果在6us中断延迟时间内没有EP2_IN的IN请求,或者即使有IN请求,设备EP2_IN没有准备好,应答NAK,那一切正常。我的应用中实际测试EP2_OUT响应ACK以后,大约0.6us以后主机就会发送IN请求,刚好落在6us的中断延迟时间内。这时候如果设备EP2_IN端点准备好,那么就开始响应EP2_IN请求,给主机发送数据,发送完成主机应答ACK,触发EP2_IN的TF中断标志,正常触发中断,这个中断会把它前面EP2_OUT的中断标志冲掉,导致丢失前面的EP2_OUT传输完成中断。
usb的固件库代码我看过是可以同时处理同一个端点OUT和IN两个TF中断标志的,所以问题大概率在USB硬件。目前该问题还未得到官方确认。这个问题在USB实际通讯速率不高的问题,极少出现,大流量的通讯的时候会出现,概率几十万分之一吧,没有什么规律,所以定位起来十分困难。
测试过GD32E103,GD32F303,都有这个问题,其它型号有待确认,大概率GD32全系CAN外设都有这个问题。
CAN状态寄存器的bit9 RS表示接收状态,实际测试,CAN初始化退出睡眠模式以后RS位就是1,进入初始化模式以后RS位清零,退出初始化模式以后RS=1
然后整个使用过程中这个RS位一直都是1,本来这个位是指示CAN硬件有没有在接收数据的,现在完全失去了意义。
CAN的一帧很长,需要上百个位,持续数百微秒,硬件接收完了完整一帧才会放入FIFO,软件才能查询到,所以如果软件想知道硬件是否在接收数据,这个接收指示位就很重要,如果这个位行为异常,软件通过RX管脚来判断是否CAN正在接收数据非常困难。
实测STM32和AT32的这个RS位行为是正常的,只有接收数据的时候才会置1,可以判断CAN的接收状态。
联系过GD原厂,确认了这个问题,GD32的CAN外设无法通过硬件判断CAN外设是否在接收数据,还有更坏的消息:原厂不认为这是bug,也不打算在新产品型号中更改。
好消息是他们的CAN IP是自研的,所以这个bug应该是GD32芯片独有的,不会影响其它厂商的产品。
附和原厂技术人员沟通记录:
GD:我找人测了下,默认是处于接收状态,如果是发送数据时,会处于发送状态,发的时候会变 0,其他都是1
ME:这种行为模式没有用处,因为实际需要的是硬件在接收数据才置1,而且其它厂家人家也是这么定义的
GD:设计就是这样,那就只能别这么用
ME:那应该如何判断CAN硬件在接收数据?有别的方法也行
GD:没有办法,就我跟你说的判断帧数量
ME:我说过了,没法根据帧判断,CAN总线在接受数据的时候,数据还没进FIFO,一帧接收完了才会进FIFO
GD:我知道你意思,那就无解啦,无法识别正在接收状态
ME:好吧,只能尽量避免用这个芯片了,这个IP不知道是自研的还是外购的,STM32F103是没有这个问题的
GD:自研
ME:那别家应该没这个问题,你们可以对比下友商的产品
GD:知道,设计人员对这个理解与别人有偏差,这就跟485接口类似
ME:就是受了RS485的影响,485不支持多主,发送完数据要设置为接收,问题CAN是支持多主的,没有这个问题,所以是芯片bug,不是特性
GD:485没有仲裁机制,CAN有仲裁机制,现在这个特性你认为是BUG那就是,他不影响正常使用,只是你刚好想要用的点有点特殊,无法满足你的应用场景
ME:这个位相当于没有,是不是bug,你们要确认,涉及到新芯片是否会更新的问题。
GD:我回你了啊,我们设计是我跟你说的那样,这个你能理解为他是bug,也能理解为他为设计特性
ME:我明白了,那就是以后新型号也不会更改。
感觉会比ESP8266更便宜,内置FLASH的版本也终于不把FLASH引脚引出来了。QFN24封装4x4。
https://www.espressif.com/zh-hans/news/ESP32-C2
乐鑫宣布推出低功耗、低成本的 ESP32-C2 芯片,比 ESP8266 面积更小、性能更强。ESP32-C2 在满足简单物联网应用需求的基础上,进一步优化成本,能够为用户提供一个极具性价比的开发平台。值得一提的是,乐鑫的射频技术实现重要突破,可达到 1024-QAM 技术指标,未来将为客户提供更多高性能的产品选择。
ESP32-C2 集成 2.4 GHz Wi-Fi 和支持长距离的 Bluetooth 5 (LE),搭载 RISC-V 32 位单核处理器,时钟频率高达 120 MHz,内置 272 KB SRAM (16 KB 专用于 cache) 和 576 KB ROM,具有 14 个可编程 GPIO 管脚,支持 SPI、UART、I2C、GDMA 和 PWM。
dgtg 说:啥都没改吗?
改改管脚也行啊..直接抄的版图,啥都没改。WCH也抄别人的,pin兼容的CP2102N,CP2104和FTDI的产品,但是WCH只是抄功能,设计实现都是自己搞的,不涉及侵权,类似GD32抄STM32。
管脚兼容,我觉得不算是抄。举几个极端点的例子,电阻都是2条腿,SOT-23的MOS管,gds三个管脚排列都是一样的,没有人觉得生产电阻和MOS管是抄。同样的485/CAN的PHY芯片,SO-8封装管脚排列也完全一样。MCU相比之下可能只是管脚多了一点,没有本质差异。当然MCU也有SO-8封装的,甚至SOT-23-6也有。
上海国*,芯片命名G开头的。
http://www.gco__.com.cn/
重点:专业公司,直接逆向,相似度100%,GC9034,价格730/830=0.88元
http://www.jmzscqlvshi.com/300.html
沁恒公司生产的CH340芯片自2011年上市销售以来深受业内人士喜爱,一跃成为业界值得信赖的国产高端芯片。正因如此,CH340芯片暗中成为了企图不劳而获的不法人员眼中的新“财路”。
2016年,G公司销售人员陶某,在进行市场调研和推广中发现CH340芯片销量大,遂从市场获取正版CH340芯片交予G公司负责公司生产经营等事务的总经理许某,在未获得沁恒公司授权许可的情况下,决定反向破解CH340芯片并对外销售。于是委托其他公司对CH340芯片各层电路布图进行破解,提取GDS文件,再生产掩模工具、生产晶圆、封装,后以G公司GC9034型号芯片名义对外销售。
2016年9月至2019年12月,G公司共销售侵犯沁恒公司著作权的GC9034芯片共计830余万个,销售金额人民币730余万元,上述收益均归G公司单位所有。
v21.11.9,再次优化性能,使用硬件SPI,TCK时钟提到8M,JTAG模式比之前版本提高了大约37%。
CH552_Blaster_v21.11.9.hex
CH573F这颗RISC-V的MCU很有意思,内部FLASH很大,CodeFlash就有448kB,但是SRAM相对较少,只有18kB。
官网介绍标的主频为20M,但是实际SDK里面,可以通过PLL提高主频到60M,关于性能,手册介绍得比较少,只在介绍FLASH的时候提了一句:20MHz系统主频下基本零等待。
根绝多年经验,判断内部使用的是大容量的SPI FLASH,代码通过cache来访问,性能比SRAM中零等待运行慢一些,但是比无cache的方案(比如GD32F1x0系列)速度有质的差异。
使用dhrystone进行了一些测试,结果完全支持以上结论,性能主要决定于主频和程序运行的位置,结果如下:
60M 13.3ms 2.76x
20M 25.2ms 1.55x
8M 73.5ms 1.94x
60M 36.7ms 36.2%
20M 39.0ms 64.6%
8M 142.4ms 51.6%
代码在SRAM中运行时,随着主频提高,性能也在提高,在FLASH中运行时,超过20M性能提升就非常有限了。
SRAM中运行时,8M主频时73.5ms,和其它RISC-V(比如GD32VF103,54.39ms)比稍慢一些,比Cortex-M3的45.92ms速度再慢一些。
代码在FLASH中运行时,性能只有SRAM中运行的一半左右,大量对速度要求不高的代码,比如业务逻辑,完全可以在FLASH中运行,性能是可以接受的。
代码在FLASH中运行时,超过20M以后性能提升很小了,手册中提到的“20MHz系统主频下基本零等待”应该就是这个意思,这个性能大约就是一个8M的Cortex-M4(38.4ms)的水平。
少数需要很高运行速度的代码可以放到SRAM中运行,不受SPI FLASH性能限制,高主频时提升还是非常明显的。
整体上感觉这个设计还是挺好的,在FLASH容量和性能之间取得了一个折衷,是个不错的解决方案。
WCH的设计经常有些类似的惊喜,比如CH552那个200次的iFLASH工艺,可以有效降低成本,200次的FLASH寿命可以满足绝大多数低端产品的需求了。
当然,所有的8051都拉胯,不是CH552的自己的问题,所有对性能有一定追求的场合,8051都是不合适的。代码很简单
while(TRUE)
{
P17=1;
P17=0;
}
//实际编译成汇编以后只有三条指令
//L0: SETB P17
// CLR P17
// SJMP L0
SETB和CLR各需要2个周期,SJMP是5个周期,加起来总共9个周期,16M主频下,最高反转频率不超过2MHz。
各种调试器的TCK频率都会有这个限制,相比之下,USB的速度并不是什么瓶颈。硬件SPI能到8M,不过限制就多了,很多场合用不了,比如有2条SDO信号的地方。CH552实现的各种调试器,只能说能凑合用。
看到一篇不错的分析riscv代码密度的文章:
https://developer.aliyun.com/article/783932
我实测的结果是目前RISC-V和Cortex-M比代码密度差距明显。
GD32F1x0系列,常见的GD32F130和GD32F150,只有前32kB闪存为零等待,32kB往后的非零等待闪存手册中只提了一句话:
从闪存的32K ~ 64K地址空间内取数据有比较长的延迟
对这句话一个严谨的工程师是没法接受的,比较长的延迟?到底多长的延迟算是比较长呢?既然官方没有说明,那我只好自己测试一下了。
测试的目的,主要是判断一下在32kB之后的非零等待闪存中运行代码有没有实用性,对用户选型做一个参考。测试方法使用Dhrystone,和之前对比Cortex-M和RISC-V效率的代码是一样的。
测试芯片为GD32F150C8T6,方法为同一份Dhrystone代码编译的固件放到0x8002000和0x8008000分别运行,测试运行时间。运行主频选择8MHz,通常主频越高,SPI闪存访问效率瓶颈会更明显,所以先用低主频来测试,如果差异不大,再提高主频测试。
# 8MHz零等待闪存O3优化
dhry
Start dhrystone test...
Stopped, elasped time = 38ms 3840
# 8MHz零等待闪存Oz优化
dhry
Start dhrystone test...
Stopped, elasped time = 57ms 5709
# 8MHz非零等待闪存O3优化
dhry
Start dhrystone test...
Stopped, elasped time = 31708ms 26465
# 8MHz非零等待闪存Oz优化
dhry
Start dhrystone test...
Stopped, elasped time = 142337ms 12387
结果汇总如下,注意单位:
8MHz零等待闪存O3优化:38.40ms
8MHz零等待闪存Oz优化:57.09ms
8MHz非零等待闪存O3优化:31.708s
8MHz非零等待闪存Oz优化:142.337s
结果一目了然,非零等待闪存的运行速度低了3个数量级,串口输出都有明显的卡顿,尤其是Oz优化的时候,我一度以为程序是不是死机了?两分多钟以后结果出来了。通常非零等待闪存运行效率的降低如果在一个数量级以内,运行一些对速度要求不高的业务代码还是完全可用的。至于低了3个数量级么,运行代码基本可以判定为不可用,放一点不常访问的数据,或者就当它不存在好了。
众所周知,标准8051只有一个DPTR指针,通过DPTR访问XRAM速度是比较慢的,尤其是从XRAM的一个缓冲区搬数据到另外一个缓冲区,更是雪上加霜。
看到CH55x的头文件了提到了新增的A5指令,配合双DPTR指针,可以快速在XRAM中搬数据,写了段代码测试了下,从XRAM的的一个缓冲区搬255字节到另外一个缓冲区,对比对象是C标准库中的memcpy函数。同时由于CH55x的DPTR支持自增操作,把DPTR自增也作为一个变量一起测试一下。
结论如图:
mempcy函数:420us
A5指令不开自增:128us
A5指令开自增:128us
从测试结果来看,A5指令配合双DPTR速度提高了大约3.3倍,节省的时间还是相当可观的。DPTR自增对运行时间几乎无影响,按说循环中节省了一条INC指令,应该能提高一点速度呀,奇怪。
完整代码如下:
/*
New Instruction: MOVX @DPTR1,A
Instruction Code: 0xA5
Instruction Cycle: 1
Instruction Operation:
step-1. write ACC @DPTR1 into xdata SRAM embedded chip
step-2. increase DPTR1
ASM example:
INC XBUS_AUX
MOV DPTR,#TARGET_ADDR ;DPTR1
DEC XBUS_AUX
MOV DPTR,#SOURCE_ADDR ;DPTR0
MOV R7,#xxH
LOOP: MOVX A,@DPTR ;DPTR0
INC DPTR ;DPTR0, if need
DB 0A5H ;MOVX @DPTR1,A & INC DPTR1
DJNZ R7,LOOP
*/
extern UINT8X Ep1Buffer[];
extern UINT8X syscall_buf[];
BOOL VerifyMemory(void)
{
uint8_t i = 0;
for(i=0; i<0xFF; i++)
{
if(Ep1Buffer[i] != syscall_buf[i])
{
return FALSE;
}
}
return TRUE;
}
void testDualDPTR(void)
{
// memcpy
memset(syscall_buf, 0, 0xFF);
P33 = 1;
memcpy(syscall_buf, Ep1Buffer, 0xFF);
P33 = 0;
if(VerifyMemory())
{
#pragma ASM
SETB P33
NOP
CLR P33
#pragma ENDASM
}
// Dual DPTR without AUTO_INC
memset(syscall_buf, 0, 0xFF);
#pragma ASM
SETB P33
ORL XBUS_AUX, #01H ;DPS=1
MOV DPTR, #syscall_buf ;DPTR1
ANL XBUS_AUX, #0FEH ;DPS=0
MOV DPTR, #Ep1Buffer ;DPTR0
MOV R7,#0FFH
L0: MOVX A, @DPTR ;DPTR0
INC DPTR ;DPTR0++
DB 0A5H ;MOVX @DPTR1,A & INC DPTR1
DJNZ R7, L0
CLR P33
#pragma ENDASM
if(VerifyMemory())
{
#pragma ASM
SETB P33
NOP
CLR P33
#pragma ENDASM
}
// Dual DPTR with AUTO_INC
memset(syscall_buf, 0, 0xFF);
#pragma ASM
SETB P33
ORL XBUS_AUX, #05H ;bDPTR_AUTO_INC=1 DPS=1
MOV DPTR, #syscall_buf ;DPTR1
ANL XBUS_AUX, #0FEH ;DPS=0
MOV DPTR, #Ep1Buffer ;DPTR0
MOV R7,#0FFH
L1: MOVX A, @DPTR ;DPTR0
DB 0A5H ;MOVX @DPTR1,A & INC DPTR1
DJNZ R7, L1
ANL XBUS_AUX, #0FBH ;bDPTR_AUTO_INC=0
CLR P33
#pragma ENDASM
if(VerifyMemory())
{
#pragma ASM
SETB P33
NOP
CLR P33
#pragma ENDASM
}
}
https://github.com/xjtuecho/CH552Nano/tree/main/FW
USB-Blaster固件,调试烧录Altera/AGM的FPGA和CPLD,使用WCHISPTool写入CH552。
测试在我的CH552Nano板子上进行的,当然由于没有什么依赖,别的CH552板子也完全可以。
支持Altera和AGM公司的FPGA和CPLD
支持JTAG和AS两种下载方式
使用MCU内部时钟,运行频率16MHz,无需外部晶振
3.3V供电,IO电平为3.3V
所有IO全部使用到
支持串口命令行
P1.1 板载LED
P1.4 NCS
P1.5 TDI
P1.6 TDO
P1.7 TCK
P3.2 TMS
P3.3 ASDO
P3.4 NCE
JTAG接口只需要连接TCK、TMS、TDI、TDO四个信号
AS接口除了JTAG的四个信号还需要连接ASDO、NCS、NCE三个信号
AG1280Q48下载FLASH需要使用AS接口,NCE信号不接
P3.0和P3.1为UART接口,波特率38400,可以使用超级终端连接
P3.6和P3.7为USB接口
AGM的FPGA和CPLD都用Altera的USB-Blaster下载,实际使用时发现下载AG1280Q48时,_sram.prg文件可以成功下载,但是_hybrid.prg文件无法下载,Supra报
Error: [as_device_id] Configuration device ID not found.
大概意思就是找不到配置器件的ID,查了半天,没有找到原因,最后怀疑到手头这个usb-blaster上。这个usb-blaster于15年购买自淘宝,非常便宜,方案是STM32F101CBT6+HC244。
市面上的usb-blaster方案很多,最早的是FT245+CPLD,性能好,成本低;后来有了cy7c68013方案的,成本低性能也低;再后来就是stm32方案的,成本还是很低,性能上去了。由于Altera的CPLD只需要JTAG,FPGA使用jic文件下载的话,也只需要JTAG接口,很多usb-blaster为了省事就去掉了AS下载功能。
然而AG1280Q48这个芯片的FLASH下载刚好需要使用AS下载功能,使用不支持AS下载的usb-blaster就会导致_hybrid.prg文件下载不进去。
解决方案很简单,自己用STM32F103C8T6做了一个usb-blaster,板子使用BluePill,这个板子非常多,MCU涨价之前也非常便宜。
USB-Blaster固件下载连接:USB-Blaster on BluePill.
在雅特力官方AT-Link v1.4版本基础上对硬件做了一定精简,减少了器件种类和数量, 替换部分不容易购买的物料,同时固件保持完全兼容,方便普通用户DIY。固件可以直接找雅特力申请。工程链接:
https://github.com/xjtuecho/CMSIS-DAP/tree/master/ATLink-Lite
有Gerber文件,已经打样验证过,可以直接去狗创白嫖PCB。
与官方AT-Link v1.4版本对比
MCU引脚分配相同,固件完全通用
阻容二极管全部更换为0805封装,方便焊接,符合JLC的SMT标准
RT9080N-08GJ5电源芯片更换为XC6206P332MR,更容易采购,保留双LDO设计
输出SWD端子更换为直插排针,减少整体长度,本身60mm已经很长了
8M无源5032晶振更换为2脚,更容易焊接
去掉4个2mm定位孔,PCB增加圆角,方便套热缩管
去掉USBLC6-2SC6等ESD器件,现代MCU的抗静电能力已经很强,低价值设备也没必要保护
USB接口的防倒灌二极管更换为500mA自恢复保险丝
按键更换为3x4x2.5小龟仔
ESP8266又一个让人窒息的设计,查找偶尔上电不工作的时候找到的,GPIO0输出26M时钟干扰3.3V电源把USB转串口芯片给干懵了。
使用esptool.py的erase_flash命令将FLASH固件全部擦除,上电,这时候在GPIO0上会输出26M时钟信号.
因为GPIO0默认状态下是通过电阻上拉到3.3V的,这个时钟信号会严重干扰3.3V电源,普通的LDO对这么高频的信号是完全没有调整能力的。
作为对比,按下复位按键以后,GPIO0和3.3V电源都是十分干净的。
像1117这种LDO对于负载的调整能力已经很强了(代价就是静态电流大),即使这样,对于这种26M的干扰完全没有抑制能力,很多ESP8266的文档提到要用500mA的电源,大概率和这个GPIO0上输出的26M时钟信号有关系,3.3V干扰成那样,无论ESP8266自身还是同样挂在3.3V电源上的其它芯片都会受到严重影响。
echo 说:其实SDK已经把底层都给封装好了,底层什么核心并不重要。
RISC-V只出了ESP32-C3一款而已。又出了个 ESP32-H2,BLE + Zigbee
https://www.espressif.com/zh-hans/news/ESP32_H2?position=6&list=2Jmgp20Ks2hwxwuzBiWoW-cyTclWAsDkriUiwY4moV4
这个ESP32-H2目前官网只有个新闻,还没有资料。别看出了这么多型号,还需要时间和市场的验证,能成功的估计不会有几个。ESP8266显然是经过时间和市场的验证了。竞争对手们也没闲着,GD出了个GD32W515,180M的Cortex-M33 内置 2.4G wifi,也想来这个市场分一杯羹。
echo 说:比如?哪个厂的什么产品?
kekemuyu 说:其他厂家并不像乐鑫一样开放,所以我们不了解。国外很多大厂在用
官网: https://www.cadence.com/en_US/home/tools/ip/tensilica-ip/partners.html#siliconservices
貌似都是些RTOS,没有具体的芯片型号
从这个结果来看,GCC实在是太拉胯了。感觉SEGGER在黑GCC。
之前对比了RISC-V和Cortex-M的代码密度,结论是同样功能,RISC-V要多用大约6成的FLASH空间,追求面积优化的应用器件选型时需要注意,那么性能如何呢?本文对比了一下。
测试方法使用Dhrystone 2.1源代码,RISC-V分别和M4,M3核心对比,测试结果如下:
RISC-V芯片,GD32VF103,RV32IMAC核心,8M主频,GCC编译器
-O3优化,实测时间54.39ms
-Os优化,实测时间94.09ms
-Ofast优化,实测时间54.39ms,与-O3完全一样
ARM芯片,GD32F330,Cortex-M4核心,8M主频,AC6编译器
-O3优化,实测时间38.40ms
-Os优化,实测时间39.15ms
-Ofast优化,实测时间38.40ms,与-O3完全一样
-Oz优化,实测时间57.09ms
GD32F103,Cortex-M3核心,8M主频,AC6编译器
-O3优化,实测时间45.92ms
-Os优化,实测时间46.68ms
-Ofast优化,实测时间45.92ms,与-O3完全一样
-Oz优化,实测时间64.88ms
结论:
最大速度优化情况下,RISC-V执行时间是M4的54.39/38.40*100%=141.64%,是M3的54.39/45.92*100%=118.45%。
粗略来看,RISC-V同频性能比M4慢大约4成,比M3大约慢2成。当然这里面肯定有编译器的差距,GCC肯定是要比AC6弱的,这点毋庸置疑。
ARM也有GCC编译器可用,不过大多数ARM用户都是使用ARM的编译器,对比两者在GCC编译器下的表现意义并不大。
还有一点是GD没有提供GCC编译器的startup文件,我也懒得再去自己写了。
echo 说:kekemuyu 说:这样比没有用的,编译器的因素影响太大。都用汇编还好点,不过理论上thum2的代码密度确实比riscv的精简指令要高。
RISC-V目前除了GCC还有其它编译器支持吗?
据说IAR支持了。
https://www.iar.com/products/architectures/risc-v/iar-embedded-workbench-for-risc-v/
In current version of the toolchain, code density is already small comparing to other available tools
看来代码密度确实是RISC-V的大问题,IAR这里 other available tools 指的应该就是GCC。
自己的Xboot工程,在ARM的M0/M3/M4/M23/M33平台下面,全部可以在7kB闪存以内实现,几个架构差异不大,7kB闪存普遍剩余一两百个字节。
最近把它移植到RISC-V上,芯片型号GD32VF103CBT6,同样的一套代码,使用gcc编译,-Os面积优化,固件尺寸11520字节。超过11kB了,速度优化代码尺寸超过16kB。
ARM算7kB,两者对比,7*1024/11520*100%=62.2%,也就是说,同样的功能,Cortex-M只需要RISC-V六成多一点的代码就能实现。
当然还有一个变量要考虑,ARM使用AC6编译,RISC-V使用gcc编译,编译器的效率也会有一定差异。
调试方面RISC-V只能用JTAG(GDLink可以支持),相比之下Cortex-M的SWD调试用起来更方便一些。
至此GD32家的M3/M4/M23/M33/RISC-V五种核心全部盘完了。
目前的V1.8版本有bug,已经给开发者反馈了,目前已经更新到V1.9版本,等我买的下载器到了就可以刷固件测试。
KT6368A的开发者看起来还比较给力,反馈的bug都能修复,如果能把bug修得差不多,我也不想折腾这个芯片了。只见用二次开发的成品就行了。
KT6368A蓝牙芯片使用说明书_V1.8.pdf
补个数据手册,不过是已经做了二次开发的KT6368A的
补充SDK,可以搞起来了。
https://github.com/Jieli-Tech/fw-AC63_BT_SDK
SO-8封装的蓝牙芯片,外围极其简单,价格1.x元。32-bit带FPU的DSP核心,最高160M,支持蓝牙5.1,带USB FS。
已经有人在上面做了二次开发,重新命名为KT6368A,支持蓝牙数传。
当然这芯片继承了很多国产芯片的特点,资料极少,杰理官网找不到资料,CPU是什么核心都不知道,更别说开发环境和SDK了。
不知道开发KT6368A的老板在不在这里。
AC6368A Datasheet V1.0.pdf
所以,开源的资料,无论是代码还是硬件设计资料,指定协议很重要。对发布者和使用者都是一个约束。
比如我开源的PCB就指定了BSD协议,按照协议,倒卖也没问题。
https://oshwhub.com/spadger/bluepill
建议各位发布原创资料的时候,一定要指定协议。使用别人资料,尤其是商业目的,一定要去看一下别人的协议。
我的意思是SPI三线还是四线其实没啥区别,都只能写写寄存器。
我也再明确下我的意思:为啥三线和四线SPI对ILI9488来说没啥差别。
原因就是SPI速度对于320x480分辨率来说速度跟不上,即使硬件SPI+DMA,最高30M,帧率也不会超过10。
而写寄存器,不写显示数据,因为数据量很小,无论IO模拟还是硬件SPI+DMA,都没多大差别,GPIO模拟三线9位SPI就足够了,硬件少拉一根线。
我现在用ILI9488是三线SPI+RGB接口。
相信你肯定对这些很了解的。
借楼再给其他朋友点信息。
三线和四线还是有很大差异的,三线的话,数据是9位,四线数据是8位,对于SPI不支持9位数据位的MCU等,就只能用GPIO模拟。
一般9488如果不是RGB接口,那么硬件SPI直接读写和用GPIO直接读写差异还是很大的。使用并行16位接口,效果也不如RGB效果好。
RGB驱动的话,画面切换没有撕裂,然后不管是用16位MCU总线驱动还是“SPI+DMA”,都能感受到画面的切换过程(我自己项目中是这样)。
对于使用RGB接口,这个“SPI”接口只用来初始化,用GPIO模拟和硬件SPI读写,差不了太多。有的RGB屏可以通过引脚或者寄存器切换比如320*480或者480*320,但是9488不行,只能RGB 320*480,通过寄存器设置成480*320的话,会不能显示完全,有1/3黑屏(如果有哪位知道设置,欢迎告知下)。echo 说:你的意思我理解呀。RGB屏幕就这样,320x480和480x320不一样。
我的意思是SPI三线还是四线其实没啥区别,都只能写写寄存器。
有条件还是用MCU接口,也不会浪费ILI9488内部的GRAM。regbbs 说:我的意思是“SPI”作为初始化,数据还是通过RBG接口,但是设置横屏模式,刷新不正常,不能全屏显示。要想当作480X320的分辨率用,只能软件实现。
CTO丁总是是我交校友,上周见了个业内大佬是他同学。
echo 说:居然有西安的职位,难得。刚刚看到个新闻。
http://ele.xjtu.edu.cn/info/1031/1388.htm西安是我们总部外最大的研发中心,欢迎西安的伙伴加入!
你的意思我理解呀。RGB屏幕就这样,320x480和480x320不一样。
我的意思是SPI三线还是四线其实没啥区别,都只能写写寄存器。
有条件还是用MCU接口,也不会浪费ILI9488内部的GRAM。
我的意思是“SPI”作为初始化,数据还是通过RBG接口,但是设置横屏模式,刷新不正常,不能全屏显示。要想当作480X320的分辨率用,只能软件实现。
echo 说:分辨率320x480,这个分辨率用SPI刷数据搞不定,即使30帧16位色,320*480*16*30/1e6=73.7M,实际ILI9488的SCL最高频率到不了这个频率的一半。
所以3线9位,还是4线SPI其实都没啥差别,都是写寄存器用的,对速度没要求,用软件模拟就行了。regbbs 说:产品用这个屏,确实很坑。
RGB模式下没法硬件上横屏,只能软件转换XY坐标。一般都会引出所谓的“SPI”接口,其实是伪SPI,如果是三线模式就比较坑,很可能得用MCU的GPIO模拟,四线模式的话,就可以用硬件SPI接口连接了。
即使用RGB模式,也要用“SPI”接口初始化很多寄存器才可以正常用。初始化代码可以找厂家提供,主要是看需要初始化的寄存器值,然后转换成自己的读写函数。
居然有西安的职位,难得。刚刚看到个新闻。
http://ele.xjtu.edu.cn/info/1031/1388.htm
分辨率320x480,这个分辨率用SPI刷数据搞不定,即使30帧16位色,320*480*16*30/1e6=73.7M,实际ILI9488的SCL最高频率到不了这个频率的一半。
所以3线9位,还是4线SPI其实都没啥差别,都是写寄存器用的,对速度没要求,用软件模拟就行了。
产品用这个屏,确实很坑。
RGB模式下没法硬件上横屏,只能软件转换XY坐标。一般都会引出所谓的“SPI”接口,其实是伪SPI,如果是三线模式就比较坑,很可能得用MCU的GPIO模拟,四线模式的话,就可以用硬件SPI接口连接了。
即使用RGB模式,也要用“SPI”接口初始化很多寄存器才可以正常用。初始化代码可以找厂家提供,主要是看需要初始化的寄存器值,然后转换成自己的读写函数。
看了下你的代码,解决了我的ILI9488颜色分量R和B相反的疑问。
/* Memory Data Access Control */
LCD_SPI_WriteByte(0x36,LCD_CMD);
LCD_SPI_WriteByte(0x08,LCD_DATA); //反人类的ST7789……RGB总线居然默认是BGR格式
ILI9488和ST7789一样反人类,默认是BGR格式。
感谢。
https://whycan.com/t_5652.html
我之前搞过个类似的屏,我的spi直接强行复用了rgb的数据引脚。你可以设置成rgb666然后只接rgb565,把多余的几个引脚接地就行了,或者刚好复用成软件spi。
我这个屏SPI和RGB接口是独立的管脚。目前测试无论是RGB565模式16位使用DB[15:0],还是RGB666模式18位使用DB[17:0],
用3线SPI接口初始化以后再用RGB接口都没问题了。
不过有一个很奇葩的问题:实测颜色分量R和B和文档上的描述是反着的。
无论18位还是16位模式下,手册上都是红色R在高位DB[15:11],蓝色B在低位DB[4:0],
但是实际测试刚好反过来,蓝色B在高位[15:11],红色R在低位DB[4:0]。
不知道有没有朋友遇到类似问题。
https://whycan.com/t_5652.html
我之前搞过个类似的屏,我的spi直接强行复用了rgb的数据引脚。你可以设置成rgb666然后只接rgb565,把多余的几个引脚接地就行了,或者刚好复用成软件spi。
使用ILI9488控制器的LCD屏,比如TM035PDHG03,感觉很多坑呀。
通过IM2 IM1 IM0三个管脚,只能选择出I80和SPI接口,扒了很久ILI9488的datasheet,发现如果要使用RGB接口,要写ILI9488的寄存器,而RGB接口又不能写寄存器,那么,要再接I80或者SPI接口?
I80占用管较多,连一个三线的SPI接口来写寄存器可能更容易一些,用RGB接口还得额外再连一个SPI,为啥不直接用SPI?穿上裤子放P的感觉。
搜到一个文章:
https://www.eefocus.com/max_huayu/blog/13-03/291938_35e2e.html
提到即使用RGB565模式,主控要设置为RGB888,ILI9488要设置为RGB666模式,更是感觉莫名其妙。
echo 说:JTAG线也不是很多,自己杜邦线连一下也不麻烦。
我这边ARM的器件比较全,M0 M3 M4 M23都有,GD32的ARM芯片几乎所有型号都有。
RISC-V芯片比如VF103价格没有优势的前提下,实在找不到考虑它的理由。
调试方面,我基本只用USB和UART,其实SWD都很少用。metro 说:不是的,GD32VF103(注意不是GD32F103)是RISC-V的CPU,不支持SWD,只支持四线的JTAG协议,所以要调试的话需要从两个地方都接出来,不是很方便。
至于CH32V103,沁恒实现了和SWD相似的RVSWD(只是引脚相同,协议应该不兼容),所以倒是不像GD32VF103那样有这个问题。不过看起来CH32V103在协议没公开之前只能用他家的调试器了。
话说GD32VF103的接口定义可以参考Sipeed Longan RV,两面共引出2x4p的2.54mm接口,不过接口稳定性堪忧,我的那块板子就被我把焊盘弄掉了是的,现在新出的单片机很多都不支持JTAG,没记错的话GD32F系列也是全员不支持JTAG。RISC-V可能是个问题,因为没有占优势的两线协议,很多厂商还在用着四线JTAG。
至于价格,我记得CH32V103应该还不错(某宝上小于5块?),只不过去年才发布,用的人还不多。
小于5块没啥优势呀,小于3块的话就考虑用它。感觉ARM核换了RISC-V核并没有降低什么成本。
JTAG线也不是很多,自己杜邦线连一下也不麻烦。
我这边ARM的器件比较全,M0 M3 M4 M23都有,GD32的ARM芯片几乎所有型号都有。
RISC-V芯片比如VF103价格没有优势的前提下,实在找不到考虑它的理由。
调试方面,我基本只用USB和UART,其实SWD都很少用。
echo 说:所有IO都引出了呀。
话说JTAG现在还有人用么?我这里无论板子还是调试器,JTAG都拿掉了,只留SWD,管脚少就是好。metro 说:感觉应该也兼容CH32V103?另外GD32VF103的调试口是JTAG,好像不是很方便,可以考虑引出JTAG的所有接口。
不是的,GD32VF103(注意不是GD32F103)是RISC-V的CPU,不支持SWD,只支持四线的JTAG协议,所以要调试的话需要从两个地方都接出来,不是很方便。
至于CH32V103,沁恒实现了和SWD相似的RVSWD(只是引脚相同,协议应该不兼容),所以倒是不像GD32VF103那样有这个问题。不过看起来CH32V103在协议没公开之前只能用他家的调试器了。
话说GD32VF103的接口定义可以参考Sipeed Longan RV,两面共引出2x4p的2.54mm接口,不过接口稳定性堪忧,我的那块板子就被我把焊盘弄掉了
熟悉lceda的过程中做的,做完就放在他们的开源平台上了,已经打板验证,项目主页:
https://oshwhub.com/spadger/bluepill
著名的BluePill开发板改进版本,兼容绝大多数LQFP-48封装的ARM/RISC-V MCU 相比市面上其它版本,管脚完全兼容,可靠性更高,成本更低。
LQFP-48封装的STM32/GD32开发板,包括但不限于以下型号:
STM32F103C8T6
STM32F030C8T6
GD32F103C8T6
GD32F130C8T6
GD32F150C8T6
GD32F330C8T6
GD32E103C8T6
GD32E230C8T6
GD32VF103C8T6
这些型号管脚排列都是兼容的,都可以使用这个开发板。
相比市面上其他版本改进如下:
USB更换为直插MicroUSB,结实耐用
BOOT0选择更换为按键,按住BOOT0再按NRST即可进入内置Bootloader。
32.768晶振更换为3x8封装,默认不焊接
VBAT管脚使用0R电阻连接板载3.3V电源
SWD接口顺序改为CLK、DIO、GND、3V3
开源资料离线下载链接。
BluePill_v20.12.24.7z
感谢。就是这个接口。顺便吐槽一下厂家,你们卖屏,为了防止白嫖,购买后提供详细资料可以理解。
datasheet这种东西难道不应该直接挂在产品介绍里面么?像物理尺寸、接口定义、端子型号这些基础信息遮遮掩掩不知道意义在哪里。
型号T5: http://www.dwin.com.cn/home/Index/t
1T 增强型8051,最高速度600MHz,双核。
T5L降低了频率到350M,不过也很高了。
一般市面上的8051产品频率都是几十MHz而已,迪文这个600M的8051咋回事?还有它的FLASH也SRAM都超过1MB,远远超过8051的64kB寻址空间。
感觉很奇葩,像是给拖拉机装最新的涡轮增压发动机。
摘要:N76E003的TA保护机制在尺寸优化下开9级优化必然出bug
N76E003的寄存器的TA保护机制造成代码中有很多的
TA=0xAA;
TA=0x55;
REG=VAL;
这样的代码,如果选择尺寸优化Favor size,然后优化Level选择:9:Common Block Subroutines,优化器会将对TA的连续0xAA,0x55赋值优化成一个函数多次调用,导致TA保护寄存器写失败。
优化器也很委屈:新唐你真不地道,光给我挖坑了。
如果和TI的EALLOW保护机制一样,TA=0xAA关闭保护,TA=0x55打开保护就行了。或者每次写入的数据不是固定的0xAA和0x55,也可以避免给优化器挖坑。
不过这些都要重新流片,实现起来不现实,只能不用9级优化了。
这个编程器非常便宜,价格7.x元包邮。到手简单测试了一下,说一下问题,希望设计者能看到。
首先看第一张图,烧写25系列FLASH,抓的SCLK上的波形,观察可以发现,高电平是5V,众所周知,大部分25系列的SPI FLASH都是3.3V或者更低电平,而且IO并不能耐受5V。
看SCLK的频率是12M,也就是CH552G运行频率为最高的24M,这个频率只能在5V的VCC下才能达到,3.3V的VCC最高频率是16M。
再看下面两张波形,写入一个字节,耗时4.76us,但是这中间的4.04us(接近85%),SCLK波形都是空闲的,这是MCU在搬运代码,毕竟是8051,速度相比SPI来说还是太慢了。
SCLK的频率不是速度的决定因素,12M还是8M,对整体的速度影响不大。
众所周知,3.3V电平是可以直接兼容5V的,所以最好是把VCC电压改成3.3V,CH552G主频降低到16M,SPI时钟8M,这样设计更合理。现在的版本5V电平直接强推3.3V IO实在是太粗鲁了。
页次: 1