how mbed communicate with peripheral

Question

Based on the answer in this question: How does cpu communicate with peripherals?

I've already know modern CPUs usually use mechanism similar to DMA to communicate with peripheral, IO device, etc.

Recently, I bought a board, FRDM-K66F. As its user guide said, this board CPU is based on ARM, as well as Mbed OS 5 is already installed on it.

When it comes to "Digital In/Out" function, I only know that:

C++ program -> mbed library -> GPIO APIs -> ...? -> Hardware

I want to clarify that how cpu works with peripheral in low-level scope? (from GPIO APIs to Hardware, especially in mbed case)

Are there some special variables declared in mbed-os library which are corresponding to specific registers in mbed-board cpu? so that arm compiler can converts such statements into specific accessing instructions?

I don't know how to search this question in Google, so if any useful reference or user guide, please paste it for me.

Answer 1

The simple answer is multiple levels of abstraction. MBED is an OS designed to be ported to many devices, from many different vendors:

• The MBED API defines how (in software) the user will specify an access to a peripheral such as a GPIO, including an abstract pin name which relates to the board level.
• The vendor specific code for the MBED port defines a common method which works for all parts from one vendor/family (there may be hundreds of different package/peripheral combinations, but vendors tend to keep the same peripheral functions. This includes the memory map of the peripherals, referenced from their base address.
• The device specific code defines where in the memory map each peripheral is located, what the 'friendly' names for each pin is, and any vendor specific dependencies (such as clock requirements for enabling a particular GPIO, and which pins this covers).

Because it is generic, the code won't always be optimal for any specific purpose. It may not even offer all of the features provided by the hardware. The intent is that it is easy to add support for new devices.

To show some examples, I'll refer to fragments from the Cortex-M3 DesignStart Eval target. This only has a limited number of peripherals, and you can also download the source code for the platform in verilog if you want to. This is just a few parts of the OS, these fragments don't join up completely.

PinNames contains both the EXPnn numbers for the 50 pin interface, and also GPIO alternate function pin muxing definitions:

typedef enum {
    ALTERNATE_FUNC = 0, /* The pin is used for alternative function */
    GPIO_FUNC = 1       /* The pin is used for GPIO function */
} PinFunction;

gpio_api.c implements the (sometimes ugly) mapping between the standard API and the internal logic. For example, to initialise a specific pin there is a lookup between the number and the peripheral (based on 16 pins per GPIO):

void gpio_init(gpio_t *obj, PinName pin)
{
struct arm_gpio_dev_t *gpio_dev;

if (pin >= EXP0 && pin <= EXP51) {
    /* GPIO pins */
    switch (GPIO_DEV_NUMBER(pin)) {
    case GPIO0_NUMBER:
        gpio_dev = &ARM_GPIO0_DEV;
    break;
    }

    arm_gpio_init(gpio_dev);

    obj->gpio_dev = gpio_dev;
    obj->mps2_io_dev = NULL;
    obj->arm_mps2_io_write = NULL;
    obj->pin_number = GPIO_PIN_NUMBER(pin);
    /* GPIO is input by default */
    obj->direction = PIN_INPUT;
    return;
}

The actual memory map for the device is captured in CM3DS.h

#define CMSDK_GPIO0_BASE        0x40010000UL
#define CMSDK_GPIO1_BASE        0x40011000UL
#define CMSDK_GPIO2_BASE        0x40012000UL
#define CMSDK_GPIO3_BASE        0x40013000UL

Answer 2

There is no difference, and no magic, and nothing specific to mbed that makes it special either.

The answer is in the documentation for the part and board in question. You google or go to NXP and look for the mcu in question: MK66FN2M0VMD18 which of course was from your link. In there it will tell you it is ARM based A cortex-m4 specifically so you would want to go to arms site and get processor details for the processor core buried in the NXP chip. You would get the documentation for the board in question from the site you linked and or search for the board name.

The users guide for that board for example shows the Gyroscope connections for SDA and SDL you use the documentation for the microcontroller to find out about the I2C interface for that part and the interface on those pins and/or you just bit bang the gpio. usually best to bit bang first then try to get the mcu i2c peripheral working later if desired.

The rest of the peripherals on the BOARD should be described in the BOARD documentation, ideally a schematic is there. For each of the chips on the board including the NXP MCU, you go to the various vendors sites to get information on each, which will include how to program it so the gyroscope for example you would in this case go to NXP since it is also an NXP chip and get that document, see how to program it etc.

Now what is between that information and the "mbed os" is a bunch of drivers and os layers, no different in concept from the layers between this web page on your browser on your computer on your operating system on your motherboard. Some chips on a board that are connected through the board or through cables, plus other items (hard drive, etc) connected through cables or connectors to other boards.

And just like your computer there are interfaces and documentation about those interfaces and software that was written using the documentation for those interfaces, busses, and protocols.

NXP likely has bare metal libraries for the on (MCU) chip peripherals like the I2C, hopefully also has some example code of some form for the gyroscope since I keep picking on that chip, but sometimes not, sometimes you have to write your own, that's the nature of the microcontroller world.

Likewise with this mbed thing, NXP probably wrote the code in a way that conforms to mbed os (note that mbed bare metal and mbed os are possibly different interfaces) basically wrote chip and board drivers for this product. Likely posted on NXP's site not on ARMs mbed site, but who knows I have no use for mbed nor CMSIS so rarely look at it. It is in NXPs interest to provide the source code for this board as they want you to use this board to make products and buy lots of chips, if they put up barriers to that all they did was sell one or a few boards to you and lose out. This is the nature of the mcu world which is different than the motherboard world where they want to sell you a single chip and a single board and call it a day. Microcontroller vendors only survive if every Nth one of us buys chips in the tens to hundreds of thousands of parts. To get that Nth person to do that they need reference/eval platforms with schematics and source code, otherwise that Nth person will use ST or ti or some other vendors product that provided a schematic and source code.

So everything you are asking about is documented in various places this is an ARM based chip (not an arm chip) so the arm core itself is documented by arm. This is an NXP chip so the rest of the chip is ideally documented by NXP but there may be other purchased IP that you need to go to that vendors site for documentation, in rare cases for MCUs but not uncommon for operating system level chips (like an allwinner chip on an orange pi or a broadcom chip on a raspberry pi) to have some purchased ip that the NDA dictates they cannot document it and the ip vendor won't give you docs without an NDA which you likely can't get (usually USB, DDR, and some other types of ip that tends to have these secrets). You shouldnt see this on these MCUs, rare occasions they might say this is a 16550 compatible uart or this is ARMs blahnumber uart and you have to google that.

if running on an OS, RTOSes included, at least generically there are exceptions to this. applications talk to apis which talk to operating system drivers which talk to the peripherals in the chip (gpio, i2c, spi, uart, usb, timers, etc) some of which are using an external to the chip interface to another item on the board or connected to the board. The combination of the application, api, and drivers cause the end peripheral to do whatever it was you asked so long as the software was designed right and is not buggy. This is no different than writing a program on your computer. There is no magic here.

Nothing special about ARM vs the ARM or x86 or other processor used on your computer. There are load/store (read/write) instructions on general purpose processors like ARM and X86, the exact syntax is well assembler specific, the machine code is processor specific. As your other link mentions x86 has a notion of I/O instructions different from memory instructions, which ultimately was at the time just a single pin on the memory interface (I/O vs memory signal/pin along with a read vs write signal/pin etc). ARMs are all memory mapped I/O and for the most part so is x86, the reverse compatibility is there and you can read up on the x86 documentation from intel to see how it is implemented today on the chips external bus(es).

Unlike an x86, the ARM is purchased IP and buried in a vendors chip, so the ARM bus is internal to the NXP chip in this case, within the NXP you have the address decoders, being an MCU little to none of that address space directly maps outside the chip. So within the NXP documentation, you find the NXP chip specific address space, this specific NXP chips uart for example may be specific to this NXP chip no reason to ever assume it is the same as another NXP chip and certainly not the same address or how it works or the interfaces/registers as a non-NXP chip that uses the same ARM core. The on chip peripherals are all accessed through load and store instructions on the ARM bus(es) within the chip. NXP defines within ARMs rules what addresses are tied to what, flash, ram, and specific peripherals. There are also the interrupts as well connected between the core and the on chip peripherals to round out their interfaces.

with an (RT)OS it is often a driver in the OS that talks to apis within the OS which ultimately become one of the flavors of load and store instructions causing arm bus transactions to the memory controller in the nxp chip that based on address passes the transaction onto the handler in the chip (flash, memory, specific peripheral).

The address space for this chip will be found in NXP documentation, some chip vendors have address space in one document like the datasheet and the details for the semi-generic peripherals with register offsets in another document. But each vendor does their own thing the information is generally there some are worse than others (NXP is pretty good, microchip pretty bad, ST, TI pretty good). Historically NXP would go so far as to have the full address of the register in the register description, where most vendors the base address is documented elsewhere in that document or another document and the peripheral documentation only shows offsets to the base.

APIs are just APIs someone designed them good, bad, or otherwise (don't assume that vendor code is good, you can tell from looking at it, it is rarely written by the "A" team, normally written by whoever got stuck doing it sometimes it's okay/good sometimes it isnt). Same goes for the operating system drivers.

It is in NXPs best interest to provide a turnkey application for these boards that demonstrates its features. But unlike a computer motherboard for most consumers of those products, MCU consumers are ideally developers making chip+software level products as well as for products like this one software+board level products. So while the turnkey application is interesting we are not buying the board to just run that software, so api documentation, source code, etc from top to bottom is ideally available somewhere. mbed is an arm thing so some of this software you may have to get from arm not nxp. it depends on exactly how and what NXP chose to package.