ARM的IO口(GPIO)

  ARM的GPIO(相当于51的IO)连接在AHB decoder上，那在使用之前就要设置时钟，它有很多种模式：1.Input mode,2.General purpose output mode,3.Alternate function mode,4.Analog mode；还有很多连接模式(芯片内部的连接方式)，更多详细信息请查看相关芯片厂商的芯片引用手册(如：STM32F0 Reference Manual)
  而51的io口不用设置，直接可以作为输出输入或者特殊的外设的IO口使用！
  各有各的好处！

ARM Cortex-M0的时钟

  ARM的时钟有很多种，驱动cpu，看门狗和不同的外设等;时钟(clock)有:HSI(内部高速时钟),HSE(外部高速时钟),LSE(外部低速时钟),LSI(内部低速时钟),PLL(锁相环);相关详细时钟和芯片的内部时钟树(clock tree)在ST的引用手册上的“Reset and Clock Control(rcc)”章节中能找到。
  而51的则不同，只有HSI,HSE。

在什么情况下可能我需要插入内存屏障指令,DMB, DSB, ISB instructions(In what situations might I need to insert memory barrier instructions?)

由于看不懂ARM汇编指令中的ISB,DSB,DMB三条指令怎么用，于是谷歌了一下，找到了ARM官网的相关描述怎么去用这三条指令的网页，地址：In what situations might I need to insert memory barrier instructions?




原文如下：

In what situations might I need to insert memory barrier instructions?

Applies to: ARM Architecture and Instruction Sets, ARMv6 Architecture, ARMv7 Architecture, DS-5, RealView Development Suite (RVDS)

Answer

This FAQ aims to help users understand when, why and how to use memory barrier instructions.

Classic ARM processors, such as the ARM7TDMI, execute instructions and complete data accesses in program order.  The latest ARM processors can optimize the order of instruction execution and data accesses.  For example, an ARM architecture v6 or v7 processor could optimize the following sequence of instructions:

      LDR r0, [r1]   ; Load from Normal/Cacheable memory leads to a cache miss
      STR r2, [r3]   ; Store to Normal/Non-cacheable memory

The first load from memory misses in the cache it will cause a cache linefill.  This typically takes many cycles to complete. Classic (cached) ARM processors, for example, the ARM926EJ-S, would wait for the load to complete before executing the store instruction.  ARM architecture v6/v7 based processors can recognize that the next instruction does not depend on the result of the load (in register r0) and can execute the store instruction before the load instruction completes.

In some circumstances, processor optimizations such as speculative reads or out-of-order execution (as in the example above), are undesirable and can lead to unintended program behaviour.  In such situations it is necessary to insert barrier instructions into code where there is a requirement for stricter, 'Classic ARM processor-like' behaviour.  There are three types of barrier instructions.  For simplicity, note that the descriptions below are for a uni-processor environment:

• A Data Synchronization Barrier (DSB) completes when all instructions before this instruction complete.
• A Data Memory Barrier (DMB) ensures that all explicit memory accesses before the DMB instruction complete before any explicit memory accesses after the DMB instruction start.
• An Instruction Synchronization Barrier (ISB) flushes the pipeline in the processor, so that all instructions following the ISB are fetched from cache or memory, after the ISB has been completed.

Note that the CP15 equivalent barrier instructions available in ARMv6 are deprecated in ARMv7. Therefore, if possible, it is recommended that any code that uses these instructions is migrated to use the new barrier instructions described above instead.

Mutexes

It is architecturally defined that software must perform a Data Memory Barrier (DMB) operation:

• between acquiring a resource, for example, through locking a mutex (MUTual EXclusion) or decrementing a semaphore, and making any access to that resource
• before making a resource available, for example, through unlocking a mutex or incrementing a semaphore.

The following examples show an implementation of a simple blocking mutex:

• lock_mutex acquires a mutex, blocking indefinitely until it acquires it. If blocked, it waits for an event (WFE) before retrying
• unlock_mutex releases a mutex, and sends an event (SEV) to notify waiting processes or processors of the change.

      LOCKED   EQU 1
      UNLOCKED EQU 0

