大家好，欢迎来到IT知识分享网。

KUKA.Sim 4.1与OfficeLite 8.6.2连接配置

KUKA.Sim 4.1与OfficeLite 8.6.2连接配置，终于不像之前KUKA.Sim 3.0版本那样繁琐了。简直不要太方便啊。KUKA.Sim 4.1的基本功能范围如下：

64 位应用程序，具有最高的 CAD 性能

内置 CAD 导入（CATIA V5、V6、JT、STEP、2D-RealDWG 等）

3D 导出功能（STEP-AP242、JT）

2D 导出功能 (RealDWG)

全面的在线数据库，包含当前可用的机器人型号等

可配置的碰撞检查和可达性检查

AVI HD 视频和 3D PDF 导出功能

用于创建自有组件的建模助手

准确确定循环时间（无 KUKA.OfficeLite 亦可）

支持虚拟现实（需要附加的 VR 硬件）

提供用于移动设备的 Mobile Viewer 应用程序

支持 3D 鼠标（例如：3Dconnexion）

支持 NVIDIA PhysX

新：用于高级离线编程的 KRL 编辑器

新：3D 安全区域配置

新：高级输入/输出信号编辑器

新：机器人惯性行程模拟

新：导出 WorkVisual 项目

看着新增功能，KUKA重要上道了，期待跟新的升级……

系统要求（最低程度）

支持的操作系统：WIN 10（64 位）

显卡 1 GB RAM（建议：显卡 2 GB RAM），分辨率至少 1024 x 768 像素（建议：1920 x 1080 像素）

双核 CPU，8 GB RAM（建议：Intel i7，16 GB RAM）

支持 DirectX 9.0

一、软件版本：

二、连接步骤

1、KUKA.Sim 4.1新建项目，并导入与OfficeLite一致的机器人模型，需改固件版本与OfficeLite一致……

查看原文：https://www.dianyuan.com/eestar/article-7959.html

串行NOR Flash中的DQS信号有什么用？

串行NOR Flash在嵌入式里的应用相当广泛，既可用作数据存储也可以用作代码(XiP)存储，串行NOR Flash种类很多，最早期有Standard SPI（一线），后来发展到QuadSPI（四线），到现在OctalSPI或者HyperBus SPI（八线），I/O管脚越来越多，数据吞吐率也越来越高。但到八线Flash的时候，你会发现多了一个特殊的控制信号DQS，DQS是Data Strobe Signal缩写，中文直译叫数据选通信号，这个DQS信号有什么作用呢？今天痞子衡带大家分析一下：

一、回顾DDR中DQS

我们对DQS信号更深的印象应该来源于DDR，DDR是DDR SDRAM的简称，其本身也是Double Data Rate（双倍数据速率）的缩写。从RAM分类来看，DDR是DRAM范畴内的重要组成，DDR已经发展到了第n代了。

在DDR中，DQS信号主要作用是用来在一个时钟周期内准确的区分出每个数据传输周期，从而便于接收方准确接收数据。DQS信号是双向的，在写入DDR时它用来传送由主设备发来的DQS信号，读取DDR时则由DDR生成DQS向主设备发送，所以DQS其实就是数据的同步信号。关于DQS以及DDR原理可以参看网上一篇很好的文章《DDR工作原理》。

那么Flash上的DQS功能与DDR上DQS是不是一样呢？有相同点也有不同点，咱们继续往下看：

二、DQS之Octal Flash篇

我们来看一款典型的Octal Flash，来自MXIC的MX25UM51345G。这款Flash包含DQS引脚（I/O属性为输出），从芯片数据手册里找到跟DQS信号相关的主要是下面这张输出时序图，DQS信号仅在DTR模式（SCLK双边沿采样）时生效，并且只在Flash输出数据时起作用（主设备写Flash时，DQS不起作用），即DQS信号是Flash发出的用于通知读取Flash的主设备SIO[7:0]数据线开始更新的标志。

让我们结合AC特性表里的Symbol再来进一步分析，SCLK信号边沿用于触发Flash数据更新，但是SIO[7:0]数据线并不是在SCLK边沿就立刻更新并且稳定的，这里有一定的时延（tCHQV），在tCHQV时间内，Flash核心收到SCLK触发信号，开始准备数据，并陆续放到SIO[7:0]线上。由于tCHQV时间相对较长，主设备仅根据SCLK信号边沿不知道应该什么时候去拿数据，因此诞生了DQS，DQS信号边沿标志着SIO数据线开始更新，但是SIO[7:0]一共8根数据线，这8根数据线更新不是完全同步的，这就有一个硬性规定，即tDQSQ时间，各数据线SIO[x]在DQS信号跳变开始后不得超过tDQSQ最大时间必须把数据更新完毕。

