符合AUTOSAR标准的RTAOS--Counters详解

原创 汽车电子嵌入式 2023-06-25 08:25

前言

本系列文章将以RTA-OS为例详细介绍AUTOSAR OS标准及概念,并分享实际使用的一些案例,本文为符合AUTOSAR标准的RTA-OS--Counters介绍。


符合AUTOSAR标准的RTA-OS --功能简介

符合AUTOSAR标准的RTA-OS --Task详解

符合AUTOSAR标准的RTA-OS --Interrupts详解

符合AUTOSAR标准的RTA-OS --Resources详解

符合AUTOSAR标准的RTAOS--Event详解


正文

6.计数器Counters

计数器以tick为单位记录操作系统中发生了多少事情。滴答是一个抽象的单位。

这是由你来决定你想要一个滴答的意思。


可以这样定义tick:


•时间Time,例如毫秒,微秒,分钟等,然后计数器告诉你已经过去了多少时间。


•旋转Rotation,例如以度或分钟为单位,在这种情况下,计数器会告诉你物体旋转了多少。


•按钮按下Button Presses,在这种情况下,计数器会告诉你按钮被按了多少次。


•错误Errors,在这种情况下,计数器计算错误发生的频率。


一个ISR(有时是一个任务)用于驱动一个计数器。驱动程序负责进行正确的RTA-OS API调用来“tick”计数器,或者告诉RTA-OS计数器已经“tick”到一个必需的值。


6.1 配置计数器Configurting Counters

每个计数器都有4个强制性属性:


Name 是计数器的名称。RTA-OS使用与计数器具有相同名称的标识符为每个计数器创建一个句柄。


Type 定义计数器模型。AUTOSAR提供两种型号


软件Software计数器是由操作系统内部维护的计数值。User需要提供一个计数器驱动程序,告诉RTA-OS计数器增加一个tick。在6.2.1节中提供了进一步的细节。


硬件Hardware计数器是由外设维护的计数值。User需要提供一个计数器驱动程序,该驱动程序告诉操作系统何时已经过了请求的tick数。操作系统还将要求您的驱动程序支持支持RTA-OS用于在运行时管理外围设备的回调例程的实现。章节6.2.2提供了进一步的细节。


当需要相对较低的分辨率(例如一毫秒或更高)时,软件计数器就足够了。当需要非常高的分辨率(例如在微秒范围内),或者需要将RTA-OS中的任务调度精确地同步到外部源(例如TPU或全局(网络)时间源)时,应该使用硬件计数器。


Maximum Value定义计数器的最大计数值。在达到最大允许值后,所有计数器在刻度上自动归零。对于16位计数器将为65535(216−1),对于32位计数器将为4294967295(232−1)。这对应于AUTOSAR OS计数器属性MAXALLOWEDVALUE。端口的最大可能计数器值由文件Os.hTickType类型的大小决定。


集成指南:对于硬件计数器,必须确保最大匹配值+1等于外围设备的模量。


Minimum Cycle最小周期定义在为Alarm或者schedule table偏移量设置周期值时允许的最短刻度数。在大多数情况下,希望它是1个刻度。但是,如果希望构建的系统在计数器上强制执行最小的警报间隔,那么可以选择更大的值。这对应于AUTOSAR OS计数器属性MINCYCLE


Ticks per base一个属性,可用于定义计数器上每个刻度所需的基础计数器驱动刻度的数量。可以为这个属性赋任何值,因为RTA-OS不使用它。这对应于AUTOSAR操作系统属性TICKSPERBASE


还有一个附加的可选属性:


Seconds Per Tick以秒为单位定义计数器滴答的持续时间。如果想要使用AUTOSAR OS提供的刻度/时间转换功能,则应该定义此选项。进一步的细节在第6.5节中给出。

 

6.1 声明一个计数器


6.2 计数器驱动Conuter Drivers

RTA-OS不控制任何硬件来提供计数器驱动程序。这使得RTA-OS非常容易与任何tick源集成,例如计时器滴答,错误计数,按钮按压,TPU外设等。这意味着需要为在RTA-OS中声明的每个计数器提供驱动程序,并将其接口到操作系统


驱动程序和计数器之间的接口取决于计数器的类型:

Software CountersAPI调用递增。


Hardware Counters该计数值保存在外部硬件外围设备中。应用程序必须提供一个更复杂的驱动程序,该驱动程序告诉RTA-OS请求的滴答数已经过了。RTA-OS使用特殊的回调来设置请求的tick数,取消请求,获取当前计数值并获取计数器的状态。


