标签: MAX32

Do you remember my recent blog about the Dr. Duino diagnostic shield that you can use to diagnose problems in your Arduino Uno and chipKIT Uno32 shield stacks?     Designed by Guido Bonelli Jr., this little scamp was a successfully funded Kickstarter Project . Well, I was just rooting around SparkFun's website (I can't help myself, they have so much cool stuff with which they keep on tempting me) when I saw that Dr. Duino is right up there on the front page as a "Kickstarter Staff Pick," which is a pretty good endorsement if you ask me.   I am glad it succeeded, because I really want one of these little beauties myself. As I said in my previous blog on this topic:   Now, this is the clever bit. Although it's not immediately obvious from the image above, the header pins sticking out of the bottom of the Dr. Duino (the ones that plug into the board above) and the corresponding headers sticking out of the top of the Dr. Duino (the ones into which the board above will be connected) are offset. By means of jumpers on the Dr. Duino, you can either pass the signal directly through from the board below to the board above (and vice versa, of course), or you can break the connection between the adjacent boards and route the signal to one of the components on the Dr. Duino.   In the case of the six analog input pins available on the Arduino Uno, for example, the Dr. Duino provides each of them with a 10KΩ potentiometer that you can "jumper-in." The reason this is of interest is that I was building myself a set of animatronic robot eyes over the weekend (there wasn't anything good on TV), and I realized needed four 10KΩ pots in order to fine-tune the eye movements (each eye can turn left-to-right independently) and the eyelid movements (each eyelid can blink independently).   Wouldn't you know it, I realized I was out of 10KΩ pots (I'd used the last of my existing stash on another project). That was the moment when I thought to myself, "Oooh, I so wish I had a Dr. Duino right now!" Quite apart from anything else, I really want this Kickstarter to succeed, because if it does, Guido says he would be interested in my thoughts as to what should be on a bigger version for use with Arduino Mega and chipKIT Max32-based systems.   Since I constantly seem to have numerous projects on the go using both of these platforms, this is an amazing opportunity for me to provide input with regard to the diagnostic capabilities I've discovered a need for over recent months. How about you? If you could add anything to the current Dr. Duino board or to a future board, what would that be?

As you probably know, I'm spending a lot of my free time creating Arduino-based projects, such as my Inamorata Prognostication Engine , my BADASS Display , and my Vetinari Clock .   Some of these projects involve the use of shields, which are boards that can be plugged on top of the Arduino in order to extend its capabilities. The thing is that you can quickly end up with a stack of shields performing tasks like motor control, sound effects generation, a real-time clock (RTC), and all sorts of other things.   Every now and again, you run into a situation whereby things aren’t working quite as expected. You aren’t sure exactly what's going wrong, and it can be really difficult to diagnose the problem. Guido Bonelli ran into this type of problem while creating an Arduino-based piece of abstract art called Orbis. His solution was to create a board he calls Dr. Duino.   You can tell that Guido has put a lot of thought into this. If you plug the Dr. Duino onto the top of your Arduino Uno (as shown in the image below) or as the uppermost board on the top of a stack of shields, then the large hole in the middle of the Dr. Duino provides you with full access to the board directly underneath.   Alternatively, you can sandwich your Dr. Duino between two of the boards in the stack. Now, this is the clever bit. Although it's not immediately obvious from the image above, the header pins sticking out of the bottom of the Dr. Duino (the ones that plug into the board above) and the corresponding headers sticking out of the top of the Dr. Duino (the ones into which the board above will be connected) are offset. By means of jumpers on the Dr. Duino, you can either pass the signal directly through from the board below to the board above (and vice versa, of course), or you can break the connection between the adjacent boards and route the signal to one of the components on the Dr. Duino.   Speaking of which, the Dr. Duino comes complete with test points, LEDs, switches, potentiometers, a piezo buzzer, an RS-232 interface, and an external reset switch that will not be blocked by any shields above it.   Any shield that uses the standard Arduino Uno footprint can benefit, including the chipKIT Uno32 from Digilent. Just yesterday as I pen these words, Guido launched his Dr. Duino Kickstarter project . Personally -- knowing how much things cost from our own Screw-Block Proto-Shield for Arduino Kickstarter project -- I think the Dr. Duino kit is an amazing bargain at only $36.   My next trick -- once his current Dr. Duino Kickstarter project has successfully concluded -- will be to persuade Guido to create a version that will work with my Arduino Mega and chipKIT Max32 boards. In the meantime, what do you think about Dr. Duino? Is this something you could use? Is there anything you would add for the Mega/Max32 version?