tCHQV - 从SCLK信号跳变到SIO[7:0]输出有效的时间
tQSV - 从SCLK信号跳变到DQS信号跳变的时间
tDQSQ - 从DQS信号跳变到SIO[7:0]输出有效的时间
tQH - SIO[7:0]输出保持时间

三、DQS之Hyper Flash篇

再来看一款典型的Hyper Flash，来自Cypress的S26KS512S。这款Flash包含RWDS引脚（I/O属性为输出），RWDS就是DQS信号。与Octal Flash不同的是，Hyper Flash的时钟信号CK往往是差分的，差分信号因为其补偿纠正特性，使得时钟跳变间隔比较稳定，因此数据传输从CK与CK#交叉点开始进行。Hyper Flash天然是DTR传输模式，RWDS作用与Octal Flash上的DQS是完全一致的。

同样结合AC特性表里的Symbol来进一步分析，CK差分信号跳变用于触发Flash数据更新，在tCKD时间内，Flash核心收到CK触发信号，开始准备数据，并陆续放到DQ[7:0]线上。RWDS信号边沿标志着DQ数据线开始更新，各数据线DQ[x]在RWDS信号跳变开始后不得超过tDSS最大时间必须把数据更新完毕……

查看原文：https://www.dianyuan.com/eestar/article-7935.html

增强型语言模型——走向通用智能的道路？！

Augmented Language Model (ALM)，笔者将其翻译为增强型语言模型，因其不仅可处理常规的自然语言处理任务（如命名实体识别、文本分类等等），而且在一些看似不是自然语言任务的场景也可以应用（如操控机械臂等），在论文[4]中，作者给我们展示了一个ALM在当前已有的一些研究，笔者深受其震撼。总结来说，ALM主要有两种最为突出的能力：

1. 推理能力（Reasoning）: 指的是模型能将复杂任务拆解为多个或多步简单任务，通过对简单任务的求解从而达到对复杂任务求解的目的。
2. 对外部工具的操控能力（The ability of using external tools）: 指的是有能力调用外部工具，比如搜索引擎、数据库、甚至是物理世界的机械臂等。这种能力有可以再细分为单纯从工具中获取知识（如调用搜索引擎），或者通过工具影响物理世界（如操作机械臂）。

首先需要强调的是，这些能力目前来看都只在大规模语言模型（Large Language Model, LLM）中有所涌现（Emergency） [5]，涌现指的是某种只在模型参数规模达到一定程度后（>10B）才能出现的能力，这些能力在小模型上都无从谈起，对此的讨论可参考博文 [6]。LLM的涌现能力可以说是ALM的基础，具备了涌现能力之后，ALM才具有了强大的逻辑推理和语义理解能力。可以想想，一个模型如果能够具有强大的语义理解能力和逻辑推理能力，并且可以通过操作外部工具获取知识，影响物理世界，那么这已经和我们认识中的『强人工智能』似乎也相差不远了？本文就是尝试对ALM的这些神奇的能力进行综述。

推理能力

通常来说，推理能力是通过证据（Evidence）和逻辑（Logic）对一个问题进行推理的能力，通常可以拆分为一些子问题进行研究，比如常识推理（Commonsense reasoning）、数学推理（mathematical reasoning）、符号推理（Symbolic reasoning）等等。近些年来，基于prompt技术的语言模型得到了广泛地流行，prompt技术+预训练模型是一种新的范式，与传统pretrain -> finetune的范式有所不同的是，在pretrain -> prompt范式中，我们可以不对模型参数进行更新，只需要考虑如何设计更加合理的prompt，就能充分地利用预训练模型中的知识。这里指的『设计更合理的prompt』，既可以是借助已有的人工标注数据进行设计，也可以对已有的人工标注数据进行扩展，比如Chain of Thought Prompt [7] 就扩展了已有标注，补充了思维链的过程。

说到底，无论是prompt还是finetune，都是为了让预训练模型更好地往着下游任务迁移的过程，然而这两者有着完全不同的设计思路。对于finetune而言，预训练模型仿佛是一个早熟的『孩子』，知识丰富却缺少了经验，因此通过一些人工标注数据作为监督信号，去教导这个孩子成为某个领域的专家，然而这个蜕变的过程是刻骨铭心的，一旦他成为了一个领域的专家，他可能就很难成为另一个领域的专家了。蜕变后的他获得了某个领域的成功，却失去了作为孩子的无限发展的可能性（模型通用性）。不仅如此，现在的预训练模型日渐庞大，GPT-3的参数量已经达到了175B，PaLM的参数量达到了540B，在这种参数量下，即便是少量样本的微调，也显得代价难以接受。

