Who wants a cheap, simple, Arduino-based LED controller?
- Thread starter der_wille_zur_macht
- Start date
chrisfowler99
Premium Member
I'll have to grab it in a bit.
One question I had (and another thing I should probably just look into before asking, but...) is: Is it possible to implement support for holding down the '+' and '-' buttons to speed through the setting? Adjusting the percentage way up or way down by hitting the button 50+ times is annoying. But setting the time, if you've got to change it a long way, one minute at a time is downright frustrating.
XSiVE
New member
I'll have to grab it in a bit.
One question I had (and another thing I should probably just look into before asking, but...) is: Is it possible to implement support for holding down the '+' and '-' buttons to speed through the setting? Adjusting the percentage way up or way down by hitting the button 50+ times is annoying. But setting the time, if you've got to change it a long way, one minute at a time is downright frustrating.
I was thinking about this too, there is an "isPressed" return value from the button library we are using, though Im a little sketchy on how to implement it.
If we just say start moving if the button is pressed, getting precise numbers might be a little tough.. I have a feeling the clock speed of the board will make the numbers fly by too fast to deal with so we'd have to only do something every so many cycles.
Give it a try in your arduino editor before you upload to your typhon, replace one of the plus.uniquePress() or minus.uniquePress() with plus.isPressed() or minus.isPressed()
If you're not comfortable making those changes or its giving you unpredictable results let us know.
I'll try it too but I may not get to it before tomorrow morning.
TheFishMan65
New member
If that fails you could always adjust hours, tens of minutes and minutes separately. Also if you can detect + and - pressed at the same time maybe you could reset to 00 or increment by15. Just some thought that might help.
mm.reefs
Member
+1 :thumbsup: I also think that incrementing/decreasing minutes by 5, 10 or 15 with each press is a good idea that will make things easier.
TheFishMan65
New member
We should have set it with an astronomical clock. We need a redesign 
The five minutes is a good idea too. I don't think that many will care if we are off by 2.5 minutes. Oh wait you allow to change seconds don't you?
The five minutes is a good idea too. I don't think that many will care if we are off by 2.5 minutes. Oh wait you allow to change seconds don't you?
DustinB
New member
We should have set it with an astronomical clock. We need a redesign
The five minutes is a good idea too. I don't think that many will care if we are off by 2.5 minutes. Oh wait you allow to change seconds don't you?
:thumbsup: Arduino Atomic Clock
TheFishMan65
New member
I don't think that will work on the I2c bus :sad2:
TheFishMan65
New member
Yes, me too. I noticed that it has specific timing requirements, that I think would prevent it from working on the I2C bus.
chrisfowler99
Premium Member
Started to take a look at it and then I got annoyed at some of the really repetitive code, so I started cleaning it up.
Then I came to the conclusion that EEPROMVars<int> doesn't want to be stuck in a structure or an array. :mad2:
Which leaves me stuck with repetitive code That looks...well...exactly like what I started with. :lmao:
XSiVE
New member
LMAO Chris! Yeah it hurts to try and get rid of some of the repetitive stuff. I looked at it right away and thought that the only way to really do it was to re-design the way that time is dealt with and menu interaction from the ground up... and I didn't feel like doing that at the time.
On a positive note I made a really nice enhancement for holding down the + or - key.
It will go "slowly" for 5 numbers, and then go fast until you let go of the button, then start slow for 5 more when you press again.
I've made this change (only a function call luckily) in all of the + and - button checks... The way I did it may not be the most elegant but it works beautifully as far as an end-user would see. I personally hate using a delay function because it chews up clock cycles that could be used for something else but I don't know how to accomplish this neat trick without it. If you've got an idea on how, please share
anyway, new source uploaded with this very nice button-hold feature for setting the menu items! Give it a try
On a positive note I made a really nice enhancement for holding down the + or - key.
It will go "slowly" for 5 numbers, and then go fast until you let go of the button, then start slow for 5 more when you press again.
I've made this change (only a function call luckily) in all of the + and - button checks... The way I did it may not be the most elegant but it works beautifully as far as an end-user would see. I personally hate using a delay function because it chews up clock cycles that could be used for something else but I don't know how to accomplish this neat trick without it. If you've got an idea on how, please share
anyway, new source uploaded with this very nice button-hold feature for setting the menu items! Give it a try
mm.reefs
Member
A promise is a promise... :spin2: here are two more bugs in menu 13 and 17:
if(plus.isPressed() && (threeFadeDuration < threePhotoPeriod/2 || oneFadeDuration == 0)){
if(plus.isPressed() && (fourFadeDuration < fourPhotoPeriod/2 || oneFadeDuration == 0)){
It's a programmer curse, you can easily see someone else code bugs but it's very hard to see them in your code!
if(plus.isPressed() && (threeFadeDuration < threePhotoPeriod/2 || oneFadeDuration == 0)){
if(plus.isPressed() && (fourFadeDuration < fourPhotoPeriod/2 || oneFadeDuration == 0)){
It's a programmer curse, you can easily see someone else code bugs but it's very hard to see them in your code!
chrisfowler99
Premium Member
If the code wasn't so repetitive that wouldn't have been a problem. :lol:
I was trying to do something like this:
Code:
typedef struct {
int Led;
EEPROMVar< int > StartMins; // minute to start this channel.
EEPROMVar< int > PhotoPeriod; // photoperiod in minutes for this channel.
EEPROMVar< int > Max; // max intensity for this channel, as a percentage
EEPROMVar<int> FadeDuration; // duration of the fade on and off for sunrise and sunset for
// this channel.
} channelVals_t;
channelVals_t channel[4];(minus a few extra spaces to prevent tags from being interpreted...)
Except it looks like you can't create an EEPROMVar without initializing it...which means you can't put it in a structure or in an array...
Looks like EEPROMVar was written very recently to cover a specific case. It could probably be cirumvented to get around the issue...or extended. But without doing one of the two I think we're stuck with separate variables.
I haven't given up yet, though.
der_wille_zur_macht
Team RC
EEPROMVar was indeed written recently, to cover a specific case. In fact, it was written moments before I wrote the prototype firmware, to cover the specific case of storing the variables I wanted to use in the firmware.
If you guys see opportunities, please, continue to "have at it." You won't hurt my feelings. I'm good at getting an idea started but poor at high-quality best-practices followthrough, at least when it comes to programming.
To me, the idea that XSiVE and I discussed a page back is the most promising right now. Use "temporary" variables to store user inputs in the UI menu structure, and then once per cycle copy those values to the "real" variables that were stored in EEPROM and actually controlled the behavior of the output channels. We'd just have to be super-super careful to only write a variable to EEPROM when a value changed. If you wrote it to the EEPROM by default every iteration through the loop, you'd burn the chip out in no time flat.
XSiVE, I haven't actually looked at your "button hold" code yet, but it strikes me that you should be able to totally avoid the use of delays to implement that sort of function. Instead, how about storing the time the button is pressed in a variable, and then each iteration through the loop, check to see if the button is still pressed, and if so, check to see how much time has elapsed since it was first pressed. Then you could change the behavior of the button based on elapsed time, instead of using a delay.
If you guys see opportunities, please, continue to "have at it." You won't hurt my feelings. I'm good at getting an idea started but poor at high-quality best-practices followthrough, at least when it comes to programming.
To me, the idea that XSiVE and I discussed a page back is the most promising right now. Use "temporary" variables to store user inputs in the UI menu structure, and then once per cycle copy those values to the "real" variables that were stored in EEPROM and actually controlled the behavior of the output channels. We'd just have to be super-super careful to only write a variable to EEPROM when a value changed. If you wrote it to the EEPROM by default every iteration through the loop, you'd burn the chip out in no time flat.
XSiVE, I haven't actually looked at your "button hold" code yet, but it strikes me that you should be able to totally avoid the use of delays to implement that sort of function. Instead, how about storing the time the button is pressed in a variable, and then each iteration through the loop, check to see if the button is still pressed, and if so, check to see how much time has elapsed since it was first pressed. Then you could change the behavior of the button based on elapsed time, instead of using a delay.
chrisfowler99
Premium Member
I think you're right...and I think I'm most of the way there. I'll see if I can get the rest of the way.
I haven't tested it yet, but my concern with this implementation is that it would seem to introduce a 1 second delay between initial button presses, so if you aren't holding it down 1 per second is as fast as you can go. I could be wrong.
chrisfowler99
Premium Member
Looks like that worked. Need to see if I can integrate the latest button press changes into this.
When I get that I'll send you a copy to take a look at.
chrisfowler99
Premium Member
Cleaned up version...not as clean as I'd like, but gets rid of the repetitive functions.
The button press update is integrated, but I'm not sure if it's performing right. I don't know if it's the button press code or the button press code in combination with my latest changes.
When you hold down the button the value changes, but the screen goes blank while it's changing. I'll look into this one.
Wanted to go ahead and let you guys take a look at the changes I've made and see if they're worth keeping.
You can grab it here:
http://pages.suddenlink.net/chrisfowler99/typhon2.pde
I'm also not positive if I missed any other changes between the last version I grabbed and the current one. I just did the button press changes. The version I started from was grabbed earlier today.
The button press update is integrated, but I'm not sure if it's performing right. I don't know if it's the button press code or the button press code in combination with my latest changes.
When you hold down the button the value changes, but the screen goes blank while it's changing. I'll look into this one.
Wanted to go ahead and let you guys take a look at the changes I've made and see if they're worth keeping.
You can grab it here:
http://pages.suddenlink.net/chrisfowler99/typhon2.pde
I'm also not positive if I missed any other changes between the last version I grabbed and the current one. I just did the button press changes. The version I started from was grabbed earlier today.
Similar threads
