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.
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: