In the last installment I introduced the Arduino uno groovebox concept. In order to be able to realize the design we need to use some libraries in order to perform the required tasks. Let me say that choosing the libraries can sometimes be an iterative process. Maybe we have to change our initial choice later. But we have to start somewhere, that is perform our first iteration. So, let's see the components we will use and the libraries we can utilize to communicate with them.
1. Sound generation. This is maybe the most important component. Arduino uses a microcontroller as its processor. It is an ATMEL atmega 328p with 32Kb of flash memory, 2Kb of ram and 1Kb of EEPROM. It doesn't have a pcm codec like a PC or even raspberry pi have. So in order to produce sound we need either some additional component like an i2c dac, or we can use a PWM output and then filter it to produce a signal that can be fed to headphones, an amplifier or recording equipment. The approach I chose is to use PWM because I did not have a dac, and from the research I did, I found that PWM output does sound OK, if properly filtered. The first candidate for sound generation was Mozzi, a fantastic library with excellent documentation. You should definately check it out: http://sensorium.github.io/Mozzi/
2. Library for the 128x64 OLED display: I searched for a driver/library to drive my OLED display. The display uses an SSD1306 chip. The particular display in my case was wired as SPI. You can find i2c or SPI/i2c versions in various places and with various prices. I bought 5 of those displays for under 20 euros in order to use them in various projects. The good thing about this display is that you can show a lot of information, With an 8x8 character matrix you can show 8 lines of 16 characters. That is a lot of information. The display is pretty crisp too! The only problem is that it is smallish, so if you are a bit older you may have trouble reading it. You can see details for the wiring in this Adafruit tutorial: https://learn.adafruit.com/monochrome-oled-breakouts
The library I initially used is this one: https://github.com/adafruit/Adafruit_SSD1306. This library supports both SPI and i2c and it uses the Adafruit GFX library (a separate download) for text and graphics rendering. Using the wiring documentation above and the library, I managed to connect the OLED display to arduino uno without any problems.
3. Library/code for rotary encoder support. Anyone interested in reading rotary encoders with arduino should definately check out this post by Oleg Mazurov: https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino
At first it was not working, but the problem was not in the code but rather on my poor soldering skills. You see I made 2 small breakout boards in order to make the encoders breadboard friendly and I created some sort circuits. When I found the problem Oleg's code worked like a charm.
4. Library code for reading the buttons. No worries about this one! The support is built in arduino. Just configure the input pins with the INPUT_PULLUP parameter like this
1. Sound generation. This is maybe the most important component. Arduino uses a microcontroller as its processor. It is an ATMEL atmega 328p with 32Kb of flash memory, 2Kb of ram and 1Kb of EEPROM. It doesn't have a pcm codec like a PC or even raspberry pi have. So in order to produce sound we need either some additional component like an i2c dac, or we can use a PWM output and then filter it to produce a signal that can be fed to headphones, an amplifier or recording equipment. The approach I chose is to use PWM because I did not have a dac, and from the research I did, I found that PWM output does sound OK, if properly filtered. The first candidate for sound generation was Mozzi, a fantastic library with excellent documentation. You should definately check it out: http://sensorium.github.io/Mozzi/
2. Library for the 128x64 OLED display: I searched for a driver/library to drive my OLED display. The display uses an SSD1306 chip. The particular display in my case was wired as SPI. You can find i2c or SPI/i2c versions in various places and with various prices. I bought 5 of those displays for under 20 euros in order to use them in various projects. The good thing about this display is that you can show a lot of information, With an 8x8 character matrix you can show 8 lines of 16 characters. That is a lot of information. The display is pretty crisp too! The only problem is that it is smallish, so if you are a bit older you may have trouble reading it. You can see details for the wiring in this Adafruit tutorial: https://learn.adafruit.com/monochrome-oled-breakouts
The library I initially used is this one: https://github.com/adafruit/Adafruit_SSD1306. This library supports both SPI and i2c and it uses the Adafruit GFX library (a separate download) for text and graphics rendering. Using the wiring documentation above and the library, I managed to connect the OLED display to arduino uno without any problems.
3. Library/code for rotary encoder support. Anyone interested in reading rotary encoders with arduino should definately check out this post by Oleg Mazurov: https://www.circuitsathome.com/mcu/reading-rotary-encoder-on-arduino
At first it was not working, but the problem was not in the code but rather on my poor soldering skills. You see I made 2 small breakout boards in order to make the encoders breadboard friendly and I created some sort circuits. When I found the problem Oleg's code worked like a charm.
4. Library code for reading the buttons. No worries about this one! The support is built in arduino. Just configure the input pins with the INPUT_PULLUP parameter like this
pinMode(BUTTON_1,INPUT_PULLUP);
Well, not so fast my friends. Why? Well these parts work OK on their own but when you try to make them work together problems DO occur.
For example some libraries use particular pins that cannot be shared. Some others use a lot of precious ram starving the other libraries from it. So what seems a good start at first, may need some iterations before it works adequately as a system with the required functionality.
So in our next blog post, we will go through some of the iterations required to make those libraries work together and even replace them with others in order to achieve the necessary interoperability and performance.