Good grief! I wonder where time goes. It seems like only a couple of days ago that I was waffling on about my MSGEQ7-Based DIY Audio Spectrum Analyser . However, the sands of time have wended their way through the hourglass, as is their wont; the days have turned into weeks; and thus we find ourselves in the "here-and-now."   What can I say? I'm too young for all of this excitement (LOL). As usual, just to set the scene before we leap headfirst into the fray with gusto and abandon, let's first take a look at this short video to remind ourselves as to just how cool this looks in the real world.     Now, in this column, I'd like to share a few extra tidbits of trivia and nuggets of knowledge that I've picked up along the way. With regard to accessing the spectrum data from the MSGEQ7s, let’s start by reminding ourselves of the official timing requirements from the data sheet, as illustrated below.     As we see, a positive-going pulse on the RESET signal kicks everything off. This pulse takes a copy of the current peak detector outputs and stores (latches) the values. We then apply seven negative-going pulses to the STROBE input. Every time the STROBE input goes low, we can read the value of one of the bands on the DATA_OUT signal, starting with 63 Hz and working our to 16,000 Hz.   The DATA_OUT is an analog value whose magnitude reflects the value from the corresponding peak detector. This value can be read using one of your microcontroller's analog inputs. (Observe that the DATA_OUT signal is clamped to 0V when the STROBE signal is HIGH.)   When I originally purchased the MSGEQ7 chips, I looked around on the Internet to see if there was any sample code to start me on my way. In fact, I found quite a few different examples, each doing things in slightly different ways, but a representative version of the function used to read the spectrum data values from the MSGEQ7s might be as shown below.     Note that the names I use for the RESET and STROBE signals in my code are "ctrlReset" and "ctrlStrobe," respectively. As we see, we start with a positive-going pulse on the ctrlReset signal, and then we enter a loop to read the seven data values. Observe that the only delay that is explicitly defined occurs after the ctrlStrobe signal is driven LOW. According to the data sheet, the minimum output settling time is 36 µs, and some of the examples I found used this exact value, but in my code I boosted this up to 40 µs, just to "make sure."   To be honest I feel like an old fool (but where are we going to find one at this time of the day? LOL). I know better than to simply use someone else's code without thinking about it, but that's what I did, and it worked, so I might have simply left it at that, but...   ...as I was driving into work one morning, I suddenly got a "niggly feeling" about the width of the positive-going pulse on the ctrlReset line. From the data sheet, we know that this pulse has a minimum width of 100 ns. It struck me that all of the code examples I'd seen had been for an 8-bit Arduino Uno or Arduino Mega running at 12 MHz, but I'm running this on a 32-bit chipKIT MAX32 running at 80 MHz. Could it be that my pulse was too narrow?   I started off under the misguided assumption that the compiler would optimize and/or convert the "digitalWrite (ctrlReset, HIGH);" and "digitalWrite (ctrlReset, LOW);" function calls into low-level instructions that would be executed in a single clock cycle. On this basis, the width of the positive-going pulse on the ctrlReset signal on my chipKIT would be 1/80,000,000 = 12.5 ns, which would be way too narrow. Even on an Arduino, this pulse width would be 1/12,000,000 = 83 ns, which would still be too narrow.   But my system was doggedly working, so what was going on? In order to see what was happening in the real world, we hooked everything up to an oscilloscope. The results were as illustrated below:     Imagine my surprise to discover that the positive-going pulse width of the ctrlReset signal on my chipKIT was actually 800 ns. What this means is that "digitalWrite (ctrlReset, HIGH);" and "digitalWrite (ctrlReset, LOW);" function calls aren’t being optimized into low-level instructions. Instead, they are being executed as full-blown function calls, which involve things like pushing stuff onto the stack. This means that each of these high-level statements is actually consuming 800ns/12.5ns = 64 instructions. On the one hand I thought "Wow! That is really inefficient." On the other hand, I thought, "Well, at least my pulse is wide enough."   But now look at the reset-to-strobe (trs) time. From the data sheet, this has a minimum value of 72 µs, but the measured value is only 800 ns, which is only approximately 1% of the required value. The MSGEQ7 is obviously a fairly robust little chappie; in fact, it's amazing that it worked at all. Even though it did work, however, I decided to add the appropriate delay as illustrated below (once again, I added a couple of microseconds for safety's sake).     At 49 µs, the low-going ctrlStrobe pulse width (ts) exceeds the minimum specified value of 36 µs. But look at the narrow high-going pulses on the ctrlStrobe signal. Since the minimum strobe-to-strobe time is specified as 72 µs, these high-going pulses should have a minimum value of 72 - 49 = 23 µs. However, their actual width was only 800 ns (the delay associated with the combination of the "digitalWrite (ctrlStrobe, HIGH);" statement at the end of the loop followed by the "digitalWrite (ctrlStrobe, LOW);" statement at the Beginning of the loop), which is only around 3.5% of the desired value. Once again, even though the original code did work, I decided to add another delay as illustrated below (as usual, I boosted this up somewhat to give myself some "breathing room").     The final code for the "readMSGEQ7s()" function I'm currently using is shown below. You will observe that this includes a simple noise filter in the form of the two instructions highlighted in yellow.     The thing is that even when no music is playing, you tend to get low-level noise when you read the DATA-OUT signal. In turn, this causes the LEDs to flicker, which you don’t really want between tracks. I played around a little and determined that removing anything below a value of 50 worked rather well, but then I changed this to a value of 42 (the answer to "life, the universe and everything") on a whim.   Last, but not least, speaking about noise, I was looking at some code created by my chum Steve Manley for use with his MSGEQ7-based system when I noticed that he'd read his DATA_OUT value twice and averaged the two values. In the context of my code, and just considering the left channel, this would look something like the following:     When I asked Steve why he'd done this, he said that he'd heard that this was a useful technique to mitigate against unwanted noise on the DATA_OUT signal. In fact, Steve said he's actually seen people averaging four samples (as shown below) and even eight samples (which seems to be overly enthusiastic, if you ask me).     Since I'm always "game for a laugh," I ran a few experiments comparing the results from using one, two, and four samples. I looked at both the LED displays and the corresponding numerical values -- and I really couldn’t see much difference, so I returned to using a single sample. However, I would be very interested to hear your thoughts on this. Have you seen this technique being used or used it yourself? Are there any situations when one really should make use of multiple samples in this manner? As always, I welcome any comments and questions.

As you may remember, one of my current hobby projects is my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic Display (a.k.a. BADASS Display ). I will be the only one on my street to have one of these little beauties; how the neighbors will envy me (LOL).   The display itself is going to use about 10 meters of NeoPixels from Adafruit, all controlled by an Arduino Mega development kit, which is powered by a microcontroller from Atmel. Meanwhile, the audio stream from my iPad is going to be analyzed by a chipKIT MAX32, which is powered by a microcontroller from Microchip.   Now, one way to test this little beauty (when I finish building it, of course) will be to simply plug the audio output from iPad straight in and see what happens. Personally, however, I prefer to take things in stages. I've been thinking that it would be very handy to have an audio frequency generator that I could use to inject specific frequencies into the system to check its response.   This requirement was turned up a notch when my chum Steve Manley, who is currently blogging about one of his hobby projects, suggested I take a look at the MSGEQ7 Graphic Equalizer from SparkFun.   The MSGEQ7 chips are great. You feed an audio signal into one of your MSGEQ7s, which then filters out seven frequency bands centered around 63Hz, 160Hz, 400Hz, 1,000Hz, 2,500Hz, 6,250Hz, and 16,000Hz. I've decided to use these devices to test out the rest of the system before moving on to use digital signal processing (DSP).   I will be using two MSGEQ7 chips -- one for each audio channel -- but I actually purchased four of the little rascals, "just in case." Steve told me that he's bought a bunch of these, and that he really likes them, but that their sensitivity and response can be quite variable. Thus, he suggested using a frequency generator to feed the same frequency to all of the chips, to compare their, responses, and to pick the two with the closest match (I can also apply "fiddle factors" in software of necessary).   The end result is that I really need a frequency generator. Now, there are a variety of very tasty-looking frequency generator apps for the iPad, but I'm already using that over-worked little ragamuffin to generate the audio stream and as an oscilloscope using my Oscium iMSO-204 .   My first port of call was to meander my way into the next bay and talk to my chum Ivan. Even though they don’t actually have a need for a frequency generator, Ivan rooted around under a bench and extracted a somewhat battered old case.     After blowing the dust off, he opened the case to reveal...     ...something that scared the socks off me. I'm not quite sure what this is. I think it's a creation Ivan pulled together deep in the mists of time. He assured me that this would satisfy all my signal generating needs (once he'd worked out how to use it again), but I'm sad to say that I remained unconvinced. Once more, Steve Manley came to the rescue. When I asked him what he used to test his sound-to-light creations, he pointed me at the FG085 MiniDDS Function Generator kit from those little scamps at SparkFun. Based on Steve's glowing recommendation, I decided to invest in one of these little beauties. I don’t know about you, but I find there's something exciting with an air of expectation about an unopened package containing some electronic goodie sitting on one's workbench.     This function generator kit falls under the heading of "some assembly required." Happily, all of the finicky surface-mount devices have already been installed on the main board for you.     All that's left are things like the through-hole capacitors, connectors, buttons, and other bits and pieces. On the other hand, there are certainly enough of these to make you feel as though you are earning your keep.     Fortunately, the "quick start" assembly instruction sheet was very well done, and it really didn’t take long at all to pull everything together and set it running.     I'm also impressed with the intuitive interface and the associated ease-of-use. You can select between continuous waveforms of Sine, Square, Triangle, Ramp (up and down), and Staircase (up and down). It's immediately obvious how to select things like the frequency (0 to 200KHz), peak-to-peak amplitude (0 to 10V), and DC offset (-5 to +5V) and set them to your required values. You can enter initial values using the keyboard then make fine adjustments using a rotary switch.   You can also use this little beauty to generate servo test/control signals with microsecond resolution with user programmable pulse width, amplitude, and cycle. All-in-all, I have to say that this $49.95 kit is well worth the money. The next step is to use it to drive my BADASS Display; watch this space...