Can we use the CLK0 output on the Baby-O 328?


I’ve done a few projects using the Baby-O 328…they are amazing…
But now I try to use more and more features…

I’m looking through the documentation, the forum, the source code…

I cant get proper information regarding the CLKO Output pin (PB0) and the PWM output Pins (OC1A)
Based on what I read, It looks like I could change the Clock Out divider to output a square wave on PB0

Up until now I only found: (regarding CLKPR)

I will try this in the next days…
Let me know if you have more info
…I hope I wont crash my 328p… the “fuse” related topics scare me a little !


You definitely should be very careful when it comes to changing the fuse settings, especially the clock fuses. If you set those incorrectly, you could permanently disable your Baby Orangutan. That said, there is only a single fuse bit that governs whether the clock is output on the CLKO line, so if you are careful to only change this one fuse bit, you should be ok. I suggest you take a look at page 35 of the ATmega328P datasheet (section 8.9) for more information on the clock output buffer.

Note that the clock signal output on the CLKO line is the system clock. You can change the frequency of this signal by changing the Clock Out divider as mentioned in the datasheet and the thread you linked to, but doing so will change the frequency of the clock the Baby Orangutan is running off of, which could cause all sorts of other issues (especially if you are using the Pololu AVR libraries). The CLKO pin is really intended for systems where you want to use the AVR clock as the clock for another device in the system. Is this what you’re trying to do? If not, I suggest you use one of the hardware PWM outputs (or even a software PWM, perhaps interrupt-driven) to achieve your desired output.

- Ben

Thanks Ben,

You’ve put me on the right path…
I now use a PWM instead of the CLK0
For those more evolved features, I was struggling to find proper documentation for those registers,
I started to be convinced that I was missing an important piece of documentation

And in another post, I saw somebody referencing the Amtel documentation
The thing is, I wasn’t sure how much of the features of the baby-orangutan was from Pololu baby-o board and how much from Amtel 328p cpu

I downloaded the Amtel ATmega328p 566 pages tech spec and found everything I was looking for !

In 2 days of work, I converted my project: single thread non-blocking while(1) loop that was doing quite a lot
A “multi-thread” kind of project, with TIMER1 triggering a 40Khz house keeping handler, TIMER2 driving a motor at 10Khz PWM on M2 and a TIMER0 driving a special device at 40Khz PWM on M1 !
I like the Orangutan even more !

The only question I feel like asking is:
I saw in the lib avr library that the motors are driven at 10Khz, not at 40KHz because all devices supports it, except for the LV device
but a second note is ambiguous:

So the question is: is this valid for all Orangutan ? or just the Orangutan LV-168 ?
Right now, my project is running fine on a Baby-O at 40Khz
I’m not connected to any QTRsensors, but “OrangutanTime” …is a software package…how can I break this !


I’m glad to hear you made so much progress after discovering the AVR datasheet! The Orangutans give you direct access to the AVR microcontroller, so the datasheet can be very helpful if you want to do advanced things not supported by the Pololu AVR library.

One of the reasons the motors are driven at 10 kHz is because of the LV-168 limitation, but another is that the motor PWM timer is also used for general system timing by several parts of the library, and it does this by interrupting at every timer overflow. Increasing the motor PWM frequency therefore increases the frequency of the interrupts, which occupies more of the AVR’s processing time.

By “break OrangutanTime”, we mean that the OrangutanTime functions will not work properly if you change the motor PWM frequency. For example, get_ms() will be off by a factor of four if you use a 40 kHz PWM (i.e. it will return units of quarter milliseconds instead of milliseconds). You should be able to fix OrangutanTime by changing the timer2 overflow ISR code in OrangutanTime.cpp to:

	us_over_10 += 256;

	if (us_over_10 >= 10000)
		us_over_10 -= 10000;

- Ben

True, I saw that I could not change Timer2 and keep on using use get_ms()

But after a few tests, I saw that I could drive the motor M1 from TIMER0 at 40Khz without affecting the library’s timing functions

So thanks, this explains the note…

All is good…