6.2.1 软件计数器驱动Software Counter Drivers

对于每个软件计数器,需要提供提供刻度的驱动程序。RTA-OSStartOS()期间将所有软件计数器初始化为零并向上计数。


软件计数器驱动模型在AUTOSAR OS中标准化,如图6.2所示。

 

6.2 Ticked Counter Driver Model


实现软件计数器:


使用API调用IncrementCounter(CounterID)来增加RTA-OS中保存的计数器值。当向MAXALLOWEDVALUE中添加1时,软件计数器会自动归零。


可以从应用程序代码中的大多数地方调用IncrementCounter(CounterID)。计数器最常见的用途之一是为RTA-OS提供基于AlarmSchedule table激活任务的时间基础。在这种情况下,需要提供一个周期性计时器中断,在每次到期时调用IncrementCounter(CounterID)


6.1展示了毫秒中断如何驱动一个名为TimeCounter的计数器。


#include ISR(HandleTimerInterrupt) {    DismissTimerInterrupt();    IncrementCounter(TimeCounter);}


Example 6.1: Using a periodic interrupt to tick a software counter


软件计数器的另一个常见用途是作为容错系统的一部分,在超过错误阈值时需要采取某些操作。软件计数器可用于记录错误的数量,然后可以使用警报来触发恢复操作(例如,激活错误恢复任务)


6.2展示了名为Critical的任务如何在名为ErrorCounter的计数器上记录错误。


#include TASK(Critical){    ...    if (Error) {    IncrementCounter(ErrorCounter);    }    ...    TerminateTask();}


Example 6.2: Using a periodic Task to tick a software counter


静态计数器接口Static Counter Interface


由于AUTOSAR API调用将计数器的名称作为参数,这意味着RTA-OS必须在更新OS数据结构之前在内部取消对参数的引用。这也意味着编译器需要在进入时将参数压入堆栈。

然而,通常情况下,在构建时就知道将从何处计时哪个计数器。可能需要从中断处理程序驱动计数器。


RTA-OS认识到这一点,并为配置文件中声明的每个计数器生成一个专用的API调用Os_IncrementCounter_()(其中CounterID是计数器的名称)


集成指南: API调用Os_IncrementCounter_()不一定可移植到其他AUTOSAR操作系统实现。


例如,考虑一个包含两个计数器的应用程序:一个名为TimeCounter,另一个名为AngularCounterrtaosgen将生成例6.3中所示的两个API调用。


为定时器和角中断提供服务的中断处理程序必须调用这些API调用。


6.4展示了这些中断处理程序。


#include ISR(HandleTimerInterrupt) {    ServiceTimerInterrupt();    Os_IncrementCounter_TimeCounter();}
ISR(HandleAngularInterrupt) { ServiceAngularInterrupt(); Os_IncrementCounter_AngularCounter();}

Example 6.4: Interrupt Handlers for Example 6.3


#include ISR(MillisecondInterrupt) {    ServiceTimerInterrupt();    Os_IncrementCounter_Counter1();    Os_IncrementCounter_Counter2();    ...    Os_IncrementCounter_CounterN();}


Example 6.5: Making multiple calls to the static software counter interface


如果您有多个软件计数器,您需要以相同的速率tick,可以在处理程序中进行多个Os_IncrementCounter_()调用,如例6.5所示 


对于声明的每个计数器,都有一个Os_IncrementCounter_() API调用。这些静态API调用比AUTOSAR IncrementCounter() API调用更快,使用更少的RAM,因为调用不需要参数,也不需要计算出哪个计数器被选中。user应该决定哪个版本适合您的应用程序,并相应地进行选择。


6.2.2 硬件计数器驱动Hardware Counter Drivers

对于每个硬件计数器,User需要提供调用RTA-OS的硬件计数器驱动程序和RTA-OS使用的一组回调。与软件计数器一样,RTA-OS提供了一个定义良好的接口,用于将高级计数器驱动程序连接到操作系统。


集成指南:AUTOSAR OS标准没有指定处理硬件计数器的标准API调用。如果要将应用程序从另一个操作系统移植到RTA-OS,则可能需要更改硬件计数器驱动程序API调用。


