职位分析:Firmware Engineer

本文介绍工业自动化领域的软件及固件开发经验要求,包括实时系统开发、Modbus与EtherNet/IP协议的应用,以及VxWorks、Workbench IDE等开发工具的使用。
Requirements:
- 2+ years as firmware/software engineer for real time software development, or 5+ years as software/firmware engineer for Industrial Automation Firmware/software development
关键字:Real Time System, Firmware/Software Development

- Industrial protocols Modbus, EtherNet/IP
关键字:Modbus, EtherNet/IP
Modbus协议最初由Modicon公司开发出来,在1979年末该公司成为施耐德自动化(Schneider Automation)部门的一部分,现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备,包括PLC,DCS,智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它,不同厂商生产的控制设备可以连成工业网络,进行集中监控。

当在网络上通信时,Modbus协议决定了每个控制器须要知道它们的设备地址,识别按地址发来的消息,决定要产生何种行动。如果需要回应,控制器将生成应答并使用Modbus协议发送给询问方。

Modbus协议包括ASCII、RTU、TCP等,并没有规定物理层。此协议定义了控制器能够认识和使用的消息结构,而不管它们是经过何种网络进行通信的。标准的Modicon控制器使用RS232C实现串行的Modbus。Modbus的ASCII、RTU协议规定了消息、数据的结构、命令和就答的方式,数据通讯采用Maser/Slave方式,Master端发出数据请求消息,Slave端接收到正确消息后就可以发送数据到Master端以响应请求;Master端也可以直接发消息修改Slave端的数据,实现双向读写。

Modbus协议需要对数据进行校验,串行协议中除有奇偶校验外,ASCII模式采用LRC校验,RTU模式采用16位CRC校验,但TCP模式没有额外规定校验,因为TCP协议是一个面向连接的可靠协议。另外,Modbus采用主从方式定时收发数据,在实际使用中如果某Slave站点断开后(如故障或关机),Master端可以诊断出来,而当故障修复后,网络又可自动接通。因此,Modbus协议的可靠性较好。

工业以太网协议 (Ethernet/IP) 是由 ODVA 所开发并得到了罗克韦尔自动化的强大支持。它使用已用于 ControlNet 和 DeviceNet 的控制和信息协议 (CIP) 为应用层协议。

CIP 提供了一系列标准的服务,提供 “ 隐式 ” 和 “ 显示方式对网络设备中的数据进行访问和控制。 CIP 数据包必须在通过以太网发送前经过封装,并根据请求服务类型而赋予一个报文头。这个报文头指示了发送数据到响应服务的重要性。通过以太网传输的 CIP 数据包具有特殊的以太网报文头,一个 IP 头、一个 TCP 头和封装头。封装头包括了控制命令、格式和状态信息、同步信息等。这允许 CIP 数据包通过 TCP 或 UDP 传输并能够由接收方解包。相对于 DeviceNet 或 ControlNet ,这种封装的缺点是协议的效率比较低。以太网的报文头可能比数据本身还要长,从而造成网络负担过重。因此, EtherNet/IP 更适用于发送大块的数据 ( 如程序 ) ,而不是 DeviceNet 和 ControlNet 更擅长的模拟或数字的 I/O 数据。

- Experience of Vxworks, Workbench IDE, ClearCase
关键字:VxWorks, Workbench IDE, ClearCase
Workbench IDE: IAR公司的一款不错的ARM工具

- PC software development experience, Visual Studio, MFC, ATL
关键字:Visual Studio, MFC, ATL

- Programming language and methodologies – C++, OOAD applied to embedded firmware, UML modeling, with experience developing embedded firmware on projects that require integration with hardware to deliver a complete and interoperable solution.

- Problem solving, Sense of responsibility, Initiative, Intelligence

