This macro should not generate an unsafe block, unsafe should be required at the call site. With the current state, it's possible to cause UB without using unsafe:

#[global_allocator]
static HEAP: Heap = Heap::empty();
#[entry]
fn main() -> ! {
    { embedded_alloc::init!(HEAP, 1024); }
    let data = Box::new(1);
    { embedded_alloc::init!(HEAP, 1024); }
    // Here we drop the `data` box. Its pointer points to the first heap,
    // but this will try to drop it with the second heap.
    drop(data);
}

You did not fix the issue. Multiple invocations of the macro will generate multiple versions of the static so the init call can run multiple times.
Using Atomics also prevents from compiling on some platforms that could use this crate.

I don't see a way other than not including unsafe in the generated code and require the user to wrap the macro in unsafe:

    unsafe {
        embedded_alloc::init!(HEAP, 1024);
    }

At present, I only think of a way to ensure it is called once at runtime, which is using an atomic. Is it appropriate?

I don't think Rust provides a safe way to ensure that efficiently. One way would be to use a global static (defined once in embedded-alloc, not in the code generated by the macro), and check/update it with critical_section. The other way would be to check that the heap is not already allocated using APIs currently not provided by the upstream implementations.

As your suggestion, I added a call_once function. It uses a global static critical_section::Mutex to ensure it is called once.

Multiple invocations of the macro will generate multiple versions of the static so the init call can run multiple times.
Using Atomics also prevents from compiling on some platforms that could use this crate.

I'm not sure why we're being very strict here. The macro is only replicating code that we currently recommend people to write. I think we mainly just need to document all the possible caveats and safety concerns so users are aware. The macro really shouldn't be making things expensive+complicated with atomics IMO.

If UB can be reached from user code without the user having unsafe anywhere, the macro is unsound.

So either the unsafe must be removed from the generated block and the user should wrap the macro call in unsafe themselves, or the macro should be made fully safe.

(And I think for this case it makes more sense to require downstreams to use unsafe to use that macro).

If UB can be reached from user code without the user having unsafe anywhere, the macro is unsound.

I think it's more a Rust limitation that it's not possible to have unsafe macros. However, what you propose sounds good to me. User having to unsafe { } wrap the macro call, isn't a lot to ask for and they'd have to do that if this was a function (because it would be an unsafe fn). I just think we don't need to bring atomics and other complications here.