标签: embedded

什么是嵌入式系统的优秀C内存分配器?

我有一个单线程的嵌入式应用程序,可以分配和释放大量的小块(32-64b).基于缓存的分配器的完美方案.虽然我可以尝试写一个,但这可能是浪费时间,而不是像一些已经在前线的解决方案那样经过测试和调整.

那么我可以用于这种情况的最佳分配器是什么?

注意:我在系统中使用Lua虚拟机(这是80%以上的分配的罪魁祸首),所以我不能轻易地重构我的代码以使用堆栈分配来提高分配性能.

c embedded malloc lua allocation

21
推荐指数
5
解决办法
6110
查看次数

ARM架构的Linux交叉编译

我有兴趣在x86主机上为ARM目标交叉编译Linux内核.你推荐一些好的做法吗?您认为哪个是最好的交叉编译套件?您是否已经确定了自定义交叉编译环境?如果是,您有什么建议?这是个好主意吗?

linux embedded x86 arm

21
推荐指数
5
解决办法
3万
查看次数

我们必须使用C"出于性能原因"

在这个多语言的时代,几乎每一项任务似乎都有一种很好的语言,而且我发现自己在专业上正在努力克服" 除了C很快 "之外的咒语,其中快速的意思是"足够快".我和非常理性的思想开放的人合作,他们喜欢比较数字,而我所拥有的只是想法和意见.你能帮助我找到主观意见并进入"现实世界"吗?

您是否可以帮我找到关于嵌入式和(Linux)系统编程可以使用其他任何语言的研究?我很可能会推动一个错误的假设,并非常感谢研究向我展示这一点.您可以链接或包含好的数字,以帮助将"这只是他/她的意见"评论保持在最低限度.


所以这些是我的特殊要求

  • 记忆不是一个严重的约束
  • 便携性不是一个严重的问题
  • 这不是一个实时系统

c linux embedded systems-programming

21
推荐指数
10
解决办法
7716
查看次数

Lisp在嵌入式平台上

有没有适合实时嵌入式应用程序的开源Lisp编译器?即增量垃圾收集,可定制内存处理,占用空间小等.

编辑:

为了澄清,"编译器"我的意思是本机代码,而不是字节码解释器(尽管建议的微控制器解释实现比我想象的要小得多!).

lisp embedded real-time

21
推荐指数
3
解决办法
1万
查看次数

小尺寸微控制器上的C++

在我看来,人们总是回避,或者更确切地反对在微控制器上使用C++,但我不能为我的生活找出原因.如果您远离大型C++库(例如STL)并且您不尝试使用RTTI或异常处理等复杂功能,那么C与C++之间是否存在明显的差异?虚拟继承是否会对复杂性或占用空间产生巨大影响?我认为这是一个额外的内存,但大多数复杂性将由编译器处理,但我再也不知道很多关于那个黑魔法.我只是不明白为什么人们非常坚持使用C,除了少数几个没有C++编译器的架构(如果有的话).即使你不能使用你的cin或cout,模块化和模板的好处似乎也是明智之举.

我问,因为我正在为一些我想做的爱好项目做一些研究.理想情况下,我希望严格地使用C++来实现很好地模块化的能力,而C语言的"SomeClass_SomeMethod(struct object*this ...)"是"面向对象"的方法.(我更喜欢这些项目的对象Pascal,但是对这种语言的支持并不完全是明星......)我宁愿避免转向功能更强大的微处理器,因为A.对于我正在做的项目,我不需要大量的资源..我不打算写60个状态卡尔曼滤波器或编码1080p视频B.(真正的踢球者)我想使用DIP和QFP封装中提供的处理器.我希望能够在没有焊接或烤制烤箱的任何东西的情况下进行原型设计.

有什么想法吗?

c++ oop embedded

21
推荐指数
3
解决办法
4439
查看次数

什么是小型嵌入式系统的优秀脚本语言?

我正在寻找可以包含在嵌入式系统中的脚本语言,以允许用户根据系统事件(I/O端口更改,时间事件......)预先配置单元行为.需要的控制是

if (some_event)
{ 
    do some stuff
    delay N seconds
    do more stuff
    if (some condition)
    {
        do something
    }
    else
    {
        delay until condition
        do something else
    }
}
Run Code Online (Sandbox Code Playgroud)

每个"do stuff"部分通常是改变IO的状态或允许/禁止处理一个或多个事件.

除非脚本语言实现在内部需要,否则不需要文本处理或文件处理.

在构建正常的操作代码之后,我使用的处理器有大约8K的RAM和20K的程序存储.固件是用C语言编写的,因此脚本语言的任何源代码也必须在C中.

