including custom-switch support in Deviation

the 2 x 2way and 1 x 3way patches are still the original ones posted in the forum, i have attached them here

and the most info about gale's changes are in this post here and onwards in the thread >> www.deviationtx.com/forum/builds/2395-de...-fit-in-rom?start=40

and gale's repo >> bitbucket.org/galee/galee-devo7e

i know that rbe2012 has also been working towards merging gale's work back into deviation but has come up against a problem

Ho boy! .ini configurable! best news I heard this year.

Using the same patches 1x3 and 2x2 like Harry but with the extension that the emulators will be patched also.
Already posted here: http://deviationtx.com/forum/7-development/2524-devo-7e-deviation-4-0-0-2-switch-patch-problem#17671

blackmoon wrote: Ho boy! .ini configurable! best news I heard this year.

The best news is the year is still young. So looking forward to good things from Deviation.

1x3 and 2x2 are the most popular.

But if we can somehow figure out what Galee did to support two 3-position switches, that would be awesome. As some quads with it's advance functions wants two 3-way switches now.

I had a deeper look into Galee's code. There the key matrix is gone through twice - first the columns are switched and the rows are read, then vice versa. If I remember correct he puts one column line low in the first run and one row line high in the second.
The switches (2*3-way) are bound to a common line (actually I don't remember if a column or a row line) and the four input lines belong to the four corresponding input lines (rows / columns). To distinguish them from the standard buttons he adds diodes so that buttons are recognized twice (in each direction), switches only once (he only determines the switches if the first run gave a zero result).
This is something what should be transferable to all buttons, but I did not get this working (with all combinations of pin input and output configs - some combinations gave me values which did not allow to determine the switch).
I am sure if you look into you will see how to do that, but maybe some external pullups/pulldowns or other circuits do not allow to use each line equally.

At least we should get 4 switch lines working - usable for 2 3-way-switches, on 3-way and two 2-way or 4 2-way switches.

best news of the year...

rbe2012 wrote: I had a deeper look into Galee's code. There the key matrix is gone through twice - first the columns are switched and the rows are read, then vice versa. If I remember correct he puts one column line low in the first run and one row line high in the second.
The switches (2*3-way) are bound to a common line (actually I don't remember if a column or a row line) and the four input lines belong to the four corresponding input lines (rows / columns). To distinguish them from the standard buttons he adds diodes so that buttons are recognized twice (in each direction), switches only once (he only determines the switches if the first run gave a zero result).
This is something what should be transferable to all buttons, but I did not get this working (with all combinations of pin input and output configs - some combinations gave me values which did not allow to determine the switch).
I am sure if you look into you will see how to do that, but maybe some external pullups/pulldowns or other circuits do not allow to use each line equally.

Please note that Galee's code changes the GPIO mode between scans:

gpio_set_mode(KEY_ROW_PORT,GPIO_MODE_OUTPUT_50_MHZ, GPIO_CNF_OUTPUT_OPENDRAIN, GPIO6);
gpio_clear(KEY_ROW_PORT, GPIO6);

then

gpio_set_mode(KEY_ROW_PORT, GPIO_MODE_INPUT, GPIO_CNF_INPUT_PULL_UPDOWN, GPIO6);
gpio_set(KEY_ROW_PORT, GPIO6);

you can see that the first scan uses opendrain, the second pull_updown. I think that's key to get the right results

Here are the GPIO lines used:

GPIO B
5: Button Matrix Col 1 - Red
6: Button Matrix Col 2 - White
7: Button Matrix Col 3 - Yellow
8: Button Matrix Col 4 - Blue

GPIO C
6: Button Matrix Row 1 - Brown

GPIO C6, Brown goes to the center contact of the 3-way switch, and the GPIO B5-8 are connected to the outer contacts thru diodes. Basically it seems to be using Button Matrix Row 1 set high and low, then reading what happens to the GPIO B5-8

Also adding Galee's code for the key scans on Devo 7e and the relevant pictures for soldering the switches

I think rbe2012 had problems when trying to enable more than just the positions required for the 2 3way switches

Exactly.

HappyHarry wrote: I think rbe2012 had problems when trying to enable more than just the positions required for the 2 3way switches

That would be even better, but I'd be happy enough with the two 3-way switches for the Devo 7e Pretty selfish of me, I know

But, seriously, if the two 3-way switches could be enabled, that would make at least a few people very happy...

Going back to being my useless self, fading into the background...

Is it also possible to add inputs to the Devo 6? I haven't seen any information on this model.

It is. The same mechanism as for Devo7e should work in Devo6 too (or if you have some advanced soldering skills you can solder new switches directly to inputs where they are connected in Devo8 and use the Devo8-build - haven't looked deep inside but they are so similar that it should work).
But the Devo6 is not very common, it seems. There are nearly no statements or questions to Devo6 in the forum.

I suggest we add the Devo8s vibration patch as a standard option to the builds as well.

that's great news pb I look forward to trying it out

RBE,

please provide the Devo8s Vibration patch to PB to include as standard option in the TX.ini

RM

PhracturedBlue wrote: Just an FYI:
I installed the 2x3way switches in my Devo7e today, and got the code working against Deviation 4.0.1
I'm still struggling to figure out how to make this a ru-ntime enabled capability rather than compile-time enabled.
Supporting the 2x2way, 1x3way or 2x3way in the same code-base is pretty easy. Once I find a solution to run-time enabling, you'll be ale to choose between them from tx.ini (I hope)

Please let me know if you need additional test on a Devo 7e, even at this hardcoded stage. I have the switches soldered already in the "galee configuration" and I'd be happy to run any test you might need. I can compile using the Linux VM (or if you prefer to send a DFU, even better)

while i think that run time enabling would be a nice addition i feel that if it is not possible to make it work properly this way that for someone has the ability to add the switches to their tx then they surely will have the ability to build a custom dfu if required. i understand why you would like run time enabling as it makes maintaining more streamlined in that one build per tx type will cover all switch mod types, i just think that it could be done without this type of run time enabling without too much trouble to those who would use it.