企业官网建设流程全解析

1. 项目概述：从寄存器到函数库的CLB开发之路

如果你正在使用TI的TMS320F2837xD系列微控制器，并且已经摸到了它的可配置逻辑块，那你大概率已经感受到了寄存器手册的“厚重”与“直接”。没错，CLB作为芯片内部的“可编程硬件”，功能强大到可以让你自定义数字逻辑，实现从简单逻辑门到复杂状态机的各种功能，是电机控制、数字电源、高级PWM生成等实时性要求极高场景的利器。但它的配置也足够复杂，动辄几十个寄存器，每个寄存器又包含多个字段，直接操作它们就像在汇编语言里用机器码编程，虽然控制力极强，但效率低下且容易出错。

我最近在为一个高速数据采集项目设计自定义的触发逻辑，CLB是核心。在啃了无数遍技术手册后，我意识到，高效开发的关键在于理解两套“语言”的映射关系：一套是硬件工程师和手册里写的“寄存器语言”，另一套是软件工程师日常使用的“Driverlib函数语言”。比如，手册里那个CLB_PULL_y寄存器，它的偏移地址是100h + (y * 2h)，功能是管理从系统到CLB的FIFO数据流。而在代码里，我们调用的却是CLB_writeFIFOs()和CLB_clearFIFOs()这样的函数。这中间的桥梁是什么？如何确保我们调用的函数确实精准地操控了目标寄存器？这就是本文要深入拆解的核心：CLB寄存器与Driverlib函数之间的详细映射关系、背后的设计逻辑，以及在实际项目中如何正确、高效地使用它们。无论你是刚接触CLB的新手，还是想优化现有底层代码的老手，理解这份“映射表”都能让你避开许多坑，显著提升开发效率和代码可靠性。

2. CLB架构与寄存器编程基础

在深入具体的寄存器之前，我们必须先建立起对CLB整体架构和寄存器编程范式的清晰认知。这就像看地图前得先知道东南西北和图例一样。

2.1 CLB模块的核心组成与数据流

TMS320F2837xD的每个CLB模块（芯片内有多个）都不是一个简单的黑盒，而是一个高度可配置的数字逻辑子系统。你可以把它想象成一个微型的、可编程的FPGA切片。其核心数据通路通常围绕着几个关键部分构建：

1. 输入多路复用与滤波：这是逻辑的起点。CLB有多个外部输入源（来自GPIO、其他外设等）和内部反馈信号。IN_MUX_SEL_0、LCL_MUX_SEL_1/2、GLBL_MUX_SEL_1/2这类寄存器，就是用来配置这些信号如何被选择并路由到内部逻辑单元（如LUT、FSM）的“交通指挥员”。INPUT_FILTER寄存器则负责对输入信号进行消抖或同步处理，这对于在噪声环境中确保逻辑稳定至关重要。

2. 逻辑执行单元：这是CLB的“大脑”，主要包括：

   • 查找表：通常指LUT4（4输入查找表）。LUT4_IN0至LUT4_IN3寄存器选择其输入源，而LUT4_FN1_0和LUT4_FN2寄存器则定义了其布尔逻辑函数。你可以通过配置这些寄存器，让一个LUT4实现任何4输入1输出的组合逻辑。
   • 有限状态机：FSM是CLB实现时序逻辑的核心。FSM_EXTRA_IN0/1、FSM_EXTERNAL_IN0/1选择其输入；FSM_LUT_FN1_0和FSM_LUT_FN2定义其状态转移条件和输出逻辑；FSM_NEXT_STATE_0/1/2则直接定义在特定条件下下一个状态是什么。
   • 计数器：COUNT_EVENT、COUNT_MODE_0/1、COUNT_RESET等寄存器用于配置计数器的事件源、工作模式和复位条件，常用于实现定时、分频或事件计数。

3. 输出与互连：逻辑运算的结果需要通过OUTPUT_LUT_0至OUTPUT_LUT_7等寄存器配置的输出查找表进行最终处理，然后通过OUT_EN寄存器控制哪些输出最终有效，驱动到芯片引脚或反馈给其他部分。

4. 数据交换接口：这就是CLB_PULL_y和PUSH寄存器所在的领域。它们是CLB与系统内存（CPU/DMA）进行数据交换的“港口”。PULLFIFO用于系统向CLB发送数据或命令，PUSHFIFO用于CLB向系统回传数据或状态。这种基于FIFO的通信机制，是实现硬件加速器与软件协同工作的关键。

