How To apply "two switches" patch for Devo7e soft

i updated the svn before patching, is there a new one that i should be using?
Or has the config files changed again so i need to remake them?

The latest nightly is almost a month old now. Strange.

I don't seem to have the menu issues on my devo 10 and the latest svn build ddf6350.

I think the nightly is still without newgui. So yes the config changed. Currently the're some issues on the devo7e you can find more info in the thread www.deviationtx.com/forum/7-development/1899-pb-s-newgui

Can anyone patch the latest build, please? AIL_DR & ELE_DR Toggle switch control is the only feature I want that I'm missing.

Got X4v2 full LED and anti-flip control as well as V222 accessory control on yesterday's nightly build. Also got the ability to use trims as switches.

Just added toggle switches to my 7E last night, and that's the only thing not working.

TIA!!

Edit: Daryoon hooked me up! Thanks bro!

EDIT: I've now made the hardware mods to my Tx and made a couple of fixes to my previous updates :-
- the emu key assignments are now made in the emu_devo7e target rather than the emu_common target.
- the emu key assignments now properly cater for when HAS_ADDITIONAL_SWITCHES is both defined and undefined - see below

In anticipation of doing the two switch mod to my 7e, I've re-applied the previously posted patch file to the current nightly build code (c960b8e).
I've modified the patch to use a define so the two-switch support can easily be turned on and off (comment out HAS_ADDITIONAL_SWITCHES in src/target/devo7e/target_def.h to turn it off)
I've also modified the emulator so it gets the additional switches too
The emu key assignments are :-

When HAS_ADDITIONAL_SWITCHES is defined :-
z = HOLD
x = ELE_DR
c = AIL_DR
v = FMOD

When HAS_ADDITIONAL_SWITCHES is not defined :-
z = HOLD
x = FMOD

I increased the number of trims from 6 to 10, which seems to work ok on my Tx, although PB did express a concern that the 7e might not have the resources to handle more than 6 - so caveat emptor if you decide to leave as-is.

Ian



If you are already using the latest nightly (c960b8e), you only need to flash the dfu and copy the protocols folder to the Tx - and copy the emu exe & dlls into your existing emu folder.

do you mind to build the code so that I can test it out in my 7e?

cmPang

I've updated my post above with the release zip files.
Take note of the caveat before you proceed

Ian

sllewji wrote: I've updated my post above with the release zip files.
Take note of the caveat before you proceed

Ian

looking forward to it .. thx

I've now made the hardware mods to my Devo7e and noticed a couple of issues in the code I previously posted, so I've updated the code in my earlier post with corrections.

sllewji wrote: I've now made the hardware mods to my Devo7e and noticed a couple of issues in the code I previously posted, so I've updated the code in my earlier post with corrections.

got it. Will test it out asap... thx

cmPang

cmpang wrote:

sllewji wrote: I've now made the hardware mods to my Devo7e and noticed a couple of issues in the code I previously posted, so I've updated the code in my earlier post with corrections.

got it. Will test it out asap... thx

cmPang

yep... it works.. thx..

BTW, would you like to go a step further to turn the two additional switches into a three positions type ?

Yes I would really appreciate if one of them could be a three position( but more is always better ).

Thank you for your time if this is possible.

One three-way-switch should be possible because the two switches share a common line (B.5). The other pins of the switch have to be connected to C.7 and C.9 as with the two two-way-switches.
But I am quite sure that the implementation has to be changed because with a three-way-switch there are only 3 positions (right, left, middle) against four with the other solution (right-right, right-left, left-right, left-left).

If I understand you correctly, one could only have two two way switches or one three way switch.

A combination of one three and one two way isn't possible.

--deleted--

I have no Devo7e so I can not tell you for sure but I am quite confident that I understood it right (and I believe to have read it somewhere else).
If you look at the Devo7e hardware connections here: Devo7e-Hardware you can see in the table at the end that only two buttons are not connected. This is where the additional switches are placed. There are simply not more connections for more switches.

I was the one who pointed out the possibility to add two more switches in the 7e and from then a happy user after PB has implemented it Deviation.