对于每个硬件计数器,RTA-OS知道该计数器驱动的下一个动作是什么,是使警报过期,还是处理调度表上的过期点,或者两者兼而有之。RTA-OS还知道在发生这种情况之前需要经过多少滴答。这被称为匹配值。

 


6.3 Advanced Counter Driver Model


当使用软件计数器时,驱动程序会在每次计时结束时告诉RTA-OSRTA-OS在内部对刻度进行计数,当达到匹配值时,采取操作。然后RTA-OS计算下一个匹配值并重复该过程。

相比之下,当使用硬件计数器时,RTA-OS通过回调函数告诉驱动程序何时需要进行下一个操作。外设计算请求的滴答数,并在正确的滴答数耗尽时生成中断。在中断处理程序中,可以调用Os_AdvanceCounter_CounterID() API来告诉RTA-OS处理CounterID上的下一个操作。RTA-OS这样做,然后重复这个过程。


通常,User将使用中断来驱动软件和硬件计数器。对于软件计数器,无论RTA-OS是否有任何事情要做,每个计数器滴答都会发生中断。对于硬件计数器,只有当RTA-OS需要做某事时才会发生中断。这意味着硬件计数器将中断干扰减少到所需的绝对最小值。


Advancing Hardware Counters


User使用API调用Os_AdvanceCounter_()来告诉RTA-OS匹配值已经达到。


集成指南:User负责编写调用Os_AdvanceCounter_()的驱动程序,并确保在正确的时间采取下一个操作。


Os_AdvanceCounter_() API调用导致下一个警报和/或到期点被处理,并将通过调用User提供的回调来设置下一个匹配值,或者,如果没有操作要做(即计数器上没有活动警报或计划表),取消来自驱动程序的中断。关于编写硬件计数器驱动程序的更多详细信息可以在后面章节中找到。


Callback Functions


对于软件计数器,RTA-OS在内部计算经过的滴答数。这意味着RTA-OS总是知道当前的计数器值,在下一次到期之前有多少个滴答等等。


对于硬件计数器,外设计算经过的滴答数。这意味着RTA-OS必须告诉硬件计数器它需要计数多少个节拍,并且必须询问外设当前的计数值,到下一个到期的节拍数等。


这种交互是使用回调函数在RTA-OS和您想用作计数器驱动程序的任何类型的硬件外设之间进行接口的。回调函数的确切功能性取决于用作硬件计数器驱动程序的外设。


然而,通过一个简短的概述,需要四个回调:


Os_Cbk_Set_()

这个回调为下一个动作到期时发生的中断设置状态。回调函数被传递一个计数器的绝对值,在这个计数器上应该发生一个动作。对于计数器,这个回调在两种不同的情况下使用:


1. 开始 Starting

Schedule TableAlarm在计数器上启动时,设置初始中断源。


2. 重置 Resetting

缩短到下一个计数器到期的时间。这是必要的,例如,当下一个中断超过100个滴答时,做一个SetRelAlarm(WakeUp, 100)调用。


AlarmBaseType Info;GetAlarmBase(Alarm2, &Info);MaxValue = Info.maxallowedvalue;BaseTicks = Info.ticksperbase;MinCycle = Info.mincycle;

Example 6.6: Using GetAlarmBase() to read static counter attributes


Os_Cbk_State_()

此回调返回计数器上的下一个操作是否挂起,以及(通常)在达到匹配值之前剩余的tick数。


Os_Cbk_Now_()

此回调需要返回外部计数器的当前值。这用于GetCounterValue() API调用。


Os_Cbk_Cancel_()

这个回调必须为计数器清除任何挂起的中断,并确保中断不能成为挂起,直到一个Os_Cbk_Set_()调用进行。如果不取消计数器上的所有警报和/或停止由计数器驱动的计划表,则不需要此调用。


集成指南:硬件计数器可用于多核系统。RTA-OS将确保State, SetCancel回调只在拥有计数器的核心上被调用。这意味着User可以从拥有计数器的不同核心启动alarmScheduleTables, RTA-OS将向计数器的核心发送消息,告诉它调用适当的回调。


6.3运行时获取计数器属性Accessing Counter Attributes at Run time

RTA-OS API调用GetAlarmBase()总是返回配置的计数器值。GetAlarmBase()的结构如例6.6所示。


配置的值也可以以符号常量的形式访问,如下所示。


• OSMAXALLOWEDVALUE_


• OSTICKSPERBASE_


• OSMINCYCLE_


因此,上面的例6.6也可以写成例6.7:


MaxValue = OSMAXALLOWEDVALUE_Alarm2;

BaseTicks = OSTICKSPERBASE_Alarm2;

MinCycle = OSMINCYCLE_Alarm2;


Example 6.7: Using macros to read static counter attributes


6.3.1 特殊的计数器名Special Counter Names

如果创建了一个名为SystemCounter的计数器,那么在AUTOSAR OS中可以通过省略末尾的_CounterID来使用简短的宏形式访问相关的计数器属性:


OSMAXALLOWEDVALUE_SystemCounter ➔ OSMAXALLOWEDVALUE


OSTICKSPERBASE_SystemCounter ➔ OSTICKSPERBASE


OSMINCYCLE_SystemCounter ➔ OSMINCYCLE


RTA-OSSystemCounter生成两种形式的宏,User可以使用任何一种版本。SystemCounter还提供了一个额外的宏来获取计数器滴答的持续时间(以纳秒为单位),称为OSTICKDURATION


集成指导:生成一个有意义的OSTICKDURATION宏需要配置计数器属性“Seconds Per Tick”。


6.4 读取计数器值Reading Counter Values

应用程序需要能够在运行时读取计数器的当前值。例如,User可能想知道错误计数器记录了多少错误,按钮被按了多少次,或者经过了多少时间。


计数器的当前值可以在运行时通过调用GetCounterValue() API来读取,如例6.8所示。


TickType HowMany;GetCounterValue(ButtonPresses,&HowMany);


Example 8.8: Using GetCounterValue()


当使用GetCounterValue()时,应该意识到:


计数器从MAXALLOWEDVALUE到零,因此计算需要补偿Counters wrap around from       MAXALLOWEDVALUE to zero, so the calculation needs to compensate for the wrap


抢占可以在调用返回时发生,这意味着当您恢复时,' Now '的值将是旧的


当使用硬件计数器时,当调用返回时,计数器驱动程序仍将递增。即使没有发生抢   占,立即执行的计算也将基于旧数据


如果需要执行一个简单的计算来计算自上次读取值以来计数器经过了多少次计时,那么可以通过使用GetElapsedCounterValue() API调用来避免这种潜在的竞争条件。该调用将先前读取的计数器值作为输入,并计算已经过的刻度,包括对计数器包装的补偿。计算发生在操作系统级别(即禁用中断),因此不会受到抢占效应的影响。


示例6.9显示了如何使用此特性来度量任务的端到端(响应)时间。


#include TickType Start;ISR(CaptureTrigger){    /* Dismiss interrupt */    GetCounterValue(TimeCounter,&Start);    ...    ActivateTask(GenerateResponse);}

TASK(GenerateResponse){ TickType Finish; CalculateValue(); WriteToDevice(); GetElapsedCounterValue(TimeCounter,&Start,&Finish); ... TerminateTask();}


Example 6.9: Using GetElapsedCounterValue()


如果计数器正在计算时间刻度(如例6.9),那么这在AUTOSAR OS中被称为自由运行计时器free running timer”。这种类型的计数器没有什么特别之处——它与任何其他类型的计数器相同——唯一的区别是计数器是由计时器滴答源驱动的。


自由运行计时器功能的预期用途是在运行时测量短、高准确度的持续时间。如果需要这样做,那么可能需要使用硬件计数器来获得所需的计数器分辨率。


6.5 Tick数转换为时间Tick to Time Conversions

通常将计数器用作操作系统的时基参考。对于编写的大多数应用程序,事件的相对定时将是由系统需求决定的实时值。很可能会根据实时值、纳秒、毫秒等来考虑系统配置,而不是使用更抽象的tick(滴答)概念。


如果计数器配置参数“秒每滴答”已经配置,那么RTA操作系统生成宏供使用,以在滴答和实时单位之间转换。


可移植性注意事项:AUTOSAR OS声明Tick到时间的转换仅适用于硬件计数器。但是,该特性通常对软件和硬件计数器都有用,并且AUTOSAR XML配置语言支持对这两种类型的计数器进行配置。


RTA-OS中,这种异常通过为软件和硬件计数器提供刻度到时间的转换来解决。但是,应该注意,其他AUTOSAR OS实现不一定支持为软件计数器提供这些宏。


提供了以下Tick转换为时间的宏:


• OS_TICKS2NS_CounterID(ticks) converts ticks to nanoseconds


• OS_TICKS2US_CounterID(ticks) converts ticks to microseconds


