Flashing of custom layout fails

Help and Getting Started
1

I’m using algernon’s layout as a base since he has most of what I want already. The only modifications I’ve done are swapping the positions of two sets of keys and adding an F12 key to the Nav layer.

I’m doing this under Arch Linux with the official packages, so I’ve added the following exports to my shell config:

export ARDUINO_PATH=/usr/share/arduino
export ARDUINO_TOOLS_PATH=/usr/share/arduino/tools
export AVR_SIZE=/usr/bin/avr-size
export AVR_NM=/usr/bin/avr-nm
export AVR_OBJDUMP=/usr/bin/avr-objdump
export AVRDUDE=/usr/bin/avrdude
export AVRDUDE_CONF=/etc/avrdude.conf
export AVR_GCC_PREFIX=/usr

I’ve also altered line 38 of Model01-sketch/lib/hardware/keyboardio/avr/boards.txt to read as follows:

model01.build.core=archlinux-arduino:arduino

I’ve confirmed that ModemManager is not running, and also copied the provided udev rule and reloaded my rules by resetting just to be sure.

I’ve added my user to the uupc group, Arch equivalent to dialout, and logged out and back in.

I’m able to reset back to the stock image using avrdude without issue. However, when I try to run make flash the project builds, but only gets this as output for flashing:

- Size: firmware/algernon/algernon-0.0.0.elf
   - Program:   26864 bytes (93.7% Full)
   - Data:       1247 bytes (48.7% Full)

To update your keyboard's firmware, hold down the 'Prog' key on your keyboard,
and then press 'Enter'.

When the 'Prog' key glows red, you can release it.



Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

After that I do see the LEDs flash red across the left keyboard, but it terminates on the ‘C’ button on the third pass. The ‘led’ button never flashes blue. The keyboard then does nothing in response to key presses until I reflash the stock image.

Does anyone have any solutions or ideas about how I can get more information about what’s going wrong?

2

If you’re using my sketch as a base, it has progmem layouts disabled by default, so keys will not do anything until you fill up EEPROM one way or the other. In src/00-config.h, you can change WITH_PROGMEM_KEYMAP to 1, and then the built-in keymap will be compiled in, too. I’m fairly sure this is why no keys do anything until you re-flash the original firmware.

As for the blue light: that’s done by a plugin that is not included in my sketch.

In short, everything seems to be fine, except that the base you use, requires an extra step or two for the keyboard to work.

2 Likes
3

Yep, that did it.
If you don’t mind my asking, how are you supposed to fill up the EEPROM so the sketch works without changing that flag? Is there some advantage to doing it that way?

4

You can use Chrysalis to set up a layout. Or load up a pre-saved keymap. Luckily, you only need to do this once, not every time you flash. If you change the keymap in the firmware, and don’t want to flash twice, you can use Chrysalis to apply the same changes, and you may be able to skip flashing altogether.

The reason for having to do this rain dance is because there’s so many things crammed into my sketch that storing the keymap in the firmware itself makes the firmware too big. So I had to disable the keymap, by moving it to EEPROM (fun fact: I started working on the eeprom keymap support when my sketch got too big :P).

2 Likes