页次: 1
AGM的还可以。安路的,把你查得底朝天,最后要买芯片,还要求上门看项目情况。像求他们一样。
安路没用过,不评论。AGM我个人比较鄙视,直接套用Altera的工具链,节操不知道去哪了。
别跟xxx32比,好歹xxx32还不涉及专利侵权,Altera的比特流和IP是有知识产权的。一个是不讲究,另一个干脆就是侵权。
复旦微也是一比一克隆,你也买不到,这个是国家队搞的高端赛灵思克隆,不是民品。
紫光没用过,貌似做的是百kLUT级别的产品,我也用不到。
高云的产品我几乎每个产品线都用过,算是比较熟悉了。高管是Lattice出来的,核心架构和ECP3/5极其相似,外设和IP都是自研的。
趁下班时间画了一版,大家猜猜这是什么方案😏
https://whycan.com/files/members/1510/AQUA-Lite.png
这是要用PIO做USB PHY?也就是只能测FS/LS咯?
最近在CNX看到这个芯片的讨论,老外怀疑这个ARM版权是有问题的,可能涉及ARM中国和ARM总部之前的争议。这样,使用这个芯片会有版权风险或者以后涨价的风险。
大家怎么看?
版权?啥版权?要严格讲,中国没有合规的东西。你用的钢铁铝铜,哪个采矿工程研发和矿石处理流程是百分百正版?
只要从中国出去的东西都包含大量的盗版,有本事老外别买。之前老外不接受GD32,后来STM32涨价,老外像苍蝇看到屎一样都来了。
涨价是有可能的,但是中国人嘛,自有办法。PY被老外告了,PY官方涨价包含版费,第二天PY就把晶圆拿出去开个小号卖。
一个说不清道不明还花了钱的M0算啥,国产复杂一点的大芯片里面某个对外不开放的深度嵌入式核里面用盗版A7/A53的都有。
更有甚者,国家队搞的军用FPGA里面还有直接从台积电里面安排人偷出来的版图,改了改模拟IP,躲过黑IP检测算法,台积电一样给生产。
看代码编号,后面会陆续做性能裁剪去推P1-2-3?这颗国内竞品BL808还带wifi,考虑乐鑫一直在转型往国外发展,国外对标stm32FH7,竞争力就相当不错了?
国内确实恼火啊,各种拿着政府补贴的准国家队,国网,移动啥的都在搞多核RV神U,价格卷的私企根本玩不动。
深制程开发最贵的就是mask,国家队研发成本都是有补贴的,几百上千万的流片成本都是国家报销。
所以国家队都搞28nm,22nm这种先进工艺,时序和面积成本就不是私企搞的什么55nm,40nm能比的。
另外就是杰理这种高配低价,BSP不完善,但是代理商帮你移植的公司,你乐鑫陪客户搞好了,人家订单截胡了。
最后发现跟中国人做买卖怎么都算不过,不如去做国外了。
关于BL808,这个芯片我看有前途。ESP8266就是Sipeed团队搞火的(那时候是安信可,后来分家了),现在BL也在搞一样的模式。
关于H7,我没拿到P4,不好说,但是双核LX6干不过H7,最起码不搞汇编优化的话,光靠编译器优化是不行的。
LX6潜力很大,但是Tensilica在GCC上花的钱和ARM差好几个数量级。CPU设计不错,但是优化跟不上。RV应该能好一点。
Tensilica卖收费的编译器,最早是自研的,后来是改的LLVM,都是闭源的。GCC人家一开始就没当亲儿子。
至于乐鑫是怎么用单核80MHz跑WiFi SDR的,人家是手写的汇编,把各种优化都手工搞了,所以那玩意不开源,给你的是个.a文件。
@Blueskull
这个HAL版权纠纷能否展开讲讲?据我所知GD32没有HAL库,早期他们的标准库和STM32很像,现在的新库完全不像了。
至于管脚排列兼容,这个应该不构成侵权。
早期STM32的驱动库是开源但不自由的版权协议,用了STM32的驱动库就得配ST的芯片。GD宣传二进制兼容,就等于教唆用户使用盗版STM32驱动库。
当然GD也发现问题了,之前很多欧美客户找国内ODM,点名不用GD32,所以GD自己搞了自己的库,而且第三方的libopencm3也出来了。
后来STM32的驱动库改成自由版权协议了,应该就是为了让野鸡MCU打压GD的市场份额,和纵连横。
今天测试了一下py32f003L18S6的串口,发现这个芯片功耗控制的挺好的。因为是用usb功率计,粗略计算基本和手册一直一致。
https://whycan.com/files/members/1315/Screenshot2022-11-02002844.png
“数据基于考核结果”
这是赤裸裸地机翻英文手册中的“Data based on characterization, not 100% tested.”。
这帮人这么懒的吗?难道让工程师用人话写一遍这么难?
@Blueskull
感谢大佬科普外行纯好奇,我看这里的ch552核心图,
https://www.richis-lab.de/CH55x.htm
里面提到核心1.8x1.5mm。这芯片adc才8位,功能也简单。为啥面积比起1mm2大那么多?
CH552是180nm工艺,而且存储器是MTP,比flash的cell密度低,但是mask数少
@Blueskull
请教大神,“Mask开一套算2M人民币”,是说 200万元人民币吗?
就是说,做一套模具要 200万元。然后这套模具能用多少次?再者,55nm 的 12英寸晶圆,制造费用是 50000*0.15元 = 7500元?
是这样吗?
1. 是的,具体价格看你的金属布线层数以及mask shop报价,比如你找tsmc给你做mask就比找第三方贵
2. 无限次,但是mask分两种,MLM和full mask,MLM mask便宜,但是光刻成本高,适合中批量(以前,现在fab厂很少陪你玩MLM了,不缺订单),full mask贵,但是光刻成本低
3. 差不多,40nm到90nm价格差不多,都是一样的二代DUV机台,你可以按照0.25到0.3人民币每平方毫米算,14nm到28nm差不多0.4到0.5人民币,这是大陆fab价格,umc之流台湾二线fab要贵20%,tsmc要再贵20%,国外fab价格可能要翻几番了
上海好多MCU公司啊,很多都是低端MCU。我在想怎么养得活员工的,房价都十万了,坐标张江
还有很多利润呢。55nm工艺,如果模拟性能拉稀一点,ADC/OSC掺点水,这个MCU完全可以做到1个平方毫米以下,也就是一个十二寸片出来5w+颗。这么算成本才一毛五钱左右。封装编带再算五分钱,税钱找政府补助,那也就是两毛钱成本。
这玩意研发没啥成本,CPU一片授权费几分钱,其他模拟/存储IP加起来也就是几分钱,数字IP国产单片机大多数用的是盗版Synopsys的DesignWare,S也不管,反正买了人家的基础EDA他们就默许盗版高级EDA和IP了。
算上上面说的IP,实际上制造成本也就三毛钱。Mask开一套算2M人民币,如果能卖10M片,摊下来就是两毛钱,所以总成本就是五毛钱。在国内这种互相卷死对方的环境里面,17%毛利率已经算不错了,毕竟量大。找好几家大腿,每月每款KK级别出货不是梦。而且有些卷王,比如沁恒,CPU是自研的,NVM是自研的,那就完全没有IP成本,还能少一毛钱。
If you don't speak Chinese, just post in English. It's harder to guess what you meant after it has been translated improperly.
Now to your original question, put it simple, no. ARM cores are not only copyrighted, but have their instruction set patented, meaning no one can implement an ARM core until the instruction set patent has expired (and make money).
Also, ARM9 is not a small core. It takes a lot of logic resource to implement and a lot of human labor to optimize on a given FPGA architecture to a usable timing (after all people anticipate a few hundreds of MHz on an ARM9 core).
So put it simple, you only get FPGAs with hard core ARM9 (or any application class cores) IPs. You might find smaller cores like Cortex M0 or M1 in soft core form, but never something like ARM9.
HiFi4就是Xtensa加一些扩展,gcc-xtensa都支持,但是具体启用哪一个需要自己配置,魔改ESP32编译器就好。
国外大神已经通过crosstools-ng搞出来了。
Rev 4已更新,本版本增加了1个可变电压IO口和一个5V IO口,去掉了1个3.3V IO口,并去掉了动态更改5V IO方向的能力。
本版本5V IO方向可在烧录PMIC固件是更改,也可通过I2C在MCU里更改,该部分代码尚未实现。
本版本将LGA焊盘改为BGA焊盘以改善焊接良率及可靠性,同时微调RC器件参数以增强系统稳定性并减少贴片成本。
本版本增加了USB双缓冲和TCK恒定时钟输出功能,用以实现高速下载以及FPGA Flash编程(固件已实现,上位机尚未实现)。
本版本增加了VBUS分压器开关,因此VBUS分压电阻在不读取VBUS电压时不消耗功率,从而减少待机功耗。
本版本将上位机软件从Python移植至NodeJS(错误的决定,未来还会移植回Python),并重构了USB底层API。
https://github.com/blueskull/PicoGate
https://github.com/blueskull/CH552-JTAG
本坑已填,硬件除非有明显bug,否则不会更新。软件会继续添加功能。
同时,硬件开新坑,基于ESP8685的无线GW1NZ核心板,板载ESP的所有可用ADC+GW1NZ的所有可用IO+PMIC的若干路5V IO。敬请期待。
可能需要翻墙,或者你家网络太差。不同地区,不同运营商墙的东西不完全一样。
EEPROM的问题,我的板子没有FT2232H,所以没有EEPROM。我是用CH552做的下载桥,下一代准备换ESP8285或者ESP8685。
已经收到板子, 只是有个疑问,
https://whycan.com/files/members/7773/mangopi-d1s.png图中送的小排针做什么用的?
盲猜是串口,让你焊接串口线的。
https://dl.sipeed.com/shareURL/MaixII/MaixII-Dock/SDK/Toolchain
{"code":-1,"msg":"error"}不知是否我被牆了
重试一下看看。我刚试了一下也是error,刷新就好了。
@Blueskull
ep4ce10都涨到400了,想找家国产的替代,不知道哪家靠谱
小容量的都靠谱,都是抄的国外成熟的核心技术(高云和AGM高管部分是Lattice出来的)配上自己的外围。
大容量的复旦微有,几百kLUT的都有,一比一抄的Virtex,但是有些黑盒IP要改,全白盒IP可以pin-to-pin直接换。
纯国产技术的(紫光?)没用过,不了解。
10kLUT可以看看高云的18kLUT产品GW2A-LV18,实际上有21.5kLUT。但是高云的逻辑门慢一些,可能时序不满足。
同一代产品,Xilinx最快,Intel次之,再下面高云和AGM,Lattice略慢一点垫底。
@echo
按照1个闪存字节7.2um2计算(格罗方得55nm,比较先进的闪存单片机标配工艺),批量3毛钱每mm2算,每1块钱可以买452kB的片上闪存。
按照一个小型嵌入式系统使用32kB闪存,armcc能节省1/3计算,每一台产品可以节约0.0236元,约合0.0036美金。
按照一套armcc授权3000美金计算,研发团队需要三人同时使用软件,则armcc的软件成本需要销售2.5kk台产品才能赚回来。
我很难想象什么普通公司能卖出去2.5kk台产品,哪怕什么产品都加起来。
另外arm核心也不是免费的,换用廉价的rv核心,很可能单单是授权费就能把闪存和ram的钱赚回来。
arm有专利,你用了就要交钱,就算你自己做出来了ip实现也得交专利费。
rv没有专利,虽然具体的设计ip核还要买,但是这个价格可以内卷。你卖一分我卖一厘,别人为了上市融资还可以亏本白送。
所以我还是认为在未来,rv从成本上是有优势而且势不可挡的。
arm的m系列我感觉时候不多了,r系列也会慢慢被蚕食,真正有竞争力的是a系列,就像intel/amd不做单片机一样。
kekemuyu 说:看到一篇不错的分析riscv代码密度的文章:
https://developer.aliyun.com/article/783932我实测的结果是目前RISC-V和Cortex-M比代码密度差距明显。
你那个测试是基于arm@armcc和rv@gcc的吧。那个本来就是不公平的,arm有自家开发工具的加成。
试试都用gcc和自带的libc,rv开启c扩展,应该还是有差距,但是很小。
If you are looking for a solution with D1, maybe you can talk to the people at Sipeed. They are the official sales outlet of Allwinner's D1 EVK outside the country (through Seeed Studio, they themselves handle tech support and a good part of the development of that board).
Sipeed started as a dev kit manufacturer, but now is focusing on solutions. I think you can have a wonderful collaboration with them.
FYI, D1 is designed to run Linux. I don't know if anyone has a working non-Linux BSP at all. If you do not want to reinvent all wheels, I'd suggest either you talk to someone who has intimate knowledge of the chip and its BSP, so that he or she can easily port the drivers to whatever OS you choose, or just use an MCU, not an MPU at all.
Don't know why it has to be SDIO, but if you just want to bridge Ethernet to an FPGA, consider using SPI. There are a lot of MCUs that have both an Ethernet MAC, sometimes even a PHY, and a fast SPI port. Take no more look other than ESP32, the most widely used IoT chip in the hobby, and you will find that it has all, even SDIO (though I'd avoid it due to patent issues).
Oh, BTW, the founder and owner of Sipeed also founded AI-Thinker, the company that propelled Espressif to what it is from just another discreet Chinese IoT chip manufacturer. If you want an ESP32 consultant, consider no more than her or her husband, a genius on chip designing, the designer of K210, and he "casually" designs 14nm chips at home.
Disclaimer: I know the people behind Sipeed well, though I do not work there nor do I get paid for promoting their services.
@echo
对复制到非DPTR,比如外设,有用啊。
比如考虑如下场景:
__xdata uint8_t *buf;
int len;
while(len--)
{
SPI0_DATA=*buf++;
while(!S0_FREE);
}
这个代码可以优化成:
XBUS_AUX=0x00; // Select DPTR0
SAFE_MOD=*buf; // Load DPTR addresses from xdata pointer
SAFE_MOD=0x00; // Prevent 0x55, 0xaa patterns
XBUS_AUX=0x04; // Select DPTR0 and enable auto increment
while(len--)
{
__asm("movx @a, DPTR");
__asm("mov SPI0_DATA, @a");
while(!S0_FREE);
}
XBUS_AUX=0x00; // Disable DPTR auto increment
速度确实会快很多(SDCC操作DPTR默认每次都加载DPTR寄存器,非常保守,但是非常低效),但是每隔几百KB就会错乱一次,SPI收到的数据和USB发过来的对不上。
@saub
啥时候我成倒腾芯片的了?我一个做电源模块开发的,嵌入式就是做着玩玩。我就是看不惯你们这帮白嫖怪,啥都要白嫖。
顺便说一下,A78以前的ARM核现在不要国外授权了,ARM中国和ARM母公司干掰了。
现在ARM中国独立运营。卖了IP还要给母公司分成,但是卖谁怎么卖已经是中国人说了算了。
我玩F1C200S的时候XBOOT只有F1C100S的BSP,F1C200S的LD文件和内存初始化要自己稿。最后我搞出来了个1秒进UI的超级精简版。
我玩GD32F350的时候全网找不到GCC的BSP,整个BSP从start.s,LD文件到libc底层函数全是我手写的。现在全网应该也只有我那一份GCC的BSP。
我玩CH552的时候SDCC的BSP只有头文件,所有外设驱动都要手写,而且手册里面还偶尔有坑。现在我有全网吞吐率最高的CH552 JTAG桥。
玩个3352还玩出优越感了,我真是服了。我玩3358的时候内核还是3.x的版本,我读书的时候还拿3358作了个课程设计。
手册不是说能跑到24mhz吗
5V下可以,3.3V只能16MHz。
能否将spi设在4mhz 用nop调延时让实际速率略低于4mhz 这样输出时钟比较均匀 更利于连长线
可以。这个取决于用户需求。我的nop是宏定义的,要几个给几个。SPI降频,nop数跟着降就好了。
我现在没有做环形缓冲,也没有做USB分包,现在是一个USB数据包是一条指令,如果作了分包,就可以高效地发超长或者超短包了。到时候USB利用率还能提升。另外,我现在指令数据没有分离,所以协议需要解析才能发送。以后开个新的端点,只负责SPI数据,带宽还能提升。
但是我不想搞了,等什么时候速度不够了我再弄吧。
这单片机频率有的超么 还是跟usb绑定的
速度是受CPU限制的。这个单片机不支持DMA到其他外设,只有USB能DMA。所以USB DMA进来的数据需要使用CPU拷贝到SPI里面,这个是最浪费时间的部分。
因为8051只能寻址256字节idata内存,额外的数据(USB buffer)要放到xdata内存里面,因此需要DPTR操作,这个最费时间。
一个连续地址DPTR操作需要完成五件事,写入DPH,写入DPL,读取数据到ACC,从ACC读取数据到实际目的地,自增DPL。
因为我用的免费编译器SDCC优化不是特别好,我怀疑它没有对这部分进行优化。
如果手写汇编或者使用商业编译器,只要我的数据在一个256字节的页里面,DPH只要写一次,不需要每次都写。
同理,CH552支持DPL自增,每次读取他会自动加一,因此DPL也不用每次读取都自增然后写入。这三个指令优化掉了应该会再快一点。
“公司的知识产权协议允许我拥有工作中开发的工具的知识产权”
什么高大上的公司竟然允许这样
甲方工作中为乙方产生的可交付直接结果,例如按照客户要求或内部立项要求所研发的电路拓扑、电路原理图、电路板版图、集成电路版图等,和上述结果的中间过程结果,例如上述结果在迭代过程中产生的中间版本,其知识产权归乙方所有。甲方在产生上述结果的过程中所开发之工具,例如EDA软件、仿真软件、测试方案及软硬件等,其知识产权归甲方所有,并授予乙方无条件的、永久的、免费的使用权。
这是我的合同里面的原文。大老板完全OK,秒同意,但是下面的法务有点顾虑。这个版本是和HR和法务拉锯战谈判下来的产物。
最近工作需要调一大堆PWM发波电路,每一块实验板都要画FPGA,JTAG桥和PMIC,遂心生一计,何不把我每次都重复的部分单独拉出来,搞个核心板封起来当IC用?
基于这个想法,我开发了一块尺寸仅9.5mm*10.5mm的核心板,集成上述功能,外部连上供电就能跑,连上USB还能下载程序或模拟SPI主机和FPGA通信。
因为公司的知识产权协议允许我拥有工作中开发的工具的知识产权,遂将这个项目开源出来,和大家分享。
传送门: https://github.com/blueskull/PicoGate
固件见我之前的USB-JTAG项目,支持SRAM下载,很短的未来里会新增功能,尤其是FLASH下载。敬请期待。
R0->R6, R1->R7这种接法在0x00~0x3f范围内的累积误差最小。
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#define EIEO // Extreme input, extreme output, 0x00->0x00, 0x3F->0xFF
uint8_t makeByte(uint8_t in, int b0Mode, int b1Mode)
{
uint8_t out=in<<2;
if(b0Mode==0) ; // b0=0
else if(b0Mode==1) out|=0x01; // b0=1
else if(b0Mode<=7) out|=(out>>b0Mode)&0x01; // b0=b_b0Mode
else {printf("Invalid input.\n"); exit(1);}
if(b1Mode==0) ; // b1=0
else if(b1Mode==1) out|=0x02; // b1=1;
else if(b1Mode<=7) out|=((out>>b1Mode)&0x01)<<1; // b1=b_b1Mode
else {printf("Invalid input.\n"); exit(1);}
return out;
}
int main()
{
int i, j, k;
int err;
int errsum[8][8];
unsigned int errmin=-1;
for(i=0;i<8;i++) // Scan b0Mode
for(j=0;j<8;j++) // Scan b1Mode
{
#ifdef EIEO
if(makeByte(0x00, i, j)!=0x00) // Zero input zero output
continue;
if(makeByte(0x3f, i, j)!=0xff) // Max input max output
continue;
#endif
errsum[i][j]=0;
for(k=0;k<64;k++) // Scan input value
{
uint8_t out=makeByte(k, i, j);
float diff=k/63.0*255-out;
if(diff<0) diff=-diff;
err=(int)(diff+0.5);
errsum[i][j]+=err;
}
if(errsum[i][j]<errmin) errmin=errsum[i][j];
}
for(i=0;i<8;i++)
for(j=0;j<8;j++)
if(errsum[i][j]==errmin) printf("Minimum error %d reached at b0Mode=%d, b1Mode=%d.\n", errsum[i][j], i, j);
return 0;
}
刚写了个程序验证过了。
https://www.bantamtools.com/cnc-milling-machine
4000美金+500美金国际运费,加上16%增值税和25%惩罚性关税,大概4w2,你想做的都能实现。或者邮到香港自己人肉带回来,2w9,一个拉杆箱应该能装下,这个机器很小的。
and those fees do not include VAT (+20 %) … On the top of this DHL Express demands – original Chinese invoices with wet stamp. In your opinion, how many seller on Taobao issue such?
My condolences to your situation. Blame the EU bureaucrats, not us. I never had issues shipping to or from the US, and I lived both here and there for extended periods. Probably that's why the EU doesn't have as strong economy.
Since the Chinese government does nothing about the raised issues, what one can do?
International purchase is not protected in the first place. Not happy with this? Don't buy internationally, or buy from companies known to do well on international orders. I happen to be close friends with a leading Chinese open source hardware startup that made its way to Mouser. If you started this thread with an attitude to solve problems rather than like this, I might offer some of my resources.
For example, filing a report to the Chinese police requires a Chinese ID number …
I happen to be a PI to a few students, one being Pakistani. Weird though, he doesn't seem to have problems dealing with the government. No ID? Use your passport! There are as many foreigners living in China as the population of a small European country. How did they get around here?
In Bulgaria we had one businessmen, a billionaire ... his companies were not paying taxes – more that 250M EUR for 5 years …
You also have Olimex to refer to and you have to refer to this guy. Brilliant.
Dealing with China is just loss of money, time, resources … to mention not the insults etc.
Because you didn't do it the Chinese way. You could have just taken the loss and spare yourself from a lot of troubles and find another reshipper an save all the efforts bitching here. In the end you ended up wasting less time, and spending less jumping through the hoops.
We are a utilitarian country. We don't care what is "right" or otherwise. We care about getting the things done, the quickest and cheapest way. Just do what successful, or rich people do. Your country certainly has many people dealing with China and made great money. Copy and paste what they do, don't ask questions, and you will be fine.
Never pursue what is theoretically "should be" in China. It doesn't work here.
Blueskull 说:yobbo 说:如果能出个spi从机的wifi模块就完美了
有啊,8285可以刷SPI从机或者UART从机固件。
有固件地址或者说明吗? 在网上只能找到一个卖模块的支持spi从机高速传输
如题,最近写了个基于CH552的通用JTAG适配器。用法如下:
向EP1写入0x00+一个字节:控制电源、FPGA复位等,具体逻辑参见jtag.c的jtag_power()实现。其中0x04位控制JTAG模式还是SPI模式。
向EP1写入0x01+字节数+比特数+0x00+tms序列数组(以字节为单位,lsb先出)+tdi序列数组(同上):输出一个JTAG序列,最多30字节。
向EP1写入0x02+数据:输出一个SPI序列,复用JTAG引脚,最多63字节。
从EP1读取数据:读取JTAG写入时TDO采样得到的数据,字节序和TMS、TDI相同。
支持WCID,可以免驱(但是WinUSB貌似不被PyUSB支持,所以我手工安装了libusb-win32)。
下位机只负责输入输出JTAG序列,具体高层逻辑(TAP状态改变、读写、复位等)完全依赖上位机。
附送Python程序用于加载高云FPGA的比特流。实测GW1NR-LV9可用。
但缺点好像就是内存太小,我训练50张图片出来的模型都很大了? ?? 更别说那些训练几千张的模型(一般有几百M了),这点不知道大家如何解决的?
不需要也别快的话可以从SPI加载模型,然后往KPU里面倒腾。K210有MMU,可以SPI映射内存,但是K210用的RiscV版本有bug,MMU看现在的RV手册不好使,得参考某个特定版本的MMU手册。有个日本人搞出来了,可以把完整的16MB NOR映射成内存。
我用K210不跑实际训练的模型,所以不是很在乎内存大小。我跑的是简单的几何图形检测(贴片捡放机,找零件位置和pin1圆圈),都有数学表达式的,可以直接推出来卷积核,pooling参数和激活函数,模型特别简单。
在网上找到了IPD635这个板子的电路图,但是看描述好像这个电路图有点问题。但是可以作为参考,希望有大神可以点亮。
原网页:https://e2echina.ti.com/question_answer/dlp_mems/f/106/t/86095
电路图:(DWG-ES0128-R01)IPD635 Main Board V1.1 Schematic
图上只有排线到DLPC2607的部分,DLPC2607到DMD的部分没画,而且连DMD具体是啥都没写。
请问:算力的具体意义是什么,有统一标准吗?
对AI来说,算力一般指的是计算8比特数据的能力。先乘后加算两次运算。
所以一个400MHz主频,576个乘加器的NPU就有0.4*576*2=0.46T的算力(K210)。
K210可以超频到800MHz,但是要加压,功耗和稳定性都炸了。现实点说600MHz没问题,也就是0.69T算力。
K210的所有内存都是单周期片上SRAM,这一点比外挂内存的芯片强太多了。6MB用于CPU程序和NPU模型,2MB用于NPU数据。
CPU可以寻址全部8MB空间,NPU只能寻址2MB的NPU数据内存,NPU的模型要逐层由CPU加载到NPU里面。
NPU模型内存只存储当前计算层的参数,独立于上述8MB之外。
容量小是硬伤,但是速度快很爽。
如果你的模型能压缩到6MB以下,而且层数据(当前+下一层)能做到2MB以下,K210应该实际速度比那些号称1T/2T/3T的基于外部DRAM的方案快的多。
这芯片潜力很大,但是就是文档太日狗了。没有内部人士帮忙想跑tinyyolo以外的任何东西基本上都不可能。
我试着把官方IDE里的示例给下载到k210的板子上,工程编译通过了,不过没法往板子上下载。
IDE 可以看见开发板的串口,但是输出了这个错误信息:[INFO] try reboot as KD233 [INFO] Failed to boot as KD233: Timeout greeting kd233 board
我用的k210开发板是一个叫Sipeed M1n 的板子,和Sipeed Maixduino 兼容。怎么让官方IDE 识别M1n 的板子,而不是把它当成 KD233 呢?
谢谢
这几块板子都是用RTS/DTR实现的复位和进入ISP模式。不同的板子接法不同,所以有不同的RTS/DTR时序。尝试使用-b选项指定不同的板子。
顺便说一下,start.s不是必要的。可以通过设置代码段的方式强行把数组放到一个段里面,然后让LD把这个段放到代码的最开始。这样SPL header和向量表就可以都用C写了。纯C是完全可以实现bootloader的,反正性能不是那么重要,真正引导之后各种核心函数比如memcpy都在内核里面重新写了。bootloader有很多懒人写法,比如把堆放到栈上面,LD脚本和sbrk的实现都会简单很多。
基本上能把时钟和内存初始化了,能读闪存,能加载内核和参数(DTB等),就可以引导。F1C 32KB的SPL的空间应该够了,不需要第三阶段引导器。XBoot的SPL包含上述全部外加一些其他驱动,也就是16KB。如果不用既有框架而是从头开始为F1C手写的话,应该能再小。之前我闲的玩F1C的时候写的纯C向量表+时钟+内存+SPI+NOR+UART+hello world也就是几KB。后来没时间了,要不然准备练手写个最简RTOS的。
如题,最近我自己做的GD32F3x0 GCC连接脚本+启动文件+makefile,打包福利群友。
具体用法详见README。需要系统带arm gcc,如果不是Ubuntu官方ARM GCC编译器,需要修改makefile指向新的工具链。需要rm命令,windows用户请自行修改为del /s。如需自动下载,需要stm32loader,可以从python3的pip里面装。
不支持libc,需要标准函数库的同学可以自行移植。
测试环境:Ubuntu 20.04,最新版开发工具,GD32F350G8U6,RTS=RST,DTR=BOOT0。
本站下载: gd32f350_spl_gcc.7z
> cmake -GNinja -S. -Bbuild" or "cmake -GNinja -S. -Bbuild -DCMAKE_BUILD_TYPE=Debug
> cmake --build ./build工具链参考这个:https://github.com/talpachen/vsf/wiki
我现在参考的就是这个代码还有楼上xiaohui的代码,以及搜出来的几份stm32 bare metal教程。
目前start代码和ld脚本编译成功,bsp启动代码成功,gpio led点亮,下一步是测试其他外设。
全弄完了我另外开贴发出来。
请教各位一个问题,GD32怎么使用UART1进入ISP模式?
芯片是GD32F350,QFN28封装。手册说把BOOT0拉高可以进入ISP模式,可以使用UART0@PA9/10或者UART1@PA14/15中的任意一组下载。
然而我做了个板子,CP2102N的TXD和RXD连接GD32 UART1的RXD和TXD,CP2102N的RTS和DTR连接GD32的RST和BOOT0,然后在GD官方的ISP软件里面选择RTS拉低复位,DTR拉高进ISP,超时1秒,波特率试过了9600、57600、115200,都报超时错误。
3.3V没问题,RST和BOOT0电平在点击下载按钮的时候都有跳变(3.3V->0V->3.3V),但是就是进不去ISP模式。
麻烦各位大佬帮忙看看是怎么一回事。
淘宝上有这个Hi3516CV300 IP摄像头模块,RMB 56,不知能否引出串口当开发板用?
https://item.taobao.com/item.htm?s&id=614218177372
楼主是保加利亚来的一个傻逼,已经被我骂退群了。
一个老外的论坛上一个人看到了我发的XBoot+F1C项目,联系我帮忙开发一款产品。我肯定没时间,就想把这个机会福利给坛友,有谁想赚个外快可以接。
内容很简单,F1C100S播放MP3,按键控制,要求带蓝牙输出(插耳机就是耳机输出,不插耳机就是蓝牙输出),蓝牙可以使用成品的CSR等方案的模组。
源是SD卡,系统可以SD启动也可以NOR启动,系统不限。XBoot,RTT,sunxi,Melis都可以,要求支持USB MSC。
预算5000元,交期1~2个月。三个月后可能要求修改LCD显示格式,另付费。
这是一个正向设计项目,不要求逆向工程已有设计,但是为了方便开始,对方可以提供一个基于同方案的样机作为参考。
我之前研究XBoot代码的时候发现它的算法实现是基于x=filter(ad_x)*gain_x+filter(ad_y)*dist_x+bias_x, y=filter(ad_y)*gain_y+filter(ad_x)*dist_y+bias+y的。
filter是一个低通滤波函数,XBoot自己有一个实现,F1C的TSC模块也有自己的硬件实现,可以配寄存器配置出来。最简单的,可以做一个IIR一阶数字RC滤波器,或者滑动窗口,丢弃最大值最小值,其他做平均。
gain_x是x轴增益,dist_x是y轴输入对x轴的影响,如果你的触摸屏没有失真的话该值为0,bias_x是偏移量。y轴参数同理。
一般调参数都是假设两个失真参数为0,通过y=kx+b拟合出来本轴增益和偏移量,再微调失真增益。
@Blueskull, Don’t you understand what huge JOKE you are …
I know what I am, little angry man.
You probably want to know that Baidu is the world's largest piracy website, technically, and they make good money and even got listed on NASDAQ.
No one cares about what you believe fucktard. Let's see what your puny little police friends can do to us.
In UK for example people loose their jobs … for such comments …
So white supremacy is true in the decadent West. I ALMOST can't breathe.
I currently wondering which would be more effective, to demand from the European authorities this web site to be ban in Europe, North America or take more drastic measures ?
I recommend you to do all of these and see if anyone ever gives you a single shit. We'd be glad if this forum is not plagued with inferior races.
I really highly recommend you not to play further on my nerve. Presume you follow the Huawei case … Additional measures can be taken against China and Chinese companies and people.
Lol. Who the F do you think you are? Oh, just another partially evolved white trash with stinky armpits.
BTW, Chinese government has captured a few Canadian and American spies, one eben being former doplomat. I don't see China loses in Ms. Meng's case on an an eye for an eye basis.
The Chinese greediness is endless. Not only the shipping cost were raised, different fees introduced, but the lattes: The earlier advertised PCB manufacturer, raised the price, for 2 model PCB – 20 CNY/10 pcs., for 4 model – 120 CNY.
If you need something from them, they have the advantage on price setting.
If you don't know what (raw) capitalism is, I suggest you to look it up on Wikipedia.
发一下你的绐我们看一下。
Anycubic Photon S,三千多,再加个一千多的清洗机,再加上几种树脂,包括一两种常用树脂,数显卡尺,固化灯,3M砂纸,柠檬烯,酒精,基本上就是八千打底了。
树脂真的是无底洞,一小瓶250ml荷兰产的特种树脂小一千,几种常见的国产加进口的工程、柔性、光学树脂买全了轻松就破万了。
而且低端LCD打印机打印空间很小,打印大件会翘曲。需要尝试性补偿,废料率高,再加上固化的树脂是热固性的,没用热抛光、溶剂抛光和修复的可能性,文件没调好材料和时间就都浪费了。
这玩意适合有耐心,不差钱,但是要求变态精度的人。而且还需要接触液态树脂,有潜在化学风险,需要戴手套和口罩,而且需要维护大量的易燃溶剂。日常做个结构件的话还是FDM省心。
The latest Chinese “invention” in shipping:
You are welcomed to use 100x more expensive legally licensed products.
Rule number 1 in China, there's no right or wrong, only power matters.
If they can f* your IP and get around, they will. One day you will do the same depending on which shoes your feet are in.
The copyright issues are quite important. I’ve seen on this site software with cracks etc. Shouldn't the site administrators delete such posts ?
This is a forum which is supposed to share resources.
I personally don't use pirate software, but there's nothing weird or wrong to use cracked software in China for most people.
Return the loot the West took from China and we can talk IP rights.
Also why don’t you use free compilers/IDEs like GCC, Segger Embedded Studio, Eclipse … ?
I use gcc, Linux, KiCAD and LibreOffice, and when I used to use Windows, I had a $10k copy of Altium designer, a few copies of Windows and a few copies of Office and Visio, all paid with real cash.
It's hard to persuade the others to practice what you think is right, and my recommendation for you is simple: when in Rome, do Romans do.
BTW, in case you haven't feel from the verbiage of most posters here, you are either a joke here, or a joker. You are probably not very welcomed here.
更新:修复了一些bug,同时附了一个python版本的,从kflash里面扒出来的,我就是按照这个写的C语言版。另外,我已经把flash芯片焊掉了,正常运行。
如题,今天写了个支持K210串口启动的程序,可以允许K210不带QSPI FLASH工作。
搞这个的目的主要是为了我的一款产品,使用ESP32和K210协同工作。为了减小尺寸,时钟和存储都由ESP32提供。
K210不支持那种超小封装的SPI FLASH,因为K210要求必须1.8V SPI,并且必须是QSPI。这种芯片不好找,所以干脆就串口启动算了。
串口启动时如果能保证永远进入ISP模式(永远不会进入正常启动模式),则QSPI脚可以空置,否则MOSI, MISO, HOLD, WP最好拉高*。
本来是给ESP32写的,不过也适用于电脑和其他小端架构。大端架构要改169, 170和173行,加一个大小端转换即可。
基本上就是把kflash的sram部分扒了下来,用C重写了一遍。没有测过Windows和macOS,Ubuntu 20.04+MAIX Bit测试可用。
串口API部分改一改应该能适配所有架构。我在ESP32上实现没问题。
RTS和DTR控制启动模式和复位,这里的时序是按照Sipeed的MAIX Bit做的,也适用于KD233。其他板子参考kflash源码修改72, 74和77行。
*:没测过,目前是带FLASH测试的,但是K210设计者说可以完全不挂FLASH,但是4根数据线最好拉高。
这芯片有个小问题,NPU没有独立大内存。CNN基本上不会是受限于乘法器的,主要的限制还是内存带宽。
他这个设计要求每次算完一层网络之后都得从DRAM里面读新的参数,而K210的网络是放在SRAM里面的。
而且单核400M A7论算力应该比不上双核400M Rocket RV64+FPU,何况K210不加电压可以稳定超频600M,而且保证全温度范围。
这个芯片牛逼的地方在于ISP支持高分辨率,不像K210那个最大VGA的分辨率。
我现在用K210得先用OV5640降采样到VGA,再找特征,找到了还得配置OV5640放大那个区域,然后做二次识别。
顺便一提,楼主说的那个K210标称1T算力实际只有0.3T的问题,1T是超频800M的数值,理论400M最大只有0.5T,实际达到0.3T,还算可以了。
K210内部有576个乘加器,400M的频率下进行400M*576次乘法和加法,因此总共400M*576*2=0.46T次理论最大算力。
不过K210还有额外算力,KPU的pooling,归一化,激活插值(K210的激活函数不是固定的,可以load进去一条16折线),都没有算在算力里面。
需要交额外的版权费吗?
专利费先不说,你用的软件全都是开源的就不用交。真正的问题是专利。
但是在中国,有人在乎吗?你用了SD卡槽(非SPI模式)就要交SDIO专利费。
你用了任何多媒体编解码器(包括开源的,只要核心算法有专利)就要交专利费。欧洲开发OGG是有理由的,就是为了避开MP3和AAC的专利。
你再加个ESP32,WiFi和蓝牙都有专利费,WiFi是澳大利亚一所大学发明的,全世界收专利费。
后来被IEEE在美国政府的授意下买下来了,实质上不受理专利,也就是完全免费了。蓝牙仍然有专利,BLE还有单独的专利。
就算你自己想到的点子,十有八九会有别人申请过专利。没人闲的会告你,因为他自己的专利都不一定有效。
自主实现不等于不侵犯知识产权。严格按照法律,中国的电子产业全得完蛋。在中国,奉行中庸之道,混水摸鱼就好了。
我在美国生活过六年,其中做过两年顾问工程师。实际上美国人也不在乎,如果严格遵守专利法,全世界的工程师群体早就被大公司,专利流氓,给独裁了。
所以我的建议就是闷声发大财,该怎么用就怎么用。不要说专利,侵犯版权甚至直接抄板这种更容易查的知识产权的都大有人在,你怕个毛线?
AIRV选料上的确使用了更高成本的器件(CH340在7688上用被害惨了,国产TF卡槽在工程中也吃过大亏不敢用),但关键是AIRV配齐液晶摄像头才99.9元,这个定价比一般竞品售价低了将近20元。被说成是”为了提价/吹嘘而盲目使用无实际意义的物料“。这就有点心机叵测了。
我们设计的产品或多或少使用一些更高成本物料,同时还尽量保证性价比,我们就是这种设计理念,难道使用了高成本物料还不能让用户知道吗?
真是恶心到我了
虽然是个老帖子,但是我不得不说,Sipeed推国产芯片毕竟是有情怀的。K210就是国产芯片,F1C也是国产芯片,V3S也是国产芯片。那人家为什么就不能推CH340呢?你嫌它bug多完全可以绕过去,或者用CH552自己实现,新版的Sipeed板子就时CH552做的。
再说了人家也没有指名道姓,何必非要认为人家就一定在说你?
再者说,Sipeed的板子用的是塞孔工艺,板材上花的钱就属于“盲目使用无实际意义的物料“,所以你就当是Sipeed自嘲好了。没必要那么敏感。
国内做开源硬件的就那么几个大玩家,没必要搞得那么僵不是?何况只要你搞K210,就免不了从他们那里拿货。
1、不是想不开,只是想支持一下国产。
2、经过贸易战的洗礼,采购AXL的器件,采购都带排斥心理。
3、国产FPGA也挺好的,起码把DDR封装到IC内部,可以减少PCB的体积。
4、现在去美化要求。IC能用国产尽量国产。
Altera是供货最没把握的,本身Intel就不想搞低端市场,而且性价比、能耗比都不行,国内库存不是很好。
Xilinx短期没问题,国内一众AI和挖矿都用,保有量大,天塌下来有人顶着。
实在害怕或者做军品、敏感工业品就老老实实用Lattice。
国产几个架构都类似Lattice,因为那几个老总都是Lattice出去的。真的断供了马上能顶上。
我都怀疑高云的手册里面的时序图是不是直接从Lattice手册里面截的。
安路需要货源可以私我,做荔枝糖的那个团队我认识,他们能搞到。
高云我没有货源,但是我做过他们的方案,有技术问题我可以帮忙看下,虽然我也是半吊子。
Hi
Can You upload latest code to eevblog forum?
I can't download anything from hereBest regards
Piotr
Don't really want to necropost on the old thread. PM me with your email and I can send it to you directly.
BTW, I believe posting at least 3 posts here should grant you download privilege. Don't quote on me.
今天在外网论坛发现Silabs把uC-OS3版权买了,license改为Apache2,然后在GitHub上发出来了。
https://github.com/SiliconLabs/uC-OS3
注意License,已经从商业开源变成Apache2了,也就是说以后再有人告你盗版uC,你可以直接说我的代码是从这里面下的,一切责任找Silabs去。
既然免费了,各位会不会考虑用uC,还是会继续使用FreeRTOS或者RTT?
我是吐槽这种对看不出有什么友好态度和贡献行为的,却跑来社区做商业推广的公司。
没记错的话这家卖板子的自己封的X3吧,某种意义上这款芯片是人家自己开发的,人家自己的芯片放出来什么资料,怎么放出来,先给谁后给谁,人家自己说了算吧。
不喜欢的话你也可以自己去找全志买A33裸片自己封SiP。
何况,因为die是A33,就算X3原厂不提供BSP,你买几个芯片要个pin脚图和内存时序,还不是可以直接套用A33的BSP?
既然有别的路可以走,那么你真的感兴趣,愿意玩的话人家卖多少钱就不影响你了。
至于说你想白嫖原厂BSP还想快速商业开发,一点都不想贡献sunxi社区,那就是你的不对了。你说我这话讲理不?
乐意和这种完全看不出有什么友好态度或贡献行为,却利用开源社区这个平台做商业推广的公司抬杠。
没有第一批吃螃蟹的出钱你永远拿不到BSP。得便宜还要卖乖。说句不好听的,没有金主推动支持,这种复杂的多核SoC你连start.S都写不出来。
TI和飞思卡尔官方开发板买的贵是事实,但人家脸皮没那么厚来开源社区推广,何况beaglebone系列开发板的推广和对社区的支持力度有目共睹。
AM3358多少钱?对标的单核全志A13多少钱?
我吐槽的原因是这个,至于你为什么要捧它们,我倒是很好奇。
就是看不惯白嫖有理怪。
此外,吐槽国内公司不好就说是捧洋大人的脸,这点不敢苟同。现在这个年代,承认别人优秀没那么难吧,这点脸皮都没有?
除了Beagle全世界没有比全志资料更好找的MPU了吧。Microchip确实有A5的SAM系列,STM也有A7的MP系列,我咋没看到有人用?我承认谁优秀?
不如现在的优秀,我凭啥捧着它?号称开源社区最大的RPi系列连个电路图都没有,芯片也买不到,没见某些牧羊犬去婊。
呵呵,别人都说屎难吃,难不成你不信还要试试?我就是看不惯国内这种公司的吃相,做得差还不承认,还说爱买不买。
飞思卡尔iMX6UL系列528M主频单核A7原厂板子带屏250美金,没有技术支持,只有一个日均发帖量不过百的论坛和几个PDF教程。爱买买,不爱买别买。
TI除了给爱好者准备的Beagle系列,其他面向专业用户的ARM MPU(非MCU)板子都在300美金以上。
X3这个价格不正常?国产芯片单价便宜就算了,凭啥开发门槛还得低?卖给你已经是给你脸了。日韩台湾很多消费类芯片小批量不签NDA买都买不到,不一样大规模应用?
这个级别的4核A7就没有集成RAM的,不爱买X3可以自己开模封一个SiP。骨头贱喜欢洋大人的完善生态链的没人说你不可以买iMX6Q/iMX8或者Sitara。
没那个预算还想要人家的生态,梦里都有。你非抬杠说手机SoC有集成RAM的那我也没话说,你买得到还能搞到BSP算。
我和厂家一毛钱关系也没有,我老老实实玩我的F1C,也不指望短期内能玩到X3,但我就是看不惯天天想不劳而获还振振有词的。
小智大佬的团队不是准备推出X3开发板么,大家只能再等等喽,另外X3(35 RMB) 的定价貌似还是高了些。
跟它对标的TI处理器AM3358的SiP版本要300多,单核,而且封装还大好几倍。
1. 2.8v干什么用了?
2. vra/vrb不需要复杂的退耦网络。1uf电容怼到地即可,如果你不需要tvout的话。
3. esp系列芯片输出阻抗不一定是50欧,需要加补偿网络调到50欧才能进同轴线。
4. 为啥vcc直接进tvout供电了?5v直接进芯片会炸机。
5. 为啥2.5v和1.2v稳压器的输入是3.3v而不是vcc?除非你特别计算过,一般来讲二次转换只会增加损耗。
6. 你的屏幕自带升压?不带的话你的vcc不能直接怼进去,要加横流升压电路的。
7. svref分压器为啥搞两个?
8. 为啥你的reset是从2.5v分出来的?reset电平应该是vccio电平,也就是3.3v。而且你的电容太大了,换0.1uf。
9. 16MHz晶振的话你要改好多代码。现在成品的bsp都是按照24MHz适配的。
10. NAND SPI可以用uboot,但是rtt和XBoot没有适配,fel也要改。自求多福。
11. CP2102电路看手册。nrst应该上拉,vdd,vregin,vbus在bus powered,外置稳压器模式应该都接3.3v。
复制粘贴电路的时候一定要先理解再做,要不然早晚要出事。顺便,你导出来的protel格式altium打不开。
顺便说个题外话,这个芯片的2.5v和3.3v需求不是很大。如果不考虑wifi的话2.5v和3.3v完全可以上LDO。1.1V必须上DC/DC。
我只焊了EA3036部分的电路,把EA3036的3.3伏输出单独接了个电阻负载测试了下。(接10欧负载时电压正常3.3V ,4欧负载就直接跳0.59伏了。)
4欧就快1A了,你的电源能带动吗?还有,3036反馈脚和输出之间不光要接电阻分压,还要接个小电容,你接了吗?最后,输出电容的容量够吗?陶瓷电容的实际容量在加了电压以后是肯定低于标称容量的,低多少看个体。如果你用的电容和参考设计型号不同,哪怕参数相同,实际容量有可能相去甚远。这就是为什么很多高端设备都要在陶瓷电容附近并一个钽电容,因为钽电容CV曲线是平的。容量稳定了转换芯片的控制回路才能稳定。
如果想试试I2C、GT911,WDG驱动,可以试试我的
https://gitee.com/zhangheyang/f1c100s_rt-thread
希望老大能力入RTT。。
大佬nb!
我现在的策略是把XBoot的启动代码和驱动扒出来,然后照着Linux,RTT和FreeRTOS的libcpu自己写一个上下文切换代码,然后自己写一个抢占式调度器替换XBoot的。
XBoot最不方便的就是不支持抢占调度,XBoot的调度器只能从非中断进,所以没法实现从timer ISR抢占。
倒不是说这么搞跟RTT比有什么优势,主要是自从转了电力专业,好久没写代码了,操作系统那些基础都快忘干净了。不赶紧搞个大项目估计技能就废掉了。
最近做了个小手术,今天刚从医院放出来,还要在家静养两周,心里有点长草,总想搞点大新闻。总想不光要改XBoot,更想把XBoot的启动代码和驱动扒出来自己写个RTOS,估计以后能吹一辈子。
RTT的官方BSP中,包含了图形支持和SDIO这些,不是只含SPI、UART、LIBCPU。
并且I2C、WDG这些驱动的移植并不复杂,基本上只要从Xboot上稍作修改就可以了。
声音驱动也并不难,USBD也能找到足够的资源完成。麻烦的是JPEG、H264这些,确实有难度。
不是说为了卖柿饼pi官方把图形支持阉了吗?我看最新版的github源码里面驱动只有uart,gpio,spi,mmu,sdio。这几个都是内存卡启动必备的,其他的驱动最新版的驱动是没有的。
我知道旧版的bsp里面有一些东西,但是毕竟官方不支持了,那一天rtt驱动架构改了,或者芯片revise了,就用不了了。
I am considering F1C100S for one product that I would like to behave like Jexy (https://www.imdb.com/title/tt9354944/). Other solution: Allwinner R329, HiSilicon Hi3516DV300 … ?
Do you have an anticipated OS to run? Linux? XBoot? RTT? Or bare U-Boot?
Just so you know, Tina (the die codename behind F1C series and those non-SiP packages) has very bad documentation. The only things you can find are datasheets and one single user manual that has no explanations on how peripherals work, just a register book and very simplified diagrams and verbiage.
The only practical use of those chips is to wither run AllWinner's own Melis OS or Official (non-GPL-compliant Linux), or to run a third party OS based on drivers stripped and rewritten from Melis or AllWinner Linux.
Put it in other words, see if your application fits one of the existing OSes, and if it does, then great. If not, the chance for an average hobbyist to port a feature to a new OS is virtually zero.
So far, I've been very unwilling to touch Melis or AllWinner Linux as I don't want to step into copyright infringements. I'm only open to FOSS OSes, such as Linux sunxi, XBoot and RTT.
Linux sunxi has all drivers but video encoders/decoders (which was supplied in AllWinner Linux as a blob), but require the longest time to boot and has the most overhead. XBoot has decent support for the chip, but missing some critical ones like USB, also it is not preemptive, so you have to manage all coroutines to make sure they work in synergy.
RTT was great, until it went commercial and stripped graphics support (framebuffer) from Tina BSP (they sell that part now) among many other peripherals. It was neutered to just SPI, UART and libCPU. Unless you do a ton of works, it won't do much other than printing hello world.
So if you are after something like full FreeRTOS support or official FOSS Linux support, this is not your best bet. You only choose this chip if all you need is a powerful SoC with little expanding capability and you are willing to be under the mercy of whatever existing OS you can use.
这种试过,没什么用。我怀疑windows下的app访问声卡,实际就是软件转换为指定的比特率的,不然怎么实现多个设备同时访问声卡?
Windows的音频驱动分两层,硬件层和媒体层。硬件层负责操作硬件,仅支持硬件支持的采样率,而且同一时间仅支持一个采样率一个位深和一个时钟源。
媒体层负责采样率转换,用以同步不同的时钟,采样率和位深。如果同一时间只有一个应用访问硬件,且该设备以独占模式打开设备,则硬件层使用该应用选择的参数,如硬件不支持所选参数或有多个硬件打开设备,则媒体层介入,执行采样率转换。
具体参考MSDN对于KS(kernel streamer)相关的说明。
不过Windows的ASRC性能很好,Vista以后的ASRC的SNR在120dB左右,完全够一般使用。你就以16bit录,应该是没问题。转8位你还得想想怎么做。但是1个LSB的抖动是正常的,因为你要用8b表示16b,肯定存在一个量化噪声的问题,为了从概率上减小量化噪声,很定要做噪声整形,也就是dither,这时候低频误差就会转成高频抖动,然后你低通滤一遍就好了。
不在乎量化误差可以直接y=(x+128)>>8,省去dither,也就没有1LSB抖动了。
You do not seem to have proper understanding about the North American engineering regulations, laws etc.
You do realize the US is a different country than Canuckistan.
I doubt that it will, it is a business. Furthermore the communist ideology, it is not yours. You seem to miss the fact that Bulgaria was part of USSR, I lived in those times …
And apparently you didn't enjoy that time, which is not what I feel in China.
Also what communism you talk about ? The Chinese businesses are greedy as hyenas.
Communist politics with market economy. In another word, authoritarian capitalism, which I'm extremely fond of.
In Canada some say a person have to love what he/she is doing. Why you consider just profit ? The stuff a person works suppose to bring enjoyment etc.
Which part of "For fun? Not." you can't comprehend?
Sure, but as I stated, I am not charity and expect refund of my money including compensations etc.
Whine to a cop.
By the way the comment above refers also to all your Chinese junk products … on our markets.
Strange enough, the pathetic West still buys from China. I wonder why.
In my opinion, you are forgetting something. Europe, North America … are not China. There is media censorship.
I give no shit to freedom of speech. I hated Western democracy so much that I sold my house and car in US, gave up my green card application and moved back to Shenzhen, where I make the same amount of money but houses are 10x more expensive.
If you've never seen a hard core nationalist, count me as your first encounter.
If you insist on “certified proof”, I can inquire the British authorities to initiate a formal investigation how Boris Johnson government granted the 5G contract to Huawei.
I'm talking about BBC and their ilks.
It is also interesting the Canadian perspective, one of the lattes: Meng Wanzhou was paying actors to protest at the front of a court … look at the articles at CBC (https://www.cbc.ca/).
When the West stops paying people to complain against the communist ideology, we can talk.
In your opinion should it be thrown away ?
For fun? Not. For profit? You better ditch it now.
By the way I was considering Hi3516EV200 for such usage, but more and more I read your comments, get convinced that I should not deal with Chinese products at all etc.
Please never consider a Chinese product and GTFO.
As about Huawei, there are very serious concerns in Europe regarding this company. I was reading few days ago, the French financial minister was complaining that this company was potentially blackmailing the French government, by promising to open a factory …
Potentially. That's an elusive word.
Probably you are aware how Huawei got the 5G contract in UK – granting to some UK royalties contracts in China etc.
Any proof from a government certified news agency of any major country?
安卓没问题,苹果看你用的什么功能。如果是需要MFi的,就需要你去向苹果申请认证。不需要MFi的就不需要。
BLE和蓝牙标准协议(串口等)不需要MFi,自定义协议(打印机等)需要MFi。
https://mfi.apple.com/MFiWeb/getFAQ.action#4-0
暂时弃坑,想来想去感觉XBoot可扩展性还是太差了,还是老老实实用RTT吧。CSDN上有坑网大神移植好了fb驱动和lvgl,但是我还是想自己做一遍。顺便学习一下rtt和arm9 bare metal开发。
07年的时候简短玩过一段时间的2410,那时候技术差,很快就退坑了。后来10年又搞了一下2440,不过也仅局限在跟着友善之臂的教程把qt跑起来,然后就是上层应用开发了,从来没有接触过底层。
中间玩过Altera的Cyclone V SoC,不过也是用的原厂Kernel自己打包了一下上层,驱动都是用的/dev里面的共享内存,所以也算是没有接触底层。同理,iMX6也是画完板子跑起来原厂uboot和Kernel就弃坑了,从来没有研究过底层。
到目前为止我对arm bare metal的理解仅局限在Cortex-M单片机,因此我也希望接着移植fb驱动的机会好好读下rtt源码,研究一下ARM9是如何处理一些底层事物的。
有精力就开个rtt坑,没精力就自己闷头搞了,码文字比码代码累多了。。。
以上
nbiot + gsm + 室外定位 有现成模块,就是室内定位和录音这两个比较麻烦,加个wifi模块作室内定位不知是否是最好的方案。
整个ESP32模块,用信号质量定位,用内置ADC录音。双核CPU,一个给WiFi,另一个给编码器,把ADC的输入做个高通滤波,做个低通滤波,做个AGC,做个下采样,然后ADPCM即可。
48K采样率下采样到8K(足够涵盖语音),8bit深度(11bit a/u率压缩),再用ADPCM压到4bit,总码率是4b*8k=32kbps,4kBps,2MB的存储够你玩512秒的。愿意进一步深入可以做个DCT,把4k的频谱分一下bin,然后分别量化,参考mp3和jpg的方案,能压到至少4:1,也就是2048秒。
外扩一片16MB的NOR够你录16384秒,也就是差不多5小时。
选的PMIC太偏了?,要不是AXP173需要定制我就选这货了,这回我自己DIY一个。
我加了摄像头,所以没有外扩接口了,
surface用户啊,我的串口调试是蓝牙的?。
如果不用调试的话,还可以连接蓝牙设备。
有中意的屏吗?
我在等元件到货,确认一下布局。应该比你快,嘻嘻
SLG46580内部是一个基于查找表+互联矩阵的CPLD+4个LDO,可以实现一些胶水逻辑,比如电平移位,看门狗,PWM等。纯PMIC没法定制。
蓝牙可以搞,但是别人怎么办?不能要求每个人都用蓝牙调试,何况一片USB2512也花不了几块钱。
屏幕的话我用的是Startek的KD043WVFPA022-C015A,某宝190一片,工业级,电容屏,没有EOL。
今早顺丰把屏幕样品送到了,看着还行,就是不知道要怎么固定,这个还得研究。这厂家有做带圆角玻璃外板的型号,但是太大了,我没看中。
BOM成本不是问题。计划是科研教学用,我在深圳某研究所带学生,需要各种监测和用户接口之类的功能,每次都让学生重搞有点浪费人力。
我大概算了一下BOM,算屏,BOM大概在300左右,含定制铝合金外壳。屏和外壳是最贵的,板子没多少钱。
所以我的策略就是不差钱,好用就行。选择XBoot也是同理,我把底层框架做好,学生就负责写上层就行。
硬坑开完了我再开个JIT/IL编译器的坑,算是把这个完整的产品周期填上了。
你会发现你想要引出的接口,会很捉急。
使用内部LCD+RTP控制器,NOR,6线SDIO和UART0控制台的情况下还能扩一路I2S,一路I2C,一路SPI或串口。不用RTP还能扩一路SPI或串口。
我的想法是用电容屏,省下来RTP接口,这样我有两路SPI或串口,一路分给SPI,一路分给串口。
I2C上面挂GT911,一个EEPROM或者FRAM,一个SLG46580。各一路I2S,SPI和UART给到用户模块自己玩去。
这样分完PE2没用,某个当串口用的SPI/UART控制器剩两个IO没用,HSYNC和VSYNC可以空出来(LCD使用DE模式),共5个IO口,
其中PA0/1做ADC,监控电池电压和输入电压,PE2做I2C中断输入,PD20、PD21做通用快速IO留给用户模块,可以做同步触发等。
SLG46580用作PMIC,内置4个可编程LDO或高速开关,两个并联配成buck,供1.1V,另外两个配成2.5V和3.0V LDO。
SLG46580除PMIC和I2C外还有9个IO,1个用作1.1V buck反馈,剩下8个接I2C开漏中断,电池电压采样开关,外部按键和红绿LED。
剩余4个IO里面3个用作背光boost(峰值电流取样+FET驱动),1个用于震动马达,1个用于控制NOR SPI SCK下拉。
把HUB用在电脑端....这个....好吧...
重度Surface用户,那种连台式机笔记本都卖了的重度用户表示两个口伤不起。在单位还好有原厂磁吸dock,在家就只能俩口了,其中C口要接显示器和充电。
显示器带俩USB口,一个给analog discovery留着,另一个插网口。
XBoot+LVGL跑起来了,下一步就是要用这个平台做点什么了。本来想搞一下HMI的,后来一想这个点子别人做过了,价钱也白菜了,于是就想到了做个手持机。这玩意前几年也有做的,但是最近可能是因为全定制开发的成本下来了,这种准系统也就不常见了。
想法很简单,铝合金外壳,里面用隔板分成上下层,上层放电容屏,ARM核心板和接口,按钮等等,下层放可拆卸电池和用户模块。核心板留出常见接口给用户模块,包括SPI,I2C,UART,I2S等。
计划预留一个uSD卡槽和一个USB口,内置hub,一路分给ARM,一路分给串口芯片,用串口芯片的CTS/DTR逻辑实现复位和SPI SCK拉低,具体实现参照ESP32板子。用户按键设计两个,均放在下面,左右各一个,方便左右手持机的用户小拇指按压(和侧面按钮相比省了一点点厚度)。按钮集成LED,用于指示充电,两个按钮和LED并联(独立分流电阻)。
外壳计划由三部分组成,顶壳,隔板,底壳。顶壳厚4mm,开屏幕孔和一半uSD/USB/按键侧孔。隔板厚2mm,开PCB挖空和另一半uSD/USB/按键侧孔,用于放置PCB并垫高厚度,防止PCB压迫LCD。底壳厚6mm,用于容纳用户模块和电池。底壳可选开电池盖孔,用于支持可更换电池。
ARM核心板内置NOR,电源管理等全部电路,不支持无线。需要无线可自行在用户模块插槽加入。
未完待续
@Blueskull, It seems you do not have understanding what troll means, probably you should read more before using foreign words:
I'm native speaker. I grew up reading English books and taking notes in English and I spent 6 years in US.
As about the complains, currently the ship-forwarding company – YoyBuy demands money …
You still didn't quite explain what exactly happened. If you can't translate them properly in Chinese, post in English.
You posted a few incidents, and they got completely smashed up.
For your first case, you said they didn't provide technical docs -- of course. What do you expect, spoon feeding you with tech support for buying a cheap module? If it's too good to be true, it is not true.
Then comes to the HiSilicon case. I have no idea what were you expecting, but expecting English documentation from a Chinese firm, especially considering the chip is actually designed in China, is not something that I'd do.
Then there is the shipping case, which I still can't comprehend what you were talking about.
It seems like you have a package shipped from China to a reshipper then to your place, but sometwhere it f*ed up, right?
And it seems like you've spent some time with the seller and reshipper, and got totally disoriented.
How about you describe things clear and let us know exactly what happened? Complaining doesn't help as none of us took your money.
In general, many Chinese do not understand it, but depending on the jurisdiction - if goods, products not delivered on time - no money.
China has its export control laws, and if your products can't be exported, the customs can forfeit them. Not saying that is the case, but there could be many cases other than you got completely scammed.
Also, when your goods leave the seller, the seller is not entitled to make sure you receive them. If your reshipper f*ed up, you still can't get a refund from the seller.
The seller either gets the returned goods, or your money. That's how it works in China. Unless they arranged the shipping and it screwed up.
By the way, what is the situation with the corona virus, disinfecting packages purchased from TaoBao ... ? I was reading the Chinese government started to disinfect the money in China.
Better safe than sorry. I wouldn't lick a package from God knows where it came from.
As for money, I really can't care. We no longer use banknotes.
@Blueskull, From my observations, what I read on the media … currently the biggest trolls are the Chinese.
Doesn't negate the fact that you are baby crying here like a troll.
Paying bribes to European authorities, making fake comments on Internet to promote Chinese products and services, protests etc.
Did I say I consent them?
Please also note that the image is from a popular film. Quite doubt that the Copyright was complied with ?
Wiener brothers can come to me. Not really your concern.
这个貌似我算错了, 左右声道,应该再乘以2才对。
fs只要ESP32和ES8388支持之内的都可以, 现在的数字音乐用48khz基本可以满足需要。
如果你想用48khz的I2S采样速度播放 96/44.1hkz等其他采样率的音乐就要重采样(resample).
重采样会引起音频失真等问题。
做过几年音频DIY,算是老烧友了,给大家科普一下DAC吧。
首先,MCLK是DAC的内部频率,一般要求和BCLK同步,是BCLK的整数倍,从1倍到N倍不等,一般N是2的次幂。
BCLK是DAC传输信号的频率,等于32*LRCK*fs,对于立体声(非TDM),LRCK永远是fs的2倍(64个BCLK周期)。
BCLK是fs的通道数倍数*32,无论采样深度。
对于不到32位的数据,有效数据可能在32位空间的前面(LJ),后面(RJ)或者LRCK同步脉冲的后一位开始(I2S)。
至于采样率,这个看你的需求。硬件采样率和软件采样率不同就会要求采样率转换,这个过程可以做到无损(动态范围大于140dB,失真小于-130dB),但是需要消耗大量的CPU资源。采样率转换器就是个滤波器,带外抑制越高,带宽差越小,采样率越高,需要的CPU资源越多。
因为一般的音频资源都是44.1k的,我推荐硬件采样率设成44.1k就好(不知道ESP32的PLL是否支持,实在不行外加个晶振,然后ESP32设为I2S slave模式)。
采样率越高不意味着音质越好。现代的DAC芯片都是sigma delta技术,内置整数倍插值,除非你的插值器比芯片硬件的好,否则你自己做采样率转换器只会降低音质。
另外常见的误解就是采样率高输出滤波器就会更简单,这个也不正确。DAC内部已经集成插值了,而且SDM调制器也会插值好多倍,同时把音频带外的低频噪声能量移动到高频区(SDM和PWM的最大区别之一,噪声整形),所以你自己做片外插值没啥卵用。
而且DAC内部的插值器一般是固定角频率的,而不是固定绝对频率的,所以通带阻带都是相对输入采样率的。如果你的输入采样率是48k,他的阻带一般是20k,你的输入采样率的96k,他的阻带就是40k。
如果你自己做了插值,而带外镜像抑制没做好,你的镜像频谱是不会被DAC的插值器干掉的,所以这部分会被输出,然后在运放等模拟输出单元里面和你的输入信号非线性混频,导致信号质量下降。
所以老老实实48k或者44.1k,不要作死是最好的,除非你很明确你在做什么。
那个FLASH上有三道横杠,什么意思?
次品,flash水很深,有什么原片,白片,降级片,黑片等等。
一般打原厂标的是原片(镁光,三星,东芝,闪迪等真正做闪存的)。一般用于高端消费类产品和工业、医疗产品以及服务器。
打别的标的是白片(金士顿,大S等),可能和原片质量一样,也可能是质量稍差一点的。一般是一批晶圆里面废品率比较高,但是这个芯片本身没有坏。因为同批次废品多,怕可靠性不是很好,于是就便宜卖给第三方封装,用于消费类产品。这是我们日常生活接触到最多的。
降级片一般就指白片。
黑片就是原厂不敢打自己的标,大品牌的贴牌商也不敢打标的垃圾片,便宜卖给一些大陆和台湾的小厂,做杂牌内存卡的。一般内存卡和u盘这种低写入应用黑片不一定会出问题,但是ssd等高写入应用掉盘几率还是挺大的。
最后就是你说的这种划线片,这种是封装厂收到的符合对应等级标准(你这个是大S,也就是白片)的芯片,但是在封装过程中出了问题,封完了再测能用但是不达标的产品。应该是比黑片好,比白片差。
如果原厂芯片划线(镁光标,三道杠),那就应该是比白片好,比原片差。
顺便,大S就是镁光自有的白片品牌,不符合镁光严格的质量标准的芯片优先给大S,大S不要的给别的白片公司。大S和其他一些顶级白片,比如金士顿,差不多。但是金士顿可能是东芝镁光或者别的品牌,大S保证是镁光。
bug解决了吗?
代码重写了,原来的三线程让我合到一起了。一个timer任务更新lvgl的tick,其他的任务都做到main_task里面了。
反正ARM9主频高,刷新一下花不了太长时间,从串口的角度看应该是没有延迟的。
而且就算我分了三个线程,XBoot的协程机制也没法保证串口的实时性。无论如何我都得等当前任务忙完了才能切换线程。
所以我干脆把每次刷新的buffer大小改小,借以减少lvgl的线程粒度,然后把三个任务放一起做,给串口高一点的优先级(如果串口buffer不读完不进行下一步操作)。
这样我的最坏延迟就是刷屏幕的几分之一花的时间,只要保证这个时间里面串口buffer不爆炸就好了。
F1C200S有64字节的硬件串口buffer,外加stdio的4096字节,总共4160字节。算上开始位和停止位,共41600符号。
在115.2k的波特率,传输41600符号需要361毫秒。我的刷屏代码咋的也不能这么慢吧。
有没有人遇到过F1C200S运行LVGL随机卡死的?我的系统在移植LVGL之前连夜跑过无限memtest循环,没有出现死机的问题。
最近移植了LVGL,并启用了看门狗,设置为1秒,然后主线程里面每隔100ms喂一次狗。现在开始出现随机的重启,时间在20分钟到两小时不等。
我看了一下,系统里面只有四个任务在运行,主线程,图形线程,通信线程和一个内核定时器。
主线程就是循环延时喂狗,图形线程就是每隔10ms刷一次lv_task_handler(),通信线程就是循环非阻塞poll stdin。
所有延时都是基于以下函数实现的:
void sleep(int ms)
{
clock_t tend=clock()+ms*1000;
while(likely(clock()<tend)) task_yield();
}
系统是XBoot,非抢占,所以任何线程没有及时放开资源都会导致整个系统锁死。
讲道理这个函数每一次wrap around需要50万年(最大值是2^64,单位是us)。
其他的地方我想不到会出问题了,除非lvgl那两个函数会锁死。
咋办?
可以尝试使用rtx啊,keil自己移植好了在arm9上直接用
不用Keil是我的原则之一。从我之前踩过的坑看,买不起的软件坚决不能用。
早晚得被软件开发商,客户或者同行审计出来,然后要么交钱要么推倒重来。
被Altium坑了小十万,office+visio+windows坑了小一万,在下不敢作死了。
所以我现在除了已经买了的Altium+微软全家桶,其他的一概不用。
编译器用gcc/tcc/sdcc,ide不用或者vs community,jlink之流一概不碰。
数值分析用octave,录屏用obs,cad和力热仿真用freecad,电磁仿真用fast field solver。
这样也好,发布项目的时候不用担心别人能不能打开,而且几年间自己也积攒了不少自己写的杂七杂八的工具。
我移植lvgl花了好多时间。xboot 里面的驱动 是怎么用的呢,我准备用到按键,我见唱戏机上有十来个按键的。还有就是是否可以建两个任务,实行交替打印?
可以新建多任务,如何在一个任务里面创建另一个任务可以参考framework/vm.c里面的vmexec实现。
XBoot搞了半天不是抢占式的,所以你的任务里面不能有mdelay之类的循环延时函数,否则会占住cpu资源不放。
要实现多线程,每一个线程的任务尽可能短,需要延时的时候用task_yield()实现。
参考我在XBoot大群里面发的这个:
void sleep(int ms)
{
clock_t tend=clock()+ms*1000;
while(likely(clock()<tend)) task_yield();
}
嗯,就是标题写的,点屏测试固件。这个固件什么也不做,单单是把CPU主频设置为720MHz,然后点屏,显示66CCFF,并循环运行内存测试并在串口打印一行Hello World表示我还活着。因为把CPU小超了一下,顺便还能测试稳定性。
然后就没有然后了。
后就没有然后了。
就没有然后了。
没有然后了。
有然后了。
然后了。
后了。
了。
。
使用sunxi-fel -p spiflash-write 0 xboot.bin烧录,然后复位即可看到效果。适配的屏幕是480*272的。
Chapter 7: Writing a buffer to the framebuffer
It is finally the time to get our most important peripheral, the LCD, to work. Despite XBoot has a /sys filesystem, it does not support operating framebuffer as a block device. There is an fb entry in sysfs, but it is only for controlling backlight. To operate the framebuffer, we need to query the framebuffer object from device database, then create a surface on the framebuffer to draw.
XBoot comes with a boot logo program that we can take a look at. The related function is located in src/init/init.c. After reverse engineering the original code, the following code can be used to initialize the framebuffer and fill it with a solid color.
void initfb()
{
struct device_t *p, *n;
struct framebuffer_t *fb=NULL;
struct surface_t *s;
struct matrix_t m;
struct color_t c;
if(list_empty_careful(&__device_head[DEVICE_TYPE_FRAMEBUFFER])) return;
list_for_each_entry_safe(p, n, &__device_head[DEVICE_TYPE_FRAMEBUFFER], head)
{
fb=(struct framebuffer_t *)(p->priv);
if(fb) break;
}
if(!fb) return;
s=framebuffer_create_surface(fb);
matrix_init_identity(&m);
color_init(&c, 0x66, 0xcc, 0xff, 0xff);
surface_fill(s, NULL, &m, surface_get_width(s), surface_get_height(s), &c, RENDER_TYPE_GOOD);
framebuffer_present_surface(fb, s, NULL);
//framebuffer_destroy_surface(fb, s); //Not destroyed since I want it to retain this screen
framebuffer_set_backlight(fb, 1000); //Max is 1000
}
Apparently, this is not the best code, and we will have a lot of troubles using it since it does not manage variables well and you have to allocate/free objects frequently. Therefore, we need to write a wrapper for the framebuffer to maintain all variables in the entire lifecycle of the framebuffer and surface objects, which we will do later when porting LittlevGL.
Chapter 6: Mapping peripherals to a specific board
With the SoC support of the BSP ready, we can start working on hardware adoption. Since I want this BSP to be as universal as possible, I tried to bring out as many digital peripherals as possible. My final target use is HMI, but I might add some control features, so let’s bring all possible SPI, I2C and UART ports. I will not be interested in multimedia, so I2S, TVIN/OUT and audio codec will not be considered. Due to limitation of RTOS, I will also not be supporting USB.
After consulting the datasheet and a few reference designs, I found that port D is essentially all occupied by LCD interface, therefore all digital communication peripherals must be brought out on port A/B/C/E/F. Since port B is not bonded on QFN88 package, we will leave it alone. Because the goal is to build a minimum system, we will use the touchscreen interface built-in with the chip, therefore port A is off limit too. Similarly, port C is occupied by SPI NOR flash, thus it is off limit for other uses. Despite I do not plan to support SD card, considering it is such a popular feature, I will reserve port F for it. So, all in all, we only have port E at our disposal. Even for port E, PE0 and PE1 are occupied by startup console and I have no intention on remapping them as doing so will require modification of many codes in the existing BSP.
Considering all pin conflicts, I decided to being out I2C0 on PE11~PE12, SPI1 on PE7~PE10, or alternatively UART2 on PE7~PE8. I also plan to bring out PWM1 on PE6 for LCD backlight dimming, and 4 GPIOs on PE2~PE5. Many existing boards use PE2 as USB OTG, but since we do not have USB support other than debugging, we do not have to support USB host, thus no OTG.
Remember the json file we renamed before in BSP/romdisk/boot? Let’s go back to it and see what it has. If it looks like an ascii device tree file in Linux, then you are right. It is the XBoot version of device tree, and it gets parsed every time the kernel boots. By modifying it, we can change how kernel probes drivers upon booting. Skip everything before line 191, as anything before are not supposed to be touched – clock, reset and interrupt controllers. The first thing we need to get familiarized is GPIO definitions, here we can see port A/C/D/E/F are defined with their logical base address. Write those numbers down as we will be needing those. PA is 0, PC is 64, PD is 96, PE is 128 and PF is 160.
In the PWM section we can see PWM0 defined to use GPIO 0, which is PA0. We intend to use PA0 for touchscreen, but we can leave it as is as anyway we will not be using PWM0. PWM1 is set to use GPIO 134, which is 128+6, or PE6, which is what we intended, thus we can leave this one untouched too. Ignore the times as they don not occupy GPIOs. For I2C0, we can leave the settings as is as GPIO 139 and 140 are PE11 and PE12, exactly what we wanted. Ignore I2C1 and I2C2 as we will never use them. We will also leave UART0 untouched for previously mentioned reasons. UART1 is not used, so let it be. UART2 was set to use GPIO 135 and 136, which are PE7 and PE8, again, what we anticipated, so nothing needs to be done ere either. SPI0 was mapped to PC0~PC3, which is what my hardware uses, and SPI1 was mapped to PE7~PE10, so nothing needs to change here. We will also leave SD as is since there is only one set of SD pins, and they cannot be changed. SPINOR is set to use SPI0, which is correct. We will not change WDT as it does not have pins, and we will leave LRADC as is since we will not be using it. You can remove or just leave led-gpio and ledtrigger there as we do not really need them and really cannot care about them.
Finally, it is time for porting the LCD interface. First, in ts section we need to take a look at calibration term. The tuple dictates how ADC readings are translated to on-screen coordinates. The calibration is based on 2D linear functions, where:
X(x, y)=(k0+k1*x+k2*y)/k6
Y(x, y)=(k3+k4*x+k5*y)/k6
All k factors are stored in coefficient tuple in k0~k6 order. This will be modified once we have real data from an actual touchscreen. We will just leave the default numbers there. Then we move to led-pwm-bl section, where it specifies PWM controller, minimum/maximum duty cycle and default states. The default can be used as is. Lastly, in fb section we can see parameters for the framebuffer, and what we really care are width, height, vertical and horizontal front/back porch times and pixel clock. In this case, I will be using a 480*272 LCD. After consulting the datasheet, I stuffed all correct timing values in fb section. Since I anticipate up to 60fps refresh rate, the pixel clock has to be at least 60*(480+8+43)*(272+4+12)=9.2MHz. The default 33MHz will do just fine, so I left it as is and saved the file. In addition, I also changed length and offset in spinor section since I anticipate my program will be no more than 1MB, so I figured I would save an extra 3MB for custom file storage.
After modifying the device tree file, we can then work on modifying CPU clock. The CPU clock frequency is defined in BSP/sys-clock.c, sys_clock_init(). Change the literal 408000000 to 600000 or 720000. There is a limit of 720MHz in clock_set_pll_cpu(), which you can override to allow the CPU to be overclocked to up to 900MHz, but it is not recommended due to excessive heating and reduced reliability. To reliably operate at 900MHz, core voltage has to be raised from 1.1V to at least 1.2V. It is recommended to operate the CPU at below 600MHz for maximum reliability at 1.1V, and no more than 720MHz at 1.2V.
Despite both XBoot and F1C200S support dynamic CPU clock, the BSP did not have such implementation. To add such feature, populate clk_f1c100s_pll_set_rate() in BSP/drivers/clk-f1c100s-pll.c with:
static void clk_f1c100s_pll_set_rate(struct clk_t * clk, u64_t prate, u64_t rate)
{
struct clk_f1c100s_pll_pdata_t * pdat = (struct clk_f1c100s_pll_pdata_t *)clk->priv;
if(pdat->channel==0)
clock_set_pll_cpu(rate);
}
Then copy clock_set_pll_cpu() and wait_pll_stable() from BSP/sys-clock.c. They have to be declared as static in BSP/sys-clock.c to save a few bytes in order to pack SPL down to 7680 bytes.
At this step, low level porting has been finished, and app development can begin.
Chapter 5: Making the splash message your own
At this point, we should have a pretty functional F1C200S BSP, and we should be able to do some work.
Before getting into app development, let's first customize the splash message.
Following src/init/main.c, you will see it calls a function called do_initcalls, and here's where it prints all messages.
Using grep, we can trace it down to src/kernel/core/initcall.c, which leads us to /src/include/initcall.h, which then leads to machine_initcall().
Tracing that function with grep, we found that in our own BSP/xxx_machine.c we declared machine_initcall() using a macro, which leads to register_machine().
Using the same grep trick, we can pin point to src/kernel/core/machine.c, where register_machine function prints the banner and version using mach->logger().
Grep mach->logger, we can see it was also used in machine_logger(), which is aliased as LOG() macro, then we grep LOG, we can find quite some references.
Therefore, by disabling machine_logger, we can disable all debug info other than the banner and version.
Adding some #ifdef, #else return 0; and #endif gets the problem done, then define your definition name in app.h and include app.h in machine.c.
Now with boot log disabled, splash message gets considerably clean, but we still need to customize banner and version to fit our needs.
In register_machine, a 5 line banner was printed, then the version was printed. We can remove the code or change it to whatever we want.
In our case, I put the banner info in app.c and externed the string in app.h, and modified machine.c to print my banner.
I also removed version line and manually added it in my banner string. We can then remove src/init/version.c and src/include/version.h as they are no longer referenced anywhere.
This is a milestone, and this means the kernel is ready to be used by an app. We sure will modify it from time to time, but the ground work has is now done.
I attached a copy of mine just for reference. It boots in ~0.5s, and most of the time it took was by the boot ROM, which we have absolutely no way to improve.
So, here we go, an as fast as possible RTOS image running on F1C200S ready for app development.
Chapter 4: Doubling the RAM
The official BSP supplied with XBoot is for F1C100S, which has only 32MB of copackaged RAM. Our F1C200S has double the RAM, so let's not waste it.
First, create a copy of the BSP in src/arch/arm32/mach-f1c100s, let's name it mach-f1c200s. In my case I just renamed it not keeping the old, but that probably is a bad idea.
Rename the sast-kk131.c to whatever the name you want that reflects your product, in this case I named it hmi-machine.c. The original use of this BSP was for SAST KK131 media player.
Do some minor modifications starting from line 83, to rename functions and string literals to reflect your product.
Don't worry about changing the name of the file will cause compiler to not find it. The makefile is set to find and compile all files in specified folders.
The next file to modify is xbood.ld, which tells how the linker arranges memory. The most important part is in MEMORY section, change heap len to 48M (since now we have 64M of RAM).
The original BSP author was kind enough to add an auto memory size detection feature in sys-dram.c, so it will automatically adapt both 32MB chip and 64MB chip, and we don't have to change anything.
Finally, make sure your kernel loads the correct device tree file upon booting by renaming BSP/romdisk/boot/sast-kk131.json to xxx.json where xxx is product name string you put in xxx-machine.c.
We can leave BSP for now, but we will come back later to adjust some parameters in that json file according to our hardware configuration. We'll come back after the hardware has been designed.
You can try your new BSP by compiling the project with new PLATFORM parameter when invoking make. To make your life easier, you probably want to add those info in src/makefile.
There are some tidy up works that we can do, such as renaming all f1c100-* files and variables to f1c200-*, but I see no point doing so. You might want to do that if you are submitting it to XBoot mainline.
Finally, it's the moment of truth. Do a simple malloc(40*1048576) should be enough to see if your new BSP can use more than 16MB of heap (which is for 32MB RAM). If it return non null, congratulations.
Just to be on the safe side, I wrote a memtest for it, and it runs perfectly.
#ifdef MEMTEST
int *buf=malloc(1048576*MEMTEST_SIZE);
if(!buf)
{
LOG("Failed to allocate memory.\r\n");
while(1) task_yield();
}
for(i=0;i<1048576*MEMTEST_SIZE/4;i++)
buf[i]=i;
for(i=0;i<1048576*MEMTEST_SIZE/4;i++)
if(buf[i]!=i) break;
free(buf);
if(i!=MEMTEST_SIZE*1048576/4)
{
LOG("Memtest failed.\r\n");
while(1) task_yield();
}
LOG("Memtest passed.\r\n");
#endif
Put that in your app_main() before your real business, and define MEMTEST in app.h or app.c, you should be able to see it walking through the entire heap region.
I did a test, and I found I can allocate up to 44MB of heap, which is plenty enough or my HMI application.
Chapter 3: Display the iconic Hello World
Since we nuked the shell, at this time the kernel will have nothing to do after boot.
As we removed the task for the shell to remove shell dependency, we have to add it back, this time pointing to our own app.
In src/init/main.c, add the following between do_automount() and scheduler_loop():
struct task_t * task = task_create(scheduler_self(), "app_main", app_main, NULL, 0, 0);
task_resume(task);
Then create a function call app_main somewhere, and extern it in main.c.
A sample app_main could be simple as this:
#include <xboot.h>
void app_main(struct task_t * task, void * data)
{
int cnt=0;
while(1)
{
printf("%02d: Hello world.\r\n", cnt++);
if(cnt>99) cnt=0;
mdelay(1000);
}
}
Congratulation, now you have a stripped down version of XBoot running your own app.
To tidy things up, let's create a folder called app in src folder, to decouple XBoot and our own app code.
Create an app.c, copy the previous code to it, and create an app.h to declare the function, like this:
#ifndef __APP_H__
#define __APP_H__
#ifdef __cplusplus
extern "C" {
#endif
void app_main(struct task_t * task, void * data);
#ifdef __cplusplus
}
#endif
#endif /* __APP_H__ */
Add app.h to your makefile in INCDIRS section, and add app folder to SRCDIRS section.
Tidy up your main.c to remove all the crap we just added, and now we should have a clean separation between our own code and XBoot.
To try out our work, use sunxi-fel tool to download the program to RAM of F1C200S or SPI flash by appending the following to the grand makefile (not the one in src we we mentioned above, the one in its parent directory, xboot if you cloned it from github):
boot:
-sunxi-fel spl output/xboot.bin
sunxi-fel -p write 0x80000000 output/xboot.bin
sunxi-fel exec 0x80000000
flash:
sunxi-fel -p spiflash-write 0 output/xboot.bin
Chapter 2: Getting XBoot to boot in no time
XBoot is more than a bootloader. It was designed to be a minimum OS, with its own HAL, FS, GUI and even LUA interpreter.
It was so complicated that it was designed to run LUA programs without needing a host side compiler for app development.
While LUA is cool, it is also huge, let alone large libraries like lz4, freetype and cairo. With all options enabled, the binary image for F1C100S is 3.4MB.
What I need is a bare bone system with HAL, FS (FAT only) and nothing. I can come up with my own GUI and my own runtime.
Thus, I stripped XBoot down to bare minimum following this thread (Chinese): http://quotation.github.io/development/2018/10/04/xboot-tailoring.html
1. Remove src/romdisk, this will remove what is known in Linux as initramfs, and there will be only kernel running, not LUA apps and resources.
Since we don't need LUA, we lose nothing. Also delete romdisk related targets in makefile, but leave the one in arch folder as it as the kernel will have to see it and parse it to load devices.
There is a json file in each BSP which is used to tell the kernel what hardware to initialize, essentially ascii version of dtb in Linux. This is the one we want to leave in romdisk.
2. Strip out LUA by removing all lines related to LUA and framework in makefile. Framework is the LUA binding driver for all kernel functions.
Doing so will cause compilation errors due to LUA commands are integrated to CLI shell, so in shell.c there will be function calls to LUA library.
You can strip out related calls t keep the shell while nuking LUA, but what I did was to completely remove the shell as I have no use of it.
To strip the shell, remove src/kernel/shell and src/kernel/command from makefile.
3. Remove graphics libraries such as chipmunk (seriously, why a gaming physics library in an RTOS?), zlib, libpng, libjpeg, pixman, cairo and freetype.
This is a nasty process as text.c in core graphics library depends on freetype.
Since I will be using Littlevgl, I don't need a text engine at all in the kernel, so I removed text.c and font.c from src/kernel/graphic, and all related calls and declarations from surface.c.
I also nuked svg.c and svg-raster.c as I don't need any image support. I'll let Littlevgl to handle all GUI.
4. I also removed XFS support as I have no need to load images from file (anyway I got rid of PNG and JPEG), and if I need, I will use the implementation from Ligglevgl.
XFS is used to implement on the go image file loading. To remove XFS, remove src/kernel/xfs from makefile.
This will cause a ton of compilation errors as surface.c is tangled with XFS. Strip them out line by line will fix it.
I also removed EXT4 and tarball support from src/kernel/vfs in makefile. I left FAT and CPIO as I might need SD in the future, and XBoot binary is in CPIO format.
5. I then removed all unused driver supports in the kernel. There are two types of driver, HAL and kernel.
Kernel driver provides a unified interface cross different platforms, HAL driver is the actual one talking to hardware.
I didn't touch anything in HAL as without reference they won't be called and will be stripped automatically during linking.
To remove kernel drivers, remove line in makefile regarding to drivers in src/driver/ folder, such as src/driver/audio.
I kept ADC, block, clock, clockevent, clocksource, console, dma, framebuffer, gpio, i2c, input, interrupt, led, pwm, rst, sd, spi, uart and wdt.
ADC is used by input to support analog keys (resistive ladder), led is use by framebuffer to support backlight, pwm is used by led.
I don't need I2C, keys and sd in this case, but I'd rather have them in the BSP so I don't have to port them next time I use them in another project.
6. Finally, remove all symbols that are reserved. Normally if a symbol is not used, gcc will strip it out if -s is enabled, but this can be prevented.
This is done to allow dynamic linking (so not every app has to carry those symbols, essentially dynamic linking).
In our case, everything will be compiled to a single binary, so I removed all reserved symbols.
Replace EXPORT_SYMBOL {lots_of_functions} with EXPORT_SYMBOL ; to allow gcc to strip all unused functions.
7. Optionally, you can further modify xbook.mk in your arch folder to add -Wl,--gc-sections in LDFLAGS and -ffunction-sections -fdata-sections in MCFLAGS.
This will allow the compiler to further delete unused symbols. If you are really desperate, you can set -Os in xboot.mk and makefile.
With all efforts, I was able to strip XBoot to 230kB.
Finally, if you wish to do so, you can delete source and header files for all functions you stripped from makefile.
Removing the source will be okay, removing the headers will create troubles as some functions, despite never called, are referenced, so removing them may render the code unable to compile.
Let's take it as an opportunity to pave the road for the future -- if you don't remove those dependencies, in the long run if you call certain functions, your code won't link correctly.
After removing all references to stripped out functions (mostly graphic related), now we have a clean header structure.
Chapter 1: Hardware showcase and demo firmware
The Widora TINY 200 is a small one, not much larger than a uSD slot, the main chip, two USB ports (console and OTG) and an LCD connector.
The board comes with a 480*272 LCD with resistive touch. After connecting the FFC cable, writing demo firmware, I was able to see the LCD turning on running a demo app based on Linux.
At this moment, touch doesn't work as the firmware I run is not for this board, it was for Lichee pi nano, which is a tiny bit different.
Resolution is also not correct for the same reason.
The SoC runs cool. Barely warm to touch. It runs at 5 degs above the rest of the board, which is at around 30C.
Interesting enough, we can see the stacked die structure from thermal image. The top die (hotter) is the RAM, and the bottom die (cooler) is SoC.
The RAM being hotter makes sense as some heat comes out from the SoC through the RAM, so it has to dissipate more heat.
Goal:
To build a human to machine interface (HMI) with resistive touch for lab and light industrial applications. Resistive touch is chosen to allow the use with gloves and water/oil contamination.
UI apps are created on the go using a custom static (no function calls, etc.) interpreted language.
UI is updated by itself using link mechanism (i.e. if a slider moves, the progress bar moves accordingly) or serial command.
All controllable widgets can send commands over serial for the external host to process.
Hardware:
The HMI module is built around AllWinner F1C100S/F1C200S SoC with 450MHz/600MHz ARM9 core, full LCD interface with 2D acceleration, touch screen controller and more.
An external resistive touch screen is connected to the SoC via parallel RGB666/DE/VSYNC/HSYNC and CLK pins.
An onboard NOR flash is used to store firmware and user resource, loaded via serial port.
Only one port is exposed to the external, that is the serial port. USB is only used in debugging phase.
Software:
No full OS like Linux or AllWinner's Melis is used in this case due to the requirement of instant boot.
XBoot is chosen for its high customizability and MIT license.
To further accelerate boot time, all non essential components are stripped from XBoot.
XBoot is used as a task scheduler and HAL, all UI features are implemented using Littlevgl.
To strip XBoot down to bare minimum, all GUI is removed (Freetype, Cairo, PNG, JPG, SVG, XFS), LUA interpreter is removed.
GUI component of XBoot was initially considered, but due to the lack of convenient C interface (it was written in C, but tailored for working with LUA) and huge size (~2.5MB), it was dumped.
A custom app will be used in place of XBoot's shell and LUA interpreter. This app handles serial communication and widget control.
HAL layer (down to framebuffer level) is kept so that my code will be portable in the long run.
Links:
F1C200S datasheet: https://linux-sunxi.org/images/1/11/Allwinner_F1C200s_Datasheet_V1.0.pdf
F1C200S manual: https://linux-sunxi.org/images/2/21/Allwinner_F1C200s_User_Manual_V1.0.pdf
XBoot: https://github.com/xboot/xboot
Dev kit I use: https://item.taobao.com/item.htm?id=587925184119
Dev kit wiki (Chinese): https://wiki.widora.io/tiny200
Another kit (Lichee Pi Nano): https://wiki.sipeed.com/en/lichee/nano.html
Documentation 1 (Chinese): http://nano.lichee.pro/
Documentation 2 (Chinese): https://whycan.cn/t_449.html
Amazing forum for F1C200S (Chinese): https://whycan.cn/f_17.html
用AWTK这个GUI功能不是更多吗?
不想用LGPL,因为我要静态链接。我做的BSP是开源的,但是我的最终应用是闭源的。
另外,AWTK太强大了,很多功能我用不到。我只需要基本的显示和控件。AWTK的一大堆底层库我都用不到。
AWTK更像wx或者Qt,我需要的是类似MiniGUI的东西。
关于输入法和中文支持,这些我都没有需求。能显示ASCII,能支持常见触控控件,我就OK了。
不用普通单片机的唯一理由就是我想刷新到30fps/60fps,常见的IL系列芯片SPI频率最大10M/15M,可超到30M。
30M串口没法支持320*240*16*30,何况还得考虑过扫描和其他协议损耗。
剔除LUA和GUI搞定了,支持64M内存搞定了,精简启动串口输出也搞定了。
当前阶段的BSP我打了个包,欢迎大家拿走。
睡醒明天搞LittlevGL和framebuffer、触摸屏适配,最好明天能把图形跑出来。
不过因为Widora板子用的是i2c触屏芯片,我的目标板用的是原生tsc,我应该不会花时间在TINY 200上支持触控。
最近入手了一块Widora的板子,准备自己画个最小HMI玩玩。在此同时,把我的路程记录下来。
请移步此处查看最新进展,回复本贴我也会回。实在不回可私信。
https://www.eevblog.com/forum/projects/building-an-hmi-based-on-f1c200s-and-xboot/
页次: 1