How do I generate an NIRQ hardware interrupt on the Si4x5x, Si446x?
You need to globally enable the interrupt source(s) of the corresponding interrupt group via INT_CTL_ENABLE (i.e. Chip, Modem, Packet Handler interrupt groups), and enable them individually via INT_CTL_PH_ENABLE, INT_CTL_MODEM_ENABLE, INT_CTL_CHIP_ENABLE properties. See the API documentation for more details. Note that regardless of having them enabled as hardware interrupt or not, the interrupts are always generated inside the chip; therefore it is possible to poll them via GET_INT_STATUS/ GET_CHIP_STATUS/ GET_PH_STATUS/ GET_MODEM_STATUS commands.
What is the difference between SPI active and Ready states on the Si4x5x, Si446x?
In SPI active mode the current consumption is somewhat lower due to the XTAL being turned off (~1.35mA vs ~1.8mA). The trade-off is that going from SPI active to any other higher level state (i.e. TX/RX Tune, TX/RX State, Ready) takes longer due to the XTAL turnaround time. The chip is fully accessible in both states without any limitation. If the chip is in Sleep/Standby and an API command is sent, the chip will go to SPI active state and execute the command that has been sent. After power-up (i.e. sending the POWER_UP command) the chip goes to Ready state.
What is a Fast Response Register on the Si4x5x, Si446x?
Unlike the so called PROPERTIES which are API software registers, the Fast Response Registers (FRRs) are actual hardware registers that are configurable and that can be read immediately without the requirement to monitor CTS (Clear-To-Send signal). Thus accessing the FRR(s) is faster than retrieving the same information via a PROPERTY read, or any other API command. The FRRs can be configured via FRR_CTL_x_MODE properties, and they may return interrupt status, chip state, or the Latched RSSI. Note that it is NOT possible to clear an interrupt via a FRR (you need to use GET_INT_STATUS/ GET_CHIP_STATUS/ GET_PH_STATUS/ GET_MODEM_STATUS command for that purpose).
What is the difference between PENDING vs STATUS interrupts on the Si4x5x, Si446x?
STATUS returns the current state of an internal interrupt event such as preamble/sync word detection, packet received, etc. whereas PENDING simply latches the rising edge of the corresponding STATUS, and does not change until cleared by GET_INT_STATUS / GET_CHIP_STATUS / GET_MODEM_STATUS / GET_PH_STATUS commands. It is possible to poll for interrupts by reading the STATUS and PENDING response bytes of the commands above as they are always up-to-date. Additionally, a PENDING interrupt may be a source to generate a HW interrupt at the NIRQ pin when enabled through INT_EN_ properties.
What is the default configuration for the pins/GPIOs during shutdown, and during/after power-up on the Si4x5x, Si446x?
The table below describes how the pins and GPIOs are configured during shutdown (i.e. SDN pin held high), and during power-up (i.e. POWER_UP command sent and waiting for CTS):
|Pin name||Direction||SDN = High||During/After POWER_UP|
|nIRQ||Output||Pull-up||Driven high (no Pull-up) / NIRQ*|
|SDO||Output||Pull-up||SDO data or Pull-up if no valid data|
*Once the CTS for the POWER_UP command arrives (i.e. the API is successfully loaded) NIRQ goes low, and the interrupts have to be cleared using GET_INT_STATUS command.
By default, the GPIOs (i.e. GPIO0-GPIO3, NIRQ, SDO) are configured to the lowest drive strength. This means that retrieving the GPIO configuration via GPIO_PIN_CFG command right after the POWER_UP command, the chip returns 0C 08 0C 0C 27 0B 60. Note, however, that in the WDS-generated radio configurations the drive strength is set to the highest by default (e.g. GPIO_PIN_CFG 00 00 00 00 00 00 00). This is different than the chip default.
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 atleast 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.