The capture contest entry from David Fries #10
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
506 bytes before and after
Even though the loop doesn't end, the compiler is giving a warning about it not having a return.
In another case the function couldn't be left undefined. Pass the Hz value to inform what value was invalid.
I would expect that it isn't getting transferred over to the device, but that's just a guess. PROGMEM works, so using that.
That is before the code cleanup, but it should still be good.
Press a button or two to begin. The lights start moving at the top left or right. If they are moving right you must hit the bottom right button, opposite for left. Two points if it is captured on 8, one point if it is captured on 7 or 9, loose a try any other place, you get three tries before the game starts over. The score is displayed as follows. A sweep to 10 indicates the ten's digit is the next LED, a sweep to 1 indicates a 1's digit, if either is 0 all LEDs stay dark. The game gets faster the further along you get. Subtitle First Time Quality. The First Time Quality, because no kidding after the "EEMEM isn't working, use PROGMEM instead" commit was just figuring out audio, all the game logic was coded up with only one write to the AVR ATtiny chip, and that is this version. EEPROM failed me again, good enough so I'm going with it.
Slow the interrupt rate back down before displaying the score. Otherwise a fast score is also too fast to see. This also increases the sweep speed for the score for the effect.
SetState(CURRENT_SCORE); was overriding the SetState(NEW_HIGH_SCORE); The loops were wrong in it anyway and would have left the speaker running.
The math and logic runs fine in the software emulator for repeating the score display. There it would display 10's, 1's, then as data counted up led=1<<(12-data); would continue to go negative causing two sweeps top and bottom, pause, a number of times before data became 0 and repeated the score. On the hardware it would display 5 for a bit, pause, 1 for a longer time, then nothing until it repeated. Without looking I'm guessing it has something to do with 16 bit unsigned subtraction using 8 bit registers. DisplayScore advances to the next state after it is completed. Except the next state was COUNT_DOWN so after getting a high score tries was still 0 and the next miss would decrement it to 255 and cause it to take the long way around.
This also displays the current score three times before displaying the high score again.
Why not, that LED was available.
Any that are required will be replaced by C++ objects to control what happens when they are read or written.
it was a bit number not a binary value check for NULL function name
This is to emulate that the compiler hides 16 bit register reads and writes with 8 bit register reads and writes.
This also required that the avr interrupt routine be in a shared object, otherwise dlsym wasn't able to lookup the symbol name.
That's how the real hardware would work.
util/atomic.h is pretty generic, so no changes were needed It did set and restore the status register, adding an accessor for that.
This is because setting the interrupt state on one while the other isn't yet configured causes it to complain about an unsupported mode. It was easy enough to add.
These are inverted so 0 means pressed, and they start out not being pressed.
It was multiplying seconds times seconds per tick, which isn't desired and it needed to a do mod operation to get the correct range.
include/avr/wdt.h currently exists to not give an error when it can't be opened. The program in question didn't actually use anything from the header file so this didn't bother to put anything in there.
To compile objects and overloading are required, so compile it in C++ even if it has a .c extension.
The watchdog timer assembly instruction is only going to be present on the device. Disable it otherwise.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This contains the contest entry keypad program in src/dfries_capture/, and the C++/Qt emulation work alike framework in src/keypadalike/ which all but one example and contest program compiles and runs (I didn't implement the uart), and are in varying degrees of functional.