注意：理解这个数据流至关重要。错误的输入选择会导致逻辑功能完全失效；不正确的输出使能会导致信号无法输出；而FIFO操作不当则会造成数据丢失或阻塞。在配置任何寄存器前，先在脑海中或纸上画出你期望的信号流图。

2.2 寄存器直接编程：原理、优势与陷阱

所谓寄存器编程，就是通过C语言指针，直接对芯片内存映射中特定地址进行读写操作。对于CLB，每个寄存器都有一个唯一的基地址偏移量。

// 假设 CLB1 的基地址是 0x5F00_0000 #define CLB1_BASE (0x5F000000) #define CLB_PULL_0_OFFSET (0x100) // y=0 #define CLB_PULL_0_ADDR (*(volatile uint32_t *)(CLB1_BASE + CLB_PULL_0_OFFSET)) // 直接向 PULL FIFO 0 写入数据 CLB_PULL_0_ADDR = 0xA5A5A5A5; // 直接从 PUSH FIFO 读取数据（假设地址已知） uint32_t received_data = SOME_PUSH_REGISTER_ADDR;

这么做的优势很明显：

• 极致性能：没有函数调用开销，就是一次内存写操作，速度最快。
• 完全控制：你可以精确控制每一个比特位，实现一些非常规或底层的操作。
• 代码精简：对于简单的、一次性的配置，直接赋值可能比调用一个多参数的函数更简洁。

但陷阱更多，尤其是对于CLB这样复杂的模块：

1. 地址错误：手册中的偏移量计算（如100h + (y * 2h)）必须绝对准确。一个字节算错，操作的就是完全不同的寄存器，可能导致系统崩溃。
2. 位域操作繁琐：很多寄存器的一个32位值包含多个独立字段。直接赋值会覆盖所有字段，你需要用“读-改-写”模式来安全地修改其中一部分，代码冗长且易错。

   // 错误：直接覆盖，可能破坏其他配置位 SOME_CONFIG_REG = 0x00000001; // 正确：读-改-写 uint32_t temp = SOME_CONFIG_REG; temp &= ~(0xF << 4); // 清空第4-7位 temp |= (0x1 << 4); // 设置第4-7位为1 SOME_CONFIG_REG = temp;

3. 可读性差：0x5F000100这样的“魔法数字”遍布代码，几个月后你自己都看不懂当初想干嘛。
4. 可移植性为零：如果TI未来推出新芯片，寄存器地址或布局变了，你的代码需要全部重写。
5. 同步与状态问题：对于PULL/PUSH这类FIFO寄存器，直接读写前必须检查FIFO状态（空/满），否则会造成数据丢失或写入阻塞。而手册明确提到CLB_PULL_y寄存器上电复位后是随机值，直接读取可能得到垃圾数据。

正是这些陷阱，使得在大型、复杂的项目中对所有寄存器进行直接编程变得非常危险且难以维护。这时，Driverlib函数库的价值就凸显出来了。

3. CLB_PULL_y寄存器深度解析与FIFO操作机制

让我们聚焦到输入内容中提到的CLB_PULL_y寄存器，这是一个理解CLB与系统交互的绝佳范例。

3.1 寄存器位域与物理含义

根据手册描述，CLB_PULL_y寄存器是一个32位可读写寄存器，从bit 31到bit 0只有一个字段，就叫PULL。这看起来非常简单，但内涵丰富。

• 偏移地址公式：Offset = 100h + (y * 2h)，其中y = 0h to 3h。
  • 100h是基偏移。
  • y * 2h意味着每个PULLFIFO寄存器占用2个字节（16位）的地址空间？等等，这里有个关键细节！公式是y * 2h，但寄存器是32位（4字节）。这可能是手册排版或表述上的简化。实际上，在内存映射中，32位寄存器通常是4字节对��的。更常见的理解是，y是索引，每个PULL寄存器占用4字节空间，偏移量可能是0x100 + y * 0x4。在实际编程中，我们必须以芯片头文件（如F2837xD_clb.h）或Driverlib中定义的常量为准，切勿仅凭手册公式计算。Driverlib的CLB_writeFIFOs()函数内部已经处理好了这些地址计算。
