|
Chirp SonicLib
2.1.0
|
User-supplied board support package functions to interface Chirp SonicLib to a specific hardware platform. More...
#include "soniclib.h"
Go to the source code of this file.
Functions | |
| void | chbsp_board_init (ch_group_t *grp_ptr) |
| Main hardware initialization. More... | |
| void | chbsp_debug_toggle (uint8_t dbg_pin_num) |
| Toggle a debug indicator pin. More... | |
| void | chbsp_debug_on (uint8_t dbg_pin_num) |
| Turn on a debug indicator pin. More... | |
| void | chbsp_debug_off (uint8_t dbg_pin_num) |
| Turn off a debug indicator pin. More... | |
| void | chbsp_reset_assert (void) |
| Assert the reset pin for all sensors. More... | |
| void | chbsp_reset_release (void) |
| Deassert the reset pin for all sensors. More... | |
| void | chbsp_program_enable (ch_dev_t *dev_ptr) |
| Assert the PROG pin. More... | |
| void | chbsp_program_disable (ch_dev_t *dev_ptr) |
| Deassert the PROG pin. More... | |
| void | chbsp_group_set_io_dir_out (ch_group_t *grp_ptr) |
| Configure the Chirp sensor INT pin as an output for a group of sensors. More... | |
| void | chbsp_set_io_dir_out (ch_dev_t *dev_ptr) |
| Configure the Chirp sensor INT pin as an output for one sensor. More... | |
| void | chbsp_group_set_io_dir_in (ch_group_t *grp_ptr) |
| Configure the Chirp sensor INT pins as inputs for a group of sensors. More... | |
| void | chbsp_set_io_dir_in (ch_dev_t *dev_ptr) |
| Configure the Chirp sensor INT pin as an input for one sensor. More... | |
| void | chbsp_group_pin_init (ch_group_t *grp_ptr) |
| Initialize the set of I/O pins for a group of sensors. More... | |
| void | chbsp_group_io_clear (ch_group_t *grp_ptr) |
| Set the INT pins low for a group of sensors. More... | |
| void | chbsp_io_clear (ch_dev_t *dev_ptr) |
| Set the INT pin low for one sensor. More... | |
| void | chbsp_group_io_set (ch_group_t *grp_ptr) |
| Set the INT pins high for a group of sensors. More... | |
| void | chbsp_io_set (ch_dev_t *dev_ptr) |
| Set the INT pin high for one sensor. More... | |
| void | chbsp_group_io_interrupt_enable (ch_group_t *grp_ptr) |
| Enable interrupts for a group of sensors. More... | |
| void | chbsp_io_interrupt_enable (ch_dev_t *dev_ptr) |
| Enable the interrupt for one sensor. More... | |
| void | chbsp_group_io_interrupt_disable (ch_group_t *grp_ptr) |
| Disable interrupts for a group of sensors. More... | |
| void | chbsp_io_interrupt_disable (ch_dev_t *dev_ptr) |
| Disable the interrupt for one sensor. More... | |
| void | chbsp_io_callback_set (ch_io_int_callback_t callback_func_ptr) |
| Set callback routine for Chirp sensor I/O interrupt. More... | |
| void | chbsp_delay_us (uint32_t us) |
| Delay for specified number of microseconds. More... | |
| void | chbsp_delay_ms (uint32_t ms) |
| Delay for specified number of milliseconds. More... | |
| uint32_t | chbsp_timestamp_ms (void) |
| Return a free-running counter value in milliseconds. More... | |
| int | chbsp_i2c_init (void) |
| Initialize the host's I2C hardware. More... | |
| int | chbsp_i2c_deinit (void) |
| De-initialize the host's I2C hardware. More... | |
| uint8_t | chbsp_i2c_get_info (ch_group_t *grp_ptr, uint8_t dev_num, ch_i2c_info_t *info_ptr) |
| Return I2C information for a sensor port on the board. More... | |
| int | chbsp_i2c_write (ch_dev_t *dev_ptr, uint8_t *data, uint16_t num_bytes) |
| Write bytes to an I2C slave. More... | |
| int | chbsp_i2c_mem_write (ch_dev_t *dev_ptr, uint16_t mem_addr, uint8_t *data, uint16_t num_bytes) |
| Write bytes to an I2C slave using memory addressing. More... | |
| int | chbsp_i2c_write_nb (ch_dev_t *dev_ptr, uint8_t *data, uint16_t num_bytes) |
| Write bytes to an I2C slave, non-blocking. More... | |
| int | chbsp_i2c_mem_write_nb (ch_dev_t *dev_ptr, uint16_t mem_addr, uint8_t *data, uint16_t num_bytes) |
| Write bytes to an I2C slave using memory addressing, non-blocking. More... | |
| int | chbsp_i2c_read (ch_dev_t *dev_ptr, uint8_t *data, uint16_t num_bytes) |
| Read bytes from an I2C slave. More... | |
| int | chbsp_i2c_mem_read (ch_dev_t *dev_ptr, uint16_t mem_addr, uint8_t *data, uint16_t num_bytes) |
| Read bytes from an I2C slave using memory addressing. More... | |
| int | chbsp_i2c_read_nb (ch_dev_t *dev_ptr, uint8_t *data, uint16_t num_bytes) |
| Read bytes from an I2C slave, non-blocking. More... | |
| int | chbsp_i2c_mem_read_nb (ch_dev_t *dev_ptr, uint16_t mem_addr, uint8_t *data, uint16_t num_bytes) |
| Read bytes from an I2C slave using memory addressing, non-blocking. More... | |
| void | chbsp_external_i2c_irq_handler (chdrv_i2c_transaction_t *trans) |
| Interrupt handler callout for external devices sharing the I2C bus. More... | |
| void | chbsp_i2c_reset (ch_dev_t *dev_ptr) |
| Reset I2C bus associated with device. More... | |
| uint8_t | chbsp_periodic_timer_init (uint16_t interval_ms, ch_timer_callback_t callback_func_ptr) |
| Initialize periodic timer. More... | |
| void | chbsp_periodic_timer_irq_enable (void) |
| Enable periodic timer interrupt. More... | |
| void | chbsp_periodic_timer_irq_disable (void) |
| Disable periodic timer interrupt. More... | |
| uint8_t | chbsp_periodic_timer_start (void) |
| Start periodic timer. More... | |
| uint8_t | chbsp_periodic_timer_stop (void) |
| Stop periodic timer. More... | |
| void | chbsp_periodic_timer_handler (void) |
| Periodic timer handler. More... | |
| void | chbsp_proc_sleep (void) |
| Put the processor into low-power sleep state. More... | |
| void | chbsp_led_on (uint8_t dev_num) |
| Turn on an LED on the board. More... | |
| void | chbsp_led_off (uint8_t dev_num) |
| Turn off an LED on the board. More... | |
| void | chbsp_led_toggle (uint8_t dev_num) |
| Toggle an LED on the board. More... | |
| void | chbsp_print_str (char *str) |
| Output a text string via serial interface. More... | |
User-supplied board support package functions to interface Chirp SonicLib to a specific hardware platform.
This file defines the I/O interfaces that allow the standard Chirp SonicLib sensor driver functions to manage one or more sensors on a specific hardware platform. These include functions to initialize and control the various I/O pins connecting the sensor to the host system, the I2C communications interface, timer functions, etc.
The board support package developer should not need to modify this file. However, that developer is responsible for implementing these support functions for the desired platform. Note that some functions are optional, depending on the specific runtime requirements (e.g. is non-blocking I/O required?) or development needs (e.g. is debugging support needed?).
The file organization for a BSP is intentionally very flexible, so that you may efficiently use existing code that supports your hardware or otherwise use your own organizing preferences.
By convention, the functions that implement the BSP interfaces defined in chirp_bsp.h are placed in a source file called chbsp_VVV_BBB.c, where "VVV" is the board vendor name, and "BBB" is the board name. For example, the BSP for a Chirp SmartSonic board has a main file called chbsp_chirp_smartsonic.c.
The board support package must supply a header file called chirp_board_config.h containing definitions of two symbols used in the SonicLib driver functions.
The following symbols must be defined in chirp_board_config.h:
The chirp_board_config.h file must be in the C pre-processor include path when you build your application with SonicLib.
In some cases, the BSP is required to call a function to notify SonicLib or the application that an event has occurred:
Most of the required functions take a pointer to a ch_dev_t device descriptor structure as a handle to identify the sensor being controlled. The ch_dev_t structure contains various fields with configuration and operating state information for the device. In general, these data field values may be obtained using various ch_get_XXX() functions provided by the SonicLib API, so it should not be necessary to access fields directly.
Some functions take a pointer to a ch_group_t (sensor group descriptor) structure as a parameter but must operate on individual sensors. These functions can be implemented using the ch_get_dev_ptr() function to access the ch_dev_t structure describing each individual sensor in the group, based on its device number (I/O index value). The total number of possible sensor devices in a group may be obtained by using the ch_get_num_ports() function.
Similarly, each sensor's ch_dev_t structure contains a dev_num field that may be used to manage the pin assignments for the various sensors, by using it as an index into individual arrays which list the pins assigned to the PROG, INT, and RESET_N lines. The dev_num value for a sensor may be obtained using the ch_get_dev_num() function.
Often, an action should only be taken on a sensor port if a sensor is present and has been successfully initialized and connected. The ch_sensor_is_connected() function can be used to obtain the connection status.
These functions are often used together to implement a board support routine, as in the following pseudo-code which shows how to perform an action on all connected devices in a group. This snippet assumes that a sensor group pointer (ch_group_t *) called grp_ptr is an input parameter to the function:
ch_dev_t *dev_ptr; uint8_t dev_num; for (dev_num = 0; dev_num < ch_get_num_ports(grp_ptr); dev_num++ { dev_ptr = ch_get_dev_ptr(grp_ptr, dev_num); if (ch_sensor_is_connected(dev_ptr)) { DO WHAT NEEDS DOING FOR THIS CONNECTED DEVICE } }
The dev_num value for each device is specified by the user application as a parameter to ch_init().
| void chbsp_board_init | ( | ch_group_t * | grp_ptr | ) |
Main hardware initialization.
This function executes the required hardware initialization sequence for the board being used. This includes clock, memory, and processor setup as well as any special handling that is needed. This function is called at the beginning of an application, as the first operation.
Along with the actual hardware initialization, this function must also initialize the following fields within the ch_group_t sensor group descriptor:
Often, during initialization the BSP needs to determine which sensor ports (possible connections) actually have a sensor attached. Here is a short sequence you can use to confirm if a Chirp sensor is alive and communicating by reading two signature byte values from the device using I2C. This sequence applies to both CH101 and CH201 devices.
A couple key points:
So, the overall sequence should be:
This function is REQUIRED.
| void chbsp_debug_off | ( | uint8_t | dbg_pin_num | ) |
Turn off a debug indicator pin.
| dbg_pin_num | index value for debug pin to turn off |
This function should drive the the specified debug indicator pin low. The dbg_pin_num parameter is an index value that specifies which debug pin should be controlled.
This function is OPTIONAL.
| void chbsp_debug_on | ( | uint8_t | dbg_pin_num | ) |
Turn on a debug indicator pin.
| dbg_pin_num | index value for debug pin to turn on |
This function should drive the specified debug indicator pin high. The dbg_pin_num parameter is an index value that specifies which debug pin should be controlled.
This function is OPTIONAL.
| void chbsp_debug_toggle | ( | uint8_t | dbg_pin_num | ) |
Toggle a debug indicator pin.
| dbg_pin_num | index value for debug pin to toggle |
This function should change the state (high/low) of the specified debug indicator pin. The dbg_pin_num parameter is an index value that specifies which debug pin should be controlled.
This function is OPTIONAL.
| void chbsp_delay_ms | ( | uint32_t | ms | ) |
Delay for specified number of milliseconds.
| ms | number of milliseconds to delay before returning |
This function should wait for the specified number of milliseconds before returning to the caller.
This function is REQUIRED.
| void chbsp_delay_us | ( | uint32_t | us | ) |
Delay for specified number of microseconds.
| us | number of microseconds to delay before returning |
This function should wait for the specified number of microseconds before returning to the caller.
This function is REQUIRED.
| void chbsp_external_i2c_irq_handler | ( | chdrv_i2c_transaction_t * | trans | ) |
Interrupt handler callout for external devices sharing the I2C bus.
| trans | pointer to Chirp sensor I2C transaction control structure |
This function is called when a non-blocking I2C operation completes on an "external" (non Chirp sensor) device. The chbsp_external_i2c_queue() function should be called to add such a transaction to the I2C queue.
| void chbsp_group_io_clear | ( | ch_group_t * | grp_ptr | ) |
Set the INT pins low for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
This function should drive the INT line low for each sensor in the group.
This function is REQUIRED.
| void chbsp_group_io_interrupt_disable | ( | ch_group_t * | grp_ptr | ) |
Disable interrupts for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
For each sensor in the group, this function should disable the host interrupt associated with the Chirp sensor device's INT line.
| void chbsp_group_io_interrupt_enable | ( | ch_group_t * | grp_ptr | ) |
Enable interrupts for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
For each sensor in the group, this function should enable the host interrupt associated with the Chirp sensor device's INT line.
This function is REQUIRED.
| void chbsp_group_io_set | ( | ch_group_t * | grp_ptr | ) |
Set the INT pins high for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
This function should drive the INT line high for each sensor in the group.
This function is REQUIRED.
| void chbsp_group_pin_init | ( | ch_group_t * | grp_ptr | ) |
Initialize the set of I/O pins for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
This function initializes the set of I/O pins used for a group of sensors. It should perform any clock initialization and other setup required to use the ports/pins. It should then configure the RESET_N and PROG pins as outputs (from the perspective of the host system), and assert both RESET_N and PROG. It should also configure the INT pin as an input.
This function is REQUIRED.
| void chbsp_group_set_io_dir_in | ( | ch_group_t * | grp_ptr | ) |
Configure the Chirp sensor INT pins as inputs for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
This function should configure each Chirp sensor's INT pin as an input (from the perspective of the host system).
This function is REQUIRED.
| void chbsp_group_set_io_dir_out | ( | ch_group_t * | grp_ptr | ) |
Configure the Chirp sensor INT pin as an output for a group of sensors.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
This function should configure each Chirp sensor's INT pin as an output (from the perspective of the host system).
This function is REQUIRED.
| int chbsp_i2c_deinit | ( | void | ) |
De-initialize the host's I2C hardware.
This function de-initializes the I2C hardware and control structures on the host system.
This function is OPTIONAL.
| uint8_t chbsp_i2c_get_info | ( | ch_group_t * | grp_ptr, |
| uint8_t | dev_num, | ||
| ch_i2c_info_t * | info_ptr | ||
| ) |
Return I2C information for a sensor port on the board.
| grp_ptr | pointer to the ch_group_t config structure for a group of sensors |
| dev_num | device number within sensor group |
| info_ptr | pointer to structure to be filled with I2C config values |
This function is called by SonicLib functions to obtain I2C operating parameters for a specific device on the board.
This function returns I2C values in the ch_i2c_info_t structure specified by info_ptr. The structure includes three fields.
- The address field contains the I2C address for the sensor.
- The bus_num field contains the I2C bus number (index).
- The drv_flags field contains various bit flags through which the BSP can inform SonicLib driver functions to perform specific actions during I2C I/O operations. The possible flags include:
This function is REQUIRED.
| int chbsp_i2c_init | ( | void | ) |
Initialize the host's I2C hardware.
This function should perform general I2C initialization on the host system. This includes both hardware initialization and setting up any necessary software structures. Upon successful return from this routine, the system should be ready to perform I/O operations such as chbsp_i2c_read() and chbsp_i2c_write().
This function is REQUIRED.
| int chbsp_i2c_mem_read | ( | ch_dev_t * | dev_ptr, |
| uint16_t | mem_addr, | ||
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Read bytes from an I2C slave using memory addressing.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| mem_addr | internal memory or register address within device |
| data | pointer to receive data buffer |
| num_bytes | number of bytes to read |
This function should read the specified number of bytes from an I2C slave device, using an internal memory or register address. The remote device will return num_bytes bytes starting at internal memory/register address mem_addr.
The I2C interface must have already been initialized using chbsp_i2c_init().
This function is normally implemented such that the device address and memory address are written to the I2C bus, then a repeated-start marker is sent, and the data is read. Most micro-controller I/O libraries support such an access sequence. (If this is not possible, the write and read phases may be separated into two discrete operations, without the repeated-start. However, this may be a problem if more than one bus master is present, because the bus is not held between the two phases.)
This function is REQUIRED.
| int chbsp_i2c_mem_read_nb | ( | ch_dev_t * | dev_ptr, |
| uint16_t | mem_addr, | ||
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Read bytes from an I2C slave using memory addressing, non-blocking.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| mem_addr | internal memory or register address within device |
| data | pointer to receive data buffer |
| num_bytes | number of bytes to read |
This function should initiate a non-blocking read of the specified number of bytes from an I2C slave. The I2C interface must have already been initialized using chbsp_i2c_init().
This function is OPTIONAL.
| int chbsp_i2c_mem_write | ( | ch_dev_t * | dev_ptr, |
| uint16_t | mem_addr, | ||
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Write bytes to an I2C slave using memory addressing.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| mem_addr | internal memory or register address within device |
| data | data to be transmitted |
| num_bytes | length of data to be transmitted |
This function should write one or more bytes of data to an I2C slave device using an internal memory or register address. The remote device will write num_bytes bytes of data starting at internal memory/register address mem_addr. The I2C interface will have already been initialized using chbsp_i2c_init().
This function is REQUIRED.
| int chbsp_i2c_mem_write_nb | ( | ch_dev_t * | dev_ptr, |
| uint16_t | mem_addr, | ||
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Write bytes to an I2C slave using memory addressing, non-blocking.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| mem_addr | internal memory or register address within device |
| data | pointer to the start of data to be transmitted |
| num_bytes | length of data to be transmitted |
This function should initiate a non-blocking write of the specified number of bytes to an I2C slave device, using an internal memory or register address. The remote device will write num_bytes bytes of data starting at internal memory/register address mem_addr.
The I2C interface must have already been initialized using chbsp_i2c_init().
This function is OPTIONAL.
| int chbsp_i2c_read | ( | ch_dev_t * | dev_ptr, |
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Read bytes from an I2C slave.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| data | pointer to receive data buffer |
| num_bytes | number of bytes to read |
This function should read the specified number of bytes from an I2C slave device. The I2C interface must have already been initialized using chbsp_i2c_init().
This function is REQUIRED.
| int chbsp_i2c_read_nb | ( | ch_dev_t * | dev_ptr, |
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Read bytes from an I2C slave, non-blocking.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| data | pointer to receive data buffer |
| num_bytes | number of bytes to read |
This function should initiate a non-blocking read of the specified number of bytes from an I2C slave.
The I2C interface must have already been initialized using chbsp_i2c_init().
This function is OPTIONAL.
| void chbsp_i2c_reset | ( | ch_dev_t * | dev_ptr | ) |
Reset I2C bus associated with device.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should perform a reset of the I2C interface for the specified device.
| int chbsp_i2c_write | ( | ch_dev_t * | dev_ptr, |
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Write bytes to an I2C slave.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
| data | data to be transmitted |
| num_bytes | length of data to be transmitted |
This function should write one or more bytes of data to an I2C slave device. The I2C interface will have already been initialized using chbsp_i2c_init().
| int chbsp_i2c_write_nb | ( | ch_dev_t * | dev_ptr, |
| uint8_t * | data, | ||
| uint16_t | num_bytes | ||
| ) |
Write bytes to an I2C slave, non-blocking.
| data | pointer to the start of data to be transmitted |
| num_bytes | length of data to be transmitted |
This function should initiate a non-blocking write of the specified number of bytes to an I2C slave device.
The I2C interface must have already been initialized using chbsp_i2c_init().
This function is OPTIONAL.
| void chbsp_io_callback_set | ( | ch_io_int_callback_t | callback_func_ptr | ) |
Set callback routine for Chirp sensor I/O interrupt.
| callback_func_ptr | pointer to application function to be called when interrupt occurs |
This function sets up the specified callback routine to be called whenever the interrupt associated with the sensor's INT line occurs. The implementation will typically save the callback routine address in a pointer variable that can later be accessed from within the interrupt handler to call the function.
The callback function will generally be called at interrupt level from the interrupt service routine.
This function is REQUIRED.
| void chbsp_io_clear | ( | ch_dev_t * | dev_ptr | ) |
Set the INT pin low for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should drive the INT line low for the specified sensor.
| void chbsp_io_interrupt_disable | ( | ch_dev_t * | dev_ptr | ) |
Disable the interrupt for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should disable the host interrupt associated with the Chirp sensor device's INT line.
This function is REQUIRED.
| void chbsp_io_interrupt_enable | ( | ch_dev_t * | dev_ptr | ) |
Enable the interrupt for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should enable the host interrupt associated with the Chirp sensor device's INT line.
This function is REQUIRED.
| void chbsp_io_set | ( | ch_dev_t * | dev_ptr | ) |
Set the INT pin high for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should drive the INT line high for the specified sensor.
This function is OPTIONAL.
| void chbsp_led_off | ( | uint8_t | dev_num | ) |
Turn off an LED on the board.
This function turns off an LED on the board. The implementation of this function is flexible to allow for different arrangements of LEDs.
The dev_num parameter contains the device number of a specific sensor. The device number may be used to select which LED should be turned off (e.g. if it is located next to an individual sensor). If the board does not have LEDs associated with individual sensors, the BSP may implement this routine to combine all device numbers to control a single LED, or any other organization that makes sense for the board.
This function is RECOMMENDED.
| void chbsp_led_on | ( | uint8_t | dev_num | ) |
Turn on an LED on the board.
This function turns on an LED on the board. The implementation of this function is flexible to allow for different arrangements of LEDs.
The dev_num parameter contains the device number of a specific sensor. The device number may be used to select which LED should be turned on (e.g. if it is located next to an individual sensor). If the board does not have LEDs associated with individual sensors, the BSP may implement this routine to combine all device numbers to control a single LED, or any other organization that makes sense for the board.
This function is RECOMMENDED.
| void chbsp_led_toggle | ( | uint8_t | dev_num | ) |
Toggle an LED on the board.
This function toggles an LED on the board. It changes the on/off state from whatever it currently is. The implementation of this function is flexible to allow for different arrangements of LEDs.
The dev_num parameter contains the device number of a specific sensor. The device number may be used to select which LED should be toggled (e.g. if it is located next to an individual sensor). If the board does not have LEDs associated with individual sensors, the BSP may implement this routine to combine all device numbers to control a single LED, or any other organization that makes sense for the board.
This function is RECOMMENDED.
| void chbsp_periodic_timer_handler | ( | void | ) |
Periodic timer handler.
This function handles the expiration of the periodic timer, re-arms it and any associated interrupts for the next interval, and calls the callback routine that was registered using chbsp_periodic_timer_init().
This function is RECOMMENDED.
| uint8_t chbsp_periodic_timer_init | ( | uint16_t | interval_ms, |
| ch_timer_callback_t | callback_func_ptr | ||
| ) |
Initialize periodic timer.
| interval_ms | timer interval, in milliseconds |
| callback_func_ptr | address of routine to be called every time the timer expires |
This function initializes a periodic timer on the board. The timer should be programmed to generate an interrupt after every interval_ms milliseconds.
The callback_func_ptr parameter specifies a callback routine that will be called when the timer expires (and interrupt occurs). The timer interrupt handler function within the board support package should call this function.
The period timer is often used to trigger sensor measurement cycles by having the application's callback function call ch_trigger() or ch_group_trigger().
This function is RECOMMENDED.
| void chbsp_periodic_timer_irq_disable | ( | void | ) |
Disable periodic timer interrupt.
This function enables the interrupt associated with the periodic timer initialized by chbsp_periodic_timer_init().
This function is RECOMMENDED.
| void chbsp_periodic_timer_irq_enable | ( | void | ) |
Enable periodic timer interrupt.
This function enables the interrupt associated with the periodic timer initialized by chbsp_periodic_timer_init().
This function is RECOMMENDED.
| uint8_t chbsp_periodic_timer_start | ( | void | ) |
Start periodic timer.
This function starts the periodic timer initialized by chbsp_periodic_timer_init().
This function is RECOMMENDED.
| uint8_t chbsp_periodic_timer_stop | ( | void | ) |
Stop periodic timer.
This function stops the periodic timer initialized by chbsp_periodic_timer_init().
This function is RECOMMENDED.
| void chbsp_print_str | ( | char * | str | ) |
Output a text string via serial interface.
| str | pointer to a string of characters to be output |
This function should print debug information to the console. The user can implement this function to print characters over a serial port, for example.
In the Chirp SonicLib sensor driver, debug message output may be enabled by defining CHDRV_DEBUG and/or CHDRV_DEBUG_VERBOSE.
| void chbsp_proc_sleep | ( | void | ) |
Put the processor into low-power sleep state.
This function puts the host processor (MCU) into a low-power sleep mode, to conserve energy. The sleep state should be selected such that interrupts associated with the I2C, external GPIO pins, and the periodic timer (if used) are able to wake up the device.
This function is RECOMMENDED.
| void chbsp_program_disable | ( | ch_dev_t * | dev_ptr | ) |
Deassert the PROG pin.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should drive the Chirp sensor PROG pin low for the specified device.
This function is REQUIRED.
| void chbsp_program_enable | ( | ch_dev_t * | dev_ptr | ) |
Assert the PROG pin.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should drive the Chirp sensor PROG pin high for the specified device. It is used by the driver to initiate I2C communication with a specific Chirp sensor device before a unique I2C address is assigned to the device or when the programming interface is used.
When the PROG pin is asserted, the device will respond to the standard programming I2C address (0x45).
This function is REQUIRED.
| void chbsp_reset_assert | ( | void | ) |
Assert the reset pin for all sensors.
This function should drive the Chirp sensor reset pin low (assert RESET_N) on all sensors.
This function is REQUIRED.
| void chbsp_reset_release | ( | void | ) |
Deassert the reset pin for all sensors.
This function should drive the Chirp sensor reset pin high (or open drain if there is a pull-up) on all sensors.
This function is REQUIRED.
| void chbsp_set_io_dir_in | ( | ch_dev_t * | dev_ptr | ) |
Configure the Chirp sensor INT pin as an input for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should configure the Chirp sensor INT pin as an input (from the perspective of the host system).
This function is RECOMMENDED.
| void chbsp_set_io_dir_out | ( | ch_dev_t * | dev_ptr | ) |
Configure the Chirp sensor INT pin as an output for one sensor.
| dev_ptr | pointer to the ch_dev_t config structure for a sensor |
This function should configure the Chirp sensor INT pin as an output (from the perspective of the host system).
This function is RECOMMENDED.
| uint32_t chbsp_timestamp_ms | ( | void | ) |
Return a free-running counter value in milliseconds.
This function should use a running timer to provide an updated timestamp, in milliseconds, when called.
If CHDRV_DEBUG is defined, this function is used by the SonicLib driver to calculate elapsed times for various operations.
This function is OPTIONAL.


What?
Late last year, I started experiencing some unusual intermittent connection issues on my Desktop. In general, I had a stable connection with average latency; however, at (seemingly) random times throughout the week, I would start experiencing sudden 2000ms+ latency spikes every couple of seconds.
This made all audio/video calling software unusable and most online games unplayable.
This issue appeared to line up with my cross-country move from Washington State to South Carolina, so there were too many factors to easily pinpoint the issue. However, as it mainly only effected gaming and audio/video calls, I didn’t put too much focus on it.
Over the past couple of months I have (slowly) tried to figure out why this was happening, with little luck until today.
Why?
Initially, the only thing that was clear about the issue was that it was limited to my desktop computer only. My laptop and other devices connected to the wifi did not have this issue, even when placed in the exact same spot as the desktop.
First, I purchased a new, highly-reviewed, wifi adapter on Amazon. It didn’t resolve the issue. It did, however, come with an offer for a free 64GB flash drive in exchange for a good reviews.
(That was a pretty terrible purchase overall)
Later, (for unrelated reasons) I built an entirely new desktop computer, not using anything from the old one, except the new wifi adapter. This included a fresh install of Windows 10.
It was great, this new computer had no issues! I had suspected that my old motherboard’s USB ports might have been damaged during the move to SC, so that must have been the case. Everything is good now, right?
No. Everything is not good now.
A few weeks later, and the issue suddenly began happening on the new computer also, and I had no idea what the cause could be.
I tried using multiple different wifi adapters that I owned.
I tried changing the wifi channel, as it appeared to overlap a neighbors.
I tried turning off Windows Update Delivery Optimization (p2p update sharing). After turning this off and restarting, the issue appeared to be resolved, but then reappeared later.
At one point, my wifi issue even annoyed one of my brothers so badly, due to dropping Skype calls, that he bought me another (slightly less sketchy) wifi adapter on Amazon. This appeared to temporarily resolve the issue after installing the Realtek driver and restarting, but then it came back.
Nothing seemed to work.
Today, in a last-ditch desperate attempt at fixing the issue, I:
- Turned off the box fan in my room
- Unplugged my wireless Wacom drawing tablet’s USB dongle.
- Closed FireFox
- Closed MediBang Paint Pro
The issue stopped.
I immediately suspected interference from the wireless drawing tablet or box fan, so tried those again, but they were not the cause.
I couldn’t possibly imagine how a web browser or drawing application could cause this, but I tried anyway.
First I ran FireFox, opened multiple tabs on different sites, and waited…
Nothing
Then I ran MediBang Paint Pro.
Why!?

As it turns out, there are multiple instances of people complaining about this issue with MBPP.
If we take a quick look with Process Monitor, we can see that it’s definitely doing something odd.
At the exact same time the lag spikes occur, MBPP starts querying the registry keys for all of the network interfaces.
To dig a bit deeper into why this is happening, we can attach to the process with a debugger (x64dbg here), and set breakpoints on the Win32 Reg* APIs.
Eventually, our RegOpenKeyExInternalW
breakpoint is hit, and we can take a look at the call stack to determine where this is being called.
Looking at the call stack, we can see that first non-system library in the call stack is qt5network.
Surprisingly, no more debugging is needed, as a quick google search for “q5network ping issue” will lead you to QTBUG-40332.
If I understand correctly, any Qt5 (<5.14) application using QNetworkAccessManager
will check for wifi interface changes every 10 seconds for the purpose of bearer management, causing massive lag spikes and/or packet drops entirely. Even if QNetworkAccessManager
is instantiated internally for something simple, like an HTTP request.
I suppose the workaround is simple enough, set the environment variable QT_BEARER_POLL_TIMEOUT
to -1
.
I just wish I knew that around 8 months ago.
TL;DR
Qt5 has been crippling my wifi system-wide for past 7-8 months, just by running MediBang Paint Pro.
I stupidly attributed it to many other things, because, honestly, who would expect Qt to be the cause of their system-wide wifi problems?
Related
- https://invent.kde.org/graphics/krita/-/commit/d4eaaa63af8dc769acf79cd497e741f1de9be31b
- https://github.com/sqlitebrowser/sqlitebrowser/issues/1209
- https://github.com/mumble-voip/mumble/issues/1585
- https://community.amd.com/thread/209327
- https://github.com/Mudlet/Mudlet/issues/1587
- https://github.com/MultiMC/MultiMC5/issues/1422
- https://lostdomain.org/2017/06/17/qt-qnetworkaccessmanager-causing-latency-spikes-on-wifi/


 I like taking pictures of beautiful scenery and enjoying music. Of course, I can also paly the piano.
This is my hometown Ya'an, and it is tourist attraction and many people come to see the pandas every year. Welcome to Ya'an!


Interval 1: emits each second and map to i * 2 % 100
Value: {{ interval1$ | async}}
Take 1: emits each second and take 10
Value: {{ take1$ | async }}
Error 1: emits each second and error in map
Value: {{ error1$ | async }}
Flattening 1: every 5 seconds, switch to new interval observable that emits every 0.5s
Value: {{ flattening1$ | async }}
Complexe json value
Value: {{ (json$ | async) | json}}


@Immutable public interface Interpolator
interpolate(double)
method.
This interface is implemented by built-in interpolators. Applications may choose to implement their own interpolator to get custom interpolation behavior.
AccelerationInterpolator
,
DiscreteInterpolator
,
LinearInterpolator
,
SplineInterpolator
| Modifier and Type | Method and Description |
|---|---|
double |
interpolate(double fraction)
This function takes an input value between 0 and 1 and returns another
value, also between 0 and 1.
|
@RegionEffects(value="reads All") double interpolate(double fraction)
fraction
- a value between 0 and 1, inclusive, representing the elapsed
fraction of a time interval.


The NTP Security Project effort addresses a pressing problem in the Internet infrastructure, and tests a new model for supporting and maintaining its vital parts.
It has been known for some time that the authentication and security mechanisms used in Network Time Protocol (NTP) were aging, partly broken, and vulnerable to attack. Recently this concern has become reality through a string of serious security incidents involving NTP servers, in many of which the servers were exploited as amplifiers for DDoS (distributed denial of service) attacks.
An accurate common timebase is vitally important for a wide range of uses, from financial services to autonomous vehicular navigation. Accordingly, some months ago the Center for Trustworthy Scientific Cyberinfrastructure (CTSC) and Indiana University’s Center for Applied Cybersecurity Research (CACR) initiated rescue planning that included a range of individual experts on time service, senior NTP developers, and interested organizations such as the Network Time Foundation (NTF) the Internet Civil Engineering Institute (ICEI), and the National Science Foundation (NSF). The NSF approved seed funding for this work.
The rescue planning bore fruit in a detailed roadmap, beginning with breaking the NTP code base out of the proprietary BitKeeper revision control system into a Git repository, where it can benefit from regular examination and contributions by the wider community (this was not previously possible due to BitKeeper’s licensing requirements and logistical overhead).
NTF, which maintains the current reference NTP implementation, has declined to participate in these efforts to secure the NTP software. Thus, members of the NTP community have chosen to create a fork of that code base that will take advantage of and further iterate upon the remediation work funded by the NSF, CTSC, and CACR. The ongoing work is now substantially funded by the Linux Foundation’s Core Infrastructure Initiative (CII).
Thus, the NTP Security Project - familiarly, NTPsec. NTPsec will be a compatible upgrade from the NTF version, continuously evolved from that historical reference implementation.
As the project name indicates, NTPsec’s early focus will be on security improvements. We will also apply best practices in use of static-analysis tools, continuous integration, and automated testing. Down the road we plan deeper refactoring for security and simplicity, and to fully adapt the network time protocol to IPV6.
NTPsec begins with a core team of experienced and expert developers. You can read more about them on the Core Team page.
Have questions? Email us at<EMAIL_ADDRESS>or via IRC at Freenode channel #ntpsec.


[Gecode] Bug tracking?
Guido Tack
tack at ps.uni-sb.de
Wed May 19 17:00:30 CEST 2004
On Wed, 19 May 2004, Christian Schulte wrote:
> What should we do about that? Any proposals?
We could have a bugzilla here - we have a setup for Alice anyway.
Of course it might be a bit heavyweight, and the interface can be
confusing sometimes, but at least it seams to work. I saw that Mozart uses
"jitterbug", but I couldn't find any information on it, its web site seems
to be dead. Maybe Denys knows more about it?
Guido
--
Guido Tack
mailto:tack at ps.uni-sb.de
http://www.ps.uni-sb.de/~tack/
More information about the gecode-users
mailing list


Ccotact Us
This is a dummy paragraph.
Contact Us
Some Place Way
Some City
Some Postcode
Sales and Inquiries: (+##) #### ### ####
Call us Monday - Friday ##am to ##pm.
Saturday ##am - ##pm
About Us
Dummy Text


Core Banking API for Fintech Integration
backspace
Payment Reversal
Oops!! Want to cancel a transaction?? No issues.....Go ahead
Account Number
Transaction ID
Amount to be transfered
Send
send


{% include "header.html" %} {% include "intervention_form.html" %}
Use the form above to set the cost/benefit trade-off parameters of your project
Then compute the minimum performance characteristics a model will need in order to provide value.


---
layout: post
title: Inversion Count - SPOJ
date: 2015-04-11 17:41:27.000000000 +05:30
type: post
categories: algorithms
tags: [INVERSION COUNT, MERGE SORT, SPOJ INVCNT]
---
In the Question Inversion Count - INVCNT on spoj, you need to print the no. of inversion pairs. The question defines it as - "Let A[0...n - 1] be an array of n distinct positive integers. If i < j and A[i] > A[j] then the pair (i, j) is called an inversion of A".
So basically an inversion pair is the one in which if indices and the values have invert relation. ( if one is > the other is < ).
The first basic approach which comes to mind is simple Brute Force algo. That is selecting one element(let it be i th) in the array and then checking all the elements ( j index for that matter) after the selected element for the condition Arr[i]> Arr[j], if such pair occurs then count++. But time complexity of this approach is O(n2).
But submitting this solution will lead to TLE (time limit exceeded).
So we need to use some other algo, and the solution uses Merge Function in Merge Sort Algorithm.
Actually when we merge the two sorted array, while comparing elements we can perform the counting of inversion pairs. This can be done as : (for ascending order sorting) When the current element under consideration in right sub-array is smaller than current element under consideration in left sub-array the no of inversion pairs equals to the no. of all the elements after the current element in left sub-array (including itself), in each level of merge sort. Sum of all these pairs will be equal to inversion pairs.
This can be understood using following :
Here is the following pseudo-code :
{% highlight cpp linenos %}
#include
typedef long long int typex;
using namespace std;
long long int count,arr[200001];
void merge(typex p,typex q,typex r)
{
//first array has indices from p to q
//second array has indices from q to p
typex i,li,ri,n1,n2;
n1=q-p+1;
n2=r-q;
typex *lt= new typex [n1];
typex *rt= new typex [n2];//[q-(r+1)+1]
// HERE copy both the arrays in the newly dynamically allocated array.
//left and right array is ready which is all ready sorted
//now we will merge
//indices fr left copy and right copy respectively
li=ri=0;
i=p;//index for array being sorted
while(li< n1 && ri< n2)
{
if(lt[li]> rt[ri])
{
arr[i++]=rt[ri++];
count=count+n1-li;// MAIN STEP
}
else //right hand side elemnt is greater that is inversion pair
{
arr[i++]=lt[li++];
}
}
//inversion pairs have been counted till this stage, do not count again;
while(li


Normal select. The plugin will do single selection using radio buttons rather than multiple selection using checkboxes.
Select with preselected options: <option value="css" selected>CSS</option>
Multiselect with a 'Select all' option
Multiselect with a 'Select all' option and filtering enabled using the enableFiltering option.
The 'Select all' option automatically repsonds to the selection of the user. In particular, it responds to the initial state of the select.
Small button using buttonClass: 'btn btn-default btn-sm'.
Multiple select within a group with add-ons and default container for the plugin: buttonContainer: '<div class="btn-group" />'.
Using the onChange option you can add an event handler to the change event. The event handler gets the selected option as first parameter and a variable saying whether the option is checked or not as second one.
For long option lists the maxHeight option can be set.
The plugin supports disabled options, too: disabled="disabled"
Use the buttonWidth option to adjust the width of the button.
Using the onChange option to prevent user from deselecting selected options.
Option groups are detected automatically and for each option group an header element is added: <optgroup label="Mathematics">...</optgroup>
Option groups and options without any group are supported simultaneously.
Using the selectedClass option to turn off the active class for selected options.
Specifiy an alternaitve label for the options: <option label="label"></option>
Make the menu drop right instead of dropping left with dropRight.
Using the data-role="multiselect" attribute for automatic wireup.
The multiselect will adopt the state of the select: <select disabled></select>.
The button will keep the tabindex of the select.
Using optgroupss with filtering and the select all option.
Boxed Multiselect
Activates your content as a multiselect.
Select with preselected options: <option value="elem_3" selected>elem 3</option>
The event handler gets the selected option as first parameter and a variable saying whether the option is checked or not as second one.
Option groups are detected automatically and for each option group an header element is added
You can also deactivate option one by one by adding disabled attribute to each option you want to disable <option value='fuu' disabled='disabled'>bar</option>


| Book of Mormon |
Annotations |
|
An account of the death of Lehi. Nephi’s brethren rebel
against him. The Lord warns Nephi to depart into the wilderness. His
journeyings in the wilderness, and so forth.
|
|
|
Chapter 1
|
|
|
1 And now it came to pass that after I, Nephi, had made an
end of teaching my brethren, our father, Lehi, also spake many things unto
them, and rehearsed unto them, how great things the Lord had done for them in
bringing them out of the land of Jerusalem.
|
|
|
2 And he spake unto them concerning their rebellions upon
the waters, and the mercies of God in sparing their lives, that they were not
swallowed up in the sea.
|
|
|
3 And he also spake unto them concerning the land of
promise, which they had obtained—how merciful the Lord had been in warning us
that we should flee out of the land of Jerusalem.
|
|
|
4 For, behold, said he, I have seen a vision, in which I
know that Jerusalem is destroyed; and had we remained in Jerusalem we should
also have perished.
|
|
|
5 But, said he, notwithstanding our afflictions, we
have obtained a land of promise, a land which is choice above all other
lands; a land which the Lord God hath covenanted with me should be a land
for the inheritance of my seed. Yea, the Lord hath covenanted
this land unto me, and to my children forever, and also all those who should
be led out of other countries by the hand of the Lord.
|
This seems to make it quite clear that the seed of Lehi
are to be in the Americas “forever,” but as of now, there is absolutely no
evidence of any migration from the house of Israel to the Americas in this
time period.
|
|
6 Wherefore, I, Lehi, prophesy according to the workings
of the Spirit which is in me, that there shall none come into this land
save they shall be brought by the hand of the Lord.
|
Assuming this verse is true and that the Americas were
first populated by immigrants from Asia circa 13,000 to 15,000 years ago, we
would have to assume that God brought these ancient Asians to the Americas.
Edited to add: New evidence suggests there were humans in the Americas as
early as 23,000 years ago.
(see
Evidence of humans in North America during the Last Glacial Maximum)
|
|
7 Wherefore, this land is consecrated unto him whom he
shall bring. And if it so be that they shall serve him according to the
commandments which he hath given, it shall be a land of liberty unto them;
wherefore, they shall never be brought down into captivity; if so, it shall
be because of iniquity; for if iniquity shall abound cursed shall be the land
for their sakes, but unto the righteous it shall be blessed forever.
|
|
|
8 And behold, it is wisdom that this land should be
kept as yet from the knowledge of other nations; for behold, many nations
would overrun the land, that there would be no place for an inheritance.
|
Yet at this time, from what I can tell, there were already
millions of individuals living in the Americas.
|
|
9 Wherefore, I, Lehi, have obtained a promise, that
inasmuch as those whom the Lord God shall bring out of the land of Jerusalem
shall keep his commandments, they shall prosper upon the face of this land;
and they shall be kept from all other nations, that they may possess this
land unto themselves. And if it so be that they shall keep his
commandments they shall be blessed upon the face of this land, and there
shall be none to molest them, nor to take away the land of their inheritance;
and they shall dwell safely forever.
|
In “A Promised Land,” Elder Jeffrey Holland taught that
the global flood really happened, that shortly after the flood, the Americas
were separated from the rest of the world, and that,
“The promised place was set apart. Without habitation it
waited for the fulfillment of God’s special purposes.
With care and selectivity, the Lord began almost at once to repeople the promised
land. The Jaredites came first”
(“A Promised Land” by Jeffrey R. Holland).
So according to Elder Holland there was no one in the Americas when the
Jaredites arrived in maybe 2,000ish BCE. This is congruent with the language
used in this chapter.
However, this flies in the face of the evidence that the Americas were first
populated by immigration from Asia beginning about 13,000 or 15,000 years ago
and that the ancient ancestors of indigenous Americans came at least
predominantly (if not exclusively) from Asia. The evidence for this is
overwhelming. The evidence for any pre Columbian migration from the Middle
East to the America’s is non-existent.
Edited to add: New evidence suggests there were humans in the Americas as
early as 23,000 years ago.
(see
Evidence of humans in North America during the Last Glacial Maximum)
(See also 1 Ne 13:10)
|
|
10 But behold, when the time cometh that they shall
dwindle in unbelief, after they have received so great blessings from the
hand of the Lord—having a knowledge of the creation of the earth, and all
men, knowing the great and marvelous works of the Lord from the creation of
the world; having power given them to do all things by faith; having all the
commandments from the beginning, and having been brought by his infinite
goodness into this precious land of promise—behold, I say, if the day shall
come that they will reject the Holy One of Israel, the true Messiah, their
Redeemer and their God, behold, the judgments of him that is just shall
rest upon them.
|
2 Ne 1:10-11
Let’s put the time line together here.
- Lehites dwindled in unbelief circa 400 CE.
- They lived in the land fairly unperturbed for about 1,000 years or so.
- Then, after a millennium, they were decimated by plague and war and were scattered.
Would an all-loving God really punish a people of millions for dwindling in
unbelief even though the dwindling took place more than 1,000 years earlier,
so the people in question had no way of knowing anything about the God of
Abraham? What about “reproving betimes (early; quickly after the fact) with
sharpness” (D&C 121:43)? What about the references in the Book of Mormon
that tell us Christ’s “blood atoneth for the sins of those . . . who have
died not knowing the will of God concerning them, or who have ignorantly
sinned” (Mosiah 3:11 and Moroni 8:22-24)?
|
|
11 Yea, he will bring other nations unto them, and he will
give unto them power, and he will take away from them the lands of their
possessions, and he will cause them to be scattered and smitten.
|
Annotation for 2 Ne 1:10-11 above
|
|
12 Yea, as one generation passeth to another there shall
be bloodsheds, and great visitations among them; wherefore, my sons, I would
that ye would remember; yea, I would that ye would hearken unto my words.
|
|
|
13 O that ye would awake; awake from a deep sleep, yea,
even from the sleep of hell, and shake off the awful chains by which ye are
bound, which are the chains which bind the children of men, that they are
carried away captive down to the eternal gulf of misery and woe.
|
According to D&C 19:6-12 the words “endless” and
“eternal” do not mean without end when it comes to “endless torment” or
“eternal damnation”. These verses in the D&C explain that these words are
used because, “it is more express than other scriptures, that it might work
upon the hearts of the children of men.” When people read these words in the
Book of Mormon, how do they likely understand the words “endless” and
“eternal”? Is this honest communication if D&C 19 reveals the actual
meaning of these words?
|
|
14 Awake! and arise from the dust, and hear the words of a
trembling parent, whose limbs ye must soon lay down in the cold and silent
grave, from whence no traveler can return; a few more days and I go
the way of all the earth.
|
Some critics of the Book of Mormon believe that Joseph
borrowed the phrase, “from whence no traveler can return” from Shakespeare’s
“from whose bourn no traveler returns” (Hamlet Act III, Scene 1).
I stumbled across something I think just as likely. Seems the Freemasons may
have borrowed this from Shakespeare in this excerpt found in their second
degree or fellow craft ritual:
“Ever remembering that we are travelling upon that level of time, from whose
bourn no traveler returns”
(Illustrations of Masonry, by William Morgan, [1827]).
I think it’s just as likely that Joseph borrowed this from the Freemasons. He
was a Freemason, but I don’t think he became one until the 1840s.
P.S. The Freemasonry ritual at the link above is eerily similar in some ways
to the LDS temple endowment, especially the endowment version before the 1990
changes.
|
|
15 But behold, the Lord hath redeemed my soul from hell; I
have beheld his glory, and I am encircled about eternally in the arms of his
love.
|
|
|
16 And I desire that ye should remember to observe the
statutes and the judgments of the Lord; behold, this hath been the anxiety of
my soul from the beginning.
|
|
|
17 My heart hath been weighed down with sorrow from time
to time, for I have feared, lest for the hardness of your hearts the Lord
your God should come out in the fulness of his wrath upon you, that ye be cut
off and destroyed forever;
|
|
|
18 Or, that a cursing should come upon you for the space
of many generations; and ye are visited by sword, and by famine, and are
hated, and are led according to the will and captivity of the devil.
|
|
|
19 O my sons, that these things might not come upon you,
but that ye might be a choice and a favored people of the Lord. But behold,
his will be done; for his ways are righteousness forever.
|
|
|
20 And he hath said that: Inasmuch as ye shall keep my
commandments ye shall prosper in the land; but inasmuch as ye will not keep
my commandments ye shall be cut off from my presence.
|
|
|
21 And now that my soul might have joy in you, and that my
heart might leave this world with gladness because of you, that I might not
be brought down with grief and sorrow to the grave, arise from the dust, my
sons, and be men, and be determined in one mind and in one heart, united in
all things, that ye may not come down into captivity;
|
|
|
22 That ye may not be cursed with a sore cursing; and
also, that ye may not incur the displeasure of a just God upon you, unto the
destruction, yea, the eternal destruction of both soul and body.
|
According to D&C 19:6-12 the words “endless” and
“eternal” do not mean without end when it comes to “endless torment” or
“eternal damnation”. These verses in the D&C explain that these words are
used because, “it is more express than other scriptures, that it might work
upon the hearts of the children of men.” When people read these words in the
Book of Mormon, how do they likely understand the words “endless” and
“eternal”? Is this honest communication if D&C 19 reveals the actual
meaning of these words?
|
|
23 Awake, my sons; put on the armor of righteousness.
Shake off the chains with which ye are bound, and come forth out of
obscurity, and arise from the dust.
|
|
|
24 Rebel no more against your brother, whose views have
been glorious, and who hath kept the commandments from the time that we left
Jerusalem; and who hath been an instrument in the hands of God, in bringing
us forth into the land of promise; for were it not for him, we must have
perished with hunger in the wilderness; nevertheless, ye sought to take away his
life; yea, and he hath suffered much sorrow because of you.
|
|
|
25 And I exceedingly fear and tremble because of you, lest
he shall suffer again; for behold, ye have accused him that he sought power
and authority over you; but I know that he hath not sought for power nor
authority over you, but he hath sought the glory of God, and your own eternal
welfare.
|
|
|
26 And ye have murmured because he hath been plain unto
you. Ye say that he hath used sharpness; ye say that he hath been angry with
you; but behold, his sharpness was the sharpness of the power of the word of
God, which was in him; and that which ye call anger was the truth, according
to that which is in God, which he could not restrain, manifesting boldly
concerning your iniquities.
|
|
|
27 And it must needs be that the power of God must be with
him, even unto his commanding you that ye must obey. But behold, it was not
he, but it was the Spirit of the Lord which was in him, which opened his
mouth to utterance that he could not shut it.
|
|
|
28 And now my son, Laman, and also Lemuel and Sam, and
also my sons who are the sons of Ishmael, behold, if ye will hearken unto the
voice of Nephi ye shall not perish. And if ye will hearken unto him I leave
unto you a blessing, yea, even my first blessing.
|
|
|
29 But if ye will not hearken unto him I take away my
first blessing, yea, even my blessing, and it shall rest upon him.
|
|
|
30 And now, Zoram, I speak unto you: Behold, thou art the
servant of Laban; nevertheless, thou hast been brought out of the land of
Jerusalem, and I know that thou art a true friend unto my son, Nephi,
forever.
|
|
|
31 Wherefore, because thou hast been faithful thy seed
shall be blessed with his seed, that they dwell in prosperity long upon the
face of this land; and nothing, save it shall be iniquity among them, shall
harm or disturb their prosperity upon the face of this land forever.
|
|
|
32 Wherefore, if ye shall keep the commandments of the
Lord, the Lord hath consecrated this land for the security of thy seed with
the seed of my son.
|
|


FORGOTTEN SILVER A film review by James Berardinelli Copyright 1997 James Berardinelli
RATING (0 TO 10): 8.5 Alternative Scale: ***1/2 out of ****
New Zealand, 1995 U.S. Release Date: Not known Running Length: 0:52 MPAA Classification: No MPAA Rating (Mature themes, brief nudity) Theatrical Aspect Ratio: 1.85:1 Shown at the Philadelphia Festival of World Cinema, 5/6/97 & 5/9/97
Cast: Jeffrey Thomas (narrator), Peter Jackson, Costa Botes, Sam Neill, Leonard Maltin, Harvey Weinstein, John O'Shea, Linday Shelton Directors: Peter Jackson and Costa Botes Producer: Sue Rogers Screenplay: Peter Jackson and Costa Botes Cinematography: Alun Bollinger, Gerry Vasbenter Music: David Donaldson, Steve Roche, Janet Roddick U.S. Distributor: First Run Features
With some "mockumentaries" (or "meta-documentaries", "pseudo- documentaries", or whatever else you want to call them), it's best not to know beforehand that they're fakes. The opposite is true of FORGOTTEN SILVER, an inventive and wily project made for New Zealand television by film makers Peter Jackson and Costa Botes. With this film, if you don't know in advance that it isn't a real documentary, you'll almost certainly be bamboozled, and, in the process, miss some of the most subtle humor. Taken at face value, FORGOTTEN SILVER is mildly entertaining, but, for those who recognize its true nature, it's nothing short of brilliant.
Jeffrey Thomas, a man with an appropriately stentorian voice, does the narration for FORGOTTEN SILVER, which is presented as a straightforward documentary about an all-but-forgotten, turn-of-the- century New Zealand film maker. The contributions of this pioneer, named Colin McKenzie, were only recently recognized when his complete body of work was discovered. His achievements included inventing the first mechanized camera, making the first full-length feature film with sound (in 1908 -- it was a failure because all of the actors spoke Chinese and he didn't have the foresight to invent subtitles), experimenting with color (in 1911 -- he was arrested on smut charges because a topless woman appeared in the test film), and introducing the closeup.
To add to FORGOTTEN SILVER's verisimilitude, various expert talking heads are called upon to provide commentary. Movie critic/historian Leonard Maltin gushes about the scope and quality of McKenzie's work. Miramax honcho Harvey Weinstein calls the unearthing of McKenzie's footage as "the greatest film discovery of the last fifty years" (then reveals that his company will distribute the previously-unseen epic SALOME with an hour edited out). Actor Sam Neill comments about the importance of the McKenzie revelations to the New Zealand film industry. And directors Jackson and Botes mount an expedition to go deep into the New Zealand bush in search of the legendary lost site where McKenzie filmed SALOME.
Using subtle special effects to re-create old, damaged footage, FORGOTTEN SILVER makes it easy to believe that we're seeing celluloid that has been stored in a shed for fifty years. Not only are we treated to glimpses of McKenzie's pioneering efforts in cinema, but we're shown significant chunks of SALOME, a credible-looking silent presentation of the Biblical tale about the dancing girl who demanded John the Baptist's head. While the film makers have crafted FORGOTTEN SILVER as a first- rate parody, it's clear that both men possess a great deal of affection for and knowledge about the early history of cinema.
This is the sort of project one might expect from Peter Jackson, the inventive director whose previous outings have included the brilliant HEAVENLY CREATURES, the outrageously sick MEET THE FEEBLES, and the big-budget, offbeat comedy, THE FRIGHTENERS. Along with co- director Costa Botes, Jackson has put together one of the most interesting fake documentaries to come along since the genre was first popularized with THIS IS SPINAL TAP. The more you love film and understand film history, the more you'll get out of this picture, but even the most oblivious movie-goers will find FORGOTTEN SILVER's mixture of fact and fiction enjoyable.
When this movie was shown on New Zealand TV, it's impact was akin to that of Orson Welles' legendary Halloween radio broadcast of WAR OF THE WORLDS. Suddenly, men and women across New Zealand thought they had a new national hero. This simple fact shouldn't be taken as an indication of New Zealanders' gullibility, but of the effectiveness of FORGOTTEN SILVER. Watch it carefully, and you'll be amused, amazed, and entertained.
- James Berardinelli e-mail<EMAIL_ADDRESS>ReelViews web site: http://www.cybernex.net/~berardin
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews