WhyCan Forum(哇酷开发者社区)

HarmonyOS NEXT完全兼容linux应用，使用的是什么c库？

CPU：8核或以上，64位带MMU，8GB+ DRAM，需要配套的IO芯片，跑linux发行版或windows等全功能操作系统，例子：桌面CPU
APU：4-8核，64位带MMU，1G-16GB DRAM，跑linux发行版或android，例子：手机主控AP
MPU：单核/双核，32位/64位使用N32 ABI，带MMU，32M-1GB DRAM，跑嵌入式linux或rtos，例子：边缘网关主控
MCU：单核，32位 无MMU有MPU，64K-1MB SRAM，跑rtos或裸机程序，例子：电机控制芯片
更小的MCU：单核，8/16位，无MMU无MPU，4k-64k SRAM，跑裸机程序，例子：家电控制芯片

soc主要指MPU和APU两者

看起来以后平头哥专注服务器的soc研发，玄铁专注risc-v cpu核研发了。
听说搞服务器soc那帮人看不起搞risc-v cpu那帮人，是不是啊？

所以平头哥和玄铁是什么关系

Milk-V Duo

@海石生风

你们太缺乏想象力了，端到端的硬件设计会在10年内实现。
到时只要输入需求，AI就会自动选芯片，设计电路，画板。

6啊，push到github和zig社区，很快就有人会参与

大部分soc厂家都这样，特别是话事人从 单片机开发 成长起来的。
开源吧舍不得那点没什么含量的机密，升级跟上主线吧他坐在椅子上像看傻子一样看你。

只有那些近几年成立的做服务器soc的还会重视对主线的支持，因为他们的竞对就是主线上的头部贡献者，
他们的客户也习惯了驱动对各大发行版的良好支持。

这个去掉rf的p4不知道会不会跟esp32-s3同价。
君正有些mpu已经跟esp32-s3同价了，还1ghz cpu合封内存，还能跑linux。

据我所知还是有失业的

T113-S4哪里找？正愁S3内存小

@Blueskull

DesignWare好啊，linux下面一堆现成驱动 

哈哈，确实是如此的。华为里面现在就有些人在借华为的人力财力把学术界或业界的东西捣弄一遍，再整个好营销的概念推出来。这都快成套路了。
往好地方想，造轮子也是扩大了就业机会，培养了一批工程师。华为家大业大的，不怕烧钱。我们这些外人也想看看华为能烧出什么好东西，万一开源了也能借用借用。
大家想体验plan9可以试试redox嘛。

你觉得在这些公司里面说了算的老大哥们是用着gcc升上去的还是用着clang/llvm升上去的。
更换出了问题还不是找这些决策的人问责，年轻人被问责大不了换个公司，还刷了经验呢，这些老大哥被问责估计得真金白银赔钱。

@海石生风
你是AWTK开发人员吗？我一直觉得用zig实现gtk/glib那样规模和完善度的库是一个很好的证明自己的机会。当然gtk/glib有点大，能用zig实现AWTK也是很好的证明，有人推动一下就好了。

对于rust，从热度和复杂性来说我感觉有成为第二个c++的趋势。我比较同意这篇文章里面的说法，rust的做法有点迂腐了，减少了编程的乐趣。linux 6.1要集成rust支持了，我很想看看几年后just for fun的linus会怎么看待rust。

对于c++的继任者，我感觉google的carbon有可能更受欢迎。carbon对c++的兼容跟zig对c的兼容一样好。rust意味着重学重写，carbon和zig意味着学多一点。

@海石生风
zig和c/c++的互操作性很佳，你甚至可以拿zig做c/c++编译器。
可以试试zig，像这位一样：Build an LVGL Touchscreen App with Zig

这么小的机器，不用SW106/AIC800G3可惜了

