I agree that the bitfield version is more readable, but it compiles longer. 25514 vs 25598 bytes flash. Here is the LSS from the bitfield version (45 lines longer):
I guess I'm reviving an old thread - I was rereading this and thinking more about it. I like the schematic posted in #16, but having had a project with this once, I had a LED that allowed enough reverse leakage to activate a switch that was not pressed. It also requires diodes (though it takes less pins!). I was trying to think through what is the easiest to program for and I came up with this. I'm sure many others have used it before. I'm sharing the rows between a led matrix and it could be a switch matrix with more columns, but in this example the switches only have one column so they can't really be called a matrix. The inactive rows are always HiZ and the active row is output ground. The LED columns are always output, either low or high or off or on. The switch columns are always input with pullup and can be sampled to see if a button is pressed when that row is active. This should make for very simple programming:
repeat{
sample switch columns
disable active row
update led columns
activate next row
}
Sometimes I don't just want a simple monochrome LED matrix, so I have a faster ISR speed. The way I did this previously was to say apply 8 time slots/ISR executions to each row and I would turn off a column if it was only lit say 3/8 times, etc. That worked fine, but might not make sampling the inputs as quickly as I want at the same time. I think it can also be improved on with this technique:
Still have the sped up ISR, but each time we change the active row as if it were monochrome. This would allow us to sample the input switches much faster and feed them into debounce code. Now though to do brightness, we keep a variable called state. Each LED could have its own brightness or you could assign a single brightness to the entire matrix if you only needed that. Let's say the number of brightness levels was 8. Then if the brightness of a LED was set to a 4, each time we would add 4 to the state. When the state is >=levels, it is on for the ISR execution and we subtract levels from it, if it is less than, then it is off for that execution. A brightness of 4 out of 8 levels would then yield the pattern on/off/on/off/on/off. The lowest brightness 1 would yield on/off/off/off/off/off/off/off. Obviously a framerate must be selected that the lowest brightness is still a decent refresh rate that won't blink. I know there is a name of this technique of adding a value, checking to see if it is above a certain value to determine on/off, but I can't recall the name (please tell me if you know it!). Hopefully this all makes sense.
Note that a previous comment in this thread about C and "functions within functions" triggered a side-track discussion about that concept. In order that Alan has some hope of getting replies to the point he recently made in #55 that discussion now lives at: https://www.avrfreaks.net/forum/...
Thanks everyone; I appreciate the help!!! :)
Autoprogrammer:
https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers
- Log in or register to post comments
TopI agree that the bitfield version is more readable, but it compiles longer. 25514 vs 25598 bytes flash. Here is the LSS from the bitfield version (45 lines longer):
Autoprogrammer:
https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers
- Log in or register to post comments
TopActually, GCC allows/supports this but you'll lose portability as most/all other compilers don't.
Letting the smoke out since 1978
- Log in or register to post comments
TopI guess I'm reviving an old thread - I was rereading this and thinking more about it. I like the schematic posted in #16, but having had a project with this once, I had a LED that allowed enough reverse leakage to activate a switch that was not pressed. It also requires diodes (though it takes less pins!). I was trying to think through what is the easiest to program for and I came up with this. I'm sure many others have used it before. I'm sharing the rows between a led matrix and it could be a switch matrix with more columns, but in this example the switches only have one column so they can't really be called a matrix. The inactive rows are always HiZ and the active row is output ground. The LED columns are always output, either low or high or off or on. The switch columns are always input with pullup and can be sampled to see if a button is pressed when that row is active. This should make for very simple programming:
repeat{
sample switch columns
disable active row
update led columns
activate next row
}
Sometimes I don't just want a simple monochrome LED matrix, so I have a faster ISR speed. The way I did this previously was to say apply 8 time slots/ISR executions to each row and I would turn off a column if it was only lit say 3/8 times, etc. That worked fine, but might not make sampling the inputs as quickly as I want at the same time. I think it can also be improved on with this technique:
Still have the sped up ISR, but each time we change the active row as if it were monochrome. This would allow us to sample the input switches much faster and feed them into debounce code. Now though to do brightness, we keep a variable called state. Each LED could have its own brightness or you could assign a single brightness to the entire matrix if you only needed that. Let's say the number of brightness levels was 8. Then if the brightness of a LED was set to a 4, each time we would add 4 to the state. When the state is >=levels, it is on for the ISR execution and we subtract levels from it, if it is less than, then it is off for that execution. A brightness of 4 out of 8 levels would then yield the pattern on/off/on/off/on/off. The lowest brightness 1 would yield on/off/off/off/off/off/off/off. Obviously a framerate must be selected that the lowest brightness is still a decent refresh rate that won't blink. I know there is a name of this technique of adding a value, checking to see if it is above a certain value to determine on/off, but I can't recall the name (please tell me if you know it!). Hopefully this all makes sense.
Autoprogrammer:
https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers
- Log in or register to post comments
TopNote that a previous comment in this thread about C and "functions within functions" triggered a side-track discussion about that concept. In order that Alan has some hope of getting replies to the point he recently made in #55 that discussion now lives at: https://www.avrfreaks.net/forum/...
- Log in or register to post comments
TopThanks Clawson!
Autoprogrammer:
https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers
- Log in or register to post comments
TopPages