此时，我们自然就在想，是否可以在不更新模型参数的前提下，进行预训练模型的下游任务迁移呢？而这也不是痴人说梦，预训练模型在参数量足够巨大的时候，本身就蕴含着无限可能性，他好似一个无穷尽的知识库，只是缺少了有效的搜索途径。从这个角度看，『finetune』这个过程才显得可笑，这相当于为了契合某个人的喜好，就将这个已有知识宝库里面的大部分知识都付之一炬一般。理查德·道金斯所著的《自私的基因》一书中曾经有句名言：

当搜索空间足够大时,有效的搜索就与真正的创造并无二致了

我们在拥有了这个无尽知识宝库（大规模语言模型）后，应该考虑的是如何才能有效从中找到我们需要的内容，而这个过程我们不妨就称之为prompt。^1

LLM的推理能力正是可以通过prompt技术进行诱导，而prompt又可以分为zero-shot prompt和few-shot prompt，后者我们通常也称之为情景学习(in-context learning)^2。如Fig 1.1 (a) 所示，few-shot prompt技术可以通过提供一个解决某个问题的中间思维过程作为示例，如绿底字就提供了解决这个文字数学问题的中间计算过程，诱导LLM的回答里面也包含这个中间思维过程，因此这种prompt方式也称之为思维链提示(Chain of Thought Prompt, CoT prompt)。

如果只提供了一个示例，称之为one-shot prompt，如果提供了若干个示例，则称之为few-shot prompt，如果没有提供任何示例呢？如Fig 1.1 (b)所示，这种我们称之为zero-shot prompt。在zero-shot prompt中，没有提供任何和任务有关的示例，顶多会提供一些通用的提示词，如[8]只是在输入的问题后面添加上了一段 Let’s think step by step，即便如此，实验也证实了在GSM8K等推理任务中，zero-shot prompt也有着不错的表现（即便比不过few-shot prompt）……

查看原文：https://www.dianyuan.com/eestar/article-7970.html

从文件角度看Cortex-M开发(3) – 工程文件

前面两节课里，痞子衡分别给大家介绍了嵌入式开发中的两种典型input文件：源文件(.c/.h/.s)、链接文件(.icf)。痞子衡要再次提问了，还有没有input文件呢?答案确实是有，但这次真的是有且仅有了，本文要介绍的主角project文件也属于半个input文件。为什么说是半个?因为project文件不仅包含开发者指定的input信息，还包含很多其他辅助调试的input/output信息，算是嵌入式开发中承前启后的文件。而本文侧重点在于project文件中与开发者应用相关的input信息，仅当得到了这些input信息，再加上前面介绍的source和linker文件，那么你就已经得到了application所有的信息，你可以用它们来可以生成无歧义的可执行image binary。

随着嵌入式软件工程的发展，为了应对日益复杂的需求，现代IDE的功能也越来越强大了，IDE版本更迭让人应接不暇，Keil MDK已然踏入5.0时代，IAR EWARM更是进入了8.0时代，IDE各有千秋，但本文要讲的内容却是每个IDE必须具有的基本功能，还是继续以IAR EWARM为例开始今天的内容：

一、标准IDE功能

在开始今天的主题之前，痞子衡觉得有必要先简要给大家科普一下标准IDE应该具有的功能。现代IDE基本都是由组件构成，嵌入式开发中的每个阶段都对应着相应的组件，由这些组件去实现各阶段的需求。

1.1 IDE组件

标准嵌入式开发应该至少包括以下6个阶段，而IAR里对于每个阶段都有1个或多个组件：

输入（IAR Editor）：编辑源文件代码。

编译（ICCARM、IASMARM）：编译源文件代码生成可执行二进制机器码。

分析（C-STAT、MISRA-C）：编译过程中检查代码中潜在的问题。

链接（ILINK）：链接可执行二进制机器码到指定ARM存储空间地址。

下载（I-jet、flashloader）：将链接好的可执行二进制机器码下载进芯片内部非易失性存储器。

调试（C-SPY、C-RUN）：在线调试代码在芯片中执行情况。

project文件主要用来记录整合上述6个阶段的所有开发需求。

1.2 IDE文件类型

既然IDE有很多组件，那么同时也会存在不同类型的文件以存储这些组件的所需要的信息。IAR里支持的文件扩展类型非常多，痞子衡在这里仅列举你所创建的工程根目录下的与工程同名的扩展文件，相信你一定会觉得眼熟。

.eww           // Workspace file
.ewp           // IAR Embedded Workbench project
.ewd           // Project settings for C-SPY
.ewt           // Project settings for C-STAT and C-RUN</td>
.dep           // Dependency information

