How to Create a Real-Time Binary Counter

This Instructable introduces the behavior of the GreenPAK™ Real-Time Counter (RTC) and outlines a couple of common design applications in which the RTC provides added configurability to circuit designers. The RTC macrocell serves as a 47-bit binary counter for lengthy timing applications but can also be modified to work as a 32-bit counter for creating shorter periodic signals. All register information and RTC specifications contained within this document reference the SLG46580/SLG46582/SLG46583 specifically, but the principles can be applied to other GreenPAK-based RTCs.

The RTC is comprised of the 15-bit and 32-bit counters shown in Figure 1 and Figure 2. By analyzing the datasheet’s macrocell diagram in Figure 2, we can learn more about the configuration registers for this block as well as the associated matrix connections.

This block’s operation centers around the 32-bit time counter and the 32-bit alarm DCMP illustrated in Figure 2. The operation is simple: for every rising edge of its clock, the count value held within the time counter registers increments by one until it reaches 232-1. Upon reaching this value, the next clock signal causes the counter to “overflow” to zero and restart its count. When the registers of the time counter match the alarm DCMP registers, the “RTC DCMP Out” signal will go high. The RTC block operates in the 32-bit configuration as described above when the RTC’s 32-bit counter is clocked, through mux selection, by the “RTC Clock” matrix output.

Please note that the RTC’s clock input should have an active high pulse width exceeding 1 µs. Assuming a 50% duty cycle, this specification allows for input clock frequencies that are less than or equal to 500 kHz.

Looking back at Figure 2, we see the inclusion of another 15-bit counter within the RTC macrocell. This counter’s output, when selected by the mux as the 32-bit time counter’s clock, becomes the 15 least significant bits (LSBs) of a 47-bit counter configuration. The 15-bit counter overflows at 215-1 in the same way as previously described for the 32-bit counter. When the 15-bit counter overflows to “0”, the 15-bit counter clocks the 32-bit counter and the RTC block outputs a “1” into the matrix through “RTC CNT DIV Out.”

A key feature of the 15-bit counter is that it pairs well with a 32.768 kHz crystal oscillator. By selecting “32767” for the “Init. counter divider data” section of the RTC property window, the user can create 1-second pulses to clock the 32-bit time counter. This trivializes the process of creating arbitrary timing signals with the RTC block as you can simply calculate the desired delay in seconds and set the “Alarm DCMP value:” registers accordingly.

If you take another look at Figure 1 and Figure 2, you can see a matrix output named “SYNC” that connects to what we call the “Shadow Buffer.” This 48-bit buffer can be used to both read from and write to the 15-bit and 32-bit counters. Figure 3 shows the register contents for this shadow buffer which are located at the I2C addresses from 0x75 to 0x7 A.

Register <989> controls the direction of the shadow buffer data transfer. When triggered by a rising edge of “SYNC,” a digital “1” configures the RTC block to load the counter registers with the data stored inside the shadow buffer. Alternatively, a digital “0” in register <989> stores the current count value of each of the counters in the shadow buffer registers.

These register transfers are synchronized to one of two sources selected by register <990>: a rising edge on the “SYNC” matrix output as previously described or an I2C trigger signal. A digital “0” selects the “SYNC” trigger and vice versa. The I2C trigger signal is generated internally by reading (when register <989> is “0”) or writing (when register <989> is “1”) to any of the shadow buffer register addresses.

The shadow register guarantees a stable I2C read from the RTC count registers when triggered via I2C. If you were to perform an I2C read on the counter registers directly, the register contents might increment during the read time, resulting in an incorrect I2C read. By copying the register contents into the shadow buffer, the GreenPAK allows the RTC counters to continue operating while the user reads the shadow buffer registers.

For “SYNC” triggering and I2C writing to the counter registers, we recommend stopping the RTC’s clock to ensure correct data transfer. Please see the SLG46580/82/83 errata files for more information.

To create a periodic signal with the RTC block, the designer needs to configure the RTC block to reset each time the 32-bit count matches the alarm DCMP registers. When not using I2C, resetting the counter requires the use of the “SYNC” input to transfer an initial count value from the shadow buffer to the 15-bit and 32-bit counters.

By feeding the “RTC DCMP OUT” signal to the “SYNC” input as shown in Figure 4, you can create the 5-second clock pulse shown in Figure 6. Please note that this signal is generated using an external 32.768 kHz oscillator. This clock period can be modified for various applications by changing the external clock speed or the Alarm DCMP value displayed in Figure 5.

On occasion, a designer might want to perform an I2C read to check the current count of their periodic signal. This requires the user to follow a procedure as shown below:

– Follow the previously outlined procedure for generating periodic signals.

– Initialize read mode for the RTC block by changing reg <989> to “0”.

– Change the trigger from “SYNC” to the I2C trigger by setting reg<990> to “1”.

– Perform the I2C read of the desired addresses.

– Revert the trigger back to “SYNC” by setting reg <990> to “0”.

– Reset the contents of the shadow buffer to the default values.

– Set the RTC block to write mode by changing reg <989> to “1”.

Following these steps should enable you to read the register contents of the RTC while generating a periodic signal. It is important to note that the feedback mechanism is disrupted during I2C reads. If the time counter registers increment above the alarm DCMP registers during an I2C read, the “SYNC” input’s rising edge won’t trigger a counter reset. This behavior can be detected and rectified by analyzing the results of each I2C read. If any read is close to the alarm DCMP compare value and there isn’t enough time to reset the device’s settings back to its original periodic behavior, the software can manually generate the I2C commands to trigger the RTC reset.

The features explained in this Instrutable can be customized for many different applications ranging from Bluetooth beacons to household electronics. You might have a temperature sensor, for example, that you want to wake up every hour to sample data. Similarly, you might want to put a Bluetooth beacon to sleep to conserve power. This block can periodically wake up the Bluetooth device to transmit its presence to nearby Bluetooth-compatible devices.

This block can also keep track of the life expectancy for various electronic devices. For example, many smoke detectors and carbon monoxide alarms have a lifespan of about 10 years. This block provides designers with a simple, configurable, and low power timing solution for alerting homeowners of the need to replace their devices.

When clocked at 3.3 V by a 32.768 kHz oscillator, the use of the RTC block increases the SLG46580/82/83’s current consumption by about 250 nA. Please note that this value doesn’t include the current consumption due to the clock source and GPIO switching, if applicable. For additional information regarding the creation of an external oscillator circuit using GreenPAK, please see AN-CM-233.

Conclusion

The RTC block provides a low power and cost-effective timing solution for designers to create both extended signals and short periodic alerts. When combined with the other GreenPAK logic elements, this block provides increased configurability to designers as they attempt to minimize current consumption, decrease PCB size, and reduce BOM costs for their applications.