Skip to main content

4 Channel Audio Switcher Update

Update

I've been trying to move away from using the arduino environment and work at the bare metal level for avr mcus. As an experiment I decided to rewrite the code for the audio switcher I wrote about here:
 https://inverseaudio.blogspot.com/2020/01/4-channel-audio-switcher.html.

Its only a small amount of code so I didn't really expect much difference in terms of code, but it seemed like a good starting exercise. The code compiled within the arduino environment used 1014 bytes (49%) of the program memory, and 15 bytes (11%) of the dynamic memory.

I was incredibly surprised to find that the version written in pure c, compiled with atmel studio used only 220 btyes (2.7%) of the program memory, and 2 bytes (0.4%) of the dynamic memory.

The only major changes made to the code were the omission of the enum classes, the gpio pin setup, and the setting of the multiplexer pins. In such a small project the space savings weren't entirely necessary. However, I think that the changes arguably made the code more clean and readable if you're familiar with port manipulation and bit shifting. 

Code

/*
* Attiny85_audio_switcher.c
*
* Version not using any arduino elements
*
* Created: 15-Jan-20 11:31:53 AM
* Author : Zac
*/
/* Cpu speed for delay */
#define F_CPU 1000000
#include <avr/io.h>
#include <stdint.h>
#include <util/delay.h>
#define NUM_CHANNELS 4
/* Function prototypes */
void gpio_init(void);
void poll_buttons(void);
void set_mux(void);
/* Pin defines*/
const uint8_t MUX_PIN[2] = {PINB3, PINB4};
const uint8_t BTN_PIN[2] = {PINB0, PINB2};
/* State variables */
uint8_t current_channel = 0x00;
uint8_t previous_channel = 0x00;
int main(void)
{
gpio_init();
while (1)
{
poll_buttons();
if(previous_channel != current_channel)
{
set_mux();
}
}
}
void gpio_init(void)
{
DDRB |= (1U << MUX_PIN[0]) | (1U << MUX_PIN[1]); /* Set mux pins as output */
DDRB &= ~(1U << BTN_PIN[0]) | (1U << BTN_PIN[1]); /* Set button pins as input */
}
void poll_buttons(void)
{
/* Increment channel */
if(PINB & (1U << BTN_PIN[0]))
{
previous_channel = current_channel;
if(current_channel < (NUM_CHANNELS - 1))
{
current_channel++;
}
_delay_ms(250); /* debounce */
}
/* Decrement channel */
if(PINB & (1U << BTN_PIN[1]))
{
previous_channel = current_channel;
if(current_channel > 0)
{
current_channel--;
}
_delay_ms(250); /* debounce */
}
}
/* Set mux pins corresponding to bits of current channel variable */
void set_mux(void)
{
for(uint8_t pin = 0; pin < 2; ++pin)
{
if(current_channel & (1U << pin))
{
PORTB |= (1U << MUX_PIN[pin]); /* Set pin */
}
else
{
PORTB &= ~(1U << MUX_PIN[pin]); /* Clear pin*/
}
}
}
view raw switcher_v2.c hosted with ❤ by GitHub

Popular posts from this blog

4 Channel Audio Switcher

Overview The purpose of this project was as a test to see if the 4051 mux would be usable in audio switching. I've been designing a programmable guitar pedal switcher and used this as a test project to see if there were any fatal issues with using them for this purpose. I also had some attiny85s around and hadn't found a project for them. Being able to use two pins to control the select lines of 3 muxes was a perfect use case. In a future iteration I'll try the 4052 mux, the only reason I didn't use one this time is because I didn't have any, and I have heaps of 4051s lying around. Bill of Materials Attiny85 3 x 4051 Multiplexers 2 x Momentary buttons 4 x Leds 5 x Stereo sockets 1 x 7805 Voltage regulator 2 x 10uF electrolytic capacitors 3 x 1k resistors Code The code for this is pretty basic, and self explanatory, with the attiny only using 2 inputs and 2 outputs. Each of the buttons either increments or decrements the current channel. Since ...

Ableton transport control

Overview The goal of this project for me is to learn more about midi protocol, and venture into ableton live remote midi scripts. This is a basic transport controller for ableton live, but it can be used for any DAW if you manually map the controls to the CC numbers sent by the arduino. The downside of using the arduino nano is that it uses a usb to serial chip to be able to program the atmega328p. As a result of this it requires the use of a serial to midi bridge to be able to communicate with midi devices. I used Hairless MIDI < - > Serial bridge to do this, which can be found here  https://projectgus.github.io/hairless-midiserial/ . If using windows you will also need some sort of virtual midi port to be able to route the midi messages to ableton, the one I use can be found here  http://www.tobias-erichsen.de/software/loopmidi.html . I only use windows so I'm not sure what needs to be done for mac or linux. The next version I work on will use atmega328u4 wh...