16×2 Display Expansion Board for the Mercury System

Expansion board for the Mercury system carrying a 16x2 alphanumeric LCD display

SKU 7305-EB210EAN 8219671102780Item type: Assembled, Shields & add-ons

Description

Expansion board for the Mercury system carrying a 16×2 alphanumeric LCD display. It lets you connect Mercury boards in a planar arrangement and at the same time gives you a simple user interface. At the heart of the board is an 8 bit RISC PIC16F1829 microcontroller made by Microchip Technology Inc.
Hardware features
  • Mercury Connectors #1 #2: to interface the board with the other boards in the Mercury family
  • Address Dip Switch: Dip switch to set the address of the board within the Mercury system.
  • EB Programmer Connector: PicKit 3 Microchip programmer / debugger connector. It plugs straight into the debug MCU port of the EB (Expansion Board), for advanced debugging and programming.
  • BB Program&Debug Connector: PicKit 3 Microchip programmer / debugger connector. It plugs straight into the debug MCU port of the BB (Base Board), for advanced debugging and programming.
  • Display Contrast Reg.: potentiometer to adjust the contrast.
  • Buses Expansion: expansion connectors for the power supply and for the I2C and UART links.
Microcontroller features
  • ADC: 12 ch, 10-bit
  • Comparators: 2
  • Temperature range: -40°C ~ 125°C
  • Operating voltage: 1.8~5.5 V
  • Pin Count: 20
  • XLP: yes
Hardware diagram
Mercury System
Mercury System (MS for short) is a modular system for developing connectivity and IoT applications. The system uses various types of board (logic unit, modem, slave board with sensors and actuators, power boards and so on) together with a complete SW structure that makes it possible to build complex applications. Scalability, ease of use and modularity are the key points, and they are guaranteed by the use of a mixed set of parts that let you put the system together like a model built with LEGO© bricks.

The set of boards that makes up the Mercury System is divided into the following “families”:

Base Board (BB): It is the “brain” of the whole Mercury System and it carries the main logic unit, several communication buses and the connectors for interfacing the slaves. It also carries 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 and so on). It is interfaced to the base board over a dedicated serial line.

Power Board (PB): this is the board that meets the particular power needs of the system, when they arise. They vary according to the particular power need to be met (high power, solar harvesting, piezoelectric harvesting, etc.).

Slave Board (SB): these are the peripherals of the system and they vary according to the specific sensor or actuator fitted. Typical examples are SBs with relays, temperature sensors, RGB LED controllers, servo drivers, accelerometers and so on. They talk to the BB over I2C or UART with a dedicated command set.

Expansion Board (EB): these are the boards that allow the planar connection of the Mercury boards. There are variants that can carry displays, a battery holder and so on.

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 that have to keep costs 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 come with a software framework that provides all the low-level services (operating system, peripheral drivers, system services and so on), leaving the user only the application-level logic to write.

Mercury System Framework
The 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 interfacing the Slave Boards (SB) and the Modem Boards (MB) easily, 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.
SML (System Management Layer): the purpose of this layer is to provide services for handling the communication buses (I2C, UART) and for handling the Modem Board (WiFi, BT, GSM / GPRS). It also provides a set of system services, such as System Power Management, RTCC, USB terminal and so on.
It is split into two main components:

  • PML: peripheral management layer
  • SSL: system services layer

OSL (Operative System Layer): this layer consists of a lightweight RTOS that provides basic services to the system, such as the scheduling tables for the various tasks, events, SW timers, alarms and so on.

The Slave Boards of the Mercury System
The layout of the Mercury Slave boards is standardised, to make interfacing with the Base Board simpler 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 to set 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 communications. In this way up to 15 devices can be connected to the Base Board using the dynamic addressing scheme. This number can even be increased by reprogramming the Slave with an address supplied by software. In addition, two open collector digital lines connected to the external interrupts of the base board are 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 using a further UART channel.

There are several sub-families of Slave Board:

  • Sensor Slave Board
  • Actuator Slave Board
  • Communication Slave Board
  • Interface Slave Board
  • Special Slave Boards

The table below gives a few examples for each sub-family:

Sub-families Examples
Sensor Slave Board Ultrasonic, infrared, temperature and humidity, PIR, gas sensor, air quality, thermocouple, humidity, analogue input, accelerometer
Actuator Slave Board Relay, High-Side Driver, Low-Side Driver, Servo, DC Motor, Stepper Motor, Neopixel
Communication Slave Board RS232, RS485, CAN, LIN, Ethernet, Bluetooth
Interface Slave Board OLED display, Keypad, Mini-Joystick
Special Slave Boards SD Card, MP3 decoder
Documentation and useful links

Technical details

Board type Expansion Board (EB)
Addressing 4 Dip Switches
Peripheral 16x2 alphanumeric LCD display
Microcontroller PIC16F1829 main controller board
EB Programmer Connector PicKit 3 Microchip programmer / debugger connector
Display 16x2 alphanumeric LCD display
Memory type Flash
Memory 14 KB
CPU Speed (MIPS) 8
RAM Bytes 1,024
Data EEPROM (bytes) 256
Digital Communication Peripherals 1-UART, 1-A/E/USART, 1-SPI, 1-I2C1-MSSP(SPI/I2C)
Capture/Compare/PWM Peripherals 2 CCP, 2 ECCP
Timer 4 x 8-bit, 1 x 16-bit

You may also like…

About us

Open-Electronics.org is the brainchild of a world leader in hobby electronics Futura Group srl. Open-Electronics.org is devoted to support development, hacking and playing with electronics: we share exciting open projects and create amazing products!

Open-Electronics.org is not just a container of ideas: it is also a web site lead by a team of engineers and geeks who will take part in the discussions and give support.

Our mission is to become a reference Open Source hacking site with ideas and feedback aimed to enrich the community.