手动管理内存的语言在实时性上面超越GC管理内存的语言，主要是把内存释放工作化整为零，分散在执行路径各处了。大家都是手动管理内存，在实时性这方面zig不会比rust差。
可靠性zig要靠静态分析动态分析多做测试等工程上的努力去提高，这些工作做c/c++的人都很熟悉了。当然zig在这些工作上还是比c/c++方便些，而且也在语言层面做了一些保障，譬如有空安全语法，带有测试语法，可选数组越界判断，提供可跟踪的内存分配器等等。相当于把一些c/c++提高代码质量的最佳实践都提供了，只要你对代码质量有要求，是可以通过这些工具和语法去达成的。
rust说的安全其实也不是万灵神药，内存泄露是可能的，数组越界也是可能的，除0出错这些也没法处理的。当然这些都算代码逻辑错误，我的意思是rust解决了一些问题，但还是有它解决不了需要程序员以及工程方法去保证的问题。我觉得不要神话rust，特别是不要在嵌入式领域神话rust。
是选择zig这种语法熟悉灵活，但工程工作多些的语言，还是选择rust这种语法束缚多，工程工作少些的语言，还是继续c/c++到底，很考验cto们的智慧了。

跟rust把内存管理规则置于语言层面不同，zig选择跟c一样让程序员自己自由管理内存，但又提供了便利的手段去调试内存错误。就是说跟用c一样，你也可以写出有内存bug的代码，但如果你想要高质量的代码，比用c容易。zig用工程上的改进达到内存安全。
当然zig也提供了其它语言特性，譬如rust的option和result在zig都有对应的实现。go的defer zig也支持。泛型也有。没有class但支持struct内置方法。不妨把zig看成是路子正确的c ++语言吧。
zig设计的时候就考虑到了裸机开发，交叉编译、无运行时依赖一开始就有，而且可以选择生成快速的二进制或生成更紧凑的二进制，拿来做mcu开发挺合适的。

快速编码，方便解bug，这是zig做的权衡(trade off)。不妨说rust是学术的，zig是工程的实用导向的。事实上rust内存管理方式确实来自于十多年前编程语言领域的学术研究。但对于习惯了直接操作硬件的mcu工程师，rust这不行那不行，这里要那样，这样束手束脚的开发过程确实很挫败，特别是代码量不大操作指针不多内存方面出bug概率不多的程序，你会怀疑自己是不是捡了芝麻丢了西瓜。所以我很建议你们想用rust的不妨也看看zig会不会更适合自己。

改名字了：
https://slint-ui.com

666！真希望gcc，clang这些编译器直接提供这些功能

20万RMB一年，也就一个熟手rust程序员的普通工资水平，真不贵。
想想有哪些公司是需要高性能，低时延，高安全，又不能开源的app的，这些公司很可能是吃军工，航空航天，汽车行业饭的，利润之高根本不在乎这20万。
何况这20万不单单是买license还有技术支持。
普通民用消费市场，没必要非要上SixtyFPS，市面一堆c/c++的ui库，出原型又快，人还好招，消费产品出点bug可以接受。
rust的ui库较大范围替代c++ ui库，我想还有5到10年的路要走。现在可以上手，但不建议立马就用上。

还是希望能有为嵌入式app而设计的语言，有现代的语言特性，自动管理内存，含丰富类库，既能开发io控制类应用也能开发人机交互类应用，既能在rtos上跑也能在linux上跑，交叉编译一个选项就能完成。
app开发者苦c/c++久矣

drmModeObjectSetProperty()

放了一份到百度云盘
链接: https://pan.baidu.com/s/1xNVuTKCnAG8eswj4b2PFVQ  密码: fi4l

能说说哪3个版本？
INT2和INT4在DNN用来做什么？

关注，也想找有两个千兆mac的soc

那样的性能，算力，10刀好像也是合理价

业余玩玩还是挺有趣的，赚钱还是后端强啊

如果c语言支持命名参数和匿名函数，那可以写成flutter那样：

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Center(
        child: Column(
          children: <Widget>[
            Padding(
                padding: const EdgeInsets.all(8.0),
                child: Center(child: Text('$val'))),
            ElevatedButton(
              child: Text('Add'),
              onPressed: () => change(),
            ),
          ],
        ),
      ),
    );
  }

如果c语言进取一点，有更多的语法糖（https://developer.android.google.cn/jetpack/compose/kotlin），可以写成jetpack compose那样：