• 功能：FIFO From system TO CLB。这是一个单向的、从系统（CPU或DMA）到CLB模块内部的FIFO。系统写入数据，CLB逻辑在内部可以读取并消费这些数据。
• 复位值：这是一个极其重要的注意事项。手册明确写道：“The PULL FIFO register does not get reset, so random values are expected upon power-on reset.” 这意味着上电后，这个FIFO存储单元里的内容是未定义的、随机的。你不能假设它初始为空或为0。

3.2 FIFO操作的安全范式与常见误区

基于以上特性，安全操作PULLFIFO必须遵循严格的软件流程：

1. 初始化时必须显式清空：在CLB模块使能或开始使用FIFO前，必须调用CLB_clearFIFOs()函数（它同时清除PULL和PUSHFIFO）。这是清除上电随机值的唯一可靠方法。直接向寄存器写0是无效的，因为FIFO的读写指针和状态逻辑可能不在这个可访问的寄存器内。

2. 写入前检查FIFO状态（非满）：虽然CLB_PULL_y寄存器本身没有“满”标志位，但CLB模块通常有全局状态寄存器或通过其他逻辑（如输出信号）来指示FIFO状态。Driverlib的CLB_writeFIFOs()函数内部应该包含了必要的检查，或者你需要根据CLB的设计，在写入前通过查询DBG_OUT（调试输出）或其他自定义状态信号来判断FIFO是否已满。盲目写入满的FIFO会导致数据丢失。

3. 理解数据消费机制：数据写入PULLFIFO后，如何被CLB逻辑使用？这取决于你在CLB逻辑设计（通过TI的CLB工具图形化配置或直接配置相关寄存器）时，如何将PULLFIFO的数据输出连接到内部的LUT、FSM或计数器作为输入。你需要确保CLB逻辑能及时“拉取”数据，否则FIFO会积压直至写满。

一个典型的操作误区实录： 我曾遇到过一个问题，CLB逻辑似乎对写入的数据没有反应。调试后发现，我虽然调用了CLB_writeFIFOs()，但在CLB的图形化配置中，我忘记将PULLFIFO的输出信号连接到内部逻辑块的输入多路选择器上。这就好比往一个水桶里倒水，但水桶底部没有接水管，水永远流不到需要的地方。教训是：Driverlib函数只负责把数据放到“交接点”（FIFO），数据能否被CLB逻辑使用，完全取决于CLB内部的硬件连接配置。

4. Driverlib函数库：抽象、封装与最佳实践

Driverlib是TI提供的一套硬件抽象层函数库，它的目标就是将复杂的寄存器操作封装成语义清晰、易于使用且安全的API。

4.1 函数映射表解读与设计哲学

输入内容中的Table 26-74是一份宝贵的“翻译词典”。我们选取几个典型例子来分析其设计思路：

1. 一对一简单映射：

   • GP_REG->CLB_setGPREG()/CLB_getGPREG()
   • OUT_EN->CLB_setOutputMask()
   • 这类寄存器功能单一（设置/获取通用寄存器、设置输出使能掩码），Driverlib用简单的set/get函数封装，隐藏了寄存器地址和位操作细节。

2. 一对多功能聚合：

   • LOAD_EN,LOAD_ADDR,LOAD_DATA->CLB_writeInterface()
   • 这三个寄存器共同协作完成向CLB配置逻辑（LUT/FSM等）写入数据的操作。Driverlib将它们合并到一个函数CLB_writeInterface()中，你只需要提供地址和数据，函数内部会按正确的时序操作这三个寄存器。这防止了开发者因操作顺序错误而导致的配置失败，是Driverlib核心价值之一。

3. 多对一复杂配置：

   • LUT4_IN0~LUT4_IN3->CLB_selectLUT4Inputs()
   • FSM_NEXT_STATE_0~FSM_NEXT_STATE_2->CLB_configFSMNextState()
   • 这类函数对应多个寄存器。例如，配置一个LUT4的4个输入源，你需要写4个寄存器。Driverlib用一个函数接收一个结构体参数（包含4个输入选择），一次性完成所有配置。这保证了配置的原子性和便捷性。