About half year ago, I was so surprise to find that a Chinese hobbist who has based on Deviation to provide a variation (sadly GUI in Chinese only) that incorporates two three position switches. Obviously, I too have the query the same as yours as there is only two unused switches left in the stock 7e.

The attached diagram show how it is being connected.









Trust me, ever since then I have used his version since May last year and not a single problem ever since.

After some thought and a hint given by Gale the author, the trick is since we have to use a reverse diode for the usual two switches upgrade anyway, why not add two more diodes to some other input point AND scan the switch matrix one more time but in reverse COL / ROW order. That is, if we did send signal out to COL and listen to switch closure from ROW, then the second scan is to send from ROW and listen to COL and only pay attention to the four target cross points.

It is a pity that there is not much space left on the 7e panel, otherwise I think even more switches can be added.

A bit more..

the two new position Gale added the diodes to is on the "Ail Trim left" and "Elev Trim up" cross point. And the Added switches are named "Ail D/R UP" and "Elev D/R UP". The original twoo added switches are thus "Ail D/R DN" and "Elev D/R DN"

Since there is no such thing as free lunch, it does has a limitation but that is of no border to me during actual usage ...

1. while you are pressing the "Ail Trim left", there would be no instant respose if you flip the "Ail D/R" switch. Not until the time you release the Trim switch then the switching action goes.

2. same for the "Elev Trim UP"

A very clever idea, isn't it?

That's nice, couldn't Galee provide a patch against the actual code for his modification ?

Even tough I only need one three way switch and one two way.

I think I read about a patch for this configuration but don't remember where...

So the new connections as pictured in your post overlay the existing ones of c8/b8 and c6/b7, but should be read when the column/row were scanned in reverse to normal.

So, in the tx_buttons.c scanbuttons() function, could we capture these additional switch values in a second, global variable - say glbl_snottub something like this? :-

And then check for the value of that in channels.c CHAN_ReadRawInput(int channel).

Or am I way off the mark?

Ian

sllewji wrote: So the new connections as pictured in your post overlay the existing ones of c8/b8 and c6/b7, but should be read when the column/row were scanned in reverse to normal.

So, in the tx_buttons.c scanbuttons() function, could we capture these additional switch values in a second, global variable - say glbl_snottub something like this? :-

...
	static const u8 nuttobmap[] = {
		BUT_TRIM_RH_POS, 32,              BUT_TRIM_LV_POS, 31,
		BUT_TRIM_RH_NEG, BUT_ENTER,       BUT_TRIM_LV_NEG, BUT_DOWN,
		BUT_TRIM_RV_POS, BUT_RIGHT,       BUT_TRIM_LH_NEG, BUT_UP,
		BUT_TRIM_RV_NEG, BUT_LEFT,        BUT_TRIM_LH_POS, BUT_EXIT,
...
	u32 glb_snottub = 0;
...
	gpio_clear(ROW_PORT, ROW_PORT_MASK);
	for(r = row; *r != 0xffff; c++) {
		gpio_set(ROW_PORT, *r);
		u16 but = gpio_port_read(COL_PORT);
		gpio_clear(ROW_PORT, *r);
			for(c = columns; *c != 0xffff; r++) {
				if((but & *c)) {
					glb_snottub |= 1 << (nuttobmap[idx] - 1);
				}
			idx++;
		}
	}
...

And then check for the value of that in channels.c CHAN_ReadRawInput(int channel).

Or am I way off the mark?

Ian

Ian,

I am now too old to involve in the codings nowadays so just cannot tell.

But on the design level, the keypad scanning must be done in two opposite cycles in order to distinguish the ones with against the others without a diode.

Furthermore, since the original Trim switches are without diodes and so can be detected in both scans, hence the scan order should be first to scan for the no diodes, then secondly the one with diode. Should the switch without diode was found to be closed, then the corresponding diode switch action should be ignor (stay unchanged) during the second scan.

Needless to say, the second reverse scan has only to scan for the two targeted switches and not neccessary to carry out a full keypad scan

It works, I can assure you as I have been using his version for over half a year..

cmPang