lock_mutex
      ; Is mutex locked?
      LDREX r1, [r0]         ; Check if locked
      CMP r1, #LOCKED        ; Compare with "locked"

      WFEEQ                  ; Mutex is locked, go into standby

      BEQ lock_mutex         ; On waking re-check the mutex                          

      ; Attempt to lock mutex
      MOV r1, #LOCKED
      STREX r2, r1, [r0]     ; Attempt to lock mutex
      CMP r2, #0x0           ; Check whether store completed
      BNE lock_mutex         ; If store failed, try again

      DMB                    ; Required before accessing protected resource

      BX lr

unlock_mutex
      DMB                    ; Ensure accesses to protected resource have completed
      MOV r1, #UNLOCKED      ; Write "unlocked" into lock field
      STR r1, [r0]
      DSB                    ; Ensure update of the mutex occurs before other CPUs wake

      SEV                    ; Send event to other CPUs, wakes any CPU waiting on using WFE

      BX lr

The DSB ensures that the update to the synchronization variable is visible to all processors before SEV is executed.

Memory Remapping

Consider a situation where your reset handler/boot code lives in Flash memory (ROM), which is aliased to address 0x0 to ensure that your program boots correctly from the vector table, which normally resides at the bottom of memory (see left-hand-side memory map).

After you have initialized your system, you may wish to turn off the Flash memory alias so that you can use the bottom portion of memory for RAM (see right-hand-side memory map).  The following code (running from the permanent Flash memory region) disables the Flash alias, before calling a memory block copying routine (e.g., memcpy) to copy some data from to the bottom portion of memory (RAM).

     MOV r0, #0
     MOV r1, #REMAP_REG                    STR r0, [r1]                     ; Disable Flash alias
     DMB                              ; Ensure completion with Data Memory Barrier      
     BL block_copy_routine()          ; Block copy code into RAM
     DSB                              ; Ensure block copy is completed with Data Synchronization Barrier      ISB                              ; Ensure pipeline flush with Instruction Synchronization Barrier
     BL copied_routine()              ; Execute copied routine (now in RAM)

Without the DMB between the store (STR) and the branch with link (BL) instructions, there is no guarantee that the store out to memory will complete before the block copying routine starts writing to the bottom portion of memory, because the block copying routine can execute while the data is draining through the write buffer.  The DSB causes all instructions before the DSB to complete.  The ISB prevents instructions being fetched from RAM before the block copying routine completes.

Self-modifying code

Self-modifying code sequences must be preceded by an ISB, because the prefetch unit pipeline and the core pipeline may contain out-of-date instructions.

The example below shows a block of code being copied from ROM to RAM, and then branched to and executed. 

Overlay_manager
      ; ...
      BL block_copy                    ; Copy new routine from ROM to RAM
      B relocated_code                 ; Branch to new routine

Due to speculative prefetching the processor might attempt to fetch instructions from the relocated region before the block copy has completed.  To ensure that this optimization does not occur, you should insert an ISB before any newly relocated code begins executing, to ensure that the prefetch buffer is flushed before the processor continues fetching instructions:

Overlay_manager
      ; ...
      BL block_copy                    ; Copy new routine from ROM to RAM
      DSB                              ; Ensure block copy has completed
      ISB                              ; Ensure processor fetches new instructions      B relocated_code                 ; Branch to new routine

If the memory you are performing the block copying routine on is marked as 'cacheable' the instruction cache will need to be invalidated so that the processor does not execute any other 'cached' code.  For "write-back" regions the data cache must be cleaned before the instruction cache invalidate.

Overlay_manager
      ; ...      BL block_copy                    ; Copy new routine from ROM to RAM      data_cache_clean                 ; Clean the cache so that the new routine is written out to memory      DSB                              ; Ensure data cache clean has completed
      icache_and_pb_invalidate         ; Invalidate the instruction cache and branch predictor so that the old routine is no longer cached
      DSB                              ; Ensure block copy has completed
      ISB                              ; Ensure processor fetches new instructions
      B relocated_code                 ; Branch to new routine

Similar situations where you may require a barrier are:

• A Just-In-Time (JIT) compiler, for example, converting Jazelle bytecode into native ARM code
• A post linker/loader which relocates code into memory at run-time. 

Further Reading:

There are many more examples of where barriers are needed. For more information on the use of barriers see:

• ARMv7-A/R Architecture Reference Manual, Appendix G - Barrier Litmus Tests
• Application Note 321 - ARM Cortex™-M Programming Guide to Memory Barrier Instructions

Attachments

memory_barriers_1.PNG