4. 高级抽象与状态管理：

   • PULL->CLB_writeFIFOs()/CLB_clearFIFOs()
   • PUSH->CLB_readFIFOs()/CLB_clearFIFOs()
   • 这里映射关系不是严格的一对一。CLB_clearFIFOs()函数同时操作了BUF_PTR、PULL和PUSH相关的底层控制逻辑，来完成整个FIFO系统的复位。CLB_writeFIFOs()和CLB_readFIFOs()则可能内部包含了FIFO索引管理、状态检查等更多操作。Driverlib在这里提供的是“操作语义”（写入FIFO、读取FIFO、清空FIFO），而非简单的寄存器包装。

4.2 使用Driverlib的正确姿势与避坑指南

1. 始终包含正确的头文件和链接库：

#include "driverlib.h" // 主头文件 #include "F2837xD_clb.h" // CLB相关的寄存器定义和Driverlib函数声明 // 确保你的工程路径和编译设置正确包含了这些文件。

2. 理解函数参数的数据结构： 很多CLB配置函数使用结构体作为参数。不要试图直接给结构体成员赋“魔法数值”。

// 推荐：使用Driverlib提供的宏或枚举值 CLB_ConfigLUT4Inputs myLUTInputs; myLUTInputs.input0 = CLB_INPUT_MUX_SELECT_GPREG; // 使用有意义的枚举 myLUTInputs.input1 = CLB_INPUT_MUX_SELECT_FSM_OUT; // ... 而不是 myLUTInputs.input0 = 0x03; CLB_selectLUT4Inputs(CLB1_BASE, CLB_LUT_0, &myLUTInputs);

3. 注意配置顺序和模块使能： CLB的配置有依赖关系。通常的推荐顺序是：

• 步骤一：使用CLB_disableCLB()禁用CLB模块（如果之前已启用）。在模块禁用时进行配置更安全。
• 步骤二：配置输入多路选择器(CLB_configGPInputMux,CLB_configLocalInputMux等)。
• 步骤三：配置核心逻辑单元（LUT函数CLB_configLUT4Function、FSM状态表CLB_configFSMNextState等）。
• 步骤四：配置输出逻辑(CLB_configOutputLUT)和输出使能(CLB_setOutputMask)。
• 步骤五：配置全局控制，如事件选择(CLB_configHLCEventSelect)、杂项控制(CLB_configMiscCtrlModes)。
• 步骤六：清空FIFO(CLB_clearFIFOs)。
• 步骤七：最后使用CLB_enableCLB()使能模块。

4. 善用Driverlib的“获取”函数进行调试： 当你配置后逻辑不工作时，不要只盯着写配置的代码。使用CLB_getGPREG()、CLB_getOutputStatus()、CLB_getInterruptTag()等函数读取当前硬件状态，与你的预期进行对比。这是定位是软件配置错误还是硬件逻辑设计错误的关键。

5. 混合编程的注意事项： 有时为了极致的性能或实现Driverlib未封装的功能，我们可能需要在Driverlib的基础上混合一些直接的寄存器操作。如果必须这样做，请务必：

• 仔细阅读手册，确认该寄存器操作是否与Driverlib函数有隐含的时序或状态依赖。
• 将直接寄存器操作代码用明显的注释和封装函数隔离起来。
• 在修改可能与Driverlib共同操作的寄存器组（如控制寄存器）时，要格外小心竞争条件。

5. 实战：从寄存器手册到可运行代码的完整流程

让我们以一个具体的场景为例，将上述所有知识串���起来：使用CLB的PULL FIFO 0，接收来自CPU的32位命令字，当命令字等于特定值时，触发一个输出脉冲。

5.1 步骤一：硬件逻辑设计（CLB配置）

这一步通常在TI的CLB配置工具（如SysConfig图形化工具）中完成，它会生成配置代码。��理解其对应的寄存器操作很重要。

1. 配置输入：将PULLFIFO 0的数据输出连接到某个内部总线（例如LUT4_IN0的输入源之一）。这对应配置LUT4_IN0等寄存器，在Driverlib中即调用CLB_selectLUT4Inputs()，指定其中一个输入来自CLB_INPUT_FIFO0_DATA。
2. 配置比较逻辑：使用一个LUT4（假设为LUT0）实现比较功能。我们需要配置其输入：一个来自上述FIFO数据总线，另一个连接到一个常量值（可能来自GP_REG）。然后配置LUT4_FN1_0等寄存器，让LUT0执行“相等比较”的布尔函数。这对应CLB_configLUT4Function()。
3. 配置输出：将LUT0的比较结果输出连接到某个物理输出引脚。配置OUTPUT_LUT_0和OUT_EN寄存器，对应CLB_configOutputLUT()和CLB_setOutputMask()。

