-
Linux C 中的内存屏障是什么？
一、内存屏障 在 Linux C 语言编程 中，内存屏障（Memory Barrier） 是一种用于控制内存访问顺序的技术。它主要用于多处理器系统中，确保某些操作按预期顺序执行，避免 CPU 和编译器对内存访问进行优化，从而影响程序的正确性。内存屏障的功能在多线程和并发编程中尤为重要。 什么是内存屏障？ 内存屏障的障中文意思是保护和隔离的，也有阻止的意思，阻止的是CPU对变量的继续访问，停下来更新下变量，从而保护变量的一致性。 内存屏障是针对线程所有共享变量的，而原子操作仅针对当前原子变量。 内存屏障是一种指令，它的作用是禁止 CPU 重新排序特定的内存操作。它确保在屏障之前的所有读/写操作在屏障之后的操作之前完成。内存屏障一般被用来控制多处理器环境中的内存可见性问题，尤其是在进行原子操作、锁和同步时。 在多核处理器上，每个处理器都有自己的缓存，CPU 会将内存操作缓存到自己的本地缓存中。在不同的 CPU 之间，内存的可见性并非立刻同步，这就可能导致不同线程看到不同的内存值。通过内存屏障，可以确保特定的操作顺序，以避免此类问题。 内存屏障的类型 Linux C 中，内存屏障通常有以下几种类型，主要通过内核提供的原子操作或者内存屏障函数来实现。 1.全屏障（Full Barrier 或者 LFENCE、SFENCE）： 作用：以下两种相加。 用途：确保所有的内存操作都在内存屏障前完成，通常用于同步和锁定操作。 内核函数：mb() (Memory Barrier) 2.读屏障（Read Barrier 或者 LFENCE）： 作用：保证屏障之前的所有读操作在屏障之后的读操作之前完成。---》翻译过来的有歧义，难以理解，那个“完成”是缓存同步主内存的意思。 本质：作用是强制将 CPU核心 中的 L1/L2 缓存 中的共享变量值写回到 主内存。 用途：在执行并行读操作时确保读顺序。 内核函数：rmb() (Read Memory Barrier) 3.写屏障（Write Barrier 或者 SFENCE）： 作用：保证屏障之前的所有写操作在屏障之后的写操作之前完成。--》翻译过来有歧义，难以理解，那个“完成”是主内存同步到缓存的意思。 本质：作用是强制使数据从主内存加载，而不是直接使用可能已经过时的缓存数据。 用途：用于确保写操作顺序。 内核函数：wmb() (Write Memory Barrier) 4.无序屏障（No-op Barrier）： 作用：没有实际影响，仅确保 CPU 不会重排序特定的指令。 用途：常用于确保指令的顺序性而不做其他强制性的内存同步。 读写屏障的作用域 读写屏障的作用域并不局限于当前函数或者某个函数调用的局部作用域，而是影响整个 当前线程的内存访问顺序。也就是说，只要在当前线程中，任何在屏障前后的内存操作都会受到屏障影响，而不管这些操作发生在同一个函数里还是不同的函数中。 线程之间的隔离 读写屏障是 线程级别的，因此它们只影响执行这些屏障操作的线程。也就是说，如果线程 1 执行了写屏障，它只会影响线程 1 后续的内存操作，而不会直接影响其他线程。---》翻译过来的，其实就是这个线程的读写屏障只会引发自己线程变量与主内存的同步，管不到其他线程的同步。但是写屏障触发后 会 通知其他线程，如果有现代 CPU 使用缓存一致性协议（如 MESI）的话，其他线程会把主内存中的最新值更新到自己缓存中。 读屏障不会触发其他线程去把自己的缓存同步到主内存中。 如果想让多个线程之间的共享变量同步并保持一致性，通常需要在多线程间使用某些同步机制（如锁、原子操作等），而不仅仅是依赖于单个线程的屏障。 具体来说： 写屏障（Write Barrier）：会影响所有在屏障之前执行的写操作，无论这些写操作发生在当前函数内还是其他函数中。它确保屏障前的所有写操作都能同步到主内存，任何与此线程共享的缓存都能看到这些值。 读屏障（Read Barrier）：会影响所有在屏障之后执行的读操作，确保这些读操作从主内存读取最新的值，而不是从 CPU 核心的缓存中读取过时的值。读屏障会影响当前线程的所有后续读取操作，无论这些读取发生在哪个函数中。 内存屏障的使用 在 Linux 中，内存屏障主要通过一组原子操作宏来提供。这些操作用于确保不同 CPU 或线程之间的内存同步。常见的内存屏障宏包括： mb()：全屏障，防止 CPU 重排序所有内存操作。 rmb()：读屏障，确保屏障之前的所有读操作完成。 wmb()：写屏障，确保屏障之前的所有写操作完成。 示例代码 #include #include #define wmb() __asm__ __volatile__("sfence" ::: "memory") // 写屏障#define rmb() __asm__ __volatile__("lfence" ::: "memory") // 读屏障#define mb() __asm__ __volatile__("mfence" ::: "memory") // 全屏障 void example_memory_barrier() { int shared_variable = 0; // 写入数据 shared_variable = 42; // 在这里使用写屏障，确保共享变量的写操作 // 在执行屏障之后才会完成 wmb(); // 读取共享数据 printf("Shared Variable: %d\n", shared_variable); // 使用读屏障，确保屏障前的所有读取操作完成 rmb(); // 这里是确保顺序执行的一部分 printf("Shared Variable read again: %d\n", shared_variable);} int main() { example_memory_barrier(); return 0;} 为什么需要内存屏障？ 避免重排序：编译器和 CPU 会对内存访问进行优化，尤其是在多处理器系统中，这可能导致指令执行顺序与预期不一致，进而导致错误的程序行为。 保证内存一致性：当一个线程或 CPU 修改共享变量时，其他线程或 CPU 可能会看到不同的内存值，内存屏障可以保证修改操作在其他线程中是可见的。 同步操作：在多线程或多处理器环境中，内存屏障确保执行顺序和同步的正确性，尤其是在没有锁或原子操作的情况下。 缓存一致性协议（例如 MESI） 为了保证多核处理器之间缓存的数据一致性，现代 CPU 会使用缓存一致性协议（如MESI 协议，即 Modified、Exclusive、Shared、Invalid）。这个协议的作用是确保一个核心的缓存修改在其他核心的缓存中得到更新，避免出现“脏数据”。 但即便如此，MESI 协议的具体实现仍然依赖于硬件，缓存之间的同步可能不会在每一次内存访问时都发生。尤其是在没有任何同步机制的情况下，一个线程修改的值可能会暂时不被另一个线程看到，直到某些缓存刷新或同步操作发生。 Linux 内核中的内存屏障 在 Linux 内核中，内存屏障主要是通过原子操作来实现的。例如，atomic_set、atomic_add 等原子操作通常会隐式地使用内存屏障来保证内存操作顺序。而直接的内存屏障通常通过 mb()、wmb() 和 rmb() 函数来实现。 总结 内存屏障在多核处理器和并发程序中非常重要，用于控制内存操作顺序，避免由于硬件优化或编译器优化引起的内存同步问题。Linux 提供了多种类型的内存屏障函数，程序员可以根据需要使用它们来确保内存操作的顺序性。 需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享 二、变量存贮与内存屏障 你提到的问题涉及 程序执行过程中变量的存储位置、内存可见性和线程切换 的多个方面。为了更清晰地解释，我们需要从操作系统的内存管理和多线程模型入手。 1. 程序执行前变量存在哪里？ 在程序执行之前，变量的存储位置主要依赖于变量的类型和生命周期。变量可以存储在以下几个区域： 栈区（Stack）：局部变量通常会被分配到栈中。栈是线程私有的，每个线程都有一个独立的栈空间。 堆区（Heap）：动态分配的内存（通过 malloc()、free() 等）会被存储在堆中。堆是共享的，不同线程可以访问堆中的数据。 全局区/静态区（Data Segment）：全局变量和静态变量通常存储在数据段中。在程序启动时，数据段会被分配并初始化。 代码区（Text Segment）：存储程序的代码（即机器指令），线程不直接操作。 2. 线程对变量的修改，为什么对其他线程不可见？ 当一个线程修改了它的某个变量的值，这个变量的值并不一定立即对其他线程可见，主要是因为现代处理器通常会有缓存（Cache），并且每个线程可能在自己的寄存器或局部缓存中执行操作。具体原因如下： CPU 缓存：每个 CPU 核心都有自己的缓存（例如 L1、L2 Cache），当一个线程运行时，它可能会先将某个变量加载到本地缓存中进行修改，而不是直接操作主内存。这样，修改后的值可能不会立刻反映到主内存中。 内存可见性问题：因为不同的线程可能运行在不同的 CPU 核心上，并且每个核心有自己的缓存系统，其他线程（在不同的 CPU 核心上）可能无法直接看到修改后的变量值。除非通过某种同步机制（如内存屏障、锁、原子操作等）确保所有 CPU 核心的缓存一致性，否则修改的值不会立刻对其他线程可见。 3. 线程被切换时，变量的值存储到哪里？ 当一个线程被 调度器切换（例如，从运行状态切换到阻塞状态或就绪状态）时，操作系统会保存该线程的 上下文（即该线程当前的执行状态）。这个过程称为 上下文切换。 CPU 寄存器：线程的 寄存器状态（包括程序计数器、栈指针、CPU 寄存器中的数据等）会被保存在操作系统为该线程分配的 线程控制块（TCB） 中，或者在内核中由特定的机制（如进程控制块、线程栈）保存。 内存：栈中的局部变量会被存储在 栈区，这些数据在线程切换时保持不变，直到线程恢复时。 CPU 缓存：在某些情况下，线程切换后，CPU 的缓存中的数据可能会被清除或更新，以保证在切换后的线程恢复时能正确访问内存。 4. 缓存与主内存 在现代多核处理器上，每个 CPU 核心（CPU Core）通常有自己的 本地缓存（例如 L1 缓存、L2 缓存，甚至是更高层的缓存）。这些缓存的作用是加速内存访问，避免每次访问内存时都直接访问主内存（RAM）。因此，当线程对某个变量进行修改时，这个变量的值首先会被写入到该线程所在 CPU 核心的 缓存 中，而不一定立即写回到主内存。 5. 另一个线程接着运行，变量值从哪里拿？ 当一个线程被切换出去后，另一个线程会接管 CPU 的执行，并且继续执行自己的代码。另一个线程获取变量的值依赖于以下几个因素： 内存一致性：如果没有任何内存屏障或同步机制，另一个线程可能会读取到一个过时的缓存值。原因是线程 1 在修改变量时，可能只是修改了本地缓存，而没有把新值写回到主内存中；而线程 2 可能仍然读取到线程 1 的旧值。 线程间同步：为了确保变量的最新值在多个线程之间可见，通常需要使用 同步原语（如互斥锁 mutex、条件变量 condvar、原子操作等）。如果使用了如 mutex 锁定共享资源，或者使用了 volatile 关键字或原子操作，线程间对变量的修改才会更可靠地同步和可见。 缓存一致性协议：现代 CPU 通常使用 缓存一致性协议（如 MESI 协议）来确保不同 CPU 核心之间缓存的一致性。当一个线程修改某个变量时，其他线程会通过协议获取这个变量的最新值，避免缓存中的脏数据。 6. CPU 缓存与线程切换 这里有一个关键点：线程切换并不意味着缓存被清除。如果线程 1 在 CPU 核心 A 上运行，修改了全局变量，并且这个修改存储在核心 A 的缓存中，线程 1 被切换出去，CPU 核心 A 的缓存不会因为线程切换而清空。即使切换到其他线程，CPU 仍然会保留 核心 A 的缓存内容。 当线程 2 在另一个 CPU 核心 B 上开始运行时，如果它访问相同的全局变量，它会根据 自己核心的缓存 来读取这个变量。如果线程 2 看到的是旧值，那么它就是从 核心 B 的缓存 中拿到的旧值，而不是从主内存 中读取的。 7. 内存一致性问题 内存一致性问题通常出现在 多核处理器 中，特别是当多个线程运行在不同的 CPU 核心上时。在这种情况下： 线程 1 可能修改了一个全局变量的值，线程 1 所在的 CPU 核心会将该变量的新值写入到 该核心的缓存（例如 L1 或 L2 缓存）中。 如果 线程 2 运行在 另一个 CPU 核心 上，它可能会直接从 自己本地的缓存 中读取这个变量，而不是从主内存读取。假如线程 2 在缓存中读取到的是 线程 1 之前的旧值（而不是修改后的新值），那么线程 2 就读取到过时的值。 8. 为什么会有内存屏障？ 由于多核处理器中的 CPU 会对内存操作进行缓存优化，内存屏障（mb()、wmb()、rmb()）的作用是 强制同步 内存操作，确保某些操作的顺序性和内存可见性。通过内存屏障，操作系统或程序员可以确保在特定的内存操作之前或之后的操作按顺序执行，避免缓存带来的不一致性。 9. 为什么一个线程拿到的值可能会是旧的？ 这个问题的核心在于 缓存一致性 和 内存可见性： 每个 CPU 核心都有独立的缓存，这意味着它们的缓存可能保存着不同版本的内存数据。 当线程 1 修改变量时，虽然它的 本地缓存 中的数据会被更新，但主内存的更新可能并没有立刻发生，或者其他 CPU 核心的缓存并没有得到通知。 如果没有同步机制（如内存屏障、锁、原子操作等），线程 2 可能会继续读取到旧的缓存值，而不是线程 1 修改后的新值。 10. 综述：内存模型和线程切换 在现代操作系统和多核处理器中，内存模型非常复杂。通过以下几个概念可以理解线程的内存操作： 每个线程有自己的栈，但共享堆和全局变量。 缓存一致性问题：线程修改的变量不会立刻对其他线程可见。 上下文切换：线程切换时，寄存器、栈等状态会保存，并由操作系统恢复。 内存屏障和同步机制：确保变量在多个线程之间同步和可见。 示例 假设有两个线程 A 和 B，它们都操作同一个共享变量 x。假设线程 A 修改了 x 的值，但由于没有同步机制，线程 B 可能不会立刻看到修改后的值。 int x = 0; // 共享变量 void thread_a() { x = 1; // 修改共享变量 wmb(); // 写屏障，确保修改的值会被其他线程看到} void thread_b() { rmb(); // 读屏障，确保读取的是线程 A 修改后的值 printf("%d\n", x); // 打印 x 的值} 总结 线程修改变量时，该变量可能存在于不同的缓存中，其他线程可能无法看到更新的值。 上下文切换时，线程的寄存器和栈会被保存在操作系统的上下文中，恢复时会读取这些数据。 内存屏障 用于控制内存操作的顺序性，确保修改的值能在不同线程间同步。 三、编译器屏障 编译器屏障（Compiler Barrier）是一种用于控制编译器优化的机制，用来确保编译器在生成代码时不会对某些操作进行重排或优化，尤其是在多线程编程和硬件相关编程中非常重要。编译器屏障并不直接控制内存访问，而是用来防止编译器对指令的顺序进行不合适的重新排序，确保代码按照预期的顺序执行。 编译器屏障的作用 编译器屏障主要用于控制编译器如何处理代码中的指令顺序，尤其是： 防止指令重排序：编译器优化时可能会改变指令的顺序，重新排序内存访问或者其他指令。这可能导致多线程程序中某些预期的同步行为失败。编译器屏障防止这种行为。 确保指令的执行顺序：在多核处理器或并发编程中，编译器屏障确保某些关键操作（比如内存访问）在正确的顺序中执行，避免因编译器优化导致的不一致性。 编译器屏障与内存屏障的区别 编译器屏障（Compiler Barrier）: 它的目的是确保编译器不会对代码进行不合理的优化或重排序，特别是在涉及并发或多核时。 编译器屏障不能强制 CPU 层面执行同步操作，仅仅是防止编译器重排代码。 内存屏障（Memory Barrier）: 内存屏障则是用于确保在多核或多线程环境中，内存访问按照特定的顺序发生，它直接控制内存操作和硬件级别的缓存同步。 内存屏障不仅防止编译器重排，也会影响 CPU 对内存的读取和写入顺序。 编译器屏障的实际应用 编译器屏障通常用于那些需要确保内存或操作顺序的场景，尤其是在处理低级硬件和并发编程时。下面是一些编译器屏障的常见应用场景： 原子操作：在使用原子操作（比如 atomic_add）时，编译器屏障可用于确保原子操作的顺序性。 多线程同步：当线程间存在共享数据时，编译器屏障可以防止编译器重排序线程的操作，以保证正确的同步。 硬件访问：在直接操作硬件时，编译器屏障可以确保 I/O 操作按预期顺序执行，而不被编译器优化掉。 编译器屏障的实现 不同的编译器提供不同的方式来实现编译器屏障。常见的做法包括： volatile 关键字：在 C/C++ 中，volatile 可以告诉编译器不要优化对变量的访问，通常用于内存映射 I/O 或多线程共享变量。虽然它可以防止编译器优化，但它并不能防止 CPU 缓存重排序。 内联汇编：编译器屏障还可以通过内联汇编来实现。许多编译器（如 GCC）支持特定的内联汇编指令，用于告诉编译器不要重排某些指令。例如，GCC 提供了 asm volatile 来控制编译器优化。 编译器内置指令：某些编译器提供内置指令来实现编译器屏障。例如，GCC 中有 __asm__ __volatile__ ("": : : "memory")，这是一个编译器屏障，它不会生成任何机器指令，但会告知编译器不要重排此位置的内存操作。 示例：GCC 中的编译器屏障 在 GCC 中，可以使用 __asm__ __volatile__ ("": : : "memory") 来插入一个编译器屏障。它告诉编译器不要重新排序此点前后的内存操作。 示例代码： #include volatile int shared_var = 0; void func1() { shared_var = 1; // 修改共享变量 __asm__ __volatile__ ("" : : : "memory"); // 插入编译器屏障} void func2() { int local = shared_var; // 读取共享变量 printf("shared_var = %d\n", local);} int main() { func1(); func2(); return 0;} 在这个示例中，__asm__ __volatile__ ("" : : : "memory")强制插入一个编译器屏障，确保编译器在执行shared_var = 1和shared_var之间的读写操作时不会对它们进行优化或重排序。 编译器屏障的局限性 虽然编译器屏障可以阻止编译器对代码的优化，但它并不能保证在多核处理器上，缓存之间的同步或内存访问的正确顺序。要确保内存的一致性，尤其是跨多个 CPU 核心的同步，还需要使用 内存屏障 或 锁 等同步机制。 总结 编译器屏障 主要用于控制编译器优化，防止编译器对代码执行顺序进行重排序。 它不能控制内存访问的实际顺序，但可以防止编译器错误地优化掉重要的内存操作。 它通常与 内存屏障 一起使用，以确保在多线程或并发环境下的正确性。 四、CPU屏障 CPU 屏障，也常称为 处理器屏障，是一个硬件层面的同步机制，主要用于确保 CPU 在执行指令时按特定的顺序访问内存。它是为了处理 CPU 的 指令重排、内存缓存一致性 和 多核 CPU 系统中的缓存同步 等问题。 在多核系统中，每个 CPU 核心都有自己的缓存（L1, L2, L3 缓存），这些缓存可能存储过时的内存值，导致不同核心之间的数据不一致。CPU 屏障通过硬件指令，确保 CPU 按照特定的顺序执行内存操作，从而解决缓存一致性和内存重排序的问题。 CPU 屏障的作用 防止指令重排：现代 CPU 在执行指令时，通常会对指令进行重排序（指令乱序执行）以提高性能。CPU 屏障确保特定的指令顺序不被改变，避免并发编程中的数据不一致性。 确保内存操作顺序：CPU 屏障通过禁止指令重排和缓存同步，确保内存操作按预期的顺序发生。这对多核处理器尤其重要，避免不同核心之间的数据不一致问题。 控制缓存一致性：当一个核心修改内存中的某个值时，CPU 屏障可以确保这个修改值被写回主内存，并通知其他核心从主内存读取最新的值。 与内存屏障的区别 内存屏障（Memory Barrier） 是一种在软件层面控制 CPU 内存操作顺序的机制。它可以是一个指令，告诉 CPU 按照特定顺序访问内存，避免乱序执行或缓存不一致。 CPU 屏障 则是硬件级别的机制，它通过处理器的硬件指令实现类似的同步操作。CPU 屏障直接控制 CPU 内部的缓存管理和指令流水线，从而确保内存操作的顺序。 CPU 屏障的类型 不同的 CPU 和架构（如 x86、ARM、PowerPC）提供不同的屏障指令，以下是一些常见的屏障类型： 全屏障（Full Barrier）：也叫作 全内存屏障，会确保指令完全按顺序执行，通常会阻止所有的加载（Load）和存储（Store）操作的重排序。全屏障适用于需要完全同步内存访问的场景。 加载屏障（Load Barrier）：用于控制加载指令（读取内存）的顺序，保证在屏障前的加载操作完成后，才能执行屏障后的加载操作。 存储屏障（Store Barrier）：用于控制存储指令（写入内存）的顺序，确保在屏障前的写操作完成后，才能执行屏障后的写操作。 轻量级屏障（Light Barrier）：有些现代 CPU 提供更细粒度的屏障，能够针对特定类型的指令（如仅仅是缓存一致性）进行同步。 典型的 CPU 屏障指令 1. x86 架构： MFENCE：这是 x86 架构中的一个全屏障指令，它确保所有的加载和存储指令在屏障前后都按顺序执行。 LFENCE：加载屏障，用于确保加载操作的顺序。 SFENCE：存储屏障，用于确保存储操作的顺序。 2. ARM 架构： DMB（Data Memory Barrier）：用于确保数据内存操作的顺序。DMB 会阻止内存操作的重排序。 DSB（Data Synchronization Barrier）：一个更强的同步屏障，通常会确保所有的内存操作完成，才会继续执行后续操作。 ISB（Instruction Synchronization Barrier）：强制 CPU 刷新指令流水线，确保指令同步。 3. PowerPC 架构： sync：PowerPC 中的同步指令，强制执行内存访问的顺序。 CPU 屏障的应用场景 多线程编程和并发控制： 在多线程程序中，多个线程可能会同时访问共享内存。使用 CPU 屏障可以确保线程之间的内存操作顺序，从而避免出现数据不一致的情况。 内存模型： 在某些硬件平台上，特别是在不同架构（如 x86 和 ARM）之间进行程序移植时，CPU 屏障能够确保程序按照预期的内存顺序执行。 硬件编程： 对于直接操作硬件的低级编程（例如内存映射 I/O、嵌入式系统开发等），CPU 屏障能够确保 I/O 操作按顺序完成，避免因为缓存一致性问题导致硬件异常。 例子：在 x86 架构中的应用 假设有一个共享变量 shared_var，多个线程可能会修改它。如果不使用 CPU 屏障，线程 1 修改 shared_var 后，可能没有立即刷新到主内存，线程 2 可能会看到过时的缓存数据。 以下是一个简单的 C 代码示例： #include #include volatile int shared_var = 0; void thread1() { shared_var = 1; // 修改共享变量 __asm__ __volatile__ ("mfence" ::: "memory"); // 使用 MFENCE 全屏障，确保写操作完成} void thread2() { while (shared_var == 0) { // 等待 thread1 更新 shared_var } printf("shared_var updated to 1\n");} int main() { // 模拟两个线程 thread1(); thread2(); return 0;} 在这个示例中，thread1 在修改 shared_var 后使用了 mfence 指令来确保修改后的值及时写入主内存，并且被其他线程看到。thread2 会等待 shared_var 更新后继续执行。 总结 CPU 屏障 是硬件层面的机制，用来控制 CPU 内部指令执行顺序和缓存同步，确保内存操作按照特定顺序发生。 它防止 CPU 对指令的重排序，从而避免多核环境中的缓存一致性问题。 不同的 CPU 架构（如 x86、ARM）提供了不同类型的 CPU 屏障指令，如 MFENCE（x86）、DMB（ARM）等。 小结图示 +-------------------------------+ | 主内存（RAM） | | | | +-------------------------+ | | | 共享变量（shared_var） | | | +-------------------------+ | +-------------------------------+ | | v v +----------------+ +----------------+ | 核心 1 | | 核心 2 | | L1 缓存 | | L1 缓存 | | 存储变量值 | | 存储变量值 | +----------------+ +----------------+ | | v v CPU 屏障（如 MFENCE） 强制同步缓存与主内存 通过 CPU 屏障的使用，确保 核心 1 对 shared_var 的修改能正确地同步到主内存，核心 2 可以看到最新的值。 五、使用内存屏障还需要使用CPU屏障吗？ 对于大多数开发人员来说，内存屏障（Memory Barriers）通常是足够的，因为它们是软件级别的同步机制，而CPU 屏障（CPU Barriers）是硬件级别的机制，两者的目标都是确保内存操作按预期顺序执行。内存屏障通过插入特定的指令来控制 CPU 的缓存一致性和内存操作顺序，通常通过编译器提供的原语（如 __sync_synchronize、atomic_thread_fence、mfence 等）来实现。 1. 内存屏障 vs CPU 屏障 内存屏障： 由 程序员显式插入，通常作为一条特殊的汇编指令或者编译器指令。 它确保了程序中的某些内存操作顺序不会被优化或乱序执行。 对于 程序员来说，内存屏障是一个高层的工具，在需要同步共享数据时，它是最常用的同步机制。 CPU 屏障： 是 硬件层面的同步机制，直接控制 CPU 内部的缓存、指令流水线和内存访问顺序。 这些机制通常是针对 处理器架构（如 x86、ARM）的具体硬件指令，用于确保内存操作按顺序发生。 程序员通常 不直接操作 CPU 屏障，而是通过内存屏障指令间接地影响硬件行为。 2. 内存屏障满足开发者需求 对于程序员而言，使用 内存屏障 就足够了，因为： 内存屏障指令是跨平台的，开发人员不需要针对特定的 CPU 指令来编写代码。它们会依赖 编译器 来生成适合特定平台的机器代码。 编译器和操作系统已经为我们处理了硬件的差异。程序员插入的内存屏障会触发适当的 CPU 屏障或其他低层次同步机制，具体取决于目标平台的 CPU 和架构。 在 多核处理器 上，内存屏障确保一个线程对共享数据的修改能够及时写回主内存，并且通知其他线程访问这些数据时能看到最新的值。 3. 实际应用中的差异 3.1. 使用内存屏障 内存屏障（如__sync_synchronize、atomic_thread_fence、mfence）通过插入到代码中来显式指定内存操作顺序，从而控制并发操作时的内存一致性问题。 例如，在多线程编程中，你希望线程 A 在修改共享变量之后，线程 B 能立即看到该修改，可以在 A 中插入内存屏障： #include std::atomic<int> shared_var = 0; void thread_a() { shared_var.store(1, std::memory_order_release); // 写屏障} void thread_b() { while (shared_var.load(std::memory_order_acquire) == 0) { // 等待线程 A 更新 shared_var } // 现在可以安全地使用 shared_var} 在此例中，std::memory_order_release 和 std::memory_order_acquire 就是内存屏障的类型，它们保证了内存操作的顺序。 3.2. CPU 屏障 CPU 屏障是硬件级别的机制。程序员一般不会显式写入 CPU 屏障指令，除非进行非常低级的硬件编程或直接操作硬件。 例如，在嵌入式系统开发或驱动开发中，可能会看到 mfence 或其他处理器指令： __asm__ __volatile__("mfence" ::: "memory"); 在这种情况下，程序员直接插入了硬件指令，显式控制 CPU 执行顺序。但是在 一般应用程序开发 中，通常并不需要手动插入这些指令，而是依赖编译器和标准库中的内存屏障。 4. 总结 对于大多数应用程序开发人员，内存屏障已经足够，不需要直接使用 CPU 屏障指令。编译器会根据目标硬件生成合适的机器代码，确保内存操作的顺序性和一致性。 内存屏障：适用于大多数开发者，提供了一个高层次的同步工具，确保不同线程之间的内存操作顺序。 CPU 屏障：属于硬件层面的操作，通常程序员不需要直接处理，除非进行底层的硬件开发。 5. 应用场景 多线程同步：确保线程对共享数据的修改能够及时生效，避免缓存不一致导致的数据不一致问题。 优化：在多核处理器中，通过内存屏障确保正确的内存操作顺序，避免因指令重排和缓存不一致带来的问题。 6. 建议 a. 如果你在编写并发程序，内存屏障是足够的，尝试使用标准库中的原子操作和内存顺序。 b. 如果你进行低级别硬件编程（例如驱动开发、嵌入式系统），可能需要直接使用 CPU 屏障。 六、“原子操作/互斥锁” 与 “内存屏障” 1. 原子操作与内存屏障的对比 原子操作（Atomic Operation）是对某个特定变量进行原子级别的访问（通常是加、减、交换等操作），它确保操作对这个变量的修改是不可分割的，即操作要么完全执行，要么完全不执行。 原子操作的作用范围：原子操作是针对特定变量的，只会影响该变量的状态，它在进行操作时，也会隐含地执行内存屏障，确保对该变量的修改对其他线程可见。 内存屏障的作用范围：内存屏障则更加广泛，它会影响到线程的所有共享变量，确保整个内存访问顺序符合预期。 简而言之，原子操作是对某个特定变量的一种操作，保证它的正确性；而内存屏障控制的是线程的所有共享变量的访问顺序，确保不同线程之间的同步和一致性。 2. 互斥锁的读写屏障 互斥锁（Mutex）作为线程同步的一种机制，通常会涉及到内存屏障。因为互斥锁的使用会影响多个线程对共享数据的访问顺序，因此通常在加锁和解锁时，操作系统会插入内存屏障，确保在锁被持有时，所有操作会遵循正确的顺序。 加锁（线程持锁）时，需要确保该线程读取的共享数据是 最新的，因此需要通过 读屏障 来保证锁保护的变量被同步到主内存，确保读到的是最新的数据。 解锁（释放锁）时，需要确保该线程修改的数据被 同步到主内存，并通知其他线程，这通常通过 写屏障 来实现，以保证其他线程能看到更新后的数据。 加锁/解锁时的内存屏障作用示意： 加锁：会确保在加锁前，当前线程对共享数据的所有操作（尤其是写入）已经完成，并且数据对其他线程可见。这通常通过插入写屏障来实现。 解锁：会确保在解锁后，其他线程能看到当前线程对共享数据的最新修改。这通常通过插入读屏障来实现。 3. 总结 内存屏障： 内存屏障的作用是保护共享数据的一致性，确保线程对共享变量的操作顺序正确。它影响的是所有共享变量，而不仅仅是某个特定的变量。 它防止 CPU 对内存访问的乱序执行，确保内存操作按预期的顺序执行。 原子操作： 原子操作通常针对单个变量，确保操作是原子性的，即不可中断的，并且会隐式地执行内存屏障，保证操作对其他线程可见。 互斥锁和内存屏障： 互斥锁在加锁和解锁时会执行内存屏障。加锁时插入写屏障，确保当前线程的写操作完成；解锁时插入读屏障，确保其他线程能看到当前线程的修改。 4. 建议 a. 如果你编写多线程程序并使用互斥锁，确保你理解锁的加锁和解锁时的内存屏障作用，以避免数据不一致问题。 b. 了解并使用原子操作和内存屏障来控制线程间共享数据的顺序，特别是在性能要求较高的场合。 七、配合内存屏障来真正理解volatile volatile 关键字在 C 和 C++ 中用于修饰变量，告诉编译器该变量的值可能会在程序的任何时刻发生变化，通常是由外部因素（如硬件、操作系统或其他线程）引起的。使用 volatile 可以防止编译器对该变量进行优化(什么样的优化？)，从而确保每次访问时都从内存中获取变量的最新值，而不是从寄存器或缓存中读取过时的值。 优化？变量的优化就是CPU指令对此变量的操作一直在缓存中执行，增加运行速度。 防止优化？其实是防止读优化，即每次读操作都从主内存取，但是写操作不负责优化，可能写完大概率还在缓存中，其他同时在其他CPU核心运行的线程依然拿不到最新值。 等价于每次使用此变量之前都会触发一次“只针对这个变量的读屏障”（这是个比喻，读屏障不会只针对单独一个变量） 主要作用： 1.防止编译器优化： 编译器为了提高性能，通常会将变量存储在寄存器中，并减少对内存的访问。但是，如果一个变量是由外部因素改变的（比如硬件寄存器或其他线程修改），编译器可能不会及时从内存中读取该变量的最新值。 使用 volatile 告诉编译器：“不要优化对这个变量的访问，每次都直接从内存中读取它。” 2.确保变量访问的正确性： 当一个变量的值可能被多个线程、信号处理程序或硬件设备（例如，I/O端口、硬件寄存器）所修改时，volatile 关键字确保每次读取时都会从内存中获取最新的值，而不是使用缓存或寄存器中的值。 3.不保证写操作同步到主内存：如果你修改了一个 volatile 变量，编译器会直接在内存中修改这个变量的值，但这并不意味着其他核心的 CPU 或线程会立即看到这个修改。它不会自动确保 这个修改会立即同步到其他线程或 CPU 核心的缓存中。 4.volatile的作用范围：它确保你每次访问时都能获取到变量的最新值，但并不会同步其他线程或 CPU 中的缓存。例如，在多核处理器环境下，CPU 核心 A 可能会缓存某个变量，而 CPU 核心 B 可能并不知道核心 A 修改了这个变量，volatile 不能解决这种缓存一致性问题。 适用场景： 硬件寄存器：在嵌入式系统中，直接映射到硬件的内存地址经常会用 volatile，以确保每次访问时都读取硬件的最新值，而不是使用缓存。 多线程共享变量：当多个线程共享一个变量时，某个线程对该变量的修改可能会被其他线程及时看到，volatile 可以确保每次访问该变量时，都能获取到最新的值。 信号处理函数中的变量：在多线程或多进程的环境中，如果信号处理程序修改了某个变量，程序中的其他部分在访问这个变量时，需要确保获取到的是最新的值，因此也需要用 volatile。 使用示例： #include volatile int flag = 0; // 声明为volatile，表示它的值可能被外部因素改变 void signal_handler() { flag = 1; // 外部信号处理程序改变flag的值} void wait_for_flag() { while (flag == 0) { // 这里每次访问flag时，都会从内存中读取，而不是使用寄存器或缓存中的值 } printf("Flag is set!\n");} int main() { wait_for_flag(); // 等待flag被信号处理程序修改 return 0;} 在这个例子中： flag 变量声明为 volatile，表示它可能在程序的其他地方（如信号处理函数 signal_handler）被修改。 wait_for_flag 函数会在 flag 被修改之前一直等待。当 flag 被设置为 1 时，程序才会继续执行。 volatile 确保每次检查 flag 时都从内存读取，而不是从寄存器缓存中读取过时的值。 注意事项： 1.volatile 不等同于原子性或线程同步： volatile 只确保了 每次都从内存中读取变量的值，它并不会提供线程安全或原子性。例如，如果多个线程同时修改一个 volatile 变量，它仍然会有竞态条件（race condition）问题，因此在这种情况下，还需要使用互斥锁或原子操作来保证同步。 2.volatile不会防止缓存一致性问题： 在多核 CPU 系统中，volatile 并不能解决不同核心之间的缓存一致性问题。缓存一致性通常是由硬件（如 MESI 协议）或内存屏障来处理的。 3.volatile主要是为了防止编译器优化： 在大多数情况下，volatile 只是告诉编译器不要优化对变量的访问，它并不改变该变量的实际行为或内存模型。 结论： volatile 主要用于防止编译器优化，确保程序每次访问变量时都从内存中读取它的最新值，适用于那些可能被外部因素（硬件、其他线程、信号处理程序）改变的变量。 它 不会 处理多线程之间的同步问题，如果需要同步，则应该配合 互斥锁（mutex）或其他线程同步机制。 相关建议 a. 在多线程编程中，除了 volatile，你还应该了解如何使用 原子操作、互斥锁 或 条件变量 来确保共享数据的一致性。 b. 如果涉及到硬件寄存器的访问，理解 volatile 的使用是非常重要的，同时要注意与内存屏障和同步机制配合使用。
01-03 17浏览 -
为什么建议你用表驱动法？嵌入式C语言代码开发技巧
数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike 说明 本文基于这样的认识：数据是易变的，逻辑是稳定的。本文例举的编程实现多为代码片段，但不影响描述的完整性。本文例举的编程虽然基于C语言，但其编程思想也适用于其他语言。此外，本文不涉及语言相关的运行效率讨论。 概念提出 所谓表驱动法(Table-Driven Approach)简而言之就是用查表的方法获取数据。此处的“表”通常为数组，但可视为数据库的一种体现。 根据字典中的部首检字表查找读音未知的汉字就是典型的表驱动法，即以每个字的字形为依据，计算出一个索引值，并映射到对应的页数。相比一页一页地顺序翻字典查字，部首检字法效率极高。 具体到编程方面，在数据不多时可用逻辑判断语句（if…else或switch…case）来获取值；但随着数据的增多，逻辑语句会越来越长，此时表驱动法的优势就开始显现。 例如，用36进制(A表示10，B表示11，…)表示更大的数字，逻辑判断语句如下： if(ucNum < 10) { ucNumChar = ConvertToChar(ucNum); } else if(ucNum == 10) { ucNumChar = 'A'; } else if(ucNum == 11) { ucNumChar = 'B'; } else if(ucNum == 12) { ucNumChar = 'C'; } //... ... else if(ucNum == 35) { ucNumChar = 'Z'; } 当然也可以用 switch…case 结构，但实现都很冗长。而用表驱动法(将numChar 存入数组)则非常直观和简洁。如： CHAR aNumChars[] = {'0', '1', '2', /*3~9*/'A', 'B', 'C', /*D~Y*/'Z'}; CHAR ucNumChar = aNumChars[ucNum % sizeof(aNumChars)]; 像这样直接将变量当作下数组下标来读取数值的方法就是直接查表法。 注意，如果熟悉字符串操作，则上述写法可以更简洁： CHAR ucNumChar = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"[ucNum]; 使用表驱动法时需要关注两个问题：一是如何查表，从表中读取正确的数据；二是表里存放什么，如数值或函数指针。前者参见1.1节“查表方式”内容，后者参见1.2节“实战示例”内容。 查表方式 常用的查表方式有直接查找、索引查找和分段查找等。 直接查找 即直接通过数组下标获取到数据。如果熟悉哈希表的话，可以很容易看出这种查表方式就是哈希表的直接访问法。 如获取星期名称，逻辑判断语句如下： if(0 == ucDay) { pszDayName = "Sunday"; } else if(1 == ucDay) { pszDayName = "Monday"; } //... ... else if(6 == ucDay) { pszDayName = "Saturday"; } 而实现同样的功能，可将这些数据存储到一个表里： CHAR *paNumChars[] = {"Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"}; CHAR *pszDayName = paNumChars[ucDay]; 类似哈希表特性，表驱动法适用于无需有序遍历数据，且数据量大小可提前预测的情况。 对于过于复杂和庞大的判断，可将数据存为文件，需要时加载文件初始化数组，从而在不修改程序的情况下调整里面的数值。 有时，访问之前需要先进行一次键值转换。如表驱动法表示端口忙闲时，需将槽位端口号映射为全局编号。所生成的端口数目大小的数组，其下标对应全局端口编号，元素值表示相应端口的忙闲状态。 索引查找 有时通过一次键值转换，依然无法把数据(如英文单词等)转为键值。此时可将转换的对应关系写到一个索引表里，即索引访问。 如现有100件商品，4位编号，范围从0000到9999。此时只需要申请一个长度为100的数组，且对应2位键值。但将4位的编号转换为2位的键值，可能过于复杂或没有规律，最合适的方法是建立一个保存该转换关系的索引表。采用索引访问既节省内存，又方便维护。比如索引A表示通过名称访问，索引B表示通过编号访问。 分段查找 通过确定数据所处的范围确定分类(下标)。有的数据可分成若干区间，即具有阶梯性，如分数等级。此时可将每个区间的上限(或下限)存到一个表中，将对应的值存到另一表中，通过第一个表确定所处的区段，再由区段下标在第二个表里读取相应数值。注意要留意端点，可用二分法查找，另外可考虑通过索引方法来代替。 如根据分数查绩效等级： #define MAX_GRADE_LEVEL (INT8U)5 DOUBLE aRangeLimit[MAX_GRADE_LEVEL] = {50.0, 60.0, 70.0, 80.0, 100.0}; CHAR *paGrades[MAX_GRADE_LEVEL] = {"Fail", "Pass", "Credit", "Distinction", "High Distinction"}; static CHAR* EvaluateGrade(DOUBLE dScore) { INT8U ucLevel = 0; for(; ucLevel < MAX_GRADE_LEVEL; ucLevel++) { if(dScore < aRangeLimit[ucLevel]) return paGrades[ucLevel]; } return paGrades[0]; } 上述两张表(数组)也可合并为一张表(结构体数组)，如下所示： typedef struct{ DOUBLE aRangeLimit; CHAR *pszGrade; }T_GRADE_MAP; T_GRADE_MAP gGradeMap[MAX_GRADE_LEVEL] = { {50.0, "Fail"}, {60.0, "Pass"}, {70.0, "Credit"}, {80.0, "Distinction"}, {100.0, "High Distinction"} }; static CHAR* EvaluateGrade(DOUBLE dScore) { INT8U ucLevel = 0; for(; ucLevel < MAX_GRADE_LEVEL; ucLevel++) { if(dScore < gGradeMap[ucLevel].aRangeLimit) return gGradeMap[ucLevel].pszGrade; } return gGradeMap[0].pszGrade; } 该表结构已具备的数据库的雏形，并可扩展支持更为复杂的数据。其查表方式通常为索引查找，偶尔也为分段查找；当索引具有规律性(如连续整数)时，退化为直接查找。 使用分段查找法时应注意边界，将每一分段范围的上界值都考虑在内。 找出所有不在最高一级范围内的值，然后把剩下的值全部归入最高一级中。有时需要人为地为最高一级范围添加一个上界。 同时应小心不要错误地用“<”来代替“<=”。要保证循环在找出属于最高一级范围内的值后恰当地结束，同时也要保证恰当处理范围边界。 实战示例 本节多数示例取自实际项目。表形式为一维数组、二维数组和结构体数组；表内容有数据、字符串和函数指针。基于表驱动的思想，表形式和表内容可衍生出丰富的组合。 字符统计 问题：统计用户输入的一串数字中每个数字出现的次数。 普通解法主体代码如下： INT32U aDigitCharNum[10] = {0}; /* 输入字符串中各数字字符出现的次数 */ INT32U dwStrLen = strlen(szDigits); INT32U dwStrIdx = 0; for(; dwStrIdx < dwStrLen; dwStrIdx++) { switch(szDigits[dwStrIdx]) { case '1': aDigitCharNum[0]++; break; case '2': aDigitCharNum[1]++; break; //... ... case '9': aDigitCharNum[8]++; break; } } 这种解法的缺点显而易见，既不美观也不灵活。其问题关键在于未将数字字符与数组aDigitCharNum下标直接关联起来。 以下示出更简洁的实现方式： for(; dwStrIdx < dwStrLen; dwStrIdx++) { aDigitCharNum[szDigits[dwStrIdx] - '0']++; } 上述实现考虑到0也为数字字符。该解法也可扩展至统计所有ASCII可见字符。 月天校验 问题：对给定年份和月份的天数进行校验(需区分平年和闰年)。 普通解法主体代码如下： switch(OnuTime.Month) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: if(OnuTime.Day>31 || OnuTime.Day<1) { CtcOamLog(FUNCTION_Pon,"Don't support this Day: %d(1~31)!!!\n", OnuTime.Day); retcode = S_ERROR; } break; case 2: if(((OnuTime.Year%4 == 0) && (OnuTime.Year%100 != 0)) || (OnuTime.Year%400 == 0)) { if(OnuTime.Day>29 || OnuTime.Day<1) { CtcOamLog(FUNCTION_Pon,"Don't support this Day: %d(1~29)!!!\n", OnuTime.Day); retcode = S_ERROR; } } else { if(OnuTime.Day>28 || OnuTime.Day<1) { CtcOamLog(FUNCTION_Pon,"Don't support this Day: %d(1~28)!!!\n", OnuTime.Day); retcode = S_ERROR; } } break; case 4: case 6: case 9: case 11: if(OnuTime.Day>30 || OnuTime.Day<1) { CtcOamLog(FUNCTION_Pon,"Don't support this Day: %d(1~30)!!!\n", OnuTime.Day); retcode = S_ERROR; } break; default: CtcOamLog(FUNCTION_Pon,"Don't support this Month: %d(1~12)!!!\n", OnuTime.Month); retcode = S_ERROR; break; } 以下示出更简洁的实现方式： #define MONTH_OF_YEAR 12 /* 一年中的月份数 */ /* 闰年：能被4整除且不能被100整除，或能被400整除 */ #define IS_LEAP_YEAR(year) ((((year) % 4 == 0) && ((year) % 100 != 0)) || ((year) % 400 == 0)) /* 平年中的各月天数，下标对应月份 */ INT8U aDayOfCommonMonth[MONTH_OF_YEAR] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; INT8U ucMaxDay = 0; if((OnuTime.Month == 2) && (IS_LEAP_YEAR(OnuTime.Year))) ucMaxDay = aDayOfCommonMonth[1] + 1; else ucMaxDay = aDayOfCommonMonth[OnuTime.Month-1]; if((OnuTime.Day < 1) || (OnuTime.Day > ucMaxDay) { CtcOamLog(FUNCTION_Pon,"Month %d doesn't have this Day: %d(1~%d)!!!\n", OnuTime.Month, OnuTime.Day, ucMaxDay); retcode = S_ERROR; } 名称构造 问题：根据WAN接口承载的业务类型(Bitmap)构造业务类型名称字符串。 普通解法主体代码如下： void Sub_SetServerType(INT8U *ServerType, INT16U wan_servertype) { if ((wan_servertype & 0x0001) == 0x0001) { strcat(ServerType, "_INTERNET"); } if ((wan_servertype & 0x0002) == 0x0002) { strcat(ServerType, "_TR069"); } if ((wan_servertype & 0x0004) == 0x0004) { strcat(ServerType, "_VOIP"); } if ((wan_servertype & 0x0008) == 0x0008) { strcat(ServerType, "_OTHER"); } } 以下示出C语言中更简洁的实现方式： /* 获取var变量第bit位，编号从右至左 */ #define GET_BIT(var, bit) (((var) >> (bit)) & 0x1) const CHAR* paSvrNames[] = {"_INTERNET", "_TR069", "_VOIP", "_OTHER"}; const INT8U ucSvrNameNum = sizeof(paSvrNames) / sizeof(paSvrNames[0]); VOID SetServerType(CHAR *pszSvrType, INT16U wSvrType) { INT8U ucIdx = 0; for(; ucIdx < ucSvrNameNum; ucIdx++) { if(1 == GET_BIT(wSvrType, ucIdx)) strcat(pszSvrType, paSvrNames[ucIdx]); } } 新的实现将数据和逻辑分离，维护起来非常方便。只要逻辑(规则)不变，则唯一可能的改动就是数据(paSvrNames)。 值名解析 问题：根据枚举变量取值输出其对应的字符串，如PORT_FE(1)输出“Fe”。 //值名映射表结构体定义，用于数值解析器 typedef struct{ INT32U dwElem; //待解析数值，通常为枚举变量 CHAR* pszName; //指向数值所对应解析名字符串的指针 }T_NAME_PARSER; /****************************************************************************** * 函数名称: NameParser * 功能说明: 数值解析器，将给定数值转换为对应的具名字符串 * 输入参数: VOID *pvMap :值名映射表数组，含T_NAME_PARSER结构体类型元素 VOID指针允许用户在保持成员数目和类型不变的前提下， 定制更有意义的结构体名和/或成员名。 INT32U dwEntryNum :值名映射表数组条目数 INT32U dwElem :待解析数值，通常为枚举变量 INT8U* pszDefName :缺省具名字符串指针，可为空 * 输出参数: NA * 返回值 : INT8U *: 数值所对应的具名字符串 当无法解析给定数值时，若pszDefName为空，则返回数值对应的16进制格式 字符串；否则返回pszDefName。 ******************************************************************************/ INT8U *NameParser(VOID *pvMap, INT32U dwEntryNum, INT32U dwElem, INT8U* pszDefName) { CHECK_SINGLE_POINTER(pvMap, "NullPoniter"); INT32U dwEntryIdx = 0; for(dwEntryIdx = 0; dwEntryIdx < dwEntryNum; dwEntryIdx++) { T_NAME_PARSER *ptNameParser = (T_NAME_PARSER *)pvMap; if(dwElem == ptNameParser->dwElem) { return ptNameParser->pszName; } //ANSI标准禁止对void指针进行算法操作；GNU标准则指定void*算法操作与char*一致。 //若考虑移植性，可将pvMap类型改为INT8U*，或定义INT8U*局部变量指向pvMap。 pvMap += sizeof(T_NAME_PARSER); } if(NULL != pszDefName) { return pszDefName; } else { static INT8U szName[12] = {0}; //Max:"0xFFFFFFFF" sprintf(szName, "0x%X", dwElem); return szName; } } 以下给出NameParser的简单应用示例： //UNI端口类型值名映射表结构体定义 typedef struct{ INT32U dwPortType; INT8U* pszPortName; }T_PORT_NAME; //UNI端口类型解析器 T_PORT_NAME gUniNameMap[] = { {1, "Fe"}, {3, "Pots"}, {99, "Vuni"} }; const INT32U UNI_NAM_MAP_NUM = (INT32U)(sizeof(gUniNameMap)/sizeof(T_PORT_NAME)); VOID NameParserTest(VOID) { INT8U ucTestIndex = 1; printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("Unknown", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 0, "Unknown")) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("DefName", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 0, "DefName")) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("Fe", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 1, "Unknown")) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("Pots", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 3, "Unknown")) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("Vuni", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 99, NULL)) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("Unknown", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 255, "Unknown")) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("0xABCD", NameParser(gUniNameMap, UNI_NAM_MAP_NUM, 0xABCD, NULL)) ? "ERROR" : "OK"); printf("[%s] Result: %s!\n", __FUNCTION__, ucTestIndex++, strcmp("NullPoniter", NameParser(NULL, UNI_NAM_MAP_NUM, 0xABCD, NULL)) ? "ERROR" : "OK"); } gUniNameMap在实际项目中有十余个条目，若采用逻辑链实现将非常冗长。 取值映射 问题：不同模块间同一参数枚举值取值可能有所差异，需要适配。 此处不再给出普通的switch…case或if…else if…else结构，而直接示出以下表驱动实现： typedef struct{ PORTSTATE loopMEState; PORTSTATE loopMIBState; }LOOPMAPSTRUCT; static LOOPMAPSTRUCT s_CesLoop[] = { {NO_LOOP, e_ds1_looptype_noloop}, {PAYLOAD_LOOP, e_ds1_looptype_PayloadLoop}, {LINE_LOOP, e_ds1_looptype_LineLoop}, {PON_LOOP, e_ds1_looptype_OtherLoop}, {CES_LOOP, e_ds1_looptype_InwardLoop}}; PORTSTATE ConvertLoopMEStateToMIBState(PORTSTATE vPortState) { INT32U num = 0, ii; num = ARRAY_NUM(s_CesLoop); for(ii = 0; ii < num; ii++) { if(vPortState == s_CesLoop[ii].loopMEState) return s_CesLoop[ii].loopMIBState; } return e_ds1_looptype_noloop; } 相应地，从loopMIBState映射到loopMEState需要定义一个ConvertLoopMIBStateToMEState函数。更进一步，所有类似的一对一映射关系都必须如上的映射(转换)函数，相当繁琐。事实上，从抽象层面看，该映射关系非常简单。提取共性后定义带参数宏，如下所示： /********************************************************** * 功能描述：进行二维数组映射表的一对一映射，用于参数适配 * 参数说明：map -- 二维数组映射表 elemSrc -- 映射源，即待映射的元素值 elemDest -- 映射源对应的映射结果 direction -- 映射方向字节，表示从数组哪列映射至哪列。 高4位对应映射源列，低4位对应映射结果列。 defaultVal -- 映射失败时置映射结果为缺省值 * 示例：ARRAY_MAPPER(gCesLoopMap, 3, ucLoop, 0x10, NO_LOOP); 则ucLoop = 2(LINE_LOOP) **********************************************************/ #define ARRAY_MAPPER(map, elemSrc, elemDest, direction, defaultVal) do{\ INT8U ucMapIdx = 0, ucMapNum = 0; \ ucMapNum = sizeof(map)/sizeof(map[0]); \ for(ucMapIdx = 0; ucMapIdx < ucMapNum; ucMapIdx++) \ { \ if((elemSrc) == map[ucMapIdx][((direction)&0xF0)>>4]) \ { \ elemDest = map[ucMapIdx][(direction)&0x0F]; \ break; \ } \ } \ if(ucMapIdx == ucMapNum) \ { \ elemDest = (defaultVal); \ } \ }while(0) 参数取值转换时直接调用统一的映射器宏，如下： static INT8U gCesLoopMap[][2] = { {NO_LOOP, e_ds1_looptype_noloop}, {PAYLOAD_LOOP, e_ds1_looptype_PayloadLoop}, {LINE_LOOP, e_ds1_looptype_LineLoop}, {PON_LOOP, e_ds1_looptype_OtherLoop}, {CES_LOOP, e_ds1_looptype_InwardLoop}}; ARRAY_MAPPER(gCesLoopMap, tPara.dwParaVal[0], dwLoopConf, 0x01, e_ds1_looptype_noloop); 另举一例： #define CES_DEFAULT_JITTERBUF (INT32U)2000 /* 默认jitterbuf为2000us，而1帧=125us */ #define CES_JITTERBUF_STEP (INT32U)125 /* jitterbuf步长为125us，即1帧 */ #define CES_DEFAULT_QUEUESIZE (INT32U)5 #define CES_DEFAULT_MAX_QUEUESIZE (INT32U)7 #define ARRAY_NUM(array) (sizeof(array) / sizeof((array)[0])) /* 数组元素个数 */ typedef struct{ INT32U dwJitterBuffer; INT32U dwFramePerPkt; INT32U dwQueueSize; }QUEUE_SIZE_MAP; /* gCesQueueSizeMap也可以(JitterBuffer / FramePerPkt)值为索引，更加紧凑 */ static QUEUE_SIZE_MAP gCesQueueSizeMap[]= { {1,1,1}, {1,2,1}, {2,1,2}, {2,2,1}, {3,1,3}, {3,2,1}, {4,1,3}, {4,2,1}, {5,1,4}, {5,2,3}, {6,1,4}, {6,2,3}, {7,1,4}, {7,2,3}, {8,1,4}, {8,2,3}, {9,1,5}, {9,2,4}, {10,1,5}, {10,2,4}, {11,1,5}, {11,2,4}, {12,1,5}, {12,2,4}, {13,1,5}, {13,2,4}, {14,1,5}, {14,2,4}, {15,1,5}, {15,2,4}, {16,1,5}, {16,2,4}, {17,1,6}, {17,2,5}, {18,1,6}, {18,2,5}, {19,1,6}, {19,2,5}, {20,1,6}, {20,2,5}, {21,1,6}, {21,2,5}, {22,1,6}, {22,2,5}, {23,1,6}, {23,2,5}, {24,1,6}, {24,2,5}, {25,1,6}, {25,2,5}, {26,1,6}, {26,2,5}, {27,1,6}, {27,2,5}, {28,1,6}, {28,2,5}, {29,1,6}, {29,2,5}, {30,1,6}, {30,2,5}, {31,1,6}, {31,2,5}, {32,1,6}, {32,2,5}}; /********************************************************** * 函数名称：CalcQueueSize * 功能描述：根据JitterBuffer和FramePerPkt计算QueueSize * 注意事项：配置的最大缓存深度 * = 2 * JitterBuffer / FramePerPkt * = 2 * N Packet = 2 ^ QueueSize * JitterBuffer为125us帧速率的倍数， * FramePerPkt为每个分组的帧数， * QueueSize向上取整，最大为7。 **********************************************************/ INT32U CalcQueueSize(INT32U dwJitterBuffer, INT32U dwFramePerPkt) { INT8U ucIdx = 0, ucNum = 0; //本函数暂时仅考虑E1 ucNum = ARRAY_NUM(gCesQueueSizeMap); for(ucIdx = 0; ucIdx < ucNum; ucIdx++) { if((dwJitterBuffer == gCesQueueSizeMap[ucIdx].dwJitterBuffer) && (dwFramePerPkt == gCesQueueSizeMap[ucIdx].dwFramePerPkt)) { return gCesQueueSizeMap[ucIdx].dwQueueSize; } } return CES_DEFAULT_MAX_QUEUESIZE; } 版本控制 问题：控制OLT与ONU之间的版本协商。ONU本地设置三比特控制字，其中bit2(MSB)~bit0(LSB)分别对应0x21、0x30和0xAA版本号；且bitX为0表示上报对应版本号，bitX为1表示不上报对应版本号。其他版本号如0x20、0x13和0x1必须上报，即不受控制。 最初的实现采用if…else if…else结构，代码非常冗长，如下： pstSendTlv->ucLength = 0x1f; if (gOamCtrlCode == 0) { vosMemCpy(pstSendTlv->aucVersionList, ctc_oui, 3); pstSendTlv->aucVersionList[3] = 0x30; vosMemCpy(&(pstSendTlv->aucVersionList[4]), ctc_oui, 3); pstSendTlv->aucVersionList[7] = 0x21; vosMemCpy(&(pstSendTlv->aucVersionList[8]), ctc_oui, 3); pstSendTlv->aucVersionList[11] = 0x20; vosMemCpy(&(pstSendTlv->aucVersionList[12]), ctc_oui, 3); pstSendTlv->aucVersionList[15] = 0x13; vosMemCpy(&(pstSendTlv->aucVersionList[16]), ctc_oui, 3); pstSendTlv->aucVersionList[19] = 0x01; vosMemCpy(&(pstSendTlv->aucVersionList[20]), ctc_oui, 3); pstSendTlv->aucVersionList[23] = 0xaa; } else if (gOamCtrlCode == 1) { vosMemCpy(pstSendTlv->aucVersionList, ctc_oui, 3); pstSendTlv->aucVersionList[3] = 0x30; vosMemCpy(&(pstSendTlv->aucVersionList[4]), ctc_oui, 3); pstSendTlv->aucVersionList[7] = 0x21; vosMemCpy(&(pstSendTlv->aucVersionList[8]), ctc_oui, 3); pstSendTlv->aucVersionList[11] = 0x20; vosMemCpy(&(pstSendTlv->aucVersionList[12]), ctc_oui, 3); pstSendTlv->aucVersionList[15] = 0x13; vosMemCpy(&(pstSendTlv->aucVersionList[16]), ctc_oui, 3); pstSendTlv->aucVersionList[19] = 0x01; } //此处省略gOamCtrlCode == 2~6的处理代码 else if (gOamCtrlCode == 7) { vosMemCpy(&(pstSendTlv->aucVersionList), ctc_oui, 3); pstSendTlv->aucVersionList[3] = 0x20; vosMemCpy(&(pstSendTlv->aucVersionList[4]), ctc_oui, 3); pstSendTlv->aucVersionList[7] = 0x13; vosMemCpy(&(pstSendTlv->aucVersionList[8]), ctc_oui, 3); pstSendTlv->aucVersionList[11] = 0x01; } 以下示出C语言中更简洁的实现方式(基于二维数组)： /********************************************************************** * 版本控制字数组定义 * gOamCtrlCode: Bitmap控制字。Bit-X为0时上报对应版本，Bit-X为1时屏蔽对应版本。 * CTRL_VERS_NUM: 可控版本个数。 * CTRL_CODE_NUM: 控制字个数。与CTRL_VERS_NUM有关。 * gOamVerCtrlMap: 版本控制字数组。行对应控制字，列对应可控版本。 元素值为0时不上报对应版本，元素值非0时上报该元素值。 * Note: 该数组旨在实现“数据与控制隔离”。后续若要新增可控版本，只需修改 -- CTRL_VERS_NUM -- gOamVerCtrlMap新增行(控制字) -- gOamVerCtrlMap新增列(可控版本) **********************************************************************/ #define CTRL_VERS_NUM 3 #define CTRL_CODE_NUM (1< u8_t gOamVerCtrlMap[CTRL_CODE_NUM][CTRL_VERS_NUM]
01-03 35浏览 -
-
-
ADI SIGMADSP的软件移植
一、SIGMADSP的开发流程简介ADI 目前在DSP方面的产品主要有SIGMA、BLACKFIN、SHARC三大类型，分别应用于不同的市场。SIGMADSP是完全可编程的单芯片音频DSP，可以通过SIGMASTUDIO图形开发工...
2024-12-06 206浏览 -
什么是字节对齐？今天一次性说细咯
引言 最近因为硬件的一些限制，导致没有注意到四字节对齐问题，总去位域操作，导致寄存器读写不一致，这是一篇关于字节对齐的文章，写得很全很长，建议收藏细读。 考虑下面的结构体定义： typedef struct { char c1; short s; char c2; int i; }T_FOO; 假设这个结构体的成员在内存中是紧凑排列的，且c1的起始地址是0，则s的地址就是1，c2的地址是3，i的地址是4。 现在，我们编写一个简单的程序： int main(void) { T_FOO a; printf("c1 -> %d, s -> %d, c2 -> %d, i -> %d\n", (unsigned int)(void*)&a.c1 - (unsigned int)(void*)&a, (unsigned int)(void*)&a.s - (unsigned int)(void*)&a, (unsigned int)(void*)&a.c2 - (unsigned int)(void*)&a, (unsigned int)(void*)&a.i - (unsigned int)(void*)&a); return 0; } 运行后输出： c1 -> 0, s -> 2, c2 -> 4, i -> 8 为什么会这样？这就是字节对齐导致的问题。 本文在参考诸多资料的基础上，详细介绍常见的字节对齐问题。因成文较早，资料来源大多已不可考，敬请谅解。 一、 什么是字节对齐 现代计算机中，内存空间按照字节划分，理论上可以从任何起始地址访问任意类型的变量。 但实际中在访问特定类型变量时经常在特定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序一个接一个地存放，这就是对齐。 二 、对齐的原因和作用 不同硬件平台对存储空间的处理上存在很大的不同。某些平台对特定类型的数据只能从特定地址开始存取，而不允许其在内存中任意存放。 例如Motorola 68000 处理器不允许16位的字存放在奇地址，否则会触发异常，因此在这种架构下编程必须保证字节对齐。 但最常见的情况是，如果不按照平台要求对数据存放进行对齐，会带来存取效率上的损失。比如32位的Intel处理器通过总线访问(包括读和写)内存数据。 每个总线周期从偶地址开始访问32位内存数据，内存数据以字节为单位存放。 如果一个32位的数据没有存放在4字节整除的内存地址处，那么处理器就需要2个总线周期对其进行访问，显然访问效率下降很多。 因此，通过合理的内存对齐可以提高访问效率。为使CPU能够对数据进行快速访问，数据的起始地址应具有“对齐”特性。 比如4字节数据的起始地址应位于4字节边界上，即起始地址能够被4整除。 此外，合理利用字节对齐还可以有效地节省存储空间。但要注意，在32位机中使用1字节或2字节对齐，反而会降低变量访问速度。 因此需要考虑处理器类型。还应考虑编译器的类型。在VC/C++和GNU GCC中都是默认是4字节对齐。 三 、对齐的分类和准则 主要基于Intel X86架构介绍结构体对齐和栈内存对齐，位域本质上为结构体类型。 对于Intel X86平台，每次分配内存应该是从4的整数倍地址开始分配，无论是对结构体变量还是简单类型的变量。 3.1 结构体对齐 在C语言中，结构体是种复合数据类型，其构成元素既可以是基本数据类型(如int、long、float等)的变量，也可以是一些复合数据类型(如数组、结构体、联合等)的数据单元。 编译器为结构体的每个成员按照其自然边界(alignment)分配空间。各成员按照它们被声明的顺序在内存中顺序存储，第一个成员的地址和整个结构的地址相同。 字节对齐的问题主要就是针对结构体。 3.1.1 简单示例 先看个简单的例子(32位，X86处理器，GCC编译器)： 【例1】设结构体如下定义： struct A { int a; char b; short c; }; struct B { char b; int a; short c; }; 已知32位机器上各数据类型的长度为：char为1字节、short为2字节、int为4字节、long为4字节、float为4字节、double为8字节。那么上面两个结构体大小如何呢？ 结果是： sizeof(strcut A)值为8；sizeof(struct B)的值却是12。 结构体A中包含一个4字节的int数据，一个1字节char数据和一个2字节short数据；B也一样。按理说A和B大小应该都是7字节。之所以出现上述结果，就是因为编译器要对数据成员在空间上进行对齐。 3.1.2 对齐准则 先来看四个重要的基本概念： 数据类型自身的对齐值：char型数据自身对齐值为1字节，short型数据为2字节，int/float型为4字节，double型为8字节。 结构体或类的自身对齐值：其成员中自身对齐值最大的那个值。 指定对齐值：#pragma pack (value)时的指定对齐值value。 数据成员、结构体和类的有效对齐值：自身对齐值和指定对齐值中较小者，即有效对齐值=min{自身对齐值，当前指定的pack值}。 基于上面这些值，就可以方便地讨论具体数据结构的成员和其自身的对齐方式。 其中，有效对齐值N是最终用来决定数据存放地址方式的值。有效对齐N表示“对齐在N上”，即该数据的“存放起始地址%N=0”。而数据结构中的数据变量都是按定义的先后顺序存放。 第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐存放，结构体本身也要根据自身的有效对齐值圆整(即结构体成员变量占用总长度为结构体有效对齐值的整数倍)。 以此分析3.1.1节中的结构体B： 假设B从地址空间0x0000开始存放，且指定对齐值默认为4(4字节对齐)。成员变量b的自身对齐值是1，比默认指定对齐值4小，所以其有效对齐值为1，其存放地址0x0000符合0x0000%1=0。 成员变量a自身对齐值为4，所以有效对齐值也为4，只能存放在起始地址为0x0004~0x0007四个连续的字节空间中，符合0x0004%4=0且紧靠第一个变量。 变量c自身对齐值为 2，所以有效对齐值也是2，可存放在0x0008~0x0009两个字节空间中，符合0x0008%2=0。所以从0x0000~0x0009存放的都是B内容。 再看数据结构B的自身对齐值为其变量中最大对齐值(这里是b)所以就是4，所以结构体的有效对齐值也是4。 根据结构体圆整的要求， 0x0000~0x0009=10字节，(10＋2)％4＝0。所以0x0000A~0x000B也为结构体B所占用。故B从0x0000到0x000B 共有12个字节，sizeof(struct B)=12。 之所以编译器在后面补充2个字节，是为了实现结构数组的存取效率。试想如果定义一个结构B的数组，那么第一个结构起始地址是0没有问题，但是第二个结构呢？ 按照数组的定义，数组中所有元素都紧挨着。如果我们不把结构体大小补充为4的整数倍，那么下一个结构的起始地址将是0x0000A，这显然不能满足结构的地址对齐。 因此要把结构体补充成有效对齐大小的整数倍。其实对于char/short/int/float/double等已有类型的自身对齐值也是基于数组考虑的，只是因为这些类型的长度已知，所以他们的自身对齐值也就已知。 上面的概念非常便于理解，不过个人还是更喜欢下面的对齐准则。 结构体字节对齐的细节和具体编译器实现相关，但一般而言满足三个准则： 结构体变量的首地址能够被其最宽基本类型成员的大小所整除； 结构体每个成员相对结构体首地址的偏移量(offset)都是成员大小的整数倍，如有需要编译器会在成员之间加上填充字节(internal adding)； 结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要编译器会在最末一个成员之后加上填充字节{trailing padding}。 对于以上规则的说明如下： 第一条：编译器在给结构体开辟空间时，首先找到结构体中最宽的基本数据类型，然后寻找内存地址能被该基本数据类型所整除的位置，作为结构体的首地址。将这个最宽的基本数据类型的大小作为上面介绍的对齐模数。 第二条：为结构体的一个成员开辟空间之前，编译器首先检查预开辟空间的首地址相对于结构体首地址的偏移是否是本成员大小的整数倍，若是，则存放本成员，反之，则在本成员和上一个成员之间填充一定的字节，以达到整数倍的要求，也就是将预开辟空间的首地址后移几个字节。 第三条：结构体总大小是包括填充字节，最后一个成员满足上面两条以外，还必须满足第三条，否则就必须在最后填充几个字节以达到本条要求。 【例2】假设4字节对齐，以下程序的输出结果是多少？ /* OFFSET宏定义可取得指定结构体某成员在结构体内部的偏移 */ #define OFFSET(st, field) (size_t)&(((st*)0)->field) typedef struct { char a; short b; char c; int d; char e[3]; }T_Test; int main(void) { printf("Size = %d\n a-%d, b-%d, c-%d, d-%d\n e[0]-%d, e[1]-%d, e[2]-%d\n", sizeof(T_Test), OFFSET(T_Test, a), OFFSET(T_Test, b), OFFSET(T_Test, c), OFFSET(T_Test, d), OFFSET(T_Test, e[0]), OFFSET(T_Test, e[1]),OFFSET(T_Test, e[2])); return 0; } 执行后输出如下： Size = 16 a-0, b-2, c-4, d-8 e[0]-12, e[1]-13, e[2]-14 下面来具体分析： 首先char a占用1个字节，没问题。 short b本身占用2个字节，根据上面准则2，需要在b和a之间填充1个字节。 char c占用1个字节，没问题。 int d本身占用4个字节，根据准则2，需要在d和c之间填充3个字节。 char e[3]；本身占用3个字节，根据原则3，需要在其后补充1个字节。 因此，sizeof(T_Test) = 1 + 1 + 2 + 1 + 3 + 4 + 3 + 1 = 16字节。 3.1.3 对齐的隐患 3.1.3.1 数据类型转换 代码中关于对齐的隐患，很多是隐式的。例如，在强制类型转换的时候： int main(void) { unsigned int i = 0x12345678; unsigned char *p = (unsigned char *)&i; *p = 0x00; unsigned short *p1 = (unsigned short *)(p+1); *p1 = 0x0000; return 0; } 最后两句代码，从奇数边界去访问unsigned short型变量，显然不符合对齐的规定。在X86上，类似的操作只会影响效率；但在MIPS或者SPARC上可能导致error，因为它们要求必须字节对齐。 又如对于3.1.1节的结构体struct B，定义如下函数： void Func(struct B *p) { //Code } 在函数体内如果直接访问p->a，则很可能会异常。因为MIPS认为a是int，其地址应该是4的倍数，但p->a的地址很可能不是4的倍数。 如果p的地址不在对齐边界上就可能出问题，比如p来自一个跨CPU的数据包(多种数据类型的数据被按顺序放置在一个数据包中传输)，或p是经过指针移位算出来的。 因此要特别注意跨CPU数据的接口函数对接口输入数据的处理，以及指针移位再强制转换为结构指针进行访问时的安全性。 解决方式如下： 定义一个此结构的局部变量，用memmove方式将数据拷贝进来。 void Func(struct B *p) { struct B tData; memmove(&tData, p, sizeof(struct B)); //此后可安全访问tData.a，因为编译器已将tData分配在正确的起始地址上 } 注意：如果能确定p的起始地址没问题，则不需要这么处理；如果不能确定(比如跨CPU输入数据、或指针移位运算出来的数据要特别小心)，则需要这样处理。 用#pragma pack (1)将STRUCT_T定义为1字节对齐方式。 3.1.3.2 处理器间数据通信 处理器间通过消息(对于C/C++而言就是结构体)进行通信时，需要注意字节对齐以及字节序的问题。 大多数编译器提供内存对其的选项供用户使用。这样用户可以根据处理器的情况选择不同的字节对齐方式。 例如C/C++编译器提供的#pragma pack(n) n=1，2，4等，让编译器在生成目标文件时，使内存数据按照指定的方式排布在1，2，4等字节整除的内存地址处。 然而在不同编译平台或处理器上，字节对齐会造成消息结构长度的变化。编译器为了使字节对齐可能会对消息结构体进行填充，不同编译平台可能填充为不同的形式，大大增加处理器间数据通信的风险。 下面以32位处理器为例，提出一种内存对齐方法以解决上述问题。 对于本地使用的数据结构，为提高内存访问效率，采用四字节对齐方式；同时为了减少内存的开销，合理安排结构体成员的位置，减少四字节对齐导致的成员之间的空隙，降低内存开销。 对于处理器之间的数据结构，需要保证消息长度不会因不同编译平台或处理器而导致消息结构体长度发生变化，使用一字节对齐方式对消息结构进行紧缩；为保证处理器之间的消息数据结构的内存访问效率，采用字节填充的方式自己对消息中成员进行四字节对齐。 数据结构的成员位置要兼顾成员之间的关系、数据访问效率和空间利用率。顺序安排原则是：四字节的放在最前面，两字节的紧接最后。 一个四字节成员，一字节紧接最后一个两字节成员，填充字节放在最后。举例如下： typedef struct tag_T_MSG { long ParaA; long ParaB; short ParaC； char ParaD; char Pad; //填充字节 }T_MSG; 3.1.3.3 排查对齐问题 如果出现对齐或者赋值问题可查看： 编译器的字节序大小端设置； 处理器架构本身是否支持非对齐访问； 如果支持看设置对齐与否，如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。 3.1.4 更改对齐方式 主要是更改C编译器的缺省字节对齐方式。 在缺省情况下，C编译器为每一个变量或是数据单元按其自然对界条件分配空间。一般地，可以通过下面的方法来改变缺省的对界条件： 使用伪指令#pragma pack(n)：C编译器将按照n个字节对齐； 使用伪指令#pragma pack()：取消自定义字节对齐方式。 另外，还有如下的一种方式(GCC特有语法)： __attribute((aligned (n)))：让所作用的结构成员对齐在n字节自然边界上。如果结构体中有成员的长度大于n，则按照最大成员的长度来对齐。 __ attribute __ ((packed))：取消结构在编译过程中的优化对齐，按照实际占用字节数进行对齐。 【注】__ attribute __机制是GCC的一大特色，可以设置函数属性(Function Attribute)、变量属性(Variable Attribute)和类型属性(Type Attribute)。详细介绍请参考： http://www.unixwiz.net/techtips/gnu-c-attributes.html 下面具体针对MS VC/C++ 6.0编译器介绍下如何修改编译器默认对齐值。 VC/C++ IDE环境中，可在[Project]|[Settings]，C/C++选项卡Category的Code Generation选项的Struct Member Alignment中修改，默认是8字节。 VC/C++中的编译选项有/Zp[1|2|4|8|16]，/Zpn表示以n字节边界对齐。n字节边界对齐是指一个成员的地址必须安排在成员的尺寸的整数倍地址上或者是n的整数倍地址上，取它们中的最小值。亦即：min(sizeof(member), n)。 实际上，1字节边界对齐也就表示结构成员之间没有空洞。 /Zpn选项应用于整个工程，影响所有参与编译的结构体。在Struct member alignment中可选择不同的对齐值来改变编译选项。 在编码时，可用#pragma pack动态修改对齐值。具体语法说明见附录5.3节。 自定义对齐值后要用#pragma pack()来还原，否则会对后面的结构造成影响。 【例3】分析如下结构体C： #pragma pack(2) //指定按2字节对齐 struct C { char b; int a; short c; }; #pragma pack() //取消指定对齐，恢复缺省对齐 变量b自身对齐值为1，指定对齐值为2，所以有效对齐值为1，假设C从0x0000开始，则b存放在0x0000，符合0x0000%1= 0；变量a自身对齐值为4，指定对齐值为2，所以有效对齐值为2，顺序存放在0x0002~0x0005四个连续字节中，符合0x0002%2=0。 变量c的自身对齐值为2，所以有效对齐值为2，顺序存放在0x0006~0x0007中，符合 0x0006%2=0。所以从0x0000到0x00007共八字节存放的是C的变量。C的自身对齐值为4，所以其有效对齐值为2。又8%2=0，C只占用0x0000~0x0007的八个字节。所以sizeof(struct C) = 8。 注意，结构体对齐到的字节数并非完全取决于当前指定的pack值，如下： #pragma pack(8) struct D { char b; short a; char c; }; #pragma pack() 虽然#pragma pack(8)，但依然按照两字节对齐，所以sizeof(struct D)的值为6。因为：对齐到的字节数 = min｛当前指定的pack值，最大成员大小｝。 另外，GNU GCC编译器中按1字节对齐可写为以下形式： #define GNUC_PACKED __attribute__((packed)) struct C { char b; int a; short c; }GNUC_PACKED; 此时sizeof(struct C)的值为7。 3.2 栈内存对齐 在VC/C++中，栈的对齐方式不受结构体成员对齐选项的影响。总是保持对齐且对齐在4字节边界上。 【例4】 #pragma pack(push, 1) //后面可改为1, 2, 4, 8 struct StrtE { char m1; long m2; }; #pragma pack(pop) int main(void) { char a; short b; int c; double d[2]; struct StrtE s; printf("a address: %p\n", &a); printf("b address: %p\n", &b); printf("c address: %p\n", &c); printf("d[0] address: %p\n", &(d[0])); printf("d[1] address: %p\n", &(d[1])); printf("s address: %p\n", &s); printf("s.m2 address: %p\n", &(s.m2)); return 0; } 结果如下： a address: 0xbfc4cfff b address: 0xbfc4cffc c address: 0xbfc4cff8 d[0] address: 0xbfc4cfe8 d[1] address: 0xbfc4cff0 s address: 0xbfc4cfe3 s.m2 address: 0xbfc4cfe4 可以看出都是对齐到4字节。并且前面的char和short并没有被凑在一起(成4字节)，这和结构体内的处理是不同的。 至于为什么输出的地址值是变小的，这是因为该平台下的栈是倒着“生长”的。 3.3 位域对齐 3.3.1 位域定义 有些信息在存储时，并不需要占用一个完整的字节，而只需占几个或一个二进制位。例如在存放一个开关量时，只有0和1两种状态，用一位二进位即可。 为了节省存储空间和处理简便，C语言提供了一种数据结构，称为“位域”或“位段”。 位域是一种特殊的结构成员或联合成员(即只能用在结构或联合中)，用于指定该成员在内存存储时所占用的位数，从而在机器内更紧凑地表示数据。 每个位域有一个域名，允许在程序中按域名操作对应的位。这样就可用一个字节的二进制位域来表示几个不同的对象。 位域定义与结构定义类似，其形式为： struct 位域结构名 { //位域列表 }; 其中位域列表的形式为： 类型说明符 位域名：位域长度 位域的使用和结构成员的使用相同，其一般形式为： 位域变量名.位域名 位域允许用各种格式输出。 位域在本质上就是一种结构类型，不过其成员是按二进位分配的。位域变量的说明与结构变量说明的方式相同，可先定义后说明、同时定义说明或直接说明。 位域的使用主要为下面两种情况： 当机器可用内存空间较少而使用位域可大量节省内存时。如把结构作为大数组的元素时。 当需要把一结构体或联合映射成某预定的组织结构时。如需要访问字节内的特定位时。 3.3.2 对齐准则 位域成员不能单独被取sizeof值。下面主要讨论含有位域的结构体的sizeof。 C99规定int、unsigned int和bool可以作为位域类型，但编译器几乎都对此作了扩展，允许其它类型的存在。 位域作为嵌入式系统中非常常见的一种编程工具，优点在于压缩程序的存储空间。 其对齐规则大致为： 如果相邻位域字段的类型相同，且其位宽之和小于类型的sizeof大小，则后面的字段将紧邻前一个字段存储，直到不能容纳为止； 如果相邻位域字段的类型相同，但其位宽之和大于类型的sizeof大小，则后面的字段将从新的存储单元开始，其偏移量为其类型大小的整数倍； 如果相邻的位域字段的类型不同，则各编译器的具体实现有差异，VC6采取不压缩方式，Dev-C++和GCC采取压缩方式； 如果位域字段之间穿插着非位域字段，则不进行压缩； 整个结构体的总大小为最宽基本类型成员大小的整数倍，而位域则按照其最宽类型字节数对齐。 【例5】 struct BitField { char element1 : 1; char element2 : 4; char element3 : 5; }; 位域类型为char，第1个字节仅能容纳下element1和element2，所以element1和element2被压缩到第1个字节中，而element3只能从下一个字节开始。因此sizeof(BitField)的结果为2。 【例6】 struct BitField1 { char element1 : 1; short element2 : 5; char element3 : 7; }; 由于相邻位域类型不同，在VC6中其sizeof为6，在Dev-C++中为2。 【例7】 struct BitField2 { char element1 : 3; char element2 ; char element3 : 5; }; 非位域字段穿插在其中，不会产生压缩，在VC6和Dev-C++中得到的大小均为3。 【例8】 struct StructBitField { int element1 : 1; int element2 : 5; int element3 : 29; int element4 : 6; char element5 :2; char stelement; //在含位域的结构或联合中也可同时说明普通成员 }; 位域中最宽类型int的字节数为4，因此结构体按4字节对齐，在VC6中其sizeof为16。 3.3.3 注意事项 关于位域操作有几点需要注意： 位域的地址不能访问，因此不允许将&运算符用于位域。不能使用指向位域的指针也不能使用位域的数组(数组是种特殊指针)。 例如，scanf函数无法直接向位域中存储数据： int main(void) { struct BitField1 tBit; scanf("%d", &tBit.element2); //error: cannot take address of bit-field 'element2' return 0; } 可用scanf函数将输入读入到一个普通的整型变量中，然后再赋值给tBit.element2。 位域不能作为函数返回的结果。 位域以定义的类型为单位，且位域的长度不能够超过所定义类型的长度。例如定义int a:33是不允许的。 位域可以不指定位域名，但不能访问无名的位域。 位域可以无位域名，只用作填充或调整位置，占位大小取决于该类型。 例如，char :0表示整个位域向后推一个字节，即该无名位域后的下一个位域从下一个字节开始存放，同理short :0和int :0分别表示整个位域向后推两个和四个字节。 当空位域的长度为具体数值N时(如int :2)，该变量仅用来占位N位。 【例9】 struct BitField3 { char element1 : 3; char :6; char element3 : 5; }; 结构体大小为3。因为element1占3位，后面要保留6位而char为8位，所以保留的6位只能放到第2个字节。 同样element3只能放到第3字节。 struct BitField4 { char element1 : 3; char :0; char element3 : 5; }; 长度为0的位域告诉编译器将下一个位域放在一个存储单元的起始位置。 如上，编译器会给成员element1分配3位，接着跳过余下的4位到下一个存储单元，然后给成员element3分配5位。故上面的结构体大小为2。 位域的表示范围。 位域的赋值不能超过其可以表示的范围； 位域的类型决定该编码能表示的值的结果。 对于第二点，若位域为unsigned类型，则直接转化为正数；若非unsigned类型，则先判断最高位是否为1，若为1表示补码，则对其除符号位外的所有位取反再加一得到最后的结果数据(原码)。如： unsigned int p:3 = 111; //p表示7 int p:3 = 111; //p 表示-1，对除符号位之外的所有位取反再加一 带位域的结构在内存中各个位域的存储方式取决于编译器，既可从左到右也可从右到左存储。 【例10】在VC6下执行下面的代码： int main(void) { union { int i; struct { char a : 1; char b : 1; char c : 2; }bits; }num; printf("Input an integer for i(0~15): "); scanf("%d", &num.i); printf("i = %d, cba = %d %d %d\n", num.i, num.bits.c, num.bits.b, num.bits.a); return 0; } 输入i值为11，则输出为i = 11, cba = -2 -1 -1。 Intel x86处理器按小字节序存储数据，所以bits中的位域在内存中放置顺序为ccba。当num.i置为11时，bits的最低有效位(即位域a)的值为1，a、b、c按低地址到高地址分别存储为10、1、1(二进制)。 但为什么最后的打印结果是a=-1而不是1？ 因为位域a定义的类型signed char是有符号数，所以尽管a只有1位，仍要进行符号扩展。1做为补码存在，对应原码-1。 如果将a、b、c的类型定义为unsigned char，即可得到cba = 2 1 1。1011即为11的二进制数。 注：C语言中，不同的成员使用共同的存储区域的数据构造类型称为联合(或共用体)。联合占用空间的大小取决于类型长度最大的成员。联合在定义、说明和使用形式上与结构体相似。 位域的实现会因编译器的不同而不同，使用位域会影响程序可移植性。因此除非必要否则最好不要使用位域。 尽管使用位域可以节省内存空间，但却增加了处理时间。当访问各个位域成员时，需要把位域从它所在的字中分解出来或反过来把一值压缩存到位域所在的字位中。 四 、总结 让我们回到引言部分的问题。 缺省情况下，C/C++编译器默认将结构、栈中的成员数据进行内存对齐。因此，引言程序输出就变成"c1 -> 0, s -> 2, c2 -> 4, i -> 8"。 编译器将未对齐的成员向后移，将每一个都成员对齐到自然边界上，从而也导致整个结构的尺寸变大。尽管会牺牲一点空间(成员之间有空洞)，但提高了性能。 也正是这个原因，引言例子中sizeof(T_ FOO)为12，而不是8。 总结说来，就是在结构体中，综合考虑变量本身和指定的对齐值；在栈上，不考虑变量本身的大小，统一对齐到4字节。 五 、附录 5.1 字节序与网络序 5.1.1 字节序 字节序，顾名思义就是字节的高低位存放顺序。 对于单字节，大部分处理器以相同的顺序处理比特位，因此单字节的存放和传输方式一般相同。 对于多字节数据，如整型(32位机中一般占4字节)，在不同的处理器的存放方式主要有两种(以内存中0x0A0B0C0D的存放方式为例)。 大字节序(Big-Endian，又称大端序或大尾序) 在计算机中，存储介质以下面方式存储整数0x0A0B0C0D则称为大字节序： 其中，最高有效位(MSB，Most Significant Byte)0x0A存储在最低的内存地址处。下个字节0x0B存在后面的地址处。同时，最高的16bit单元0x0A0B存储在低位。 简而言之，大字节序就是高字节存入低地址，低字节存入高地址。 这里讲个词源典故：“endian”一词来源于乔纳森·斯威夫特的小说《格列佛游记》。小说中，小人国为水煮蛋该从大的一端(Big-End)剥开还是小的一端(Little-End)剥开而争论，争论的双方分别被称为Big-endians和Little-endians。 1980年，Danny Cohen在其著名的论文"On Holy Wars and a Plea for Peace"中为平息一场关于字节该以什么样的顺序传送的争论而引用了该词。 借用上面的典故，想象一下要把熟鸡蛋旋转着稳立起来，大头(高字节)肯定在下面(低地址)^_^ 小字节序(Little-Endian，又称小端序或小尾序) 在计算机中，存储介质以下面方式存储整数0x0A0B0C0D则称为小字节序： 其中，最低有效位(LSB，Least Significant Byte)0x0D存储在最低的内存地址处。后面字节依次存在后面的地址处。同时，最低的16bit单元0x0A0B存储在低位。 可见，小字节序就是“高字节存入高地址，低字节存入低地址”。 C语言中的位域结构也要遵循比特序(类似字节序)。例如： struct bitfield { unsigned char a: 2; unsigned char b: 6; } 该位域结构占1个字节，假设赋值a = 0x01和b=0x02，则大字节机器上该字节为(01)(000010)，小字节机器上该字节为(000010)(01)。因此在编写可移植代码时，需要加条件编译。 注意，在包含位域的C结构中，若位域A在位域B之前定义，则位域A所占用的内存空间地址低于位域B所占用的内存空间。 对上述问题，详细的讲解可参考 http://www.linuxjournal.com/article/6788。 另见以下联合体，在小字节机器上若low=0x01，high=0x02，则hex=0x21： int main(void) { union { unsigned char hex; struct { unsigned char low : 4; unsigned char high : 4; }; }convert; convert.low = 0x01; convert.high = 0x02; printf("hex = 0x%0x\n", convert.hex); return 0; } 5.1.2 网络序 网络传输一般采用大字节序，也称为网络字节序或网络序。IP协议中定义大字节序为网络字节序。 对于可移植的代码来说，将接收的网络数据转换成主机的字节序是必须的，一般会有成对的函数用于把网络数据转换成相应的主机字节序或反之(若主机字节序与网络字节序相同，通常将函数定义为空宏)。 伯克利socket API定义了一组转换函数，用于16和32位整数在网络序和主机字节序之间的转换。Htonl、htons用于主机序转换到网络序；ntohl、ntohs用于网络序转换到本机序。 注意：在大小字节序转换时，必须考虑待转换数据的长度(如5.1.1节的数据单元)。另外对于单字符或小于单字符的几个bit数据，是不必转换的，因为在机器存储和网络发送的一个字符内的bit位存储顺序是一致的。 5.1.3 位序 用于描述串行设备的传输顺序。一般硬件传输采用小字节序(先传低位)，但I2C协议采用大字节序。网络协议中只有数据链路层的底端会涉及到。 5.1.4 处理器字节序 不同处理器体系的字节序如下所示： X86、MOS Technology 6502、Z80、VAX、PDP-11等处理器为Little endian； Motorola 6800、Motorola 68000、PowerPC 970、System/370、SPARC(除V9外)等处理器为Big endian； ARM、PowerPC (除PowerPC 970外)、DEC Alpha，SPARC V9，MIPS，PA-RISC and IA64等的字节序是可配置的。 5.1.5 字节序编程 请看下面的语句： printf("%c\n", *((short*)"AB") >> 8); 在大字节序下输出为'A'，小字节序下输出为'B'。 下面的代码可用来判断本地机器字节序： //字节序枚举类型 typedef enum { ENDIAN_LITTLE = (INT8U)0X00, ENDIAN_BIG = (INT8U)0X01 }E_ENDIAN_TYPE; E_ENDIAN_TYPE GetEndianType(VOID) { INT32U dwData = 0x12345678; if(0x78 == *((INT8U*)&dwData)) return ENDIAN_LITTLE; else return ENDIAN_BIG; } //Start of GetEndianTypeTest// #include VOID GetEndianTypeTest(VOID) { #if _BYTE_ORDER == _LITTLE_ENDIAN printf("[%s]Result: %s, EndianType = %s!\n", __FUNCTION__, (ENDIAN_LITTLE != GetEndianType()) ? "ERROR" : "OK", "Little"); #elif _BYTE_ORDER == _BIG_ENDIAN printf("[%s]Result: %s, EndianType = %s!\n", __FUNCTION__, (ENDIAN_BIG != GetEndianType()) ? "ERROR" : "OK", "Big"); #endif } //End of GetEndianTypeTest// 在字节序不同的平台间的交换数据时，必须进行转换。比如对于int类型，大字节序写入文件： int i = 100; write(fd, &i, sizeof(int)); 小字节序读出后： int i; read(fd, &i, sizeof(int)); char buf[sizeof(int)]; memcpy(buf, &i, sizeof(int)); for(i = 0; i < sizeof(int); i++) { int v = buf[sizeof(int) - i - 1]; buf[sizeof(int) - 1] = buf[i]; buf[i] = v; } memcpy(&i, buf, sizeof(int)); 上面仅仅是个例子。在不同平台间即使不存在字节序的问题，也尽量不要直接传递二进制数据。作为可选的方式就是使用文本来交换数据，这样至少可以避免字节序的问题。 很多的加密算法为了追求速度，都会采取字符串和数字之间的转换，在计算完毕后，必须注意字节序的问题，在某些实现中可以见到使用预编译的方式来完成，这样很不方便，如果使用前面的语句来判断，就可以自动适应。 字节序问题不仅影响异种平台间传递数据，还影响诸如读写一些特殊格式文件之类程序的可移植性。此时使用预编译的方式来完成也是一个好办法。 5.2 对齐时的填充字节 代码如下： struct A { char c; int i; short s; }; int main(void) { struct A a; a.c = 1; a.i = 2; a.s = 3; printf("sizeof(A)=%d\n", sizeof(struct A)); return 0; } 执行后输出为sizeof(A)=12。 VC6.0环境中，在main函数打印语句前设置断点，执行到断点处时根据结构体a的地址查看变量存储如下： 可见填充字节为0xCC，即int3中断。 5.3 pragma pack语法说明 #pragma pack(n) #pragma pack(push, 1) #pragma pack(pop) #pragma pack(n) 该指令指定结构和联合成员的紧凑对齐。而一个完整的转换单元的结构和联合的紧凑对齐由/ Z p选项设置。紧凑对齐用pack编译指示在数据说明层设置。该编译指示在其出现后的第一个结构或者联合说明处生效。该编译指示对定义无效。 当使用#pragma pack (n) 时，n 为1、2、4、8 或1 6 。第一个结构成员后的每个结构成员都被存储在更小的成员类型或n字节界限内。如果使用无参量的#pragma pack，结构成员被紧凑为以/ Z p指定的值。该缺省/ Z p紧凑值为/ Z p 8。 2)编译器也支持以下增强型语法： #pragma pack( [ [ { push | pop } , ] [identifier, ] ] [ n] ) 若不同的组件使用pack编译指示指定不同的紧凑对齐, 这个语法允许你把程序组件组合为一个单独的转换单元。 带push参量的pack编译指示的每次出现将当前的紧凑对齐存储到一个内部编译器堆栈中。编译指示的参量表从左到右读取。如果使用push，则当前紧凑值被存储起来；如果给出一个n值，该值将成为新的紧凑值。若指定一个标识符，即选定一个名称，则该标识符将和这个新的的紧凑值联系起来。 带一个pop参量的pack编译指示的每次出现都会检索内部编译器堆栈顶的值，并使该值为新的紧凑对齐值。如果使用pop参量且内部编译器堆栈是空的,则紧凑值为命令行给定的值，并将产生一个警告信息。若使用pop且指定一个n值，该值将成为新的紧凑值。 若使用pop且指定一个标识符，所有存储在堆栈中的值将从栈中删除，直到找到一个匹配的标识符。这个与标识符相关的紧凑值也从栈中移出，并且这个仅在标识符入栈之前存在的紧凑值成为新的紧凑值。如果未找到匹配的标识符, 将使用命令行设置的紧凑值，并且将产生一个一级警告。缺省紧凑对齐为8。 pack编译指示的新的增强功能让你在编写头文件时，确保在遇到该头文件的前后的紧凑值是一样的。 5.4 Intel关于内存对齐的说明 以下内容节选自《Intel Architecture 32 Manual》。 字、双字和四字在自然边界上不需要在内存中对齐。(对于字、双字和四字来说，自然边界分别是偶数地址，可以被4整除的地址，和可以被8整除的地址。) 无论如何，为了提高程序的性能，数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；然而，对齐的内存访问仅需要一次访问。 一个字或双字操作数跨越了4字节边界，或者一个四字操作数跨越了8字节边界，被认为是未对齐的，从而需要两次总线周期来访问内存。一个字起始地址是奇数但却没有跨越字边界被认为是对齐的，能够在一个总线周期中被访问。 某些操作双四字的指令需要内存操作数在自然边界上对齐。如果操作数没有对齐，这些指令将会产生一个通用保护异常(#GP)。双四字的自然边界是能够被16 整除的地址。其他操作双四字的指令允许未对齐的访问(不会产生通用保护异常)，然而，需要额外的内存总线周期来访问内存中未对齐的数据。 5.5 不同架构处理器的对齐要求 RISC指令集处理器(MIPS/ARM)：这种处理器的设计以效率为先，要求所访问的多字节数据(short/int/ long)的地址必须是为此数据大小的倍数，如short数据地址应为2的倍数，long数据地址应为4的倍数，也就是说是对齐的。 CISC指令集处理器(X86)：没有上述限制。 对齐处理策略 访问非对齐多字节数据时(pack数据)，编译器会将指令拆成多条(因为非对齐多字节数据可能跨越地址对齐边界)，保证每条指令都从正确的起始地址上获取数据，但也因此效率比较低。 访问对齐数据时则只用一条指令获取数据，因此对齐数据必须确保其起始地址是在对齐边界上。如果不是在对齐的边界，对X86 CPU是安全的，但对MIPS/ARM这种RISC CPU会出现“总线访问异常”。 为什么X86是安全的呢？ X86 CPU是如何进行数据对齐的。X86 CPU的EFLAGS寄存器中包含一个特殊的位标志，称为AC(对齐检查的英文缩写)标志。按照默认设置，当CPU首次加电时，该标志被设置为0。当该标志是0时，CPU能够自动执行它应该执行的操作，以便成功地访问未对齐的数据值。 然而，如果该标志被设置为1，每当系统试图访问未对齐的数据时，CPU就会发出一个INT 17H中断。X86的Windows 2000和Windows 98版本从来不改变这个CPU标志位。因此，当应用程序在X86处理器上运行时，你根本看不到应用程序中出现数据未对齐的异常条件。 为什么MIPS/ARM不安全呢？ 因为MIPS/ARM CPU不能自动处理对未对齐数据的访问。当未对齐的数据访问发生时，CPU就会将这一情况通知操作系统。这时，操作系统将会确定它是否应该引发一个数据未对齐异常条件，对vxworks是会触发这个异常的。 5.6 ARM下的对齐处理 有部分摘自ARM编译器文档对齐部分。 对齐的使用： 1) __align(num) 用于修改最高级别对象的字节边界。在汇编中使用LDRD或STRD时就要用到此命令__align(8)进行修饰限制。来保证数据对象是相应对齐。 这个修饰对象的命令最大是8个字节限制，可以让2字节的对象进行4字节对齐，但不能让4字节的对象2字节对齐。 __align是存储类修改，只修饰最高级类型对象，不能用于结构或者函数对象。 2) __packed 进行一字节对齐。需注意： 不能对packed的对象进行对齐； 所有对象的读写访问都进行非对齐访问； float及包含float的结构联合及未用__packed的对象将不能字节对齐； __packed对局部整型变量无影响。 强制由unpacked对象向packed对象转化时未定义。整型指针可以合法定义为packed，如__packed int* p(__packed int 则没有意义) 对齐或非对齐读写访问可能存在的问题： //定义如下结构，b的起始地址不对齐。在栈中访问b可能有问题，因为栈上数据对齐访问 __packed struct STRUCT_TEST { char a; int b; char c; }; //将下面的变量定义成全局静态(不在栈上) static char *p; static struct STRUCT_TEST a; void Main() { __packed int *q; //定义成__packed来修饰当前q指向为非对齐的数据地址下面的访问则可以 p = (char*)&a; q = (int*)(p + 1); *q = 0x87654321; /* 得到赋值的汇编指令很清楚 ldr r5,0x20001590 ; = #0x12345678 [0xe1a00005] mov r0,r5 [0xeb0000b0] bl __rt_uwrite4 //在此处调用一个写4字节的操作函数 [0xe5c10000] strb r0,[r1,#0] //函数进行4次strb操作然后返回，正确访问数据 [0xe1a02420] mov r2,r0,lsr #8 [0xe5c12001] strb r2,[r1,#1] [0xe1a02820] mov r2,r0,lsr #16 [0xe5c12002] strb r2,[r1,#2] [0xe1a02c20] mov r2,r0,lsr #24 [0xe5c12003] strb r2,[r1,#3] [0xe1a0f00e] mov pc,r14 若q未加__packed修饰则汇编出来指令如下(会导致奇地址处访问失败)： [0xe59f2018] ldr r2,0x20001594 ; = #0x87654321 [0xe5812000] str r2,[r1,#0] */ //这样很清楚地看到非对齐访问如何产生错误，以及如何消除非对齐访问带来的问题 //也可看到非对齐访问和对齐访问的指令差异会导致效率问题 } 5.7 《The C Book》之位域篇 While we're on the subject of structures, we might as well look at bitfields. They can only be declared inside a structure or a union, and allow you to specify some very small objects of a given number of bits in length. Their usefulness is limited and they aren't seen in many programs, but we'll deal with them anyway. This example should help to make things clear: struct { unsigned field1 :4; //field 4 bits wide unsigned :3; //unnamed 3 bit field(allow for padding) signed field2 :1; //one-bit field(can only be 0 or -1 in two's complement) unsigned :0; //align next field on a storage unit unsigned field3 :6; }full_of_fields; Each field is accessed and manipulated as if it were an ordinary member of a structure. The keywords signed and unsigned mean what you would expect, except that it is interesting to note that a 1-bit signed field on a two's complement machine can only take the values 0 or -1. The declarations are permitted to include the const and volatile qualifiers. The main use of bitfields is either to allow tight packing of data or to be able to specify the fields within some externally produced data files. C gives no guarantee of the ordering of fields within machine words, so if you do use them for the latter reason, you program will not only be non-portable, it will be compiler-dependent too. The Standard says that fields are packed into ‘storage units’, which are typically machine words. The packing order, and whether or not a bitfield may cross a storage unit boundary, are implementation defined. To force alignment to a storage unit boundary, a zero width field is used before the one that you want to have aligned. Be careful using them. It can require a surprising amount of run-time code to manipulate these things and you can end up using more space than they save. Bit fields do not have addresses—you can't have pointers to them or arrays of them. 5.8 C语言字节相关面试题 5.8.1 Intel/微软C语言面试题 请看下面的问题： #pragma pack(8) struct s1 { short a; long b; }; struct s2 { char c; s1 d; long long e; //VC6.0下可能要用__int64代替双long }; #pragma pack() 问：1. sizeof(s2) = ？2. s2的s1中的a后面空了几个字节接着是b？ 【分析】 成员对齐有一个重要的条件，即每个成员分别按自己的方式对齐。 也就是说上面虽然指定了按8字节对齐，但并不是所有的成员都是以8字节对齐。其对齐的规则是：每个成员按其类型的对齐参数(通常是这个类型的大小)和指定对齐参数(这里是8字节)中较小的一个对齐，并且结构的长度必须为所用过的所有对齐参数的整数倍，不够就补空字节。 s1中成员a是1字节，默认按1字节对齐，而指定对齐参数为8，两值中取1，即a按1字节对齐；成员b是4个字节，默认按4字节对齐，这时就按4字节对齐，所以sizeof(s1)应该为8； s2中c和s1中a一样，按1字节对齐。而d 是个8字节结构体，其默认对齐方式就是所有成员使用的对齐参数中最大的一个，s1的就是4。所以，成员d按4字节对齐。成员e是8个字节，默认按8字节对齐，和指定的一样，所以它对到8字节的边界上。 这时，已经使用了12个字节，所以又添加4个字节的空，从第16个字节开始放置成员e。此时长度为24，并可被8(成员e按8字节对齐)整除。这样，一共使用了24个字节。 各个变量在内存中的布局为： c***aa** bbbb**** dddddddd ——这种“矩阵写法”很方便看出结构体实际大小！ 因此，sizeof(S2)结果为24，a后面空了2个字节接着是b。 这里有三点很重要： 每个成员分别按自己的方式对齐，并能最小化长度； 复杂类型(如结构)的默认对齐方式是其最长的成员的对齐方式，这样在成员是复杂类型时可以最小化长度； 对齐后的长度必须是成员中最大对齐参数的整数倍，这样在处理数组时可保证每一项都边界对齐。 还要注意，“空结构体”(不含数据成员)的大小为1，而不是0。试想如果不占空间的话，一个空结构体变量如何取地址、两个不同的空结构体变量又如何得以区分呢？ 5.8.2 上海网宿科技面试题 假设硬件平台是intel x86(little endian)，以下程序输出什么： //假设硬件平台是intel x86(little endian) typedef unsigned int uint32_t; void inet_ntoa(uint32_t in) { char b[18]; register char *p; p = (char *)∈ #define UC(b) (((int)b)&0xff) //byte转换为无符号int型 sprintf(b, "%d.%d.%d.%d\n", UC(p[0]), UC(p[1]), UC(p[2]), UC(p[3])); printf(b); } int main(void) { inet_ntoa(0x12345678); inet_ntoa(0x87654321); return 0; } 先看如下程序： int main(void) { int a = 0x12345678; char *p = (char *)&a; char str[20]; sprintf(str,"%d.%d.%d.%d\n", p[0], p[1], p[2], p[3]); printf(str); return 0; } 按照小字节序的规则，变量a在计算机中存储方式为： 注意，p并不是指向0x12345678的开头0x12，而是指向0x78。p[0]到p[1]的操作是&p[0]+1，因此p[1]地址比p[0]地址大。输出结果为120.86.52.18。 反过来的话，令int a = 0x87654321，则输出结果为33.67.101.-121。 为什么有负值呢？ 因为系统默认的char是有符号的，本来是0x87也就是135，大于127因此就减去256得到-121。 想要得到正值的话只需将char *p = (char *)&a改为unsigned char *p = (unsigned char *)&a即可。 综上不难得出，网宿面试题的答案为120.86.52.18和33.67.101.135。
2024-12-06 101浏览 -
-
-
-
STM32三种开发方式
前言 相比较早几年使用标准库开发来讲，最近几年HAL库的使用是越来越多，那么我们开发应当使用哪一种呢，本文着重介绍常用的几种开发方式及相互之间的区别，白猫也好、黑猫也好，抓到耗子就是好猫。 STM32三种开发方式 通常新手在入门STM32的时候，首先都要先选择一种要用的开发方式，不同的开发方式会导致你编程的架构是完全不一样的。一般大多数都会选用标准库和HAL库，而极少部分人会通过直接配置寄存器进行开发。 网上关于标准库、HAL库的描述相信是数不胜数。可是一个对于很多刚入门的朋友还是没法很直观的去真正了解这些不同开发发方式彼此之间的区别，所以笔者想以一种非常直白的方式，用自己的理解去将这些东西表述出来，如果有描述的不对的地方或者是不同意见的也可以大家提出。 1、直接配置寄存器 不少先学了51的朋友可能会知道，会有一小部分人或是教程是通过汇编语言直接操作寄存器实现功能的，这种方法到了STM32就变得不太容易行得通了，因为STM32的寄存器数量是51单片机的十数倍，如此多的寄存器根本无法全部记忆，开发时需要经常的翻查芯片的数据手册，此时直接操作寄存器就变得非常的费力了。但还是会有很小一部分人，喜欢去直接操作寄存器，因为这样更接近原理，知其然也知其所以然。 2、标准库 上面也提到了，STM32有非常多的寄存器，而导致了开发困难，所以为此ST公司就为每款芯片都编写了一份库文件，也就是工程文件里stm32F1xx…之类的。在这些 .c .h文件中，包括一些常用量的宏定义，把一些外设也通过结构体变量封装起来，如GPIO口时钟等。所以我们只需要配置结构体变量成员就可以修改外设的配置寄存器，从而选择不同的功能。也是目前最多人使用的方式，也是学习STM32接触最多的一种开发方式，我也就不多阐述了。 3、HAL库 HAL库是ST公司目前主力推的开发方式，全称就是Hardware Abstraction Layer（抽象印象层）。库如其名，很抽象，一眼看上去不太容易知道他的作用是什么。 它的出现比标准库要晚，但其实和标准库一样，都是为了节省程序开发的时期，而且HAL库尤其的有效，如果说标准库把实现功能需要配置的寄存器集成了，那么HAL库的一些函数甚至可以做到某些特定功能的集成。也就是说，同样的功能，标准库可能要用几句话，HAL库只需用一句话就够了。 并且HAL库也很好的解决了程序移植的问题，不同型号的stm32芯片它的标准库是不一样的，例如在F4上开发的程序移植到F3上是不能通用的，而使用HAL库，只要使用的是相通的外设，程序基本可以完全复制粘贴，注意是相通外设，意思也就是不能无中生有，例如F7比F3要多几个定时器，不能明明没有这个定时器却非要配置，但其实这种情况不多，绝大多数都可以直接复制粘贴。是而且使用ST公司研发的STMcube软件，可以通过图形化的配置功能，直接生成整个使用HAL库的工程文件，可以说是方便至极，但是方便的同时也造成了它执行效率的低下，在各种论坛帖子真的是被吐槽的数不胜数。 STM32 HAL库与标准库的区别 1、句柄 句柄（handle），有多种意义，其中第一种是指程序设计，第二种是指Windows编程。现在大部分都是指程序设计/程序开发这类。 第一种解释：句柄是一种特殊的智能指针 。当一个应用程序要引用其他系统（如数据库、操作系统）所管理的内存块或对象时，就要使用句柄。 第二种解释：整个Windows编程的基础。一个句柄是指使用的一个唯一的整数值，即一个4字节(64位程序中为8字节)长的数值，来标识应用程序中的不同对象和同类中的不同的实例，诸如，一个窗口，按钮，图标，滚动条，输出设备，控件或者文件等。应用程序能够通过句柄访问相应的对象的信息，但是句柄不是指针，程序不能利用句柄来直接阅读文件中的信息。如果句柄不在I/O文件中，它是毫无用处的。句柄是Windows用来标志应用程序中建立的或是使用的唯一整数，Windows大量使用了句柄来标识对象。 STM32的标准库中，句柄是一种特殊的指针，通常指向结构体！ 在STM32的标准库中，假设我们要初始化一个外设（这里以USART为例），我们首先要初始化他们的各个寄存器。在标准库中，这些操作都是利用固件库结构体变量+固件库Init函数实现的： USART_InitTypeDef USART_InitStructure; USART_InitStructure.USART_BaudRate = bound;//串口波特率USART_InitStructure.USART_WordLength = USART_WordLength_8b;//字长为8位数据格式USART_InitStructure.USART_StopBits = USART_StopBits_1;//一个停止位USART_InitStructure.USART_Parity = USART_Parity_No;//无奇偶校验位USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;//无硬件数据流控制USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; //收发模式 USART_Init(USART3, &USART_InitStructure); //初始化串口1 可以看到，要初始化一个串口，需要： 1、对六个位置进行赋值 2、然后引用Init函数 USART_InitStructure并不是一个全局结构体变量，而是只在函数内部的局部变量，初始化完成之后，USART_InitStructure就失去了作用。而在HAL库中，同样是USART初始化结构体变量，我们要定义为全局变量。 UART_HandleTypeDef UART1_Handler; 结构体成员 typedef struct{ USART_TypeDef *Instance; /*!< UART registers base address */ UART_InitTypeDef Init; /*!< UART communication parameters */uint8_t *pTxBuffPtr; /*!< Pointer to UART Tx transfer Buffer */uint16_t TxXferSize; /*!< UART Tx Transfer size */uint16_t TxXferCount; /*!< UART Tx Transfer Counter */uint8_t *pRxBuffPtr; /*!< Pointer to UART Rx transfer Buffer */uint16_t RxXferSize; /*!< UART Rx Transfer size */uint16_t RxXferCount; /*!< UART Rx Transfer Counter */ DMA_HandleTypeDef *hdmatx; /*!< UART Tx DMA Handle parameters */ DMA_HandleTypeDef *hdmarx; /*!< UART Rx DMA Handle parameters */ HAL_LockTypeDef Lock; /*!< Locking object */ __IO HAL_UART_StateTypeDef State; /*!< UART communication state */ __IO uint32_t ErrorCode; /*!< UART Error code */}UART_HandleTypeDef; 我们发现，与标准库不同的是，该成员不仅: 1、包含了之前标准库就有的六个成员（波特率，数据格式等）， 2、还包含过采样、（发送或接收的）数据缓存、数据指针、串口 DMA 相关的变量、各种标志位等等要在整个项目流程中都要设置的各个成员。 该 UART1_Handler就被称为串口的句柄，它被贯穿整个USART收发的流程，比如开启中断： HAL_UART_Receive_IT(&UART1_Handler, (u8 *)aRxBuffer, RXBUFFERSIZE); 比如后面要讲到的MSP与Callback回调函数： void HAL_UART_MspInit(UART_HandleTypeDef *huart);void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart); 在这些函数中，只需要调用初始化时定义的句柄UART1_Handler就好。 2、MSP函数 MSP: MCU Specific Package 单片机的具体方案 MSP是指和MCU相关的初始化，引用一下正点原子的解释，个人觉得说的很明白： 我们要初始化一个串口，首先要设置和 MCU 无关的东西，例如波特率，奇偶校验，停止位等，这些参数设置和 MCU 没有任何关系，可以使用 STM32F1，也可以是 STM32F2/F3/F4/F7上的串口。而一个串口设备它需要一个 MCU 来承载，例如用 STM32F4 来做承载，PA9 做为发送，PA10 做为接收，MSP 就是要初始化 STM32F4 的 PA9,PA10，配置这两个引脚。所以 HAL驱动方式的初始化流程就是： HAL_USART_Init()—>HAL_USART_MspInit() ，先初始化与 MCU无关的串口协议，再初始化与 MCU 相关的串口引脚。 在 STM32 的 HAL 驱动中HAL_PPP_MspInit()作为回调，被 HAL_PPP_Init()函数所调用。当我们需要移植程序到 STM32F1平台的时候，我们只需要修改 HAL_PPP_MspInit 函数内容而不需要修改 HAL_PPP_Init 入口参数内容。 在HAL库中，几乎每初始化一个外设就需要设置该外设与单片机之间的联系，比如IO口，是否复用等等，可见，HAL库相对于标准库多了MSP函数之后，移植性非常强，但与此同时却增加了代码量和代码的嵌套层级。可以说各有利弊。 同样，MSP函数又可以配合句柄，达到非常强的移植性： void HAL_UART_MspInit(UART_HandleTypeDef *huart); 3、Callback函数 类似于MSP函数，个人认为Callback函数主要帮助用户应用层的代码编写。 还是以USART为例，在标准库中，串口中断了以后，我们要先在中断中判断是否是接收中断，然后读出数据，顺便清除中断标志位，然后再是对数据的处理，这样如果我们在一个中断函数中写这么多代码，就会显得很混乱： void USART3_IRQHandler(void) //串口1中断服务程序{ u8 Res;if(USART_GetITStatus(USART3, USART_IT_RXNE) != RESET) //接收中断(接收到的数据必须是0x0d 0x0a结尾) { Res =USART_ReceiveData(USART3); //读取接收到的数据/*数据处理区*/ } } } 而在HAL库中，进入串口中断后，直接由HAL库中断函数进行托管： void USART1_IRQHandler(void) { HAL_UART_IRQHandler(&UART1_Handler); //调用HAL库中断处理公用函数 /***************省略无关代码****************/ } HAL_UART_IRQHandler这个函数完成了判断是哪个中断（接收？发送？或者其他？），然后读出数据，保存至缓存区，顺便清除中断标志位等等操作。 比如我提前设置了，串口每接收五个字节，我就要对这五个字节进行处理。在一开始我定义了一个串口接收缓存区： /*HAL库使用的串口接收缓冲,处理逻辑由HAL库控制，接收完这个数组就会调用HAL_UART_RxCpltCallback进行处理这个数组*//*RXBUFFERSIZE=5*/u8 aRxBuffer[RXBUFFERSIZE]; 在初始化中，我在句柄里设置好了缓存区的地址，缓存大小（五个字节） /*该代码在HAL_UART_Receive_IT函数中，初始化时会引用*/ huart->pRxBuffPtr = pData;//aRxBuffer huart->RxXferSize = Size;//RXBUFFERSIZE huart->RxXferCount = Size;//RXBUFFERSIZE 则在接收数据中，每接收完五个字节，HAL_UART_IRQHandler才会执行一次Callback函数： void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart); 在这个Callback回调函数中，我们只需要对这接收到的五个字节（保存在aRxBuffer[]中）进行处理就好了，完全不用再去手动清除标志位等操作。 所以说Callback函数是一个应用层代码的函数，我们在一开始只设置句柄里面的各个参数，然后就等着HAL库把自己安排好的代码送到手中就可以了~ 综上，就是HAL库的三个与标准库不同的地方之个人见解。个人觉得从这三个小点就可以看出HAL库的可移植性之强大，并且用户可以完全不去理会底层各个寄存器的操作，代码也更有逻辑性。但与此带来的是复杂的代码量，极慢的编译速度，略微低下的效率。看怎么取舍了。 STM32 HAL库结构 说到STM32的HAL库，就不得不提STM32CubeMX，其作为一个可视化的配置工具，对于开发者来说，确实大大节省了开发时间。相关推荐：STM32CubeMX安装教程。STM32CubeMX就是以HAL库为基础的，且目前仅支持HAL库及LL库！首先看一下，官方给出的HAL库的包含结构： 1、stm32f4xx.h主要包含STM32同系列芯片的不同具体型号的定义，是否使用HAL库等的定义，接着，其会根据定义的芯片信号包含具体的芯片型号的头文件： #if defined(STM32F405xx)#include "stm32f405xx.h"#elif defined(STM32F415xx)#include "stm32f415xx.h"#elif defined(STM32F407xx)#include "stm32f407xx.h"#elif defined(STM32F417xx)#include "stm32f417xx.h"#else#error "Please select first the target STM32F4xx device used in your application (in stm32f2xx.h file)"#endif 紧接着，其会包含stm32f4xx_hal.h。 2、stm32f4xx_hal.h：stm32f4xx_hal.c/h 主要实现HAL库的初始化、系统滴答相关函数、及CPU的调试模式配置 3、stm32f4xx_hal_conf.h ：该文件是一个用户级别的配置文件，用来实现对HAL库的裁剪，其位于用户文件目录，不要放在库目录中。 接下来对于HAL库的源码文件进行一下说明，HAL库文件名均以stm32f4xx_hal开头，后面加上_外设或者模块名（如：stm32f4xx_hal_adc.c）： 4、库文件：stm32f4xx_hal_ppp.c/.h // 主要的外设或者模块的驱动源文件，包含了该外设的通用API stm32f4xx_hal_ppp_ex.c/.h // 外围设备或模块驱动程序的扩展文件。这组文件中包含特定型号或者系列的芯片的特殊API。以及如果该特定的芯片内部有不同的实现方式，则该文件中的特殊API将覆盖_ppp中的通用API。 stm32f4xx_hal.c/.h // 此文件用于HAL初始化，并且包含DBGMCU、重映射和基于systick的时间延迟等相关的API 5、其他库文件 用户级别文件： stm32f4xx_hal_msp_template.c // 只有.c没有.h。它包含用户应用程序中使用的外设的MSP初始化和反初始化（主程序和回调函数）。使用者复制到自己目录下使用模板。 stm32f4xx_hal_conf_template.h // 用户级别的库配置文件模板。使用者复制到自己目录下使用 system_stm32f4xx.c // 此文件主要包含SystemInit()函数，该函数在刚复位及跳到main之前的启动过程中被调用。它不在启动时配置系统时钟（与标准库相反）。时钟的配置在用户文件中使用HAL API来完成。startup_stm32f4xx.s // 芯片启动文件，主要包含堆栈定义，终端向量表等 stm32f4xx_it.c/.h // 中断处理函数的相关实现 6 main.c/.h // 根据HAL库的命名规则，其API可以分为以下三大类： 初始化/反初始化函数： HAL_PPP_Init(), HAL_PPP_DeInit() IO 操作函数： HAL_PPP_Read(),HAL_PPP_Write(),HAL_PPP_Transmit(), HAL_PPP_Receive() 控制函数： HAL_PPP_Set (), HAL_PPP_Get (). 状态和错误: ** HAL_PPP_GetState (), HAL_PPP_GetError (). 注意： 目前LL库是和HAL库捆绑发布的，所以在HAL库源码中，还有一些名为 stm32f2xx_ll_ppp的源码文件，这些文件就是新增的LL库文件。使用CubeMX生产项目时，可以选择LL库。 HAL库最大的特点就是对底层进行了抽象。在此结构下，用户代码的处理主要分为三部分： 处理外设句柄（实现用户功能） 处理MSP 处理各种回调函数 相关知识如下： 1、外设句柄定义 用户代码的第一大部分：对于外设句柄的处理。HAL库在结构上，对每个外设抽象成了一个称为ppp_HandleTypeDef的结构体，其中ppp就是每个外设的名字。*所有的函数都是工作在ppp_HandleTypeDef指针之下。 多实例支持：每个外设/模块实例都有自己的句柄。因此，实例资源是独立的 下面，以ADC为例 外围进程相互通信：该句柄用于管理进程例程之间的共享数据资源。 /** * @brief ADC handle Structure definition */typedef struct{ ADC_TypeDef *Instance; /*!< Register base address */ ADC_InitTypeDef Init; /*!< ADC required parameters */ __IO uint32_t NbrOfCurrentConversionRank; /*!< ADC number of current conversion rank */ DMA_HandleTypeDef *DMA_Handle; /*!< Pointer DMA Handler */ HAL_LockTypeDef Lock; /*!< ADC locking object */ __IO uint32_t State; /*!< ADC communication state */ __IO uint32_t ErrorCode; /*!< ADC Error code */}ADC_HandleTypeDef; 从上面的定义可以看出，ADC_HandleTypeDef中包含了ADC可能出现的所有定义，对于用户想要使用ADC只要定义一个ADC_HandleTypeDef的变量，给每个变量赋好值，对应的外设就抽象完了。接下来就是具体使用了。 当然，对于那些共享型外设或者说系统外设来说，他们不需要进行以上这样的抽象，这些部分与原来的标准外设库函数基本一样。例如以下外设： GPIO SYSTICK NVIC RCC FLASH 以GPIO为例，对于HAL_GPIO_Init() 函数，其只需要GPIO 地址以及其初始化参数即可。 2、 三种编程方式 HAL库对所有的函数模型也进行了统一。在HAL库中，支持三种编程模式：轮询模式、中断模式、DMA模式（如果外设支持）。其分别对应如下三种类型的函数（以ADC为例）： HAL_StatusTypeDef HAL_ADC_Start(ADC_HandleTypeDef* hadc); HAL_StatusTypeDef HAL_ADC_Stop(ADC_HandleTypeDef* hadc); HAL_StatusTypeDef HAL_ADC_Start_IT(ADC_HandleTypeDef* hadc);HAL_StatusTypeDef HAL_ADC_Stop_IT(ADC_HandleTypeDef* hadc); HAL_StatusTypeDef HAL_ADC_Start_DMA(ADC_HandleTypeDef* hadc, uint32_t* pData, uint32_t Length);HAL_StatusTypeDef HAL_ADC_Stop_DMA(ADC_HandleTypeDef* hadc); 其中，带_IT的表示工作在中断模式下；带_DMA的工作在DMA模式下（注意：DMA模式下也是开中断的）；什么都没带的就是轮询模式（没有开启中断的）。至于使用者使用何种方式，就看自己的选择了。 此外，新的HAL库架构下统一采用宏的形式对各种中断等进行配置（原来标准外设库一般都是各种函数）。针对每种外设主要由以下宏： __HAL_PPP_ENABLE_IT(HANDLE, INTERRUPT)：使能一个指定的外设中断__HAL_PPP_DISABLE_IT(HANDLE, INTERRUPT)：失能一个指定的外设中断__HAL_PPP_GET_IT (HANDLE, __ INTERRUPT __)：获得一个指定的外设中断状态__HAL_PPP_CLEAR_IT (HANDLE, __ INTERRUPT __)：清除一个指定的外设的中断状态__HAL_PPP_GET_FLAG (HANDLE, FLAG)：获取一个指定的外设的标志状态__HAL_PPP_CLEAR_FLAG (HANDLE, FLAG)：清除一个指定的外设的标志状态__HAL_PPP_ENABLE(HANDLE) ：使能外设__HAL_PPP_DISABLE(HANDLE) ：失能外设__HAL_PPP_XXXX (HANDLE, PARAM) ：指定外设的宏定义_HAL_PPP_GET IT_SOURCE (HANDLE, __ INTERRUPT __)：检查中断源 3、 三大回调函数 在HAL库的源码中，到处可见一些以__weak开头的函数，而且这些函数，有些已经被实现了，比如： __weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority){/*Configure the SysTick to have interrupt in 1ms time basis*/ HAL_SYSTICK_Config(SystemCoreClock/1000U);/*Configure the SysTick IRQ priority */ HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0U);/* Return function status */return HAL_OK;} 有些则没有被实现，例如： __weak void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi){/* Prevent unused argument(s) compilation warning */ UNUSED(hspi);/* NOTE : This function should not be modified, when the callback is needed,the HAL_SPI_TxCpltCallback should be implemented in the user file */} 所有带有__weak关键字的函数表示，就可以由用户自己来实现。如果出现了同名函数，且不带__weak关键字，那么连接器就会采用外部实现的同名函数。 通常来说，HAL库负责整个处理和MCU外设的处理逻辑，并将必要部分以回调函数的形式给出到用户，用户只需要在对应的回调函数中做修改即可。HAL库包含如下三种用户级别回调函数（PPP为外设名）： 1、外设系统级初始化/解除初始化回调函数（用户代码的第二大部分：对于MSP的处理）： HAL_PPP_MspInit()和 HAL_PPP_MspDeInit** 例如： __weak void HAL_SPI_MspInit(SPI_HandleTypeDef *hspi)。 在HAL_PPP_Init() 函数中被调用，用来初始化底层相关的设备（GPIOs, clock, DMA, interrupt） 2、处理完成回调函数：HAL_PPP_ProcessCpltCallback*（Process指具体某种处理，如UART的Tx）， 例如： __weak void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi) 当外设或者DMA工作完成后时，触发中断，该回调函数会在外设中断处理函数或者DMA的中断处理函数中被调用错误处理回调函数： HAL_PPP_ErrorCallback 例如： __weak void HAL_SPI_ErrorCallback(SPI_HandleTypeDef hspi)* 3、当外设或者DMA出现错误时，触发终端，该回调函数会在外设中断处理函数或者DMA的中断处理函数中被调用 错误处理回调函数： HAL_PPP_ErrorCallback 例如： __weak void HAL_SPI_ErrorCallback(SPI_HandleTypeDef hspi)* 当外设或者DMA出现错误时，触发终端，该回调函数会在外设中断处理函数或者DMA的中断处理函数中被调用。 绝大多数用户代码均在以上三大回调函数中实现。 HAL库结构中，在每次初始化前（尤其是在多次调用初始化前），先调用对应的反初始化（DeInit）函数是非常有必要的。 某些外设多次初始化时不调用返回会导致初始化失败。完成回调函数有多中，例如串口的完成回调函数有 HAL_UART_TxCpltCallbackHAL_UART_TxHalfCpltCallback （用户代码的第三大部分：对于上面第二点和第三点的各种回调函数的处理）在实际使用中，发现HAL仍有不少问题，例如在使用USB时，其库配置存在问题。 HAL库移植使用 基本步骤： 1、复制stm32f2xx_hal_msp_template.c，参照该模板，依次实现用到的外设的HAL_PPP_MspInit()和 HAL_PPP_MspDeInit。 2、复制stm32f2xx_hal_conf_template.h，用户可以在此文件中自由裁剪，配置HAL库。 3、在使用HAL库时，必须先调用函数：HAL_StatusTypeDef HAL_Init(void)（该函数在stm32f2xx_hal.c中定义，也就意味着第一点中，必须首先实现HAL_MspInit(void)和HAL_MspDeInit(void)） 4、HAL库与STD库不同，HAL库使用RCC中的函数来配置系统时钟，用户需要单独写时钟配置函数（STD库默认在system_stm32f2xx.c中） 5、关于中断，HAL提供了中断处理函数，只需要调用HAL提供的中断处理函数。用户自己的代码，不建议先写到中断中，而应该写到HAL提供的回调函数中。 6、对于每一个外设，HAL都提供了回调函数，回调函数用来实现用户自己的代码。整个调用结构由HAL库自己完成。 例如： Uart中，HAL提供了 void HAL_UART_IRQHandler(UART_HandleTypeDef *huart); 函数，用户只需要触发中断后，用户只需要调用该函数即可，同时，自己的代码写在对应的回调函数中即可！如下： void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart);void HAL_UART_TxHalfCpltCallback(UART_HandleTypeDef *huart);void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);void HAL_UART_RxHalfCpltCallback(UART_HandleTypeDef *huart);void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart); 使用了哪种就用哪个回调函数即可！ 基本结构 综上所述，使用HAL库编写程序（针对某个外设）的基本结构（以串口为例）如下： 1、 配置外设句柄 例如，建立UartConfig.c，在其中定义串口句柄 UART_HandleTypeDef huart;接着使用初始化句柄(HAL_StatusTypeDef HAL_UART_Init(UART_HandleTypeDef huart)) 2、编写Msp 例如，建立UartMsp.c，在其中实现void HAL_UART_MspInit(UART_HandleTypeDef huart) 和 void HAL_UART_MspDeInit(UART_HandleTypeDef* huart) 3、实现对应的回调函数 例如，建立UartCallBack.c，在其中实现上文所说明的三大回调函数中的完成回调函数和错误回调函数 参考文档及网文链接 ST - Description of STM32F4 HAL and LL drivers.pdf ST - en.stm32_embedded_software_offering.pdf 作者：ZCShoucsdn 来源：CSDN 原文：https://blog.csdn.net/zcshoucsdn/article/details/55213616 作者：ZCShoucsdn 来源：CSDN 原文：https://blog.csdn.net/zcshoucsdn/article/details/55213616 作者：Error_4O4 来源：CSDN 原文：https://blog.csdn.net/weixin_43186792/article/details/88759321 作者：csdnpapa 来源：CSDN 原文：https://blog.csdn.net/csdnpapa/article/details/79309937
2024-08-08 170浏览
-
精密半导体参数测试解决方案 直播时间：01月08日 10:00
- 苹果A系列芯片十年进化：晶体管数量激增19倍，晶圆成本跃升300%
- 豪掷800亿美元！微软宣布加码AI数据中心
- 11家中国实体被纳入实体清单，美资禁止投资中国三个行业
- 华勤技术收购豪成智能科技，强化机器人业务领域布局
- “超越EUV”时代：美国研发拍瓦级铥激光器有望大幅提升芯片制造效率
- 三星电子完成HBM4逻辑芯片设计，采用4nm工艺进行试产
- 加拿大扩大稀土开采，杀入全球原材料竞赛
- 拆解长鑫存储DDR5颗粒：面积68.06平方毫米，比三星大40%
- 关注我们
-
扫码关注面包板社区
