Read the Manual, Stupid
Last week when I was trying to get the piezo buzzer to work with the LogoChip, I was in such a hurry to get to the sound that I skipped this part of the instructions:
Upon powering up, all of the user accessible pins on the LogoChip are configured as “inputs”. . . . Therefore, for the exercises in this document, we would like to always have all of the portb pins configured as outputs. . . . This can be done by creating the following special powerup procedure.
to powerup
write portb-ddr 0 ; turns all of portb into outputs
end
Last night when I soldered pins onto the piezo buzzer from the pager, plugged it into the LogoChip, and still couldn’t get sound out of it, I knew something was up. Finally it dawned on me that I didn’t know which way the ports were configured at boot, and looked at the getting started guide closely enough to find the section I quoted above. With the ports configured as outputs, it beeps just fine. Duh.
Beep Volume
I’m surprised at how quiet the beep is running on 5V, compared to how obnoxiously noisy the beep is in a pager on 1.5V. I changed back to the beeper from the microwave and it’s a little louder, but not much. Is the 1.5V in the pager really getting stepped up somehow? Tiny transformer, or voltage multiplier? Maybe I just need a driver transistor; I guess some experimentation is in order.
Beep Code
Making a beep was cute and simple, but booooring, so I made a little warbly sound.
to powerup
write portb-ddr 0 ; set port B to output at power-up
end
to startup
warble 3 ; "warble" three times when the Go button is pressed
end
to click-on
setbit 0 portb
end
to click-off
clearbit 0 portb
end
to delay :n
repeat :n [no-op] ; waste time by doing nothing, several times
end
to note :period :duration ; play a note of a given pitch for a given duration
repeat :duration [ ; repeat as long as requested
click-on ; make a sound
delay :period ; wait a little bit
click-off ; make another sound
delay :period ; wait another little bit
]
end
to warble :times ; make a warbly noise several times
repeat :times [
note 2 200 ; make a low-pitched sound
note 1 200 ; make a higher-pitched sound
]
end
Of course, downloading a routine named powerup doesn’t automatically invoke that routine (unless you reboot the chip), so I invoked it manually from the console. Having done that, the routine makes a nice little warbly noise any time you type warble # at the console, or press the “Go” button on the circuit board.
Another thought: Since note‘s duration code loops around calls to the click-on, click-off routine, which calls delay to set pitch, the duration is actually impacted proportionally to the pitch of the note. It’d be interesting to rewrite the duration code to take input in ms (or seconds) and check timer to see when we’ve played the tone for long enough.
Pitches and Timing
If the code makes sense to you, then you’ll notice that I’m calling the delay routine with the second-shortest and shortest possible delays–twice and once through the loop. With delays of 2 and 1, the second pitch should be an octave higher than the first (twice the frequency)–but in practice, the one sound is only about a minor third higher than the other. That means that the overhead of calling the delay procedure is much higher than the delay of running once through a timing loop around a no-op.
Here’s the math: a minor third corresponds to a frequency difference of the fourth root of 2 (in equal-tempered tuning), whereas an octave is a factor of two. So if there were no overhead for calling the procedure, then the respective frequencies and periods would be simple doubles of each other:
f2 = 2f1
p1 = 2p2
But in practice
f2 = 4√2 f1
p1 = 4√2 p2
Let’s define tcall as the duration of the function call overhead (which should be constant) and tnoop as the duration of one trip through the loop in the delay procedure, including both loop overhead and the no-op operation (which we’re told is 13ms). (This ignores the fact that loop overhead will be slightly different when repeating and when exiting, but I suspect that the difference is small enough to be irrelevant. If anyone wants to check, I can measure frequencies for more delay values and give you equations in three variables . . .)
p1 = tcall + 2tnoop
p2 = tcall + 1tnoop
Then substituting back into the period relationship
p1 = 4√2 p2
tcall + 2tnoop = 4√2 (tcall + tnoop) = 4√2 tcall + 4√2 tnoop
2tnoop – 4√2 tnoop = 4√2 tcall – tcall
(2 – 4√2) tnoop = (4√2 – 1) tcall
tcall / tnoop = (2 – 4√2) / (4√2 – 1) ≅ 4.3
So if I did all that right (and I confess I ‘m pretty rusty), the overhead of calling delay is a little more than four times the delay of one trip through the no-op loop. Hmph.
Regardless of the relative values, the actual frequencies aren’t particularly high–higher than 440Hz, but well within the limits of my hearing. (I should test them tonight with my frequency counter.) That’s a bit disappointing for a 5Mhz-clocked chip running flat-out in a busy wait.
I thought about clocking the chip up to 40MHz per the instructions in the getting started guide (8x the clock speed = 3 octaves higher = outside the limits of my hearing), but I didn’t order the crystal and I didn’t have two 10Mhz crystals in my parts bin. Shucks.
I just talked to John, and he said that he and Tom McGuire were able to produce higher sounds using the chip’s built-in PWM. Not bad for a hack, but I wanted to use both channels of PWM for motor control. Think I need me a crystal.