Pin order in the software posted in GitHub:
#define STEP1 2 // D2
#define STEP2 3 // D3
#define STEP3 4 // D4
#define STEP4 5 // D5
#define STEP5 6 // D6
#define STEP6 7 // D7
#define STEP7 8 // D8
#define STEP8 9 // D9
#define RESET 10 // D10
#define ZERO 11 // D11
#define FORW 12 // D12
#define BACK 13 // D13
#define ROTARY 14 // A0; read as analog
#define BUTTON1 10 // D10; same as RESET (same action)
#define BUTTON2 15 // A1; read as digital
#define BUTTON3 16 // A2; read as digital
#define BUTTON4 17 // A3; read as digital
#define BUTTON5 18 // A4; read as digital
#define BUTTON6 19 // A5; read as digital
#define BUTTON7 A6 // A6; must be read as analog
#define BUTTON8 A7 // A7; must be read as analog
Pin order the way I built it:
#define STEP1 9
#define STEP2 8
#define STEP3 7
#define STEP4 6
#define STEP5 5
#define STEP6 4
#define STEP7 3
#define STEP8 2
#define RESET 10
#define ZERO 11
#define FORW 12
#define BACK 13
#define ROTARY A7
#define BUTTON1 10 // same as RESET (same action)
#define BUTTON2 19
#define BUTTON3 18
#define BUTTON4 17
#define BUTTON5 16
#define BUTTON6 15
#define BUTTON7 14
#define BUTTON8 A6 // must be read as analog
Schematics/stripboard layout/software on GitHub should be consistent (I’ve tried… several times) reflecting the intended order and not my botched order.
@Christian had what sounded like a similar problem but no report whether they found a fix.
It doesn’t seem plausible to me it’s in software, because the only pin that would be held in a non zero state is the rotary switch button, if that were mixed up with BUTTON1/RESET that certainly would cause strange behavior but between the two software versions ROTARY could only be swapped with BUTTON7 or BUTTON8.