Last week we introduced a new version of the Bus Pirate universal serial interface tool. The last firmware update included an AT keyboard decoder library for both hardware versions.

There’s a ton of old AT keyboards making their way to the landfill. We’ll show you how to recycle one as an input device for your next project.

Connection

AT keyboards communicate over a bidirectional two-wire interface. The bus is open collector, but keyboards already have internal pull-up resistors. The PC AT keyboard protocol is described here. We used our Bus Pirate tool to demonstrate the keyboard protocol, but the same basic principals apply to any microcontroller.

We connected the Bus Pirate to the keyboard as outlined in the table. We believe that this is a through-hole female AT keyboard jack, but we haven’t tested it. Do you know of a source for new sockets?

Protocol

The keyboard provides the clock signal for all data transfers; the PC side resembles a slave device. None of the existing Bus Pirate interface libraries work with an external clock, so we wrote a simple AT keyboard decoder library. The library depends on the keyboard’s clock signal, and it’ll hang if the keyboard fails or isn’t connected. If you use our library in your own project, consider adding a timeout delay in the readbit() and writebit() functions.

PC to keyboard command codes

A PC uses these commands to control various functions of an AT keyboard. The keyboard responds to commands with an acknowledge byte (oxfa). In our experience, the keyboard will reset if the response byte is not read shortly after the command is sent.

Keyboard to PC response codes

The keyboard has a number of single byte response codes.  Most PC commands are acknowledged with 0xfa. 0xaa is sent after a keyboard reset.

Setup the Bus Pirate

HiZ>m
1. HiZ
…
9. PC AT KEYBOARD
MODE>9 <–set mode
900 MODE SET
X02 PC AT KB DECODER READY
PC AT KEYBOARD>

First, we setup the the Bus Pirate for AT keyboard mode, option 9.

PC AT KEYBOARD>p <–power supply setup
W/w toggles 3.3volt supply?
1. NO
2. YES
MODE>1 <–no 3.3volt supply
W/w toggles 5volt supply?
1. NO
2. YES
MODE>2 <–use the 5volt supply
9xx SUPPLY CONFIGURED, USE W/w TO TOGGLE
9xx VOLTAGE MONITOR: 5V: 0.0 | 3.3V: 0.0 | VPULLUP: 0.0 |
PC AT KEYBOARD>W <–capital ‘W’, turn supply on
9xx 5VOLT SUPPLY ON
PC AT KEYBOARD>

Next, we configure the Bus Pirate’s power supply to provide 5volts for the AT keyboard.

PC AT KEYBOARD>r <–read byte from keyboard
x30 PCATKB READ:  NONE <–no data available
PC AT KEYBOARD>

The AT keyboard library follows the standard Bus Pirate syntax. Numeric values are sent to the keyboard as bytes, ‘r’ reads a byte from the keyboard. The protocol is clocked by the keyboard so bitwise operations are disabled.  If no data is available, the read will return ‘NONE’.

Setup the keyboard

PC AT KEYBOARD>0xee r <–send 0xee, read one byte
X20 PCATKB WRITE: 0xEE GOT ACK <–write oxee, got ack bit
x30 PCATKB READ: 0xEE <–read 0xee, echo was successful
PC AT KEYBOARD>

We can test the connection to the AT keyboard using the echo command, 0xee. The keyboard will respond 0xee if our connections are correct.

The keyboard responds to commands with an ACK bit at the protocol level, and then again with an ACK byte. We found that our test keyboards reset automatically if the ACK byte wasn’t read immediately after sending the command.

PC AT KEYBOARD>0xee <–echo command
X20 PCATKB WRITE: 0xEE GOT ACK <–wrote echo, got ACK
PC AT KEYBOARD>r <–read one byte
x30 PCATKB READ: 0xAA <–read 0xaa, reset indicator
PC AT KEYBOARD>

Here, we tried to send the echo command and then read the reply later. The keyboard reset automatically and replies 0xaa, self-test passed.

PC AT KEYBOARD>0xff r r <–reset command, read two bytes
X20 PCATKB WRITE: 0xFF GOT ACK <–write reset command, got ACK
x30 PCATKB READ: 0xFA <–command ACK byte
x30 PCATKB READ:  NONE <–read once more to reset
PC AT KEYBOARD>