c embedded scripting

21
推荐指数
4
解决办法
2万
查看次数

比较英特尔Galileo和英特尔爱迪生

我是物联网的新手.我检查了英特尔网站,并通过了其他一些链接.但我无法清楚地了解英特尔Galileo和英特尔爱迪生之间有什么区别?什么时候应该用?

有谁知道一个很好的参考资源?

embedded soc intel-galileo iot intel-edison

21
推荐指数
2
解决办法
3万
查看次数

我应该何时在嵌入式系统中使用类型抽象

我曾经在许多不同的嵌入式系统上工作过.他们都使用typedefs(或#defines)作为类型UINT32.

这是一个很好的技术,因为它将类型的大小驱动到程序员家,让你更加意识到溢出的可能性等.

但是在某些系统上,您知道编译器和处理器在项目生命周期内不会发生变化.

那么应该影响您创建和实施项目特定类型的决策呢?

编辑我想我设法失去了我的问题的要点,也许它真的是两个.

使用嵌入式编程,您可能需要特定大小的接口类型,以及处理受限资源(如RAM).这是无法避免的,但您可以选择使用编译器中的基本类型.

对于其他一切,类型的重要性较低.
您需要注意不要引起溢出,并且可能需要注意寄存器和堆栈的使用.这可能会引导你UINT16,UCHAR.但是使用类型UCHAR可以添加编译器'fluff'.由于寄存器通常较大,因此某些编译器可能会添加代码以强制将结果输入类型.

__PRE__
可以变成
__PRE__
这是不必要的.

所以我认为我的问题应该是: -

鉴于嵌入式软件的限制,为一个项目设置的最佳策略是什么,这个项目将有很多人参与其中 - 并非所有人都具有相同的经验水平.

c embedded

20
推荐指数
2
解决办法
1641
查看次数

嵌入式系统的C#?

"C#旨在适用于为托管和嵌入式系统编写应用程序,范围从使用复杂操作系统的大型应用程序到具有专用功能的非常小的应用程序." - 设计目标(维基百科)

虽然它在很大程度上取决于嵌入是如何"emebedded",

你认为C#达到这个目标有多好?

您是否认为C#与C/C++一样好,如果不是更好的工具?

c# embedded

20
推荐指数
3
解决办法
4万
查看次数

使用freemodbus托管多个客户端

我正在开发一个涉及微控制器通过TCP上的modbus与PC通信的项目.我的平台是STM32F4芯片,用C语言编程,没有RTOS.我环顾四周,发现了LwIP和Freemodbus并取得了相当不错的成功,让他们两人都去工作.不幸的是,我现在遇到了一些我不确定如何处理的问题.

我注意到,如果我建立连接,然后失去连接(通过拔掉以太网电缆)我将无法重新连接(当然,当我重新插入时).Freemodbus只允许一个客户端,并且仍然有第一个客户端注册.任何尝试连接的新客户端都将被忽略.在特定的超时期限之后,它不会丢弃第一个客户端,据我所知,这是一个TCP/IP标准.

我的想法是......

  1. 我需要一个可以处理多个客户端的modbus模块.通信丢失后的新客户端请求将被接受,并且第一个客户端最终将因超时而被丢弃.

    • 如何修改Freemodbus来处理这个问题?那里有例子吗?我已经考虑过自己做这件事,看起来这是一个规模很大的项目.
    • 是否有任何好的modbus包可以处理多个客户端,是不是太昂贵和易于使用?我已经看过几个关于各种选项的线索,但我不确定它们是否满足我的需要.我很难找到自己的东西.大多数不支持TCP和仅支持一个客户端的TCP.支持多个客户端通常是个坏主意吗?
  2. 我如何通过PC连接微控制器有问题?

    • 为什么每次尝试重新连接时PC都会更改端口?如果它保持之前使用的相同端口,这将不是问题
  3. 一旦我停止沟通,我应该从Freemodbus中删除客户端吗?

    • 这似乎违反标准,但可能有效.

我倾向于1.特别是因为我最终还是需要支持多个连接.任何帮助,将不胜感激.

谢谢.

c embedded tcp modbus

20
推荐指数
1
解决办法
1638
查看次数

标签 统计

embedded ×10

c ×5

linux ×2

allocation ×1

arm ×1

c# ×1

c++ ×1

intel-edison ×1

intel-galileo ×1

iot ×1

lisp ×1

lua ×1

malloc ×1

modbus ×1

oop ×1

real-time ×1

scripting ×1

soc ×1

systems-programming ×1

tcp ×1

x86 ×1