mbed和mbed OS
（1）基本区别
mbed 指传统的；mbed OS指正在推出的。
When an mbed Classic platform is converted to an mbed OS board, we will no longer update and support this platform in the mbed SDK. This means you can continue to use any previously released version, but no bug fixes will be accepted or released as part of the mbed SDK.
－－mbed SDK即将被放弃
（2）mbed OS特性
Features
We designed mbed OS specifically for constrained devices, so it works behind the scenes to automatically make the most of the limited hardware and network resources available:
-
It’s modular: it has a code base that is common to all applications running on all hardware, and additional modules that extend functionality and create hardware-specific interfaces. The modules are only compiled if your application needs them; you don’t need to waste memory on unused code.
-
It’s single-threaded and event-driven, so you can use it even on small devices.
-
It abstracts the hardware, so that an application always “sees” the same interface, no matter which board it’s running on. mbed OS then matches the interface to the actual hardware without you manually changing the code. This allows you to write the application once, then deploy it on any supported board. mbed OS also works seamlessly with peripherals and extension boards.
-
It efficiently manages power and schedules tasks, so that even demanding applications can operate on low-power devices.
-
It manages both device and communication security using mbed OS uVisor and mbed TLS, respectively.
-
It supports multiple networking options: Bluetooth Low Energy, Ethernet, WiFi (coming soon), Thread and 6LoWPAN.
-
It works with device management protocols - LWM2M and CoAP - so that you can perform large-scale remote updates.
－－模块化，可配置。 -
－－单线程，时间驱动，与freertos/ucos等不同！！！
-
－－包含安全特性和M2M的管理特性
Core modules
-
compiler-polyfill: Common compiler intrinsics and attributes made portable across toolchains.
-
core-util: Core data structures and primitives for the OS.
-
minar: The mbed OS event scheduler.
-
uvisor: mbed OS uVisor is a supervisory kernel for security on mbed OS.
Hardware abstraction and drivers
-
mbed-drivers: Abstract drivers for common hardware peripherals and communications interfaces such as SPI and I2C. Provides a higher level interface than the mbed HAL; these are the APIs that applications should use.
-
cmsis-core: ARM’s official low level hardware abstraction for Cortex-M.
-
mbed-hal: The mbed Hardware Abstraction Layer (HAL).
Networking and connectivity
-
ble: APIs for using Bluetooth Low Energy.
-
mbed-mesh-api: APIs for initialising and using the mesh network.
-
mbedtls: mbed TLS, the SSL/TLS stack (including cryptographic and certificates handling functionality).
-
sal: The mbed OS socket abstraction layer (SAL). Provides a common interface for networking stacks from ARM and partners.
-
sal-stack-nanostack: Our IPv6/6LoWPAN stack.
-
sockets: High level portable socket layer (sitting on top of the SAL).
mbed Client
-
mbed-client-c: Core library in C.
-
mbed-client: C++ API (use this one rather than the C one, as it’s much easier to use correctly).
-
mbed-client-mbed-os: mbed OS-specific implementation for mbed Client.
-
mbed-client-mbedtls: mbed TLS-specific implementation for mbed Client.
yotta is the build system we use for mbed OS. We’ll get into the details of it later, but what you need to understand at this point is that mbed OS applications cannot be built without yotta.
yotta combines our code (application) with the mbed OS code-base and any other module (reusable library) that we may need. To tell yotta what our application needs, we add a list of dependencies to each application we write. The easiest way to add mbed OS to our application when we build it is to describe the component mbed-drivers as a dependency of our application, because mbed-drivers has most other components as its own dependencies, so yotta will build what we need.