3 ms·

> N.B. Accessing registers modified by the hardware may be treated as a multi-threaded application. Therefore, it is worth considering using std::atomic<T> inst

> N.B. Accessing registers modified by the hardware may be treated as a multi-threaded application. Therefore, it is worth considering using std::atomic<T> instead of volatile T. This is incorrect. Compilers are allowed to reorder and combine atomics as long as they follow the rules. See: https://github.com/jfbastien/no-sane-compiler https://github.com/jfbastien/no-sane-compiler

tripletao 8y ago
If I understand correctly, that makes the article grossly wrong. Like, if you have a serial port transmit register and execute SERIAL_TX_DATA = 0x01; SERIAL_TX_DATA = 0x02; to enqueue two bytes to transmit, then the compiler is allowed to skip the first write entirely.
- Gibbon1 8y ago
  A naive implementation of the SERIAL_TX_DATA macro will totally give you behavior like that.
  - tripletao 8y ago
    #define SERIAL_TX_DATA (*((volatile uint32_t *)<addr>)) is pretty naive, and correct. The article's advice seems not to be.
    - Gibbon1 8y ago
      Friend smarter than me ran into a bug where when DMA was active on a multi-core uP you needed to do a read op between two writes to a IO address or the first write wouldn't happen. I think on an ARM processor if it's normal memory you can't guarantee ordering. But ARM supports a device memory type which disables caching and reordering memory accesses by the hardware.
      - tripletao 8y ago
        I think ARM's "strongly-ordered memory" concept is supposed to solve this? Was your friend's problem intended behavior, or a silicon bug? http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DAI0321A_programming_guide_memory_barriers_for_m_profile.pdf http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DA...
        Gibbon1 8y ago
        I think the DMA accesses were confusing the memory controller. He said that sort of thing was common on internally developed silicon. They won't do a spin if there is a work around. Also my experience as well. I've had to deal with peripherals with an async clock where access timing becomes important. Observation: CS appears to teach students that code with side effects is evil. AKA hide you side effects behind os calls. With embedded code side effects are important.

tripletao 8y ago

If I understand correctly, that makes the article grossly wrong. Like, if you have a serial port transmit register and execute SERIAL_TX_DATA = 0x01; SERIAL_TX_DATA = 0x02; to enqueue two bytes to transmit, then the compiler is allowed to skip the first write entirely.

Gibbon1 8y ago
A naive implementation of the SERIAL_TX_DATA macro will totally give you behavior like that.
- tripletao 8y ago
  #define SERIAL_TX_DATA (*((volatile uint32_t *)<addr>)) is pretty naive, and correct. The article's advice seems not to be.
  - Gibbon1 8y ago
    Friend smarter than me ran into a bug where when DMA was active on a multi-core uP you needed to do a read op between two writes to a IO address or the first write wouldn't happen. I think on an ARM processor if it's normal memory you can't guarantee ordering. But ARM supports a device memory type which disables caching and reordering memory accesses by the hardware.
    - tripletao 8y ago
      I think ARM's "strongly-ordered memory" concept is supposed to solve this? Was your friend's problem intended behavior, or a silicon bug? http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DAI0321A_programming_guide_memory_barriers_for_m_profile.pdf http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/DA...
      - Gibbon1 8y ago
        I think the DMA accesses were confusing the memory controller. He said that sort of thing was common on internally developed silicon. They won't do a spin if there is a work around. Also my experience as well. I've had to deal with peripherals with an async clock where access timing becomes important. Observation: CS appears to teach students that code with side effects is evil. AKA hide you side effects behind os calls. With embedded code side effects are important.