本文要讲的内容都包含在.ewp文件里，ewp文件记录了开发者为应用指定的不可缺少的input信息，没有这些信息，application工程是不完整的。换句话说，如果你得到了application的所有source文件和linker文件，但没有ewp文件的话，可能导致最终生成的image binary文件是不同的。

Note：更多IAR支持的扩展文件类型请查阅IAR软件安装目录下\IAR Systems\Embedded Workbench xxx\arm\doc\EWARM_IDEGuide.ENU.pdf文档里的File types一节。

二、解析project（ewp）文件

前面痞子衡铺垫了很多IDE/project基础概念，该是直奔主题的时候了，本文主角ewp工程文件到底包含哪些开发者指定的input信息？痞子衡从下面3个方面为大家揭秘……

查看原文：https://www.dianyuan.com/eestar/article-7995.html

从文件角度看Cortex-M开发(4) – 可重定向文件

前三节课里，痞子衡都是在给大家介绍嵌入式开发中的input文件。从今天这节课开始，痞子衡就陆续为大家讲output文件。上一节课工程文件(.ewp)里讲说到project文件是一个承前启后的文件，今天痞子衡就为大家讲project生成的第一类output文件：relocatable文件。

文件关系：源文件(.c/.h/.s) + 工程文件(.ewp) -> 可重定向文件(.o/.a)

relocatable文件，即可重定向文件，这个文件是由编译器汇编源文件（.c/.s）而成的。直接生成的重定向文件叫object file，经过封装的重定向文件称为library file。可重定向文件属于ELF文件的分支，关于ELF文件的详细解释可见第六节课可执行文件(.out/.elf)。

本文主角object file和library file，仅是一个中间的过渡文件，其本身也不能被ARM直接执行，需经过第二步转换，即链接，所以这两个文件都是链接器的输入文件。让我们来简单分析一下这两个文件。在开始分析之前我们先回到上一节课工程文件(.ewp)的最后创建的demo工程上，编译这个demo工程可以得到如下.o文件，这些文件全是object文件，每一个源文件都对应一个object文件，本文以task.o为例讲解relocatable文件。

D:\myProject\bsp\builds\demo\Release\Obj\main.o
D:\myProject\bsp\builds\demo\Release\Obj\reset.o
D:\myProject\bsp\builds\demo\Release\Obj\startup.o
D:\myProject\bsp\builds\demo\Release\Obj\startup_MKL25Z4.o
D:\myProject\bsp\builds\demo\Release\Obj\system_MKL25Z4.o
D:\myProject\bsp\builds\demo\Release\Obj\task.o -o

一、解析object文件

task.o文件大小有11683bytes，而从源文件里看其仅包含4个变量和3个函数，可见更多的数据是记录性数据。

1.1 获得file header

c:\cygwin64\bin>x86_64-w64-mingw32-readelf.exe -h task.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          8283 (bytes into file)
  Flags:                             0x, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         85
  Section header string table index: 1

分析file header可知task.o是REL类型ELF文件，其一共含有85个section header，没有program header。

1.2 获得section header

c:\cygwin64\bin>x86_64-w64-mingw32-readelf.exe -S task.o
There are 85 section headers, starting at offset 0x205b:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000034 000000 00      0   0  0
  [ 1] .shstrtab         STRTAB          00000000 000034 0001eb 00      0   0  0
  [ 2] .symtab           SYMTAB          00000000 00021f 000350 10      3  45  0
  [ 3] .strtab           STRTAB          00000000 00056f 000248 00      0   0  0
  [ 8] .bss              NOBITS          00000000 000e1c 000004 00  WA  0   0  4
  [ 9] .noinit           NOBITS          00000000 000e1c 000004 00  WA  0   0  4
  [10] .data             PROGBITS        00000000 000e1c 000004 00  WA  0   0  4
  [11] .bss              NOBITS          00000000 000e20 000010 00  WA  0   0  4
  [12] .text             PROGBITS        00000000 000e20 000058 00  AX  0   0  4
  [13] .textrw           PROGBITS        00000000 000e78 000010 00 WAX  0   0  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

分析section header可知该task.o里的各个常见section（.bss, .noinit, .data, .text, .textrw）的大小，各个段的含义详见第二节课链接文件(.icf)……

查看原文：https://www.dianyuan.com/eestar/article-7994.html

更多精彩内容，尽在电子星球 APP（https://www.eestar.com/）

六篇技术文章，让你秒懂电容的脾气秉性

七篇DIY技术文章献给你，让你脑洞全开

五篇文章帮你开启DSP的学习思路

汇总篇：关于PID知识，重点在此