• OS_TICKS2MS_CounterID(ticks) converts ticks to milliseconds


• OS_TICKS2SEC_CounterID(ticks) converts ticks to seconds


这些宏返回的值是PhysicalTimeType,而不是TickType,可能会使用这些宏的API调用使这些值,因此需要将它们转换为适当的类型。


6.10展示了如何在应用程序代码中使用这些宏来使用静态定义的“timeout”值来模拟超时。


#define TIMEOUT_MS 100 /* Set a timeout to be 100ms */TickType TimeoutInTicks;TimeoutInTicks =(TickType)((PhysicalTimeType)TIMEOUT_MS/OS_TICKS2MS_TimeCounter(1));SetRelAlarm(TimeoutAlarm, TimeoutInTicks, 0);


Example 6.10: Programming an alarm with time rather than ticks (1)


RTA-OS将尽可能使用整数乘法或除法生成这些宏。然而,对于某些滴答率,有必要在计算中使用浮点数,以保持准确性。当这些宏被传递给编译时已知的固定值时,编译器通常会自己执行计算并嵌入整型结果。如果传递的值是一个变量,那么编译器将不得不在运行时生成使用浮点计算的代码。如果这在应用程序中可能是一个问题,应该检查文件Os_Cfg.h以检查宏的代码。


除了这些宏之外,RTA-OS还生成一个名为otickduration_ 的宏,该宏以纳秒为单位返回计数器滴答的持续时间,因此,如果您希望编写固定时间的警报,即使更改底层计数器滴答率,它也非常有用。例6.11展示了如何使用otickduration_ 宏对例6.10进行修改。这个版本提供了稍好的性能,因为单个tick的持续时间不需要在运行时计算。


#define TIMEOUT_NS 100000000 /* Set a timeout to be 100ms */TickType TimeoutInTicks;TimeoutInTicks = (TickType)(TIMEOUT_NS/OSTICKDURATION_TimeCounter);SetRelAlarm(TimeoutAlarm, TimeoutInTicks, 0);


Example 6.11: Programming an alarm with time rather than ticks (2)


可移植性注意事项: OSTICKDURATION_宏是由RTA-OS提供的,不是AUTOSAR OS标准的一部分。这些宏的使用不能移植到其他实现中。


6.6 小结


计数器用于注册一些tick源的计数。


计数器可以是软件计数器也可以是硬件计数器。User需要为配置的计数器类型提供私有驱动程序。


参考文档:

[1] RTA-OS V6.1.3 User Guide

[2] Specification of Operating System AUTOSAR Release 4.2.2



推荐阅读

Autosar架构下的模块详细设计及代码实现--基于配置的编程方法

AUTOSAR 通信服务-CanSM概念详解

AUTOSAR 通信服务-PDU Router

AUTOSAR CAN通信协议栈分析(2)-CanIf

AUTOSAR架构下CAN BusOff问题分析

C语言编程技巧(1)-表驱动法

CANoe工具使用(1)-实现CAN通道的收、发、录、回放报文

S32K平台学习(1)-S32K144启动流程分析

详解芯片Rese Vector和Interrupt Vector-以S32K和RH850为例

Can通信协议栈分析(1)-Can Driver

AUTOSAR 通信服务 - NM概念详解

AUTOSAR模式管理-EcuM Sleep and UP详解

AUTOSAR 诊断服务-DEM功能概述

基于AUTOSAR与Matlab开发应用层(三)应用层总体功能开发和集成

AUTOSAR-MCAL--SPI模块详解(三)

AUTOSAR-MCAL--MCU模块详解

RH850-U2A16芯片--RAM and Flash介绍

AUTOSAR存储协议栈-- EEPROM Driver模块介绍

AUTOSAR-MCAL--SPI模块详解(三)

详解芯片Rese Vector和Interrupt Vector-以S32K和RH850为例

AUTOSAR架构下RH850芯片深度休眠配置实践-Conifig EcuM and BswM

AUTOSAR架构下关于CanNm的几点思考

AUTOSAR下Com模块中Signal Group详解

Can/Lin报文的触发发送(Trigger Transmit)

AUTOSAR 通信服务-Com模块报文的发送机制

网络关闭但ECU没有休眠前如何网络唤醒

ECU系统休眠后通过诊断报文唤醒ECU且唤醒网络

AUTOSAR网络通信问题分析

Bug分析-内存被异常篡改问题分析

