Wi-Fi modem board for the Mercury System
SKU 7305-MB210EAN 8219671102803Item type: Assembled, Shields & add-onsIoT (Internet of Things)
Description
| Hardware features | |||||||||||||
![]() |
|||||||||||||
|
|||||||||||||
| Wi-Fi module features | |||||||||||||
|
|||||||||||||
| Hardware diagram | |||||||||||||
![]() |
|||||||||||||
| Mercury System | |||||||||||||
| Mercury System (MS for short) is a modular system for developing connectivity and IoT applications. The system uses several kinds of boards (logic unit, modem, slave board carrying sensors and actuators, power boards …) and a complete SW framework that makes complex applications possible. Scalability, ease of use and modularity are the key factors, and they are guaranteed by the use of a mixed set of components that let you put the system together like a model built out of LEGO© bricks.
The set of boards that makes up the Mercury System is organised in the following “families”: • Base Board (BB): It is the “brain” of the whole Mercury System and holds the main logic unit, several communication buses and the connectors for interfacing the slaves. It also has a simple power supply and a charger for a single LiPo cell (enough to meet the power requirements of simpler systems). It comes in several variants, depending on the microcontroller unit used. • Modem Board (MB): this is the board that provides network connectivity. It comes in several variants, depending on the network interface (GSM / GPRS, Wi-Fi, BT, Radio …). It is interfaced to the base board over a dedicated serial line. • Power Board (PB): this is the board that meets the particular energy needs of the system, when they arise. They vary according to the specific energy need to be met (high power, solar harvesting, piezoelectric harvesting, etc.). • Slave Board (SB): these are the peripherals of the system and vary according to the specific sensor or actuator fitted. Typical examples are SBs with relays, temperature sensors, RGB LED controllers, servo controller, accelerometer, etc. They talk to the BB over I2C or UART with a dedicated command set. • Expansion Board (EB): these are the boards that allow Mercury boards to be connected side by side on one plane. There are variants that can carry a display, a battery holder, etc. • Brain-Less Board (BL): these are the boards without a controller. In general they carry really simple sensors or actuators that do not need the bus interface. They are an alternative to the slave boards for applications where cost has to be kept down. The Slave Boards and the Modem Boards come pre-programmed with firmware that implements a dedicated command set for high-level control, while the Base Boards carry a software framework that provides all the low-level services (operating system, peripheral drivers, system services, etc.), leaving the user with nothing to develop but the application-level logic. |
|||||||||||||
![]() |
|||||||||||||
| Mercury System Framework | |||||||||||||
| Mercury System Framework (MSF) is a layered software framework designed specifically to support application development with the Mercury System. It gives the user a complete set of basic functions for easily interfacing the Slave Boards (SB) and the Modem Boards (MB), as well as a number of software and infrastructure system services. | |||||||||||||
![]() |
|||||||||||||
| The framework is made up of the following components:
HAL (Hardware Abstraction Layer): the purpose of this layer is to hide the hardware dependencies from the layers above. OSL (Operative System Layer): this layer consists of a lightweight RTOS that provides the basic services to the system, such as the scheduling tables for the various tasks, events, SW timers, alarms, etc. |
|||||||||||||
![]() |
|||||||||||||
| The Slave Boards of the Mercury System | |||||||||||||
| The layout of the Mercury Slave boards is standardised, so as to simplify interfacing with the Base Board and to guarantee a high level of modularity and scalability. Every slave board has an I2C (Inter Integrated Circuit) communication line and a four-position dip-switch for setting the bus address of the slave board dynamically. Addresses from 0x01 to 0x0F are available for the Slaves, while address 0x00 is reserved for broadcast communication. This way up to 15 devices can be connected to the Base Board using the dynamic addressing scheme. That number can be increased further by reprogramming the Slave with an address supplied by the software. Two open-collector digital lines connected to the external interrupts of the base board are also provided, for slave boards that have to raise asynchronous interrupts. Slave boards that need more bandwidth and peer-to-peer communication can also be interfaced over an additional UART channel.
There are several sub-families of Slave Board:
The table below gives some examples for each sub-family:
|
|||||||||||||
| Documentation and useful links | |||||||||||||
Technical details
| Board type | Modem Board (MB) |
|---|---|
| Peripheral description | Wi-Fi modem ESP8266 |
| Wi-Fi module | ESP8266 Wi-Fi module |
| Processor | L106 32-bit RISC microprocessor core |
| Clock | 80 MHz |
| RAM | 64KB instruction + 80KB user data + 16KB System |
| Flash | 512 KiB to 4 MiB external QSPI FLASH typically included |
| Interface | UART |
| Other features | External reset pin |
| PML | peripheral management layer |
| SSL | system services layer |






















