Closed dwillmore closed 5 years ago
Can you confirm the interrupts required by the rotaty code aren't interferring with the deauther?
At this point, I'm not planning on using interrupts. It looks like we spin through the main loop fast enough that I can just use a little state machine similar to how button presses are handled now. The cheap rotary encoders that I was thinking to use aren't going to spin very quickly and use only 1x decoding--because they have detents every four quadrants.
I'm not hearing a 'no, we don't want that', so I'll go write up the code and then you can look at it and we can all play with it.
The code will go right after the #ifdef USE_DISPLAY near the end of the main project file. I'll put an #define near the top to select buttons or dial. The code will replace the first if()elseif() clause and the rest of the code below that should not need changed. The dial code will just create the same buttonPressed values as the existing code.
Give me a sec as I'm completely new to github and git in general, so I'll have to do some reading to even figure out how to share the completed code.
btw @spacehuhn will reply to the contribution proposition
I'm very interested in your idea, I was on my way to try using a 5 way momentary push button on my build but I need a reflow station first as I only have the SMD version :-)
I have a few rotary buttons though, so I'll probably be testing your code too ^^
I've got the preprocessor stuff written. Now to implement the state machine which is just a LUT. I'm going to tweak it so that it should still work even if it misses a step. That should make it more tolerant to jitter in the main loop execution. Man, it's been a while since I did any real coding. ;)
Once I have it working, I can email you a patch and you can test it and whenever @spacehuhn has time to ponder including it I can see about learning git/github.
Someone is going to hate me for this #if statment. I'm doing an #if to select between two C if(){ clauses. Then they share a bunch of code and a common }. There's probably some purist out there grinding their teeth right now, sorry.
You can also create a gist and update this thread with the URL, I'm probably not the only one interested in this, moar feedback :p
Oh, that's cool. Yes, I will do that! Of course someone has already had my problem and found a solution to it. Du'ah!
I have rotation working! Now I need to put the button press back in. Woo hoo!
Okay, here it is. Hope I did this right: https://gist.github.com/dwillmore/db6a800c54eaa541984f3e83cd9dcb76
I don't know if I labeled the phases properly since I don't have the datasheet for this encoder anymore.
Also, I had to alter the state table a bit because there was jitter on the 'B' input as I labeled it. So, 0,0 and 0,1 are considered one 'state' and 1,0 and 1,1 are the other. Button events are only reported for transitions between those overall states.
I don't see any missed steps, but it would be very hard to debug or even detect that as the human eye would miss it. Considering how small the display is and how few lines it can display, I think we won't really see any problem. The only time we would be likely to lose one would be at page redraw as that operation takes a bit longer.
Okay, I made it skip. Scan, select an AP, and then start a beacon flood. That takes up enough loop time to make scrolling a bit gritty. I haven't looked at that code, but maybe it could be made a bit more granular so that it doesn't jitter the main loop timing. Or we live with this and are just happy it works at all.
Or, I go look at using interrupts. To address your question about interrupts messing with the rest of the code. I don't think they would--if they work at all--because the routine that needs to run on IRQ is so small and fast. Take a look at the code to see what I mean. If we want to go that route, we might as well move all button and encoder stuff into IRQ.
Scrolling is so much nicer with a rotary encoder. I need to print up some knobs--the bare D shaft of the encoder is akward.
Looks good! I don't make the Deauther boards but I will ask if it would be something to add to a future version.
@spacehuhn I'm glad to hear that you like it! Yay! I tried to follow your coding style. I hope I didn't make too much of a mess of it.
Has anyone had a chance to test this out? I've been using it for a few days now and it's stable for me. What's the next step to get it comitted? I am completely new to git and github.
Do we want to include this without anyone but me testing it or shall we wait for someone else to try it?
I did a similar approach by using a selector switch... Not a rotary encoder... The switch has three outputs... 1) When its pushed upwards..[DN] 2) When its pushed downwards...[UP] 3) When its pushed in... [SELECT]
Awesome! Can I ask where you got the selector switch? I found some on aliexpress but it's for surface mount or 5 positions.
@tobozo Sounds funny but I salvaged it from a old cheapo-Chinese FM+MP3+USB music player... I had that broken quite a while ago... I kept its circuit and desolderd the switch... It was surface mounted...
@sk-y2k oh right so I was chasing a ghost 👻 now I suddenly have an urgent need of scavenging old hardware :p
@tobozo LOL true...😂 I tried to find it but I was unlucky :(
@tobozo You can get similar kind of switch from old CD/DVD/Blu-ray player for TV's... It is used in disc loading tray stop detection mechanism... But it doesn't have third output... Only up and down...
So, are we ready to merge this? What do I need to do to get my code into a format that can be merged?
Darn, I didn't make 2.0. I guess I'll rebase.
Don't worry. We will get it working. I already ordered a few rotary encoders for testing :)
@spacehuhn did you order one of the I2C rotary encoders from tindie ?
No, you mean this one? https://www.tindie.com/products/Saimon/i2c-encoder-connect-rotary-encoders-on-i2c-bus
yep this one
Darn, I didn't make 2.0. I guess I'll rebase.
@dwillmore you might be interested by @reaper7's fork where an i2c keyboard is implemented and changes are isolated in only two files https://github.com/reaper7/esp8266_deauther The keyboard module is the X-Pad shield from tindie
Hey I updated the repo to use my SimpleButton library. I made a video about it a while ago when it was still Work-In-Progress: https://www.youtube.com/watch?v=iloDFFyjCbk
Anyway, with that, the deauther code can now be edited to use a rotary encoder (I2C or classic) instead of push buttons! I planned to make it even more easier with deauther v3 but I had to cancle the update, due to memory issues. I will write together a little tutorial on how to customize the input methods. (This is more of a self reminder message :P)
Would the contribution of a replacement for the UP/DOWN/SELECT buttons interface that used a quadrature rotary encoder with a press switch be welcomed?
They would use three GPIO just like the existing button interface does. I guess both could even be supported at the same time. In that case we would need just two more GPIO--the SELECT input would be the same between the buttons and the press switch on the QE.