- Good English
<think>好的,用户现在问的是关于日志中的一条错误信息:“ueventd: firmware: could not find firmware for dsi_prop”,这是什么意思。首先,我需要回忆之前的对话历史。用户之前提供了一组系统日志,其中包含了多个错误和警告信息,我之前已经对这些日志进行了分析,并给出了处理建议,其中提到了这个错误。现在用户单独询问这一条的具体含义。 首先,我需要明确这个错误信息的组成部分。关键词是“ueventd”、“firmware”、“dsi_prop”。ueventd是Android系统中负责处理设备事件的后台服务,用于加载固件和创建设备节点。firmware指的是硬件设备的固件文件,而dsi_prop可能指的是与显示串行接口(DSI)相关的某个属性或固件文件。 接下来,我需要考虑用户可能的背景。用户可能是一位技术人员,或者是普通用户遇到了系统问题,想要了解错误信息的原因和解决方法。用户之前已经得到了整体的日志分析,现在想深入了解其中一条错误的具体情况,所以需要详细解释错误的原因、影响以及解决步骤。 然后,我需要分解这个错误的具体含义。当系统启动时,ueventd服务会尝试加载设备所需的固件。如果找不到对应的固件文件(这里是dsi_prop),系统可能无法正确初始化相关硬件,导致功能异常,比如显示问题。需要解释dsi_prop的可能作用,比如与显示接口或屏幕参数相关。 接下来,要考虑可能的原因。可能包括固件文件缺失、路径错误、权限问题,或者内核模块配置错误。需要逐一分析这些可能性,并给出对应的解决建议。例如,检查固件文件是否存在,确认文件路径是否正确,检查文件权限,更新内核或固件包等。 另外,需要评估用户可能的操作能力。如果用户是普通用户,可能需要更详细的步骤指导,比如如何检查文件是否存在,如何安装固件包等。如果是技术人员,可能需要更深入的排查方法,比如查看设备树配置或内核日志。 同时,要注意用户之前的问题中提到了其他显示相关的错误,比如msm-dsi-display的问题,可能需要将这两个错误联系起来,说明它们可能共同导致显示功能异常。因此,在回答时需要指出可能的关联性,并建议用户综合排查。 最后,确保回答结构清晰,分点说明问题原因、影响和解决步骤,语言简洁易懂,避免使用过于专业的术语,或在必要时解释术语。同时,遵循之前的格式要求,使用中文,正确使用LaTeX格式,尤其是行内公式和独立公式的格式,尽管在这个问题中可能不需要数学公式,但需要保持格式一致。 可能的遗漏点包括:dsi_prop具体指代什么硬件或模块,是否有特定厂商的固件命名习惯,或者是否与特定设备型号相关。如果无法确定dsi_prop的具体含义,可能需要建议用户查阅设备文档或联系硬件供应商。此外,还需要考虑固件文件版本是否匹配当前内核版本,是否存在兼容性问题。 总结来说,回答需要涵盖以下几点: 1. 错误信息的组成部分及其含义。 2. 可能的原因分析。 3. 对系统的影响。 4. 具体的解决步骤。 5. 相关问题的关联性。</think>以下是对该错误信息的详细解析: ### **错误信息解释** 日志条目: ```log ueventd: firmware: could not find firmware for dsi_prop ``` - **关键词分解**: - **`ueventd`**:Android/Linux 系统中负责管理设备热插拔事件和加载固件的守护进程。 - **`firmware`**:硬件设备(如显示屏、网卡等)所需的固件文件(二进制驱动)。 - **`dsi_prop`**:可能与显示串行接口(DSI)相关的配置属性或固件文件(如屏幕时序参数、驱动配置等)。 --- ### **问题本质** 1. **直接原因** 系统在初始化显示硬件时,未能找到名为 `dsi_prop` 的固件文件(或配置文件)。 - 固件文件通常位于 `/lib/firmware/` 或 `/vendor/firmware/` 目录。 - `dsi_prop` 可能是屏幕驱动所需的特定参数文件(例如:高通平台的 DSI 显示配置)。 2. **硬件关联** 该错误通常出现在使用 **DSI(Display Serial Interface)接口的屏幕设备**(如手机、嵌入式设备的显示屏)初始化过程中。 --- ### **潜在影响** | 问题层级 | 可能表现 | |---------|---------| | **驱动级** | 屏幕亮度调节失效、分辨率错误、显示闪烁 | | **功能级** | 触控失灵、屏幕无法唤醒(黑屏) | | **系统级** | 开机卡在 Logo 界面、UI 渲染异常 | --- ### **排查与解决步骤** #### 1. 验证固件文件是否存在 ```bash # 检查固件目录 ls /lib/firmware/dsi_prop* # 通用 Linux ls /vendor/firmware/dsi_prop* # Android 设备 ``` - **预期结果**:应存在类似 `dsi_prop.bin` 或 `dsi_prop.mbn` 的文件。 - **若文件缺失**:需从以下来源获取: - 设备制造商提供的固件包(官网下载) - 更新 `linux-firmware` 软件包(Linux 发行版): ```bash sudo apt update && sudo apt install --reinstall linux-firmware ``` #### 2. 检查固件加载路径 - **内核驱动可能预期固件位于特定子目录**(如 `/lib/firmware/qcom/`),需确认路径是否匹配。 - **解决方法**: ```bash # 创建符号链接(示例) sudo ln -s /lib/firmware/dsi_prop.bin /lib/firmware/qcom/dsi_prop.bin ``` #### 3. 检查文件权限 确保固件文件对系统进程可读: ```bash sudo chmod 644 /lib/firmware/dsi_prop.bin ``` #### 4. 内核驱动兼容性 - **若固件存在但仍报错**:可能是内核版本与固件不兼容。 - **解决方案**: - 更新内核到最新稳定版。 - 联系硬件供应商获取适配当前内核的固件。 --- ### **关联问题参考** 同一日志中出现的其他显示相关错误: ```log msm-dsi-display: supply lab not found, using dummy regulator ``` - **关联性**:两者均指向显示子系统初始化异常,可能共同导致屏幕功能故障。 - **建议**:优先解决固件缺失问题(`dsi_prop`),再排查电源管理问题(`lab` 电源轨)。 如需进一步分析硬件配置,可提供以下信息: 1. 设备型号(手机/开发板) 2. 当前使用的 Linux 内核版本(`uname -r`) 3. `/var/log/kern.log` 中关于 DSI 的完整日志片段
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值