Neat, switching to the ItsyBitsy just... works

This article is part of a series.

Related Repo:

The ItsyBitsy

Switching to the ItsyBitsy from the Trinket means means I’ll able to do a breadboard circuit without worrying about smooshing the fragile little solder joints on the bottom for the programmer. (With normal Trinket usage that wouldn’t be a problem because normal sensible people use the UF2 bootloader capabilities.) The ItsyBitsy uses the SAMD21G18A instead of the SAMD21E18A, requiring some minor tweaks to the code. todbot already had one all soldered up with the headers and I snicked it.

Colorful pinout diagram by AdaFruit of the ItsyBitsy M0

Differences between E and G

Screenshot of the pinout diagram of the SAMD21G18A (5.2.1 in family datasheet)

The G has more pins than the E. That doesn’t matter much to this project except the vector table gets two new peripherals added back in: SERCOM4, SERCOM5. See the new startup.s [TODO LINK]

To figure out what peripherals changed, I looked at the Configuration Summary (Section 2-1, page 14 in the Family Datasheet).

Making the Circuit

Unlike the bare ATTiny, I don’t have to make the voltage regulator part of the circuit because the ItsyBitsy already has one. I just pulled the 3.3V and the GND into the breadboard buses. Otherwise it is pretty much the same, with extended wires out to a pseudo-header for the J-LINK.

(The red and black wire up on the top right are there as another pseudo-header for providing non-USB power. I left them off the schematic )

Photo of the ItsyBitsy on a breadabord with an LED and momentary switch

Schematic of ItsyBitsy with an LED and a switch.

Updating the Code

Not really much to do.

The Makefile

line 7



lines 41, 42

    .word   SERCOM4_Handler
    .word   SERCOM5_Handler

lines 88, 89

.weakref SERCOM4_Handler, default_handler
.weakref SERCOM5_Handler, default_handler


step 1

lines 17, 18

.equ ledPinOffset, 4    //PA04, "A3" on ItsyBitsy
.equ switchPinOffset, 5  //PA05, "A4" on ItsyBitsy

This works but the logic is inverted now, LED is on, unless the button is pressed, so lines 73 and 77 also need to be swapped, resulting in:

  ledOff:  //default path
    STR R3, [R5] //R3==ledMask, R5==portA_OUTSET
    B loop

    STR R3, [R6] //R3==ledMask, R6==portA_OUTCLR
    B loop

and… done! It works!

Animated gif of the button on the circuit board being pressed.


So these two chips come from the same family so it’s not too much of surprise the transition went smoothly. The real test of the Arm promise will be sharing code between one of these M0+ and a chip with a different Coretex-M rating. To do that it would make sense to be working up in the C so the compiler can handle rendering the different appropriate assembly code. A mixed C/Assembly project’s the next step!

This article is part of a series.