StackYuan
StackYuan
This guy hasn't written anything yet

注册于 2 years ago

回答
101
文章
2
关注者
1

显示应该是可以显示,但是SPI协议就不一定支持了,你对照下看看,如果少pin了就可能不支持了

问题出在你的SPI_CS逻辑上:
首先74HC165不是严格意义上的SPI设备,应该遵从74芯片的数据手册去看。
image.png

注意荧光标记的地方,如果CS拉低去做移位采集,看看逻辑是不是和你现在的一样。
故应该按照手册,在CS拉高后采集。
如果你觉得我的说法正确,请记得采纳此答案!

AP6212内封BCM/CYG43438 博通/赛普拉斯官方有跨平台的wiced方案,在github上是有相关资料的,建议去找下。

如果你认为是时钟影响了网络通信,那就重点排查下网络接口的MCLK时钟链是否合理。

这个值一看就是个地址,代表着该线程已经创建了

    rtgui_object_set_event_handler(RTGUI_OBJECT(main_win), dc_event_handler);
    rtgui_win_show(main_win, RT_FALSE);

    rtgui_app_run(app);
    rtgui_win_destroy(main_win);
    rtgui_app_destroy(app);

看到你在show之后就直接destroy销毁线程了,这部分是否有问题

文件续写在open之后使用seek,到你指定的文件指针位置

抽空帮你看了下刚刚那个TXT,可以确诊了:
1.你所有的打印行结束都是NUL,就是0x00,这个是不合理的,应该改为0x20(空格)或者0x0d(\n) 0x0A(\r)等。
2.utf-8字符编码集中有对首字节0x00的释义,记事本默认以UTF-8的编码字符集去解读,遇到你的0x00必然会以UTF-8的扩展字符去解析。
3.编码问题多思考,拿winhex之类的hexdump工具一看就了然

你如果觉得这个回答有用,那就请采纳我的答案

问题出在SDRAM上,屏幕只是诱因:
1.检查SDRAM布线和退耦合、信号回流路径等布局合理性,可以参考其他板子,如art-pi。
2.如果屏幕一开 SDRAM就出现失效问题,硬件上检查屏幕信号是否可能存在相邻SDRAM信号耦合风险,软件上可以把SDRAM的IO驱动力提高一些,HAL中改到high_speed 或者 very_high_speed,配合示波器观察波形情况,找最好的那一档。

还好有对照组可供参考,能够省很多事情。。
1.用DFU方式下载个正常固件,看串口能不能跑起来(uart4对应的stlink虚拟串口)。
2.把stcubeprogrammer升级到最新,再次升级故障板的stlink固件。
3.DFU方式如果已经正常跑起来了,按道理,stlink是可以通过SWD捕获MCU状态的.
4.可以一键把stlink更新为jlink,死马当活马医一下。
5.联系售后。。

纳秒级的延时一定是要依托超高精度硬件定时器+高速中断响应机制完成的,这两个因素天生决定了能低至多少ns。在通用arm处理器上很少能见到低至20ns指征的响应速率。

这个不影响,mdk会以来头文件做预加载提示错误,但不意味着在编译器层级它是错的。同时,某些场景为了防止耦合,不能方便地加上这些头文件。

可以插摄像头,它预留了一组并行总线,如果没有DCMI接口,可以使用并行总线模拟协议

常规做法是,在flash状态相对于MCU状态不同步时:比如MCU重启,QSPI flash依然保持初始化后的QSPI模式上。遇到这类情况时,应该首先退出QSPI mode,一般是单线模式下连续发送两个0xff,具体看对应的手册。然后再按照常规方法复位flash并初始化到对应模式。

原子的屏幕有不同批次的,不一定是GT9147,需要注意下,art-pi官方链接里是有这个Q&A说明的。

spi框架已经报错了transfer error,看看是哪边驱动没对接好吧

回到
顶部

发布
问题

投诉
建议