This library supports plug-n-play mode of device recognition, therefore it is named "Worry-Free" Architecture.
The Worry-Free architecture offers automatic configuration for all three layers. For Hardware Interface objects it supports different interface protocols. It also supports Sensor objects and their varying interfaces. Finally, the Worry-Free architecture supports sensors from multiple vendors and fulfills sensor application tasks for the user.
Worry-Free Architecture for Hardware Interface Object Layer
The EZ-PSoC library will be able to support variations of protocols such as 1-Wire protocol, which has two variations: MaxDetect and Dallas. For the MaxDetect 1-Wire protocol, one port supports only one sensor; but the Dallas 1-Wire protocol supports multiple sensors to share the same port. The developer does not have to worry about which variation of the protocol their sensor is using, as it will be determined based on the sensor.
For example, we have a RHT03 temperature and humidity sensor. The system will automatically recognize the sensor by its sensor object and configure the hardware interface object with MaxDetect 1-Wire protocol. Likewise, for the DS18B20 temperature sensor, the system will configure its Hardware object with Dallas 1-Wire protocol.
Worry-Free Sensor Object
In certain cases, some sensors are capable to support multiple interfaces. For example, the following LCD screen - SSD1306 Monochrome 128x64 OLED Display Module, supports both SPI and I2C protocols. The user will use a hardware jumper to select the protocol.
Figure 2: SSD1306 Monochrome 128x64 OLED Display - Supports I2C and SPI Interfaces
Developers do not have to worry about the details of sensor interfaces. They can choose either SPI or I2C communication protocol based on the hardware jumper setting, as both of these protocols are built-in to the EZ-PSoC Library. Developers then only need to connect their sensor object with the interface of their choice.
Worry-Free Application Object
In the Worry-Free Architecture, the Application object can connect with sensors coming from multiple vendors.
Here we show an example of MPU 9150 versus Pololu's Mini IMU V2. Both boards provide the same information for the IMU, however their sensors are different. The developer can replace one of the sensors with the other, with minimal changes to the code.
Here are the code differences between the two IMU sensors from the developer's perspective. The only difference is that MiniIMU sensor has two separate chips on its board, while MPU 9150 has all-in-one sensors combined. For the Pololu sensor we need to create two sensor objects, while only one for the MPU 9150.
Worry-Free Object Parameter Configuration
***Developers can change object's parameters without worrying about detailed configuration steps.
For example, let us consider DS18X20 sensor. We can assign specific resolution parameter - DS18X20_TEMP_RES_12_BIT to its Sensor object. This resolution parameter is only relevant to this specific sensor (DS18B20).
Another example would be a TMP102 sensor. We can setup the hardware address mode according to the ADR0 hardware connection, while also configuring the Alert Pin mode and sensor's polarity value.
For the developer it is not necessary to fully understand the details of register changes of the sensor configuration. The parameters can be easily configured for a given Sensor object, as shown below.
// For DS18B20 1-Wire Sensor ds = DS18X20_Create(); DS18X20_Connect1Wire(ds, onewire_ds); ds->Config.ROMCode.familyCode = DS_THERMOMETER_DS18B20; DS18X20_Start(ds); DS18X20_SetResolution(ds, DS18X20_TEMP_RES_12_BIT); // For TMP102 Sensor tmp = TMP102_Create(); TMP102_ConnectI2C(tmp, i2c); tmp->Config.Adr = TMP102_AD0_TO_GND; tmp->Config.AlertPinMode = TMP102_ALERT_PIN_AS_INTERRUPT; tmp->Config.AlertPinPolarity = TMP102_ALERT_PIN_ACT_HIGH; TMP102_Start(tmp);