Building an Electric Guitar Tuner with the TM4C123GXL Evaluation Board

May we ask your familiarity w/MCUs in general - and this MCU in specific?

Someone here preaches KISS - and this project seems (somewhat) beyond normal/customary KISS bounds - especially for, "Just an intro course."

Unless the "extra credit" involves, "Piles of cash" one hears, "Danger Will Robinson!"

Hello John

How do you plan to digitize the incoming signal is not at all clear here?

Regards
Amit

It is indeed just an Intro Course and I have no familiarity with the MCU at all except for the initial lab we just completed that involved some assembly coding. I am a Computer Science major not a hardware guy. If you want the name of the class and the university it is the University of Kentucky and the class is EE383 Intro to Embedded Systems. I am an undergrad and a senior this year and I am taking this class as an elective.

For an extra credit project we can make anything we want. I have seen online where people have made Electric Guitar Tuners using Arduino boards and these projects were described as beginner to intermediate level. I am confident that if I can figure out how to sample the signal from the guitar using the Tiva C evaluation board then I can implement the autocorrelation algorithm (i.e. code it) to find the fundamental frequency. Alas, the autocorrelation method won't provide me with enough accuracy or differentiate my project enough from tuners on the market. Therefore, there a are not "piles of cash: to be made here--just a project for fun, learning and a decent sized chunk of extra credit. Plus, it would look good an a resume.

Can I route the signal from the USB through the ADC to get digitized waveform data? We have a lab toward the end of the semester that involves familiarizing ourselves with and using the ADCs. However, I need to proactively learn about them now for the sake of my project.

Anyway, I understand your concern but does anyone have any information that could help me?

Hello John,

For us to be clear, make a block diagram of the system with the intended interface and description of what the interface voltage, signal conditioning needs to be done.

Regards
Amit

Hello Amit,

I am sorry, I am not a hardware guy but a Computer Science major so I may be a bit sketchy on converting the signal from analog to digital. There exist instrument cables with standard 1/4" jack with a USB on the other end. That way, I can interface with the MCU using the micro-USB connection. So, I guess that is actually part of my question. Can the ADCs take input from the microUSB? Or, can one only connect to the ADCs via the pins on the MCU? If the ADCs can receive input from the micro-USB port then I can digitize the waveform.

Thanks Amit for the interest. Sorry about being confusing. I did not make it clear what I was asking.

Thanks Amit. I will have to check the specs on the 1/4" mono to USB cable. They don't make, to my knowledge, a cable that goes directly to micro-USB. I will have to use a USB to micro-USB to ultimately make the connection to the MCU. I will check on the specs.

Best,

John

Hello John,

Does not matter what the major is in, as long as logic is clear. The USB signal to the micro is sent to the USB Controller. On the other hand the ADC samples real world signals on the pin and not inside the device. So a Logical connection is not possible. On top of that the USB signal is not a simple 1-0 but a more complex series of events in a protocol. Thus even if we connect the USB to ADC, the ADC shall not make any sense of the signal. Note that the USB in FS mode is 12Mbps signalling rate while the ADC can sample at 1MSPS. Nyquist theorem tells is Sampling rate = 2 * Max Signal frequency.

So let us now keep USB and ADC aside and look at the signal conditioning from the source to the micro.

Also since it is going to be a lot of signal processing, might I suggest looking at a DSP as an alternative.

Regards
Amit

While "kicked strongly to the curb" KISS should still receive (some) consideration.

As stated initially - this project (likely) over-challenges - demands multiple & in-depth knowledge of multiple MCU sub-systems - and you surely have a deadline.

Might the MCU's generation of different frequencies - and/or the measurement of a "pure" sound - introduced via a microphone & routed to the MCU's ADC (properly processed & voltage limited) "avoid" the complexity of USB - yet still satisfy your musical bent?

Simplification (via KISS) best enables "real world" achievement.   "Pie in the sky" (even when - and especially when "Arduino claimed to have done it!") should be treated w/(some) caution.   (i.e. most always "high" caution...)

Amit,

Thanks for the input. I did not realize how ignorant I was concerning USB protocols. I will not be using the USB now.

As far as signal conditioning, I will need to run it through an OpAmp since voltage output for a guitar pickup is probably too low. i assume I will need  a DC offset to center the signal a little less than halfway from the maximum input voltage. I don't plan on using any filters. Do you think that should be necessary? 

Upon your suggestion, I am considering using a DSP like the one by Aida. I will still need an OpAmp according to someone from their lab. They gave a suggestion on using the MCP6004. 

Thanks for the help. I plan to do an independent study in embedded systems next semester with the same professor, If it looks like I won't have enough time to complete this project, I can put this one on the back burner for next semester and do something simpler this semester.

I did not realize how ignorant I was concerning USB protocols. I will not be using the USB now.

A highly recommended move. USB involves a rather complex protocol, and you might even be forced to write your own host USB driver for this "audio profile" device.

Upon your suggestion, I am considering using a DSP like the one by Aida. I will still need an OpAmp according to someone from their lab. They gave a suggestion on using the MCP6004.

You can do so if you wish, but it is not necessary. The M4F provides enough performance for a lot of realtime audio processing tasks. For example, I have an application (on a competitors M4F device), that does a 2048 point FFT and signal/spectre diagram drawing (also by the core) on a QVGA display in about 20% of the sampling cycle time (for 2048 values). The FFT itself takes about 2.4ms, on 168 MHz core clock frequency.

Well stated f.m. - burdening an "extra credit pursuit" w/USB rings similar to climbing Everest on a lark.   (i.e. neither proves wise - nor should be attempted - w/out serious/adequate knowledge & preparation)

To your "signal/spectrum" achievement - may I ask if the QVGA display is the one bundled w/that other's Dev. board?    If not - might you briefly describe your interface - and what served as the display's frame buffer?   Merci.

Hello John

Well deserved consideration on the complexity of the project and even better course correction. Seldom do we see folks learning this fast. Kudos

Hello f.m.

Indeed a lot is possible with M4F (ours and competitors alike).

Regards
Amit

To your "signal/spectrum" achievement - may I ask if the QVGA display is the one bundled w/that other's Dev. board?

Hi cb1, the board I used for this project, a "Mikromedia for STM32F4", came "bundled" with the display (an MIO283QT, based on a HX8347D). Here is a link:

http://www.mikroe.com/mikromedia/stm32-m4/

As I later found out, there was a string attached. Drivers for the hardware (including the display and the touchscreen) were closed souce, only sold with the (mediocre rated) IDE/Toolchain from the same company. So I had to write anything from scratch - well, almost. I took some example code for initializing the HX8347D on the display, and some FFT routines from the CMSIS DSP lib ...

Hi f.m.,

Excellent report my friend - myself (especially) & others are in your debt.

Amit may note that, "not too many Euro firms (seem) to support (his) M4 devices." (while supporting multiple, other ARM vendors)

Shortcuts - (even resourceful ones) as f.m. demonstrated - often, "Speed, Ease, Enhance" user learning & reduce critical, "Time to Market!"

Amit may note that, "not too many Euro firms (seem) to support (his) M4 devices." (while supporting multiple, other ARM vendors)

Possibly because a lot of established companies here grew up with 8/16 Bit controllers, and looking for a replacement matching in pin count, complexity, performance, power consumption, and, most of all, price. And the best match in the ARM world is the Cortex M0. That's why I still believe that not having a M0 in one's portfolio is a disadvantage for TI.