5.2 步骤二：软件驱动编写

硬件逻辑“布线”完成后，软件需要负责喂数据和协调。

// 1. 初始化与配置 void CLB_CommandTrigger_Init(void) { // 假设CLB1_BASE, CLB_LUT_0等已定义 // 禁用CLB CLB_disableCLB(CLB1_BASE); // 调用由配置工具生成的函数，或手动调用一系列CLB_config...函数 // 例如：CLB_selectLUT4Inputs(...); CLB_configLUT4Function(...); // 这里省略具体的配置代码，由工具生成。 // ！！！关键步骤：清空FIFO，清除上电随机值 CLB_clearFIFOs(CLB1_BASE); // 使能CLB CLB_enableCLB(CLB1_BASE); } // 2. 发送命令的应用程序代码 bool CLB_SendCommand(uint32_t command) { // 在实际项目中，这里应该检查FIFO是否非满。 // 可以通过读取CLB的某个状态输出（连接到GPIO或中断）来判断， // 或者如果FIFO深度足够且消费及时，可以简化处理。 // 使用Driverlib函数写入FIFO CLB_writeFIFOs(CLB1_BASE, CLB_FIFO_PULL_0, &command, 1); // 写入1个数据到PULL FIFO 0 return true; // 或根据状态检查返回成功/失败 } // 3. 主循环或中断服务例程中的应用 int main(void) { // ... 系统初始化 CLB_CommandTrigger_Init(); while(1) { // 当需要触发时 if (some_condition) { CLB_SendCommand(TARGET_COMMAND_VALUE); // 例如 TARGET_COMMAND_VALUE = 0xAA55AA55 } // ... 其他任务 } }

5.3 调试与问题排查实录

即使按照上述流程，你可能还是会遇到问题。以下是我踩过的坑和解决方法：

• 问题1：写入命令后，输出引脚毫无反应。

  • 排查：
    1. 使用调试器，单步执行CLB_SendCommand，确认CLB_writeFIFOs函数被调用且参数正确。
    2. 检查CLB_CommandTrigger_Init中是否真的调用了CLB_clearFIFOs？我曾在初始化函数中漏掉这一行。
    3. 使用寄存器查看窗口：在调试器中，查看CLB_PULL_0寄存器（或其映射的内存地址）在写入后值是否正确。同时，查看OUTPUT_LUT_0相关的寄存器值，确认输出逻辑是否被正确触发。
    4. 检查CLB逻辑配置是否真的将FIFO数据与常量进行了“相等”比较。一个常见错误是在配置工具中选错了比较运算符。

• 问题2：输出信号偶尔有误触发，或者反应延迟不稳定。

  • 排查：
    1. FIFO溢出：这是最可能的原因。如果CPU写入命令的速度快于CLB逻辑处理（消费）的速度，FIFO会满。后续的写入可能被阻塞或丢弃。需要在CLB_SendCommand中加入FIFO状态检查。状态检查的方法取决于你的CLB设计：可以配置当FIFO非满时，CLB输出一个“就绪”信号到某个GPIO，软件查询该GPIO；或者使用FIFO的“可写”状态触发一个CPU中断。
    2. 时钟同步问题：CLB模块和CPU总线可能运行在不同时钟域。INPUT_FILTER寄存器中的同步器使能位（通过CLB_enableSynchronization）是否已打开？对于来自异步域（如CPU写入）的信号，通常需要使能同步器以避免亚稳态。这是一个硬件层面的常见问题，Driverlib的CLB_enableSynchronization函数就是用来配置这个的。

• 问题3：系统运行一段时间后，CLB逻辑功能紊乱。

  • 排查：
    1. 寄存器意外写入：检查代码中是否有其他部分（可能是DMA、或其他任务）错误地写入了CLB的配置空间。使用Driverlib函数可以最大程度避免这种地址错误。
    2. 电源或噪声干扰：在电机控制等强干扰环境中，需要检查PCB的电源完整性和信号完整性。CLB是数字逻辑，对电源噪声敏感。
    3. 查看LOCK寄存器：LOCK寄存器（CLB_enableLock）可以锁定CLB配置，防止意外修改。在初始化配置完成后，可以考虑启用锁功能。

