Raise is split into 3 main pieces; the 2 halves and the Huble. The Huble is the small enclosure in the join of the cable.

As well as containing the main microcontroller it also has a USB socket for extra connectivity. We have been using Atmel’s ATMEGA32U4 microcontroller during the development of Raise. The chip is easy to work with, is the default chip for the Kaleidoscope firmware, and is well supported in terms of libraries and the Arduino IDE.

The problem

One major problem with the chip is its cost and limited memory.

At the moment we can only store 3 layers in the EEPROM (a type of memory that doesn’t get lost when power is removed). To store 10 layers, we could add an extra memory chip to the board but of course adding extra memory also increases the cost.

There are other devices in Atmel’s AVR family that we could substitute, for example the AT90USB1286 which has 4 times as much EEPROM but unfortunately is nearly double the price of the 32U4.

The solution

To solve this issue we are currently investigating the possibility of moving to an ARM chip that both costs less and has more memory. It also makes the Huble more future proof, with more speed, program space and RAM. It sounds like a win-win, but ignores the development cost of moving to a different architecture. In summary, the development work includes:

  1. Choose an ARM chip – most likely the ATSAMD21G18A
  2. Port the Kaleidoscope firmware (majority of work will be KeyboardioHID and I2C communications to the 2 halves
  3. Ensure USB connectivity – make sure it works on Windows, Mac and Linux (and BIOS)
  4. Bootloader functionality – possible to update firmware in the future.
  5. EEPROM is simulated in FLASH on the ARM chip, check this isn’t a problem with many configuration changes.

The Kaleidoscope firmware is written in a way that makes it easier to modify. Part of this comes from making sure the firmware is compatible with the Arduino IDE. The ATSAMD21G18A is already supported by Arduino, and is used in the Arduino Zero board. This should make the process of moving easier and less risky.

Our plan

We’ve had estimates made by 2 ARM programmers, who expect about 4 weeks of work will be required to make the changes and verify everything is working correctly. The biggest changes are those required to make the USB HID (human interface device) parts work correctly. We’ll start by modifying that part so we can check the basics, and which should put us into a good position to make a final decision on whether to switch the microcontroller from AVR to ARM.

Share This