machine.mem32 etc. need a HAL abstraction

[microbit-matt-hillsdon]

machine.mem32[4 * 9999999] causes an out of bounds read that's trapped by the WASM runtime. Likewise writes.

After recent error handling improvements we stop the sim in the out of bounds cases. Corruption we can't do much about.

I think there are a small number of common scenarios where we might want to support read/write from particular addresses that won't be valid in the sim but could be intercepted by the HAL. More thought required.

[microbit-carlos]

The MICROPY_MACHINE_MEM_GET_READ_ADDR macro can be added to point to a custom machine_mem_get_addr() function that returns an address to whatever data we want to return.

So in mpconfigport.h we can add:

#define MICROPY_MACHINE_MEM_GET_READ_ADDR foo

And in modmachine.c (as an example):

uintptr_t foo(mp_obj_t addr_o, uint align) {
    uintptr_t addr = mp_obj_get_int_truncated(addr_o);
        if ((addr & (align - 1)) != 0) {
        mp_raise_msg_varg(&mp_type_ValueError, MP_ERROR_TEXT("address %08x is not aligned to %d bytes"), addr, align);
    }

    static const uint32_t FICR = 0x10000000;
    static const uint32_t FICR_CODEPAGESIZE = FICR + 0x010;

    static uint32_t mem;
    if (addr < FICR_CODEPAGESIZE) {
        mem = 0xDEADC0DE;
    } else if (addr == FICR_CODEPAGESIZE) {
        mem = 4096;
    } else {
        mem = 0xDEADC0DE;
    }
    return (uintptr_t)&mem;
}

[microbit-matt-hillsdon]

Support: https://support.microbit.org/a/tickets/56484 (potentially, not clear if sim or device)

This fix is now live in the Python Editor as part of simulator v0.1.4.