6. 进阶：混合编程、性能考量与自定义封装

当你对基本操作驾轻就熟后，可以考虑一些进阶话题。

6.1 何时可以（谨慎地）混合寄存器直接操作

Driverlib已经覆盖了绝大多数场景，但在以下情况，直接操作寄存器可能是合理的：

1. 极高频的FIFO操作：如果需要在极短的中断服务程序内连续写入多个FIFO数据，为了消除函数调用开销，可以考虑在确保FIFO不会满的前提下，用内联函数或宏进行直接内存写入。但必须做好充分的保护和注释。

   #define CLB1_PULL0 (*((volatile uint32_t *)0x5F000100)) // 在时间关键的循环中 for(int i=0; i<BURST_SIZE; i++) { CLB1_PULL0 = data_buffer[i]; }

2. 访问未封装的调试寄存器：手册中DBG_R0~DBG_R3、DBG_C0~DBG_C2等寄存器，Driverlib可能没有提供直接的get/set函数。如果你想实时监视CLB内部计数器的值，可能需要直接读取这些寄存器。

重要警告：混合编程时，你必须非常清楚Driverlib函数内部做了什么。例如，如果你直接操作了LOAD_ADDR和LOAD_DATA寄存器，就绕过了CLB_writeInterface()函数内部的时序和状态管理，可能导致配置失败。

6.2 针对特定应用的Driverlib二次封装

对于项目中的特定CLB功能模块，创建自己的封装层是提升代码可读性和可维护性的好方法。

// my_clb_command_engine.h typedef struct { uint32_t targetCommand; uint32_t fifoBaseAddr; // 抽象，内部可能使用CLB1_BASE和FIFO索引 } MyCommandEngine; void MyCommandEngine_Init(MyCommandEngine *eng, uint32_t targetCmd); bool MyCommandEngine_Send(MyCommandEngine *eng, uint32_t cmd); bool MyCommandEngine_IsReady(const MyCommandEngine *eng); // 检查FIFO状态 // my_clb_command_engine.c #include "my_clb_command_engine.h" #include "F2837xD_clb.h" void MyCommandEngine_Init(MyCommandEngine *eng, uint32_t targetCmd) { eng->targetCommand = targetCmd; eng->fifoBaseAddr = CLB1_BASE; // 假设固定使用CLB1 // 内部调用一系列Driverlib函数进行硬件配置 CLB_disableCLB(eng->fifoBaseAddr); // ... 详细的CLB逻辑配置（可来自工具生成代码） CLB_clearFIFOs(eng->fifoBaseAddr); CLB_enableCLB(eng->fifoBaseAddr); } bool MyCommandEngine_Send(MyCommandEngine *eng, uint32_t cmd) { if(cmd == eng->targetCommand && MyCommandEngine_IsReady(eng)) { CLB_writeFIFOs(eng->fifoBaseAddr, CLB_FIFO_PULL_0, &cmd, 1); return true; } return false; }

这样的封装将CLB的硬件细节和Driverlib调用隐藏起来，对应用层只暴露业务相关的接口，使得主程序代码更加清晰，也更容易进行单元测试和模块替换。

从直接面对CLB_PULL_y这样冰冷的寄存器地址，到熟练调用CLB_writeFIFOs这样语义清晰的函数，再到能根据项目需求进行合理的架构设计和封装，这条学习路径体现了一名嵌入式开发者从“操作硬件”到“驾驭硬件”的成长。TI提供Driverlib的初衷，绝不是���夺开发者对硬件的控制权，而是提供一座安全、高效的桥梁，让我们能把更多精力聚焦在实现创新的逻辑功能和应用本身，而不是在繁琐易错的地址和位域操作中挣扎。理解这份寄存器到函数的映射表，就是拿到了这座桥梁的构造图，它能让你走得更稳、更远。最后，我的个人习惯是在项目初期，将所用到的所有CLB相关Driverlib函数调用和关键寄存器配置，整理在一个独立的.c/.h文件里，并附上详细的注释说明其对应的硬件功能模块。这份文档在后期调试和团队交接时，价值连城。