(paraphrasing)
Arduino doesn't allow direct access to the hardware.
Basic functions (millis(), subtraction, etc) in arduino don't work, perhaps because the ARM compiler is misconfigured.
The Arduino forums hide this by censoring their forums, forcing expert contributors off onto their own forums.
The Arduino code is full of clever and complex (and thus indecipherable) C++ code.
None of those are true. You sound like a conspiracy theorist.
I ran your code from #5 through Arduino with all the warnings turned on, and took a general look through. I don't have your hardware setup, so I can't duplicate all the testing. I changed the LCD output to Serial, and it prints stuff about every 2 seconds.
These look like real problems (use of boolean "!" operator where there should be a bitwise "~"? I'm not real clear on what it's trying to do.)
/Volumes/MacOS/HD-Downloads/Downloads/lashup/button_inputs.ino: In function 'void buttonRead(unsigned char)':
/Volumes/MacOS/HD-Downloads/Downloads/lashup/button_inputs.ino:11:46: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
11 | varButtonState = (varButtonState & !(0x1 << button)) | (0x1 << button);
| ~~~~~^~~~~~~~~~
/Volumes/MacOS/HD-Downloads/Downloads/lashup/button_inputs.ino:15:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
15 | varButtonPressed = (varButtonPressed & !(0x1 << button)) | (0x1 << button);
| ~~~~~^~~~~~~~~~
And here, it bothers me that tempstring[] can apparently be up to 14 characters, while the text[] string that it's being copied to can only have 5. (whether that actually happens is a separate question, I guess.)
void asciiDistance(long vartoconvert, char *string) {
unsigned char tempstring[15];
:
while (tempcounter != 0) {
string[stringcounter] = tempstring[tempcounter];
tempcounter--;
stringcounter++;
}
}
void lcdDistancePrint() {
noInterrupts();
long distance = tachoDistanceCounts * tachoStep / 100;
char text[6] = {0, 0, 0, 0, 0, 0};
asciiDistance(distance, text);
:
There is a bunch of use of "uint8_t" and "uint16_t" and similar that would be a good idea on an AVR, but is un-useful to harmful on an ARM.
The stack pointer for a SAMD21 image is initialized to 0x20008000 (the end of the 32k of RAM), so stack-overflow - the only reason I could imagine that "millis() fails if call from "too deeply nested", seems extremely unlikely. (And I've never heard of any such thing.)
-----
There are annoying things about "Arduino", but in the end it's a very shallow framework on top of standard well-trusted tools, and it has a LOT of users. If you're going to make extraordinary claims about serious and should-be-obvious bugs and misbehaviors, we (well, I) will need extraordinary proof. That means code and instructions for a (hopefully very minimal; ie no LCD, no actual tach hardware) hardware setup that demonstrates the problem.
Nick Gammon was never an official Arduino employee, though he was a significant contributor to the forums for quite a while. His personal forums and web pages pre-date the Arduino by a long time, so it makes sense that he'd post info of long-term interest there. He hasn't been around the Arduino forums for a while, and I don't recall him posting a reason for leaving. I suspect he got tired of rude users, rather than of the administration.) I've never seen the forums censor people for technical info critical of Arduino code/etc; only for ... rudeness to other people. (And I would have, having been a main player in the "Freeduino" project, back when it looked like the HW might go "closed source.")