@Composable
fun NewsStory() {
    Column(
        modifier = Modifier.padding(16.dp)
    ) {
        Image(
            painter = painterResource(R.drawable.header),
            contentDescription = null
        )

        Text("A day in Shark Fin Cove")
        Text("Davenport, California")
        Text("December 2018")
    }
}

我了解了c语言的标准，即使是下一代标准c2x，仍然不支持这些语法，所以用c语言做声明式GUI还是不成。
有另一个法子，可以自己定义一套DSL，用编译器把DSL转换成c，然后统一通过gcc编译。作为参考，nim，vlang这些语言都可以直接编译成c，而且还是全功能语言不是DSL，DSL应该更简单。另外，vlang也有自己的声明式GUI。

不用神话声明式GUI，概略的看它跟立即式GUI很像，flutter的runApp()就是xui_loop()，它内部也是不断调用build()函数，build()函数不断调用里面的widget生成函数去实例化widget，就跟xui的应用不断调用xui_begin_xxx()一样。只不过由于flutter和jetpack compose的语言有一些便利的语法，写出来的代码看上去像声明一个个widget而不是创建一个个widget，其实内在是创建一个个widget。

如果是实现立即式GUI，用过程式编程语言就可以了；如果是实现保留式GUI，面向对象语言更合适；而要实现声明式GUI，更现代的语言才行。声明式GUI的流行可能是前端开发人员在不断采用现代化的语言的过程中受了立即式GUI的启发慢慢发展和流行出来的吧。

好像是，看了代码xui_draw_xxx()都是把绘图命令放入队列，在xui_end()做优化后绘图

如果要在程序中记住UI所有状态，这未免增加了应用开发人员的脑力负担，而且程序耦合度也高了。不过嵌入式系统ui不会很复杂元素也比较固定，这点额外负担倒是可以接受。
控件和变量天然绑定，我看了代码有些是，有些不是，譬如raido，progress，哪些应该绑定哪些不用绑定以后要好好设计。

我的第二个问题并不是通过描述文件生成ui，而是wpf中的mvvm，数据驱动ui。既然xui有数据绑定功能，那应该可以做到。
通过描述文件生成ui 看似解耦了ui和代码，其实在现实中ui和代码绝对分开的例子比例并不大，最后还是会增加ui设计者和代码开发者的沟通成本，如果都由一个人来做的话又要在ui语言和代码语言之间切换，这又增加了脑力成本，现在大家都准备走flutter和jetpack compose路线，也是吸取了多年经验教训后的结果啊。

按一个按钮让树的某个节点以及它的子节点全部展开或关闭应该怎么调用接口？
可以在一个线程循环读数和计算，然把计算结果显示在label里面吗？

买多台笔记本就那么难？

看上去像似安凯芯片oem的，毕竟安凯方案也是推荐AWTK的，两家合作很合理

穷人趋向学技术是因为搞技术稳定点吧。
想赚钱还是要靠有风险的投机，另外不要把道德放在太高的位置。

微软的Azure RTOS，也就是之前的ThreadX，今年开源了，可以了解一下。

装个kde neon，你会发现linux下做开发如此美好

现在一大堆互联网摄像头，推流早不是什么事，你网上找找直接turnkey给你都有。
不过推流最贵的是sensor和镜头，最难搞的是网络，主控反而是最成熟的。

那R331是什么呢？某牛网看到他们用R331

膜拜

云上公司无需购买办公地址，这个牛比了。难道说只要服务器在阿里云就可以开始创业了？

    云上公司个体工商户注册特色

        无需购买办公地址
        全程线上电子化登记
        支持支付宝刷脸认证
        可异地远程注册
        最快3天出照

貌似移远BC32挂个wifi就可以开干了

sdram + 读写fifo就可以实现同时操作，1M SRAM，哪个芯片厂那么壕(s)(b)

RGB接收逻辑往一个gram写，lcd驱动逻辑从另一个gram读，来回切换

