The CP2400-GQ low-power LCD controller can drive up to 128 LCD segments. These devices are easily interfaced with any microcontroller using a SPI interface. A benefit to this approach is that designers can select the best-fit MCU for the system and then add the CP2400-GQ to handle LCD requirements efficiently with respect to system size and power consumption. The device includes 36 digital I/O pins and is available in a TQFP48 package (9x9).
The longevity date shown above is for the preferred revision of this part number, for a complete list of part number revisions, use the search button below.
As part of its ongoing commitment to supply continuity, Silicon Labs may provide pin-compatible and functionally equivalent replacement products if Silicon Labs determines, at its discretion, that supply chain adjustments, product improvements, market conditions, or similar business or technical issues make this necessary or advisable.
If for business, technical or other reasons beyond Silicon Labs’ reasonable control, Silicon Labs finds that it is necessary to discontinue a product, our policy is to issue an EOL notice that provides 6 months from notice to place final orders and 12 months from notice for final shipments. This policy complies with the JEDEC standard EIA/JESD48 that is commonly used in the semiconductor industry. We provide the required support for a product for its full life cycle.
Find and download additional quality, environmental, device composition, test results, shipping and supply chain information for Silicon Labs devices.
Search results will include:
To debug using the Ozone IDE, please follow the instructions below.
Prior to debugging, please make sure you flash the firmware, that you wish to debug, using Simplicity Commander.
Link to flash the firmware: https://docs.silabs.com/wiseconnect/latest/wiseconnect-getting-started/getting-started-with-soc-mode#upgrade-si-wx91x-connectivity-firmware
Settings:
Where,
Project.AddPathSubstitute ("C:\Users\SimplicityStudio\workspace\wifi_powersave_standby_associated_soc", "$(ProjectDir)"); // Please provide the path of the folder.
Project.SetHostIF ("USB", "440270093"); // Check for this number using Simplicity Commander as shown in the below image:
Project.AddSvdFile ("C:\Users\Downloads\SiWx917.svd"); // Use the SVD file: SiWx917.svd
File.Open ("C:\Users\Downloads\wifi_powersave_standby_associated_soc.axf"); // Optional to add the *.axf file.
Above are the steps which can help one to debug SiW917 using Ozone IDE.
One can add more sensors to the Sensor Hub by following the instructions in this section. For adding new sensors, the below layers play a critical role.
HUB HAL Interface Layer: The HUB HAL Interface Layer serves as an interface between the Sensor Hub Service Layer and the Sensors HAL Layer. It handles the communication between the high-level services and the low-level sensor hardware abstraction.
Sensors HAL Layer: The Sensors HAL Layer abstracts the hardware-specific details of the sensors. It communicates with the Sensor Driver Layer to facilitate sensor-specific operations.
Sensor Driver Layer: The Sensor Driver Layer is responsible for interacting with individual sensors. It communicates with the Sensors HAL Layer to abstract the underlying hardware complexities and provides a standardized interface for the Sensors HAL Layer.
Peripheral Drivers Layer: The Peripheral Drivers Layer is responsible for managing communication with the physical peripherals connected to the sensors. This layer ensures that the sensor drivers can interact seamlessly with the underlying hardware.
Step 1:
Individual sensor files should be created, user needs to create 4 files that should be integrated with the Sensor Hub, which are the sensorHal.c, sensorHal.h, sensor.c, and sensor.h.
Step 2:
HUB HAL Interface will become the communication path between the sensor Hub service layer and the Sensor HAL layer. Users should map the sensor HAL APIs in sl_sensor_impl_type_t structure, which is present in *\sensors\src\hub_hal_intf.c file.
For Example,
sl_sensor_impl_type_t sensor_impls[] = { #ifdef SL_CONFIG_SENSOR_LIGHT //Light sensor operations { .type = SL_LIGHT_SENSOR_ID, .create = sl_si91x_lightsensor_create, .delete = sl_si91x_lightsensor_delete, .sample = sl_si91x_lightsensor_sample, .control = sl_si91x_lightsensor_control, },
After mapping the APIs in the HUB HAL interface, sensor types and sensor IDs must be generated, which should be updated in the *sensors_config.h file. Please carry out the configuration using the instructions below.
Step 3:
Now add all the sensor IDs in sl_sensor_id_t* structure, which is present in /sensors/inc/sensors_config.h, to create a unique sensor ID which Sensor Hub Application will use further operations on Sensors.
For Example,
typedef enum { #ifdef SL_CONFIG_SENSOR_LIGHT SL_SENSOR_BH1750_ID = (SL_LIGHT_SENSOR_ID << SL_SENSOR_ID_OFFSET) | SL_BH1750_ID, ///< Bh1750 sensor id #endif } sl_sensor_id_t;
where SL_LIGHT_SENSOR_ID is the Sensor type which should be added to the sl_sensor_type_t structure
where SL_SENSOR_ID_OFFSET is the Sensor offset ID
where SL_BH1750_ID is here individual sensor ID (light sensor ID)
where SL_SENSOR_BH1750_ID is to create a unique sensor ID, which the Sensor Hub Application will use for performing further operations on sensors. This ID will be used from the Sensor Hub service layer and should be used to configure in sensor hub information structure present in the sensorhub_config.c file.
Step 3.1:
Define a macro that defines the respective sensor and is unique.
For Example,
#define SL_CONFIG_SENSOR_LIGHT
Step 3.2:
If one or more sensors are present with the same sensor type, then create an individual sensor ID in sl_light_sensor_id_t structure, which is present in */sensors/inc/sensors_config.h, for each sensor that needs to be created.
For Example,
typedef enum { SL_BH1750_ID = 0x01, /*!< BH1750 light sensor id*/ SL_BH1750FVI_ID = 0x02, SL_LIGHT_MAX_ID, /*!< max light sensor id*/ } sl_light_sensor_id_t;
Step 3.3:
Create the type of the sensor if not present in the sl_sensor_type_t structure and add in this structure which is present in the */sensors/inc/sensors_config.h file.
For Example,
//Type of sensors typedef enum { SL_NULL_ID, SL_LIGHT_SENSOR_ID, SL_SENSOR_TYPE_MAX, } sl_sensor_type_t;
Step 4:
Add your sensor condition based on the unique sensor ID in the sl_si91x_sensor_event_handler function, which is present in sensorhub_app.c, so that the user can print and check the sensor's data.
Based on the sensor configurations made in the sensorhub_config.c file, the sensors' data is obtained.
For Example,
if (SL_SENSOR_BH1750_ID == sensor_id) { if (sensor_hub_info_t[sens_ind].sensor_mode == SL_SH_INTERRUPT_MODE) { DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[0].light); } else if (sensor_hub_info_t[sens_ind].sensor_mode == SL_SH_POLLING_MODE) { if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_TIMEOUT) { for (uint32_t i = 0; i < sensor_hub_info_t[sens_ind].data_deliver.timeout / sensor_hub_info_t[sens_ind].sampling_interval; i++){ DEBUGOUT(" %f \t ", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[i].light); } } if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_NUM_OF_SAMPLES) { for (uint32_t i = 0; i < sensor_hub_info_t[sens_ind].data_deliver.numofsamples; i++) { DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[i].light); } } if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_THRESHOLD) { DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[0].light); } } }
Step 5:
Configure the pins and build the project. Please refer to the Sensor Pins Setup, Build and Executing the Application section in Readme of Sensor Hub project to check the sensor data
Important NoteThis article is only applicable to the earlier EmberZNet SDK versions before v6.7.0.0. The host side source routing table has been removed in EmberZnet v6.7.0.0 as described in the emberznet-release-notes-6.7.0.0.This KBA will not be maintained. We retain it here for reference only. |
Why is there a Source Route table on the host and NCP?
The reason for two route tables is a combination of things. The first stems back to when our NCP were tight on RAM. For that reason, we had to use the host to hold the routes. However, the NCP needed routes for certain messages in order to answer them without needed to talk to the host (i.e. ZDO messages and Join/Rejoin Requests). Now we use it because it allows us to not need to talk to the host for some messages, but also because it is easier to keep the past architecture intact. So in the case of the SoC we only have one route table.
The way it works is that a message comes in to the NCP. The NCP either handles it with or without notifying the host. If it does not notify the host, and the host had not previously setup a source route (using ezspSetSourceRoute()), the NCP will send out a response with its own source route. If it notifies the host, the host has a chance to provide a source route with ezspSetSourceRoute(). If it does not, the NCP will handle it with its own source route, and it will use its own source route for the response. This means that you can set up a larger route table on the host and not be too worried about having too small of a route table on the NCP. This does not mean we recommend putting a small route table on the NCP, but if you need the space you can.
Currently, the best practice recommendation is to put all the source route table data on the NCP (if there is enough RAM on the NCP). Then you would only want to use a host-side source route table if you expected to talk to more nodes than your NCP-based source route table could hold. Currently, 254 source routes is the maximum that the NCP's RAM can have. Part of the reason why this is best practice is because it allows the NCP to respond to messages without having to ask the host for a source route, thus increasing the speed in which it can respond.
When using a High RAM Concentrator it is also important to keep at least a few source route table entries on the NCP. If you don't it is possible to hit a condition where a node sends a ZDO request to the concentrator and does not provide a Route Record and then the concentrator does not have a cached source route on the NCP. This puts the concentrator in a situation where it is unable to respond, and the ZDO does not go out. This will force the sender to send a retry and possibly initiate a network address discovery. At this point if a source route is not intact the network address discovery would not be responded to.
Silicon Labs has an active, knowledgeable user community of engineers and developers that are enthusiastic about solving problems.
Browse the CommunityPlease select at least one column.
Thank you for downloading .
If you have any issues downloading, please contact sales support or product technical support.