Multiplexer Produces strange values with a teensy project

Status
Not open for further replies.
P

pfzzz

Member
I have a mux 74HC4067 with 10 pots connected.

I have the test sketch running correctly on a teensy 3.6, however when I try to plugin the code in a different project (audio), it starts to do strange things

On startup, it shows the correct values for the pots, but whenever I change the values of 1 of the pots by hand, it changes the value of another pot at the same time

whenever I touch pot nr. 7, it changes the value of pot nr. 3 too, pot 6 with pot 2 too...etc until it changes with 0

the first few pots don't do anything, and if I enabled the last 2 (8, 9) it outputs random values.

Any idea where to look ?
 
the project has 2 encoders, audio + midi + serial connection, 1 LCD screen, and a lot of audio processing. I don't mind sharing the code, it's a big project but mostly open sourced
 
Last edited:
Hello, if it works perfectly with a test program, then we can assume your soldering is fine?! What resistance value are the pots, out of interest?
Can you share the code that reads from the multiplexer and produces the value of each pot.
Also which pins of the Teensy are in use with what hardware? I had problems with a display on an SPI bus that didn't like being shared, plus there are pins with more than one function and shared pins that can cause conflicts when various hardware is being added. From what you describe it sounds like the code if the pots are affecting each other in tandem.
 
Last edited:
Without seeing the code you’re using my best guess is you don’t have any delay added after switching your address pins of the multiplexer. Without a very small delay what can happen is you will read the pot before the multiplexer chip has a chance to completely switch the address so you end up with cross talk. The best practice that I’ve found is to change the multiplexer address after reading instead of before so any other code you have after will act like a delay without actually having to slow down your program with delays, then on the next loop it will read the address that was selected in the last loop.
Code: 
//Read multiplexer pin
//Change multiplexer address
//Run other code so the address has time to settle by the next loop
 
vjmuzik said:
Without seeing the code you’re using my best guess is you don’t have any delay added after switching your address pins of the multiplexer. Without a very small delay what can happen is you will read the pot before the multiplexer chip has a chance to completely switch the address so you end up with cross talk. The best practice that I’ve found is to change the multiplexer address after reading instead of before so any other code you have after will act like a delay without actually having to slow down your program with delays, then on the next loop it will read the address that was selected in the last loop.
Code: 
//Read multiplexer pin
//Change multiplexer address
//Run other code so the address has time to settle by the next loop
Click to expand...

I did try the delay but it still does the same thing
 
UHF said:
Hello, if it works perfectly with a test program, then we can assume your soldering is fine?! What resistance value are the pots, out of interest?
Can you share the code that reads from the multiplexer and produces the value of each pot.
Also which pins of the Teensy are in use with what hardware? I had problems with a display on an SPI bus that didn't like being shared, plus there are pins with more than one function and shared pins that can cause conflicts when various hardware is being added. From what you describe it sounds like the code if the pots are affecting each other in tandem.
Click to expand...

I uploaded the code to: https://codeberg.org/pfzzz/test_mux

You will find 2 ino files, one that works test_mux.ino
and one is the real one: test_mux.ino-rename does the issue mentioned earlier

now after adding delay, everything seem to only fail if the rest of the code is initialized
 
vjmuzik said:
This problem has come up before when people use that same library to control their multiplexer: https://forum.pjrc.com/threads/5724...eading-Buttons?p=212832&viewfull=1#post212832
Paul’s suggestion should be all you need to get it working correctly.
Click to expand...

unfortunately that didn't solve the problem

Code: 
digitalWrite(enable_pin, HIGH);
	current_channel = pin;
	for (uint8_t i = 0; i < num_of_control_pins; ++i)
	{
		delayMicroseconds(400);
		digitalWrite(control_pin[i], pin & 0x01);
		pin >>= 1;
		delayMicroseconds(400);
	}
	enable_status = ENABLED;
	if ( set == ENABLED ) digitalWrite(enable_pin, LOW);
	delay(100);
 
I believe I've located the issue, you have multiple libraries using the same pins so they are interfering with each other.

Code: 
//From config.h
#define ENC_L_PIN_A  [COLOR="#FF0000"]3[/COLOR]
#define ENC_L_PIN_B  [COLOR="#FF0000"]2[/COLOR]
#define BUT_L_PIN    [COLOR="#FF0000"]4[/COLOR]

Code: 
//From Analog.h
Analog() {
    	this->mux = new MUX74HC4067(25, [COLOR="#FF0000"]2[/COLOR], [COLOR="#FF0000"]3[/COLOR], [COLOR="#FF0000"]4[/COLOR], 5);
    }
 
vjmuzik said:
I believe I've located the issue, you have multiple libraries using the same pins so they are interfering with each other.

Code: 
//From config.h
#define ENC_L_PIN_A  [COLOR="#FF0000"]3[/COLOR]
#define ENC_L_PIN_B  [COLOR="#FF0000"]2[/COLOR]
#define BUT_L_PIN    [COLOR="#FF0000"]4[/COLOR]

Code: 
//From Analog.h
Analog() {
    	this->mux = new MUX74HC4067(25, [COLOR="#FF0000"]2[/COLOR], [COLOR="#FF0000"]3[/COLOR], [COLOR="#FF0000"]4[/COLOR], 5);
    }
Click to expand...

thank you so much, that solved it!!!
 
Status
Not open for further replies.
Back
Top