4 ms·

You've read the article, right? None of the code author gives need "64-bit count of milliseconds" nor floating-point logic. The last example (that I've mention

by theamk 2y ago

You've read the article, right? None of the code author gives need "64-bit count of milliseconds" nor floating-point logic. The last example (that I've mentioned in my comment) needs a single byte of RAM for state, and updating it involves one logic shift, one "or", and two/three compare + jumps. Easy to do even in assembly with 64 bytes of RAM.

michaelt 2y ago
Do you mean this code, from the article? uint8_t DebouncePin(uint8_t pin) { static uint8_t debounced_state = LOW; static uint8_t candidate_state = 0; candidate_state = candidate_state << 1 | digitalRead(pin); if (candidate_state == 0xff) debounced_state = HIGH; else if (candidate_state == 0x00) debounced_state = LOW; return debounced_state; } That doesn't work if you've got more than one pin, as every pin's value is being appended to the same candidate_state variable. The fact the author's correspondent, the author, and you all overlooked that bug might help you understand why some people find it takes a few attempts to get firmware debouncing right :)
- theamk 2y ago
  I don't think anyone is overlooking anything, because it should be pretty clear this code is a template, meant to be modified to fit the project style. In particular, that's not in assembly (we were talking about assembly), and uses arduino-style digitalRead and HIGH/LOW constants, which simply do not not exist on PIC12F629 or any other MCUs with 64 bytes of RAM. Translating this to non-Arduino would likely be done by replacing digitalRead with appropriate macro and removing "pin" argument. But if you want to talk more generally about atrocious state of firmware development, where people are just copy-pasting code from internet without understanding what it does, then yeah... there seems to be something in firmware development which encourages sloppy thinking and wild experimenting instead of reading the manual. I've seen people struggle to initialize _GPIO_ without the helpers, despite this being like 2-3 register writes with very simple explanations in the datasheet.

by theamk 2y ago

michaelt 2y ago

Do you mean this code, from the article? uint8_t DebouncePin(uint8_t pin) { static uint8_t debounced_state = LOW; static uint8_t candidate_state = 0; candidate_state = candidate_state << 1 | digitalRead(pin); if (candidate_state == 0xff) debounced_state = HIGH; else if (candidate_state == 0x00) debounced_state = LOW; return debounced_state; } That doesn't work if you've got more than one pin, as every pin's value is being appended to the same candidate_state variable. The fact the author's correspondent, the author, and you all overlooked that bug might help you understand why some people find it takes a few attempts to get firmware debouncing right :)

theamk 2y ago
I don't think anyone is overlooking anything, because it should be pretty clear this code is a template, meant to be modified to fit the project style. In particular, that's not in assembly (we were talking about assembly), and uses arduino-style digitalRead and HIGH/LOW constants, which simply do not not exist on PIC12F629 or any other MCUs with 64 bytes of RAM. Translating this to non-Arduino would likely be done by replacing digitalRead with appropriate macro and removing "pin" argument. But if you want to talk more generally about atrocious state of firmware development, where people are just copy-pasting code from internet without understanding what it does, then yeah... there seems to be something in firmware development which encourages sloppy thinking and wild experimenting instead of reading the manual. I've seen people struggle to initialize _GPIO_ without the helpers, despite this being like 2-3 register writes with very simple explanations in the datasheet.