其实曾经主控的LCD控制器一般也没这个功能，只是iphone出来后任意角度旋转开始流行，手机平板主控才开始加入这个功能。所以你看到全志跑android的主控都有旋转硬件，跑linux/rtos的都没有。
现在很多屏幕都是给手机平板提供的，基本都是竖屏，手机平板主控自然支持到位了。但很多嵌入式系统也想用这些屏幕，但又缺少旋转硬件，有时不得不放弃。
其实嵌入式系统只是想竖屏横用，并不需要在使用时可以任意角度旋转。现在的LCD驱动芯片都可以集成GRAM，也支持横屏取数，只需要集成2倍GRAM就可以实现竖屏横用，可以说把屏幕旋转功能加入到LCD驱动芯片是最经济对系统改动最少的做法。

这些屏我试过，刷太快就会有撕裂的现象，因为他们的驱动IC只有一倍的GRAM

同意。
走在歪路就是走在歪路了，闷声揩油接受唾骂估计人家还没那么讨厌你，“我穷我有理”不是什么好观点，为什么不实诚点呢

那该用什么？

根据iPhone推演了一把，发现推对了

楼主，我编译了你的代码。可以通过烧录运行，但下载到内存执行失败。我用的下面的指令：
sunxi-fel -p write 0x80000000 firmware.bin
sunxi-fel exec 0x80000000

看@晕哥 的帖子 https://whycan.cn/t_449.html  xboot是可以直接下载运行的，你这个是不能直接下载运行的吗？

看来A64成绝唱了，是时候换平台了

好乱，从框图看，r7是有sdio没emac的，而r11是有emac没sdio的。这跟网上的信息不同啊。

全志r7框图：

全志r11框图：

似乎r7引出的脚更多，有ephy，dvp和lcd：

引脚也一样？

官方屏上5V3A的充电器也还是中间死掉，有朋友知道咋回事吗？上4A？

屏拔掉可以正常进入系统，插入屏后启动到中间就重启了

找到了这份文档，好多兼容的模块 https://amoghdesai.com/wp-content/uploads/2018/01/FY07024DI26A30-D_Compatible_LCD_panels.xlsx
买了块FY07024DI26A30-1，发现5V2A的充电器只能boot到一半就死机了

这些外国人怎么那么牛，一下子就定制个芯片

S3系统boot起来大概需要多少秒？

没有支持量产不了都是全志故意搞的吧

有gc的语言跟c/c++比速度，这个基本不可能赢，程序规模越大差距越大。
google现在都在研究用硬件加速gc了。
在一系列新语言中，rust的速度应该跟c/c++最接近了。

C100s接5M摄像头？有点过了吧

要能出个GPD MicroPC或Pocket 2这样的机器就爽了

视频兼容性指什么，视频硬件编解码模块？
全志对3.0的定论是啥？不继续了吗？

说要一统IOT的melis 3.0呢？不是基于RTThread和Zephyr的吗？没戏了吗？

跟emmc和tf卡比有什么优劣？

没错，melis 3.0基于zephyr和rt-thread内核，比起以前的ucos感觉可玩性又高了

yuview是qt+ffmpeg，为什么选择SDL2而不是qt？

用c100做mjpeg编解码？

u-boot是打包在.img还是PhoenixSuit带的？

LGPLv3不能使用Qt Charts和Qt Data Visualization，而且估计出货时还要为每台机器给钱的吧

你要怀疑c100s只有一个地址寄存器的话可以使能vertical blanking interrupt，在中断来时修改地址寄存器。
根据lcd controller设计的不同，VBI来时修改地址寄存器也不一定来得及。因为framebuffer读取是DEBE来做的，通常DEBE内部都会有fifo来缓存几行framebuffer。DEBE设计为fifo输出完立马读取后续数据的话VBI来时修改地址寄存器就来不及了，可以用c100s的line trigger interrupt提前设置，但是SY0设置为多少合适又要不断尝试了。当然DEBE设计为tcon即将开始输出时再读取后续数据的话VBI来时修改地址寄存器就来得及了。

下一帧开始时生效，没人会做立即生效这么难实现又会出撕裂问题的控制器

dma_alloc_coherent()

晕哥老道

询过价，好像5刀可以拿下

谁整个S3的板来玩玩，全志V3+内置128M DDR3，性能、接口完胜V3S

都有什么controller呢？LCD controller？

和好几家c100s方案商聊过，他们都没有这个新的melis系统，全志又不提供

这个，全志你又不是不知道的，能不能拿到这个Melis 2.0的代码估计只能靠大神了