Keith's Electronics Blog

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:

f₂ = 2f₁
p₁ = 2p₂

But in practice

f₂ = ⁴√2 f₁
p₁ = ⁴√2 p₂

Let’s define t_call as the duration of the function call overhead (which should be constant) and t_noop 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 . . .)

p₁ = t_call + 2t_noop
p₂ = t_call + 1t_noop

Then substituting back into the period relationship

p₁ = ⁴√2 p₂

t_call + 2t_noop = ⁴√2 (t_call + t_noop) = ⁴√2 t_call + ⁴√2 t_noop

2t_noop – ⁴√2 t_noop = ⁴√2 t_call – t_call

(2 – ⁴√2) t_noop = (⁴√2 – 1) t_call

t_call / t_noop = (2 – ⁴√2) / (⁴√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.

Introduction to the LogoChip

A lot of the work in the Technology: Art and Sound by Design class will revolve around the LogoChip, a PIC18F2320 microcontroller (~$8 in 28-pin DIP) with scads of I/O pins and a Logo byte-code interpreter. (The Logo code is compiled on a host computer and downloaded to the chip.) The getting started guide gives examples to flash LEDs, beep piezo speakers, and move Lego motors.

The chip looks very promising for my own hobby use as well. I’ve been intending to dive into microcontrollers for a long time, and always assumed it’d be PICs. I have a BASIC Stamp (and a separate PIC) on my SumoBot, so that’d be one entry into microcontroller programming; but the LogoChip appears to be even easier to get into.

I’d been planning to follow up to my tilt sensor project with a PROM-based controller, but a little logic tells me that I’d need to quantize the sensor’s PWM output into at least 32 slices to get acceptable motor behavior, and that’s a lot of work to do in discrete logic. I’m afraid I’d overload my small motor just with the weight of the TTL DIPs required to do that. I had really wanted to build a motor controller without a microcontroller, just to show myself that it could be done, but I think it’s time to move on.

Building Circuits

The last two nights, I’ve breadboarded the LogoChip circuit, got it communicating with a host computer, and successfully built the cloning circuit to program the LogoChip code into the blank PICs I bought. The road to success was paved with annoying obstacles, though.

The getting started guide gives a schematic and step-by-step instructions to lay out the supporting circuitry on a breadboard. Of course, I’m stingy with space (I want as much room left over for other components to experiment with), so I managed to collapse the circuitry into the smallest possible amount of space. I saved .4″ over their design! Woo-hoo!

But I built and tested it using my bench power supply, forgetting that I was planning to power it with a 9V battery and 7805 voltage regulator. After I had it all working, I didn’t have room to add the 7805, so I had to stick it down at the other end, move the power switch, etc. ERROR.

Also, the guide’s schematic for the serial interface disagrees with its visual layout instructions, and the schematic is incorrect. The indicator LED and its current-limiting resistor need to attach directly to DB-9 pin 3 (the host’s TD / chip’s RD), not to the chip’s C5 (pin 15) as shown in the schematic. When attached to C5, it appears to pull down the signal too hard, and I couldn’t get serial communications to work.

[INSERT CORRECTED SERIAL INTERFACE SCHEMATIC HERE]

And, OBTW, the LogoChip goes into the circuit UPSIDE DOWN. That’s right, engineers–don’t try to insert it with pin 1 in the usual position, ’cause that’s not the orientation they chose to use. (???!!!)

I only did that once.

Mac Interface Troubles

The guide points to the files needed to install the LogoChip Desktop Software, but doesn’t give much information about what to do with them. I’ve written more detailed instructions on the class wiki. Strangely, the Java serial communications driver seems to require Classis (OS 9) support in order to install correctly–that’s the only difference I can find between my work desktop computer (where it installed and ran fine) and my notebook computer (where it didn’t). I still plan to get this working on my notebook somehow, so watch the wiki for updates.

Cloning LogoChips

The LogoChip has a cloning process to copy the Logo firmware onto another PIC. Because you can use this to get the firmware onto a chip without a PIC programmer (which I don’t have and haven’t built yet), I ordered blank chips from Digi-Key rather than preprogrammed LogoChips from Wellesley, and John loaned me one of his chips to clone.

The clone routine is a program that has to be downloaded to the LogoChip, not a permanent part of the firmware, so I couldn’t clone until I had the serial communications working. John loaned me the chip Tuesday and I promised to have it back today (Thursday), so that put some pressure on me to get the serial issues debugged. I ended up using my wife’s Windows machine last night for the programming.

Since I’m powering my circuit from a 9V battery instead of the 4xAA 6V pack recommended by the guide, I was curious whether I’d have to add another battery for clone circuit’s programming voltage, or whether I could get away with 9V. Googling for PIC18F2320 programming voltage led me to Microchip’s programming specification, which has an AC/DC Characteristics chart waaaay at the bottom which gives a range of 9.00-13.25V for high-voltage programming. Shiny!

I grabbed the unregulated 9V straight from the battery, threw another PIC on the board, hooked it up, and downloaded the cloner code into John’s chip. (Uh, John, did you realize I’d be overwriting whatever program you already had in there? Sorry about that . . .) Pressed the Go button, and– . . . uh, the button popped right out of the breadboard. I’m gonna have to solder longer leads onto that puppy. Jammed it back in long enough to hit it, and voila! Run light went green (“doing something”) and programming light came on.

[INSERT PHOTO OF CHIP CLONING WITH LIGHTS]

After a while (don’t know if it was four minutes like the guide said) the programming light went off and the run light went red (idle), and it was done. I pulled John’s chip out of the breadboard and put it in an anti-static bag to bring back, put my new LogoChip into the master slot, and cloned it onto another blank chip to make sure it worked. Same deal–lights came on, blah blah–and now I have two LogoChips. W00T!

Piezo Buzzer == NOT!

I tried hooking a piezo speaker to one of the pins to make a bleebledy-bloop program like the guide’s tutorial shows, but couldn’t get any sound. When I put 5V directly across it, it does click a little, so it may just need more current than the chip is supplying. I may try setting it up with a drive transistor to see if that helps; but I salvaged it out of a microwave, so I don’t actually even know for sure that it’s a speaker. Maybe it’s a secret Klingon nucrification death device.

I busted loose a piezo beeper from my stash of dead pagers, but it had SMT solder leads that I couldn’t just jam into the breadboard, so I let it go and called it a night.

And in Conclusion . . .

LogoChips are cool.