Frequently Asked Questions

A collection of (maybe) frequently asked questions.


Board design

Kakapo doesn’t have the “ICSP/SPI” connector

Warning: rant incoming.

The original purpose of the 6-pin connector in the bottom right of an Arduino was for external programming of the MCU, using the ICSP/SPI protocol.

That the header had SPI was a side effect of the way external programming for the chip worked. The “official” SPI pins were on the digital pin headers along the top. The ICSP header was a dupe of the pins with the extra pins needed for ICSP (power and reset).

When the Arduino Leonardo came along, the Arduino project decided to not wire SPI to the digital IO headers. Instead, the only SPI pins were provided on the “ICSP” header. This broke a wide array of shields which didn’t use the ICSP header for SPI.

For Kakapo, external programming is not done over SPI, and uses dedicated programming pins. SPI is provided on the pins the Uno had them available on. The choice was then between duplicating the pins on the digital header down to an “SPI” header (which wouldn’t have any programming capability) or using this space to provide an 8-pin header for extra pins on the Kakapo MCU.

We chose to give you more usable IOs rather than duplicate pins.


General Hardware

Will there be a driver for the ______ module?

The drivers provided by libkakapo are intended to be the most common used peripherals, but not all of them. Some modules are difficult to abstract as they interact with a wide variety of other modules (eg, DMA). Others are less likely to be used vs the effort of writing a general driver for them.

These features currently have no drivers in libkakapo:

  • DMA
  • Complete coverage of the event system (some module drivers expose their own elements of it, but not all aspects of the event system are covered).
  • DAC
  • Crypto acceleration
  • CRC generator
  • EBI
  • Sync mode and 9-bit mode on USART
  • SPI master mode on USART
  • TWI slave
  • AWeX and HiRes timer modes
  • XCL
  • USB
  • NVM controller beyond signature rows, eeprom, and functions provided by xboot API
  • Power modes (except as already provided by avr-libc)

Note that while libkakapo does not have drivers for these features, nothing should stop you from writing your own driver mixed with libkakapo.

We are also always happy to see patches to libkakapo to support other modules, so if you have written support for a module please consider contributing it.

Do I always need to call kakapo_init()?

kakapo_init() provides a few initial setup tasks that are typically needed for most projects anyway. It performs the following tasks:

  • Set up the system clock according to the F_CPU define
  • Set the pin direction on the built-in LEDs so they are outputs
  • Enable interrupts

Note that as many drivers are compiled with delays and timing configuration based on F_CPU, it is important to call kakapo_init() to ensure the system runs at the speed the drivers were expecting.

How do I adjust the frequency that the Kakapo runs at?

Unlike the ATMEGA on boards such as the Arduino, the clock frequency can be entirely set at runtime, and does not require an external programmer or changing crystals.

By default, kakapo_init() and all drivers will handle either 32MHz or 2MHz. This can be changed by building the library with the frequency passed as a paramter to make. For example, this rebuilds the library with 2MHz system clock:

make clean; make F_CPU=2000000

It’s important to do a `make clean` before to ensure all drivers are recompiled against the new frequency. You will also need to ensure your project calls kakapo_init() fairly early.

For other frequencies, be aware that many drivers do not support frequencies other than 32MHz or 2MHz. You will need to check every driver and add appropriate blocks for your chosen frequency, and either perform clock setup yourself (using the functions in clock.h), or modify kakapo_init() to support your chosen clock.


When using the USART right on power-up, I get corrupt text before it comes right?

The FTDI chip which provides USB based access appears to need a few cycles to get in sync with the USART from the MCU. The easiest way to force the sync is to emit a single character and then a delay.

/* init some serial ports! */
usart_init(usart_d0, 64, 128);
usart_conf(usart_d0, 115200, 8, none, 1, U_FEAT_NONE, NULL);

/* this is required to force sync with the FTDI chip */

Tech and Electronics