一文读懂AUTOSAR系列 – DEM功能详解

ECU系统休眠后通过诊断报文唤醒ECU且唤醒网络后快发NM报文

网络关闭但ECU没有休眠前如何网络唤醒

AUTOSAR MCAL-基于Infineon TC3xx芯片的ADC模块

AUTOSAR 通信服务-Com模块报文的发送机制

Can/Lin报文的触发发送(Trigger Transmit)

基于RH850芯片的MCAL详解--MCAL简介及PWM模块详解

Can通信协议栈分析(1)-Can Driver

基于RH850芯片的MCAL详解--ICU模块详解


End




欢迎点赞,关注,转发,在看,您的每一次鼓励,都是我最大的动力!

汽车电子嵌入式

微信扫描二维码,关注我的公众号


评论
  • 起源与诞生:AI 技术的起源可以追溯到 20 世纪 40 年代,随着计算机技术的兴起,科学家们开始思考如何让机器具备类似人类的智能。1950 年,英国数学家艾伦・图灵提出了著名的 “图灵测试”,为 AI 技术的发展奠定了理论基础。1956 年,美国达特茅斯学院举行了一次人工智能研讨会,标志着 AI 作为一门独立学科的诞生。符号主义阶段(20 世纪 50 年代 - 70 年代):研究人员主要关注如何使用符号逻辑和推理规则来模拟人类思维,试图通过构建复杂的逻辑系统来解决各种问题。然而,由于这种方法的
    Jeffreyzhang123 2025-01-02 15:15 86浏览
  • 在科技飞速发展的今天,5G 通信技术无疑是最耀眼的明星之一。它如同一场数字革命的风暴,以其前所未有的速度、极低的延迟和强大的连接能力,为我们的生活、经济和社会带来了翻天覆地的变化,开启了一个万物互联的崭新时代。5G 技术的卓越特性5G,即第五代移动通信技术,相比其前辈们,有着诸多令人瞩目的特性。首先是超高速率。5G 网络的理论峰值下载速度可达 10Gbps,这意味着下载一部高清电影只需短短几秒钟,而 4G 网络可能需要几分钟甚至更长时间。这种高速率让高清视频流、云游戏等对带宽要求极高的应用变得流
    Jeffreyzhang123 2025-01-02 14:18 60浏览
  • 前言近年来,随着汽车工业的快速发展,尤其是新能源汽车与智能汽车领域的崛起,汽车安全标准和认证要求日益严格,应用范围愈加广泛。ISO 26262和ISO 21448作为两个重要的汽车安全标准,它们在“系统安全”中扮演的角色各自不同,但又有一定交集。在智能网联汽车的高级辅助驾驶系统(ADAS)应用中,理解这两个标准的区别及其相互关系,对于保障车辆的安全性至关重要。ISO 26262:汽车功能安全的基石如图2.1所示,ISO 26262对“功能安全”的定义解释为:不存在由于电子/电气系统失效引起的危害
    广电计量 2025-01-02 17:18 101浏览
  • 2层PCB设计时候回路的寄生电感计算方式。由两个平面构成电流路径的回路电感,取决于每个平面路径的局部自感和它们之间的局部互感。平面越宽,电流分布就越扩散开,平面的局部自感就越小,从而回路电感也就越小。平面越长,局部自感就越大,从而回路电感也就越大。平面间距越小,平面之间的互感就越大,从而回路电感也就越小。当该区域为正方形,即长度等于宽度时,无论边长是多少,长和宽之比始终等于1。令人惊奇的是,一对平面上的边长为100mil的正方形区域和边长为1in的正方形区域的回路电感相同。平面对上的任一正方形区
    tao180539_524066311 2025-01-02 13:51 46浏览
  •  在这个日新月异的科技时代,智能家居正以前所未有的速度融入我们的日常生活,从智能灯光到温控系统,从安防监控到语音助手,每一处细节都透露着科技的温度与智慧。而在这场智能化浪潮中,一个看似不起眼却至关重要的组件——晶体管光耦,正扮演着连接物理世界与数字世界的隐形桥梁角色,默默推动着智能家居行业的发展与革新。 晶体管光耦——智能家居的“神经递质”晶体管光耦,作为一种能够将电信号转换为光信号,再通过光信号控制另一侧电路开关的电子元器件,其独特的工作原理使得它在隔离传输、抗干扰及保护电
    晶台光耦 2025-01-02 16:19 67浏览
  • 从无到有:智能手机的早期探索无线电话装置的诞生:1902 年,美国人内森・斯塔布菲尔德在肯塔基州制成了第一个无线电话装置,这是人类对 “手机” 技术最早的探索。第一部移动手机问世:1938 年,美国贝尔实验室为美国军方制成了世界上第一部 “移动” 手机。民用手机的出现:1973 年 4 月 3 日,摩托罗拉工程师马丁・库珀在纽约曼哈顿街头手持世界上第一台民用手机摩托罗拉 DynaTAC 8000X 的原型机,给竞争对手 AT&T 公司的朋友打了一个电话。这款手机重 2 磅,通话时间仅能支持半小时
    Jeffreyzhang123 2025-01-02 16:41 105浏览
  • 常见通信标准无线通信标准蜂窝移动通信标准:如 2G(GSM)、3G(WCDMA、CDMA2000、TD - SCDMA)、4G(LTE)以及 5G 等。以 5G 为例,其具有高速率、低时延、大容量等特点,为智能交通、工业互联网和物联网等领域提供支持。无线局域网标准:主要是 IEEE802.11 标准,也就是我们常说的 Wi - Fi。例如 IEEE802.11ac 和 IEEE802.11ax(Wi-Fi 6)等标准,不断提升无线局域网的传输速度和稳定性。短距离无线通信标准:包括蓝牙(Bluet
    Jeffreyzhang123 2025-01-02 14:33 49浏览
  • 在科技飞速发展的今天,机器人已经逐渐深入到我们生活和工作的各个领域。从工业生产线上不知疲倦的机械臂,到探索未知环境的智能探测机器人,再到贴心陪伴的家用服务机器人,它们的身影无处不在。而在这些机器人的背后,C 语言作为一种强大且高效的编程语言,发挥着至关重要的作用。C 语言为何适合机器人编程C 语言诞生于 20 世纪 70 年代,凭借其简洁高效、可移植性强以及对硬件的直接操控能力,成为机器人编程领域的宠儿。机器人的运行环境往往对资源有着严格的限制,需要程序占用较少的内存和运行空间。C 语言具有出色
    Jeffreyzhang123 2025-01-02 16:26 94浏览
  • 早期概念与探索阶段(19 世纪以前):在古代,人类就对自动机械充满了想象,如古希腊时期的希罗发明的自动门、水钟等自动装置,中国古代的指南车、木牛流马等,虽然这些装置不能称之为真正的机器人,但为后来机器人的发展奠定了思想基础。从概念走向实践阶段(19 世纪~20 世纪初):随着工业革命的到来,自动机概念开始与实际机械设计结合,出现了具有实际功能的自动机械,例如雅卡尔提花机等,可通过穿孔卡片控制编织图案,为后续可编程控制的机器人发展提供了灵感。现代机器人产业萌芽期(1920 年代~1950 年代):
    Jeffreyzhang123 2025-01-02 14:53 83浏览
  • 国际标准IPC 标准:IPC-A-600:规定了印刷电路板制造过程中的质量要求和验收标准,涵盖材料、外观、尺寸、焊接、表面处理等方面。IPC-2221/2222:IPC-2221 提供了用于设计印刷电路板的一般原则和要求,IPC-2222 则针对高可靠性电子产品的设计提供了进一步的指导。IPC-6012:详细定义了刚性基板和柔性基板的要求,包括材料、工艺、尺寸、层次结构、特征等。IPC-4101:定义了印刷电路板的基板材料的物理和电气特性。IPC-7351:提供了元件封装的设计规范,包括封装尺寸
    Jeffreyzhang123 2025-01-02 16:50 99浏览
  • 【工程师故事】+半年的经历依然忧伤,带着焦虑和绝望  对于一个企业来说,赚钱才是第一位的,对于一个人来说,赚钱也是第一位的。因为企业要活下去,因为个人也要活下去。企业打不了倒闭。个人还是要吃饭的。企业倒闭了,打不了从头再来。个人失业了,面对的不仅是房贷车贷和教育,还有找工作的焦虑。企业说,一个公司倒闭了,说明不了什么,这是正常的一个现象。个人说,一个中年男人失业了,面对的压力太大了,焦虑会摧毁你的一切。企业说,是个公司倒闭了,也不是什么大的问题,只不过是这些公司经营有问题吧。
    curton 2025-01-02 23:08 91浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