The keyboard is reset by writing the command 0xff, and reading two bytes. The Keyboard won’t reset until the second byte is read.

PC AT KEYBOARD>r <–read a byte
x30 PCATKB READ: 0xAA <–reset success
PC AT KEYBOARD>

A short period after reset we can read the power on self test (POST) results, 0xaa indicates POST success.

PC AT KEYBOARD>0xf5 r <–disable the keyboard
X20 PCATKB WRITE: 0xF5 GOT ACK <–wrote command
x30 PCATKB READ: 0xFA <–read ACK byte
PC AT KEYBOARD>0xf4 r <–enable keyboard
X20 PCATKB WRITE: 0xF4 GOT ACK <–wrote command
x30 PCATKB READ: 0xFA <–read ACK byte
PC AT KEYBOARD>

0xf5 disables keyboard input. 0xf4 enables the keyboard and clears the buffer.

PC AT KEYBOARD>0xed r 0b111 r <–set indicator LEDs
X20 PCATKB WRITE: 0xED GOT ACK <–set LED command
x30 PCATKB READ: 0xFA <–command acknowledged
X20 PCATKB WRITE: 0×07 GOT ACK <–send LED value
x30 PCATKB READ: 0xFA <–value acknowledged
PC AT KEYBOARD>

The num, caps, and scroll lock LEDs are controlled by the 0xed command. The last three bits of a second byte (ob111) indicate which LEDs to light. It’s very important to perform all four byte operations within the keyboard timeout period, or the keyboard will reset.

PC AT KEYBOARD>0xee r <–echo test command
X20 PCATKB WRITE: 0xEE GOT ACK
x30 PCATKB READ: 0xEE
PC AT KEYBOARD>0xfe r <–repeat last byte command
X20 PCATKB WRITE: 0xFE GOT ACK <–write repeat command
x30 PCATKB READ: 0xEE <–previous byte is repeated
PC AT KEYBOARD>

The last interesting keyboard command is the repeat byte command. 0xfe causes the keyboard to send the last byte again. This is a useful command if there was a error in the previous transmission.

Read key presses

Key presses are buffered by the keyboard until we read them.

PC AT KEYBOARD>r <–read byte
x30 PCATKB READ: 0×29 <–space scancode
PC AT KEYBOARD>r <–read byte
x30 PCATKB READ: 0xF0 <–key release scancode
PC AT KEYBOARD>r <–read byte
x30 PCATKB READ: 0×29<–space scancode
PC AT KEYBOARD>

A key press sends scancodes, multi-byte sequences that represent the key presses. In the example, we pressed space which has the scancode 0×29. When a key is released, the keyboard sends 0xf0 and the scancode for the key (0×29). Each key press results in a similar three part sequence.

PC AT KEYBOARD>r:4 <–read 4 bytes
x31 PCATKB BULK READ, 0×04 BYTES:
0×29  0xF0  0×29   NONE <–space scancode
PC AT KEYBOARD>

This is just a simplified version of the previous example. Rather than read three bytes individually, we used the bulk read command. Again, we get the space scancode sequence. Our attempt to read a non-existant fourth byte fails.

Sensirion’s SHTxx is a digitally interfaced humidity and temperature sensor. Accurate humidity measurements usually require careful analog design, but the SHTxx moves all that complicated stuff into a single chip. Through-hole (SHT7x) and surface mount (SHT1x) versions are available, we used the surface mount SHT11 with +/-3% accuracy. We’ll show you how to use the SHTxx below.

Sensirion SHT1x/SHT7x precision humidity and temperature sensor (Octopart search, starting at $25).

This isn’t a cheap sensor. Octopart lists a few places to buy it. Several smaller hobby electronics stores carry it; Hobby Engineering has it for $29 (#H01509-01C). We found compatible PCB footprints in sht10_11_15.lbr and sht11.lbr on the Cadsoft library download page. Pin connections for the different package types are in the datasheet: SHT1x (PDF), SHT7x (PDF).

The SHTxx has a two-wire serial interface that requires pull-up resistors (R1,2), values between 2K and 10K should work. Sensirion recommends a decoupling capacitor (C1) only if the sensor is powered over a length of wire, but we think it’s always a good idea to include one.

We’ll demonstrate the SHTxx using the Bus Pirate universal serial interface in raw2wire mode with Hi-Z outputs. The SHTxx is powered from the Bus Pirate’s 3.3volt supply. The Bus Pirate’s on-board pull-up resistors hold the bus high, eliminating the need for external resistors R1 and R2.

Interface

The SHTxx communicates over two wires using a simple serial protocol. The protocol isn’t compatible with I2C, but a single SHTxx can exist on a bus with I2C peripherals.

Five commands control the SHTxx, these are outlined in the table. The first 3 bits are the address (always 000), the remaining 5 bits are a unique command code.

Reset

Start a transaction by clearing any partial commands or data from a previous use. A minimum of nine clock ticks while data is high will clear the SHTxx interface. The Bus Pirate syntax to for this is -^:9; data high (-), 9 clock ticks (^:9).

Commands to the SHT11 begin with a unique start condition. Like an I2C start condition, this is the only time when the data signal changes with the clock signal high. This illegal condition causes the chip to prepare for a new command. The SHTxx start condition is different than I2C, allowing both types of devices to exist on the same bus.

The Bus Pirate code to generate an SHTxx style start condition is -/_\/-\ ; data starts high (-), clock up (/), data goes low (_), clock low (\), clock high (/), data goes high (-), and a final clock low transition (\) ends the sequence.

A soft reset is a good idea because it puts the chip in a default state. Prior to the first temperature or humidity conversion, we send the soft reset command.

RAW2WIRE>-^:9 -/_\/-\ 0b00011110 !<–command
4xx RAW2WIRE DATA OUTPUT, 1 <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
4xx RAW2WIRE CLOCK, 1
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE CLOCK, 0
4xx RAW2WIRE CLOCK, 1
4xx RAW2WIRE DATA OUTPUT, 1
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0x1E <–soft reset code
4xx RAW2WIRE READ BIT: 0 <–acknowledge bit, OK
RAW2WIRE>

First, we clear the interface (-^:9), then send the start condition (-/_\/-\). The reset command (0b00011110=0x1E) follows. The SHTxx acknowledges (acks) commands by pulling the data line low for one bit after a command is transmitted. We read one bit (!) to get the acknowledgment status; 0 is success, 1 signals an error.

Temperature

Now we can read the temperature. This happens in two steps, with a delay for the temperature conversion.

RAW2WIRE>-^:9 -/_\/-\ 0b00000011 !
4xx RAW2WIRE DATA OUTPUT, 1  <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
…
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0×03 <–start temperature conversion
4xx RAW2WIRE READ BIT: 0 <–ack bit, OK
RAW2WIRE>

First, we send a start condition and the temperature conversion command (00000011=0×03). The SHTxx replies to a successful command by pulling the data line low for one bit (ack). After the ack bit, the data line goes high until the conversion finishes.

RAW2WIRE>.
4xx RAW2WIRE DATA INPUT, STATE: 0 <–data low when done
RAW2WIRE>

When the data line goes low, the temperature conversion is finished. ‘.’ is the Bus Pirate command to read the data state without a clock tick. Now we can grab the result.

RAW2WIRE>r_^ r_^ r_^
430 RAW2WIRE READ: 0×17 <–data byte 1
4xx RAW2WIRE DATA OUTPUT, 0 <–data low
4xx RAW2WIRE 0×01 CLOCK TICKS <–send ack bit
430 RAW2WIRE READ: 0xCC <–data byte 2
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
430 RAW2WIRE READ: 0x0C <–crc
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
RAW2WIRE>

Each byte read (r) requires an I2C style acknowledgment bit with the data low. We do this with the _^ sequence; data low (_), one clock tick (^).

The first two bytes are the temperature reading (0x17cc), followed by a CRC (0x0c). The raw value (0x17cc=6092) is converted to degrees Celsius using the equation and coefficients on page 9 of the datasheet. Temperature readings are 14bits by default:

T = -39.7 + 0.01*X

21.22C = -39.7 + (0.01*6092)

Humidity

Humidity conversions are started with code 00000101 (0×05 hex).

RAW2WIRE>-^:9 -/_\/-\ 0b00000101 ! <–command
4xx RAW2WIRE DATA OUTPUT, 1 <–clear interface
4xx RAW2WIRE 0×09 CLOCK TICKS
4xx RAW2WIRE DATA OUTPUT, 1 <–start condition
…
4xx RAW2WIRE CLOCK, 0
420 RAW2WIRE WRITE: 0×05 <–start humidity conversion
4xx RAW2WIRE READ BIT: 0<–ack bit, OK

As before, a ninth acknowledgment bit is low if the SHTxx processed the command.

RAW2WIRE>.
4xx RAW2WIRE DATA INPUT, STATE: 0 <–data low when done

The data line goes high and then returns low when the humidity conversion is done.

RAW2WIRE>r_^ r_^ r_^
430 RAW2WIRE READ: 0×05 <–data byte 1
4xx RAW2WIRE DATA OUTPUT, 0 <–data low
4xx RAW2WIRE 0×01 CLOCK TICKS <–ack bit
430 RAW2WIRE READ: 0×80 <–data byte 2
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
430 RAW2WIRE READ: 0×46 <–crc
4xx RAW2WIRE DATA OUTPUT, 0
4xx RAW2WIRE 0×01 CLOCK TICKS
RAW2WIRE>

A complete conversion generates a three byte response. The first two bytes are the raw humidity reading (0×0580=1408), the final byte is a CRC (0×46) that can be used to verify data integrity.

Humidity readings have 12bits of resolution by default, convert to humidity using this equation:

RH = -2.0468 + 0.0367(X) + (-0.0000015955*(X^2))

46.46%RH = -2.0468 + 0.0367(1408) + (-0.0000015955*(1408^2))

Conclusion

This isn’t a cheap sensor, but it doesn’t require careful analog design like the Honeywell HIH series. Have you worked with a humidity sensor?

Like this post? Check out the parts posts you may have missed.

The Maxim DS2431 1K EEPROM is 1-Wire device that adds storage to a project using a single microcontroller pin. We previously interfaced a 1-wire thermometer, but this EEPROM is slightly different because it draws power directly from the 1-Wire bus. Grab the datasheet (PDF) and follow along while we read and write this simple 1-Wire memory.

DS2431 1-Wire 1K EEPROM (Digikey #DS2431+-ND, $1.67)

We used our Bus Pirate universal serial interface to demonstrate the DS2431 EEPROM, we covered the proper connections and configuration options in our previous 1-wire post. The DS2431 requires just two connections: ground (pin 1) and 1-Wire/power (pin 2).  Pin 3 remains unconnected. Like last time, we used a 2K pull-up resistor with the 1-Wire bus.

First, we use the Bus Pirate’s SEARCH ROM command to identify connected 1-Wire devices.

1-WIRE>(240) <–SEARCH ROM command macro
1WIRE ROM COMMAND: SEARCH (0xF0)
Found devices at:
Macro     1-WIRE address
1.0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B <–address
*DS2431 1K EEPROM <– type
2.0x2D 0xFE 0x8D 0×43 0×01 0×00 0×00 0×52
*DS2431 1K EEPROM
3.0x2D 0x2B 0xED 0xEF 0×00 0×00 0×00 0x7C
*DS2431 1K EEPROM
Found 0×03 devices.
The first 10 device IDs are available by MACRO, see (0).
1-WIRE>

The SEARCH ROM command reveals that there are 3 EEPROMs connected to the 1-Wire bus. The Bus Pirate stores the 64bit 1-wire addresses in macros so we don’t have to type it every time. We’ll work with the first device, identified by macro (1).

Writing to the DS2431 takes three steps:

• Write data to DS2431′s 8byte ‘scratch pad’ EEPROM buffer
• Verify the scratch pad contents and get the write access key
• Copy data from the scratch pad to the EEPROM for permanent storage.

Command 0x0f writes to the scratch pad. The scratch pad is an 8byte buffer that holds data prior to saving it permanently in the EEPROM.

1-WIRE>(85)(1) 0x0f 0×00 0×00 0 1 2 3 4 5 6 7 <–command
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0x0F <–write to scratch pad
1WIRE WRITE: 0×00 <–begin address byte 1
1WIRE WRITE: 0×00 <–begin address byte 2
1WIRE WRITE: 0×00 <–data
1WIRE WRITE: 0×01
1WIRE WRITE: 0×02
1WIRE WRITE: 0×03
1WIRE WRITE: 0×04
1WIRE WRITE: 0×05
1WIRE WRITE: 0×06
1WIRE WRITE: 0×07
1-WIRE>

The MATCH ROM macro, (85), isolates the the first device, (1). 0x0f is the command to write to the scratch pad, followed by the start address, 0 0. Finally, we send eight bytes of data to save in the scratch pad. The scratch pad is eight bytes long, and all eight bytes will be copied from the scratch pad to the EEPROM at once.

1-WIRE>(85)(1) 0xaa r:3 r:8 r:2 r:2 <–command
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0xAA <–read scratch pad
1WIRE BULK READ, 0×03 BYTES: <–access code
0×00 0×00 0×07
1WIRE BULK READ, 0×08 BYTES:<–verify our data
0×00 0×01 0×02 0×03 0×04 0×05 0×06 0×07
1WIRE BULK READ, 0×02 BYTES:<–inverse CRC
0×44 0×67
1WIRE BULK READ, 0×02 BYTES:<–all 1s from here
0xFF 0xFF
1-WIRE>

To copy data from the scratch pad to the EEPROM, we must first retrieve a three byte access code from the scratch pad with the command 0xaa.  The first three bytes are the access code (0×00 0×00 0×07), followed by the data contained in the scratch pad.

1-WIRE>(85)(1) 0×55 0×00 0×00 0×07
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0×55 <–copy to EEPROM command
1WIRE WRITE: 0×00<–access code (3 bytes)
1WIRE WRITE: 0×00
1WIRE WRITE: 0×07
1-WIRE>!!!! <–read bits
1WIRE READ BIT: 0
1WIRE READ BIT: 1 <–bits alternate, done
1WIRE READ BIT: 0
1WIRE READ BIT: 1
1-WIRE>

Command 0×55 with the correct access code will copy the scratch pad to the data EEPROM. Bit reads (!!!!) alternate between 0 and 1 when the copy completes.

1-WIRE>(85)(1) 0xf0 0×00 0×00 r:8 r:8
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0xF0 <–read memory
1WIRE WRITE: 0×00 <–start address (2 bytes)
1WIRE WRITE: 0×00
1WIRE BULK READ, 0×08 BYTES: <–read back data
0×00 0×01 0×02 0×03 0×04 0×05 0×06 0×07
1WIRE BULK READ, 0×08 BYTES: <–read beyond our data
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
1-WIRE>

Command 0xf0 followed by a two byte memory address (0×00 0×00) begins the data read process. The first eight bytes (r:8) are the values we wrote earlier. Reads don’t involve the scratch pad and don’t have an 8byte limit, so further reads continue to the end of the memory.

Don’t forget to catch up on any parts posts you may have missed.

The DS1077 is a 5volt, 133MHz to 16kHz programmable clock source. The internal frequency divider is configured over a simple I2C interface, and the chip requires no external parts. Not bad for under $2. We used the Bus Pirate to test this chip before using it in a project. Grab the datasheet (PDF) and follow along.

DS1077, $1.69 direct from Maxim + $10 shipping.

This chip isn’t available at any major distributors yet, but Maxim has them for under $2/each with a flat $10 shipping charge. This is an 8pin SOIC surface mount chip, so we made a small breakout board for testing.

Test circuit

Pin connections

We powered the DS1077 from the Bus Pirate’s 5volt power supply. Two resistors, R1 and R2, pull-up the I2C bus to 5volts when it’s not in use. Capacitor C1 is 0.01uF and C2 is 0.1uF, as recommended by the datasheet. Control pins provide some additional functions, but we bypassed them to ground during our test. Output1 is the primary clock signal pin.

Interfacing

We put the Bus Pirate into I2C mode (M, options: I2C, 100kHz). The external pull-up resistors hold the bus at 5volts, so it’s important to leave the on-board 3.3volt pull-up resistors off (default).

I2C>{0b10110000} <– DS1077 write address
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES <– got ACK
240 I2C STOP CONDITION
I2C>

First, we broadcast the DS1077′s address and see if it acknowledges. The address of the DS1077 is 1011, plus three programmable bits (000 by default), and the read (1) or write (0) bit. We got an ACK, so we know that the circuit is working and our connections are good.

The DS1077 is controlled by writing values to the locations shown in the table.

I2C>{0xb0 0x0d 0b00001000} , <–write to BUS register
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES <–DS1077 write address
220 I2C WRITE: 0x0D GOT ACK: YES <– BUS register
220 I2C WRITE: 0×08 GOT ACK: YES <– BUS register setting
240 I2C STOP CONDITION
I2C>

By default, the DS1077 saves all changes to the EEPROM. We don’t need this during testing, so we disable it by setting bit 3 (0b1000) of the BUS register (0x0d). The first four bits must be left as 0, the last three bits select the address to accommodate multiple DS1077s on the same I2C bus. See datasheet page 7.

I2C>{0xb0 0×02 0b00011000 0b00000000} <–set the 16bit MUX value
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES <–DS1077 write address
220 I2C WRITE: 0×02 GOT ACK: YES <–MUX register
220 I2C WRITE: 0×18 GOT ACK: YES <–data byte 1
220 I2C WRITE: 0×00 GOT ACK: YES <–data byte 2
240 I2C STOP CONDITION
I2C>

The MUX register controls the prescalers, CTRL pin functions, and frequency divider.  We disable the prescaler and CTRL pins, and enable the 10bit frequency divider.  The MUX register is explained on page 5 of the datasheet.

Specific frequencies are generated by dividing the 133MHz reference frequency through the prescalers and a 10bit (1025 level) programmable divider.  The clock is divided by the amount specified in the DIV register, plus two. When DIV=0, the output is 133MHz/2=66MHz.

This scheme gives the best frequency resolution in low ranges, and no steps between 133MHz and 66MHz.

I2C>{0xb0 1 0b11111111 0b11000000} <–DIV=1025
210 I2C START CONDITION
220 I2C WRITE: 0xB0 GOT ACK: YES <–DS1077 write address
220 I2C WRITE: 0×01 GOT ACK: YES <– DIV register
220 I2C WRITE: 0xFF GOT ACK: YES <– bits 9:2
220 I2C WRITE: 0xC0 GOT ACK: YES <– bits 1:0
240 I2C STOP CONDITION
I2C>f  <–do a frequency count
9xx FREQ COUNT ON AUX: 16128Hz (16kHz) <– DS1077 frequency
I2C>

We set all the bits in the DIV register to 1 for maximum frequency division. ‘F’ measures the frequency on the AUX pin, which is connected to the DS1077 clock output. With DIV=1025, the frequency is about 16kHz.

I2C>{0xb0 1 0 0} <– DIV=0, 133MHz divide by 2
…
9xx FREQ COUNT ON AUX: 0Hz <–66MHz, too fast to count

————-

I2C>{0xb0 1 0 0b10000000} <– DIV=2
…
9xx FREQ COUNT ON AUX: 3339696Hz (33MHz) <–133MHz/4

————-

I2C>{0xb0 1 0b00000001 0b00000000} <–DIV=4
…
9xx FREQ COUNT ON AUX: 22192384Hz (22MHz) <–133MHz/6

We can play with the divider and generate a range of frequencies. The output is always equal to the reference frequency (133MHz) divided by DIV+2. The Bus Pirate’s input pin is only capable of measuring about 50MHz, so the highest speeds don’t register. A future version of the Bus Pirate should include a gigahertz prescaler for high frequency measurement.

I2C>{0xb0 0x3f} <–write E2 register

Finally, we can write the E2 register (0x3f) to save these setting in the EEPROM. The DS1077 will now return to these settings at power-on.

Conclusion

The DS1077 simplifies complex clock sources by moving a programmable oscillator and frequency divider into a single chip. It isn’t available from distributors, but you can buy it directly from Maxim. If you need better control of high frequencies, check out the DS1085 with 10kHz steps from 133MHz to 8kHz. The DS1085L is a 3.3volt, 66MHz version available at Digikey.