标签: chipKIT

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?

Nothing is simple, right?. I ran into a minor "gotcha" with regard to my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display project. As you may recall from my previous blog on this topic, I'm planning on implementing a 16 x 16 array of tri-colored LEDs using NeoPixel Strips from Adafruit. I'm also planning on controlling these little beauties using an Arduino Mega 2560 R3 microcontroller development board.   When it comes to processing the audio stream from my iPad to extract its frequency data, which will subsequently be handed over to the Arduino Mega to be displayed, I'm planning on experimenting with a variety of approaches. (See also Selecting interface for linking MCUs .) A couple of these approaches will involve a chipKIT Max32 microcontroller prototyping platform.   The NeoPixel strips require a 5V power supply. Each LED can draw as much as 60mA if all three of its RGB channels are full-on. In reality, it will be rare indeed for all 256 LEDs to be fully on, but I prefer to design for worse-case scenarios. In this case, this would be 60mA x 256 = ~15.6A. In order to accommodate this, I ended up purchasing a 26A highly-regulated power supply as shown below.     Now, the Arduino Mega and the chipKIT Max 32 both require an external supply of between 7V and 12V. When this supply is fed into the board, it is first regulated down to give a constant 5V supply and then regulated down again to provide a 3.3V supply. Alternatively, these boards can also be powered from a USB programming cable, which can provide a 5V supply.   The problem is that things tend to get messy if you are powering each unit from a different supply. Quite apart from anything else, I really don’t want three power cables coming out of the display. Also, if you are using different supplies, then you can't be sure which sub-unit will power up first and you can end up with one unit back-driving another, which is not generally considered to be an ideal situation.   The bottom line is that I really want everything to be driven from my 26A supply. That way I cut down on the cables and on the power supplies, things are neat and tidy, and everything will power up together.   WARNING: The following describes some modifications that I decided to make to my microcontroller boards. Please understand that I am not recommending that you do this to your own boards, because you could easily damage them and invalidate any warranties that came with them. (Yes, these are the obligatory weasel words, but it always pays to remember the old saying: "Eagles may soar, but weasels rarely get sucked into jet engines.")   Modifying the Arduino Mega This is the point where my techno-weenie chum Ivan Cowie leaps into the center of the stage with a cloud of smoke and a fanfare of trumpets. Ivan, whose office is in the next bay to mine, is a diva when it comes to power supplies and their wily ways. Ivan first looked at the PDF schematic diagram for the Arduino Mega. You can access the entire schematic by clicking here , but the relevant portions are shown below:   Subset of the Arduino Mega schematic diagram.   Within just a couple of seconds, Ivan had determined what was required. Since he was jabbing his finger at different parts of the schematic and chattering away at the same time, it was easy to see how he came to his conclusions. The following is pretty much the way he explained it on the fly…   As we see, the external power supply comes in at the top left-hand side. First it is passed through diode D1, which is used to prevent the USB port from back-driving the main power supply (we'll come back to this later). The output from this diode is VIN, which is fed into the regulator IC1. It's the output of IC1 that drives the +5V signal.   But wait, look here… In the bottom of the schematic we see signal USBVCC. This is the five volt supply from the USB cable. This signal is passed to transistor T1, and the output from T1 is also connected to the +5V signal. Thus, the +5V signal may be driven from the external power supply via the voltage regulator, or it may be driven from the USB port.   Now look at the resistor divider formed from two 10KΩ resistors in the bottom left-hand corner of the schematic. This is fed by VIN. If no external supply is connected, then the output from the resistor divider, the CMP signal, will be 0V. This is fed to one of the inputs to comparator IC7B. The other input to IC7B is fed from the +3V3 supply. This means that if no external supply is connected, then the output from comparator IC7B will turn transistor T1 on, thereby allowing the USBVCC supply to drive the +5V line.   By comparison, suppose we have a 9V supply. The voltage drop across diode D1 could be anywhere from 0.3 to 1.0V, depending on the type of diode. If we assume a worse-case value of 1V, then VIN will be 8V. When this is fed into the resistor divider, the signal CMP will be 4V. This will cause the output from comparator IC7B to disable transistor T1, thereby blocking the USBVCC supply and allowing the output from the regulator to drive the +5V signal. Now, we want to drive the Arduino Mega from an external 5V supply. Even if diode D1 has a voltage drop of only 0.3V, this is still too much, so we are going to short it out. Next, we are going to remove voltage regulator IC1 and connect its input (pin 3) to its output (pin 2). This means our 5V supply is now connected directly to the +5V rail.     But now we have a problem. We are now feeding 5.0V into the resistor divider, which means the CMP signal will be only 2.5V. This is less than the value on the +3V3 rail, which means the comparator IC7B will turn transistor T1 on, thereby allowing the USBVCC supply to drive the +5V rail as well. In order to get around this, what we're going to do is to solder a 5.6K resistor in parallel with the upper resistor in the network.   Ivan further noted that he picked a value of 5.6KΩ because he happened to have some of these resistors handy. Also, that we had to solder this on top of the upper resistor, because both of these resistors were presented in a four-resistor pack. So what we now have is a 10KΩ resistor in parallel with a 5.6KΩ resistor. Using the formula RP = (R1 * R2) / (R1 + R2), this gives us a combined resistance of ~3.6K. In turn, when our 5V supply is now used to drive the resistor divider network, the CMP signal will be ~3.7V. This is higher than the +3V3 signal, so the comparator IC7B will disable transistor T1. Et voila! (Ivan didn’t actually say Et voila! But I could hear it in his voice.)   Suiting his actions to his words, Ivan went on to make the changes to my Arduino Mega as illustrated below. As soon as he'd finished, we tried powering the board only from my 5V supply. Everything worked perfectly. (Hurray!) Next, we tried powering the board only from the USB cable. Once again, everything worked as expected. (Double hurray!)     Finally, we connected the board to both the 5V power supply and the USB cable. As we expected, the CMP signal was high enough to cause comparator IC7B to disable transistor T1. (Triple hurray!)   Ivan also noted that there's one thing to be careful of here. If the 5V power supply is connected to the board, then it must also be plugged into the wall before one connects the USB cable. This is because we removed diode D1. If the 5V supply is connected to the board but it's not plugged into the wall, then when the USB cable is connected it will back-drive the power supply. The resulting current surge might cause the USB port to turn itself off, which wouldn’t be a disaster, but would be jolly annoying.   Modifying the chipKIT Max32 Our next step was to take a look at the PDF schematic diagram for the chipKIT Max32. Once again, you can access the entire schematic by clicking here , but the relevant portions are shown below.   Subset of the chipKIT Max32 schematic diagram.   The external power supply enters the upper left-hand side of the schematic via connector J2. By default, jumper JP1 is set to connect pins 2 and 3. This means that the external supply is fed to diode D2. The output from diode D2 feeds the input to the voltage regulator IC4, the output of which drives the VCC5V0 rail. This rail is fed to voltage regulator IC3, the output of which drives the VCC3V3 rail.   In the bottom right-hand corner of the schematic we see a comparator IC5G1. The output from this comparator is used to control transistor Q1. In turn, this transistor either enables or disables the USB5V0 supply coming from the USB cable. In this case, it looks as though the designers of the chipKIT Max32 have largely anticipated our needs. At first glance, it would appear that all we have to do is move jumper JP1 such that it connects pins 1 and 2 instead of 2 and 3. This simply bypasses diode D2 and regulator IC4, and connects our external 5V supply directly to the VCC5V0 rail. Sad to relate, however, there is a small "gotcha." Note the resistor divider network formed from resistors R13 and R14 in the upper left-hand corner of the schematic. This is similar to the Arduino Mega. The VCMP signal from the resistor divider is used to feed the input to comparator IC5G1.   There won’t be any problem if we use only our external supply to power the board. Similarly, there won’t be an issue if we use only the USB cable to power the board. The problem arises if both the external supply and the USB cable are plugged in at the same time. In this case, our 5V supply being fed into the resistor divider will leave VCMP at 2.5V, which means transistor Q1 will be turned on and the 5V supply coming through the USB cable will end up fighting our external supply.   If only the designers of the chipKIT Max32 had thought to provide another jumper allowing us to change the value of R13, but they didn't (sad face).   When you are in a prototyping situation, you very often want to connect the USB cable to tweak your program. Now, I could make the decision only to have the external supply or the USB cable plugged in at any particular time. With the best will in the world, however, I'm sure I would forget. As before, the solution is to solder a 5.6KΩ resistor in parallel with resistor R13 as illustrated below:     Once again, we tested the result first with the 5V external supply on its own, then with the USB cable on its own, and finally with both the external supply and the USB cable plugged in. In all three cases, everything worked as planned (happy dance).   So, there you have it. I'm now able to power my 256 LEDs, my Arduino Mega, and my chipKIT Max32, all from the same 5V 26A supply. All I have to do now is finish my BADASS display…

In my recent column , I related my plan to load the robot I'm building with a cornucopia of sensors. The problem with having a lot of sensors is that we have to process the raw data they are receiving and turn it into useful information. If we're not careful, the robot's main processor will be spending all of its time wading through data from the sensors without having any computational resources free to do anything useful. One solution, as we discussed, is to have a small processor associated with each sensor, and to pre-process all of the raw sensor data into useful information like "Eeek! There's a big hairy object approaching at speed from a northwest direction," thereby leaving the main processor free to make executive-level decisions like "Run away!" But even if we do offload the low-level processing tasks, we could still overwhelm the main processor if we deploy a sufficient number of sensors. The solution is to use a faster, more powerful processor for your main controller, but what are the alternatives that are open to us? Mainstream Arduinos I am currently the proud owner of an Arduino Uno , which is based on an 8bit ATmega328 processor. This little scamp offers 14 digital input/output pins (of which six can be used as PWM outputs) and 6six analogue inputs. It uses a 16MHz clock and boasts 32 KB of flash memory and 2 KB of SRAM.   The Arduino Uno. Although the Arduino Uno is almost inconceivably more powerful than the processors of my youth, and it's more than powerful enough to satisfy the requirements of a wide swathe of users, it's a tad lightweight with regard to the number of sensors I intend to deploy on my robot. One option would be to move up to the Arduino Mega , which offers 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analogue inputs, and four UARTs:     The Arduino Mega. Once again, however, the official Arduino Mega is based on an 8bit ATmega1280 processor running at 16MHz. Another alternative is to use an Arduino Due , which is based on an Atmel SAM3X8E ARM Cortex-M3 microcontroller:   The Arduino Due. This little beauty offers 54 digital input/output pins (of which 12 can be used as PWM outputs), 12 analogue inputs, and 4 UARTs. In addition to the fact that it's got a 32bit data path, the Arduino Due employs an 84MHz clock and boasts 512 KB of flash memory and 96 KB of SRAM. Arduinos on steroids One of the great things about the Arduino is that everything is open-source. Due to this, a wide variety of Arduino-compatible development boards have appeared on the market. One set of boards that really makes my mouth water is the chipKIT family . The original members of the chipKIT organisation were Microchip Technology, Digilent, and Fubar Labs. These companies have since been joined by other members, such as the folks from element14. In fact, the most recent Arduino-compatible chipKIT platform—the chipKIT Pi—comes from Microchip and element14. The chipKIT Pi can interface directly to the Raspberry Pi's I/O expansion header, but that's a story for another day. In addition to the raw processing power of the chipKIT platforms (as discussed below), the thing that really differentiates these little beauties from the herd is the amount of effort the chipKIT folks put in to making the transition from Arduino to chipKIT as seamless as possible. You do need to download a new development environment called MPIDE (multiplatform integrated development environment), but once you've done so you'll find it looks almost identical to the standard Arduino software. But it's the boards that make you drool with desire. Let's start with the chipKIT Uno32 , which is the same form factor as the Arduino Uno and is compatible with many of the standard Arduino shields. (The reason for this "many" qualifier is that some shield creators write libraries that talk directly to the AVR hardware, which sort of goes against the Arduino philosophy of keeping things portable by writing to the abstraction level.)   The chipKIT Uno32. The Uno32 board is based on the powerful PIC32MX320F128 microcontroller, which features a 32bit MIPS processor core running at 80MHz along with 128 KB of flash program memory and 16 KB of SRAM data memory. One thing that immediately caught my eye was the chipKIT Pmod Shield-Uno . This is an input/output expansion board for use with the chipKIT Uno32 that provides five 2x6 Digilent Pmod connectors (it also provides access to the I/O connectors available on the Uno32 as well as connecting to the I2C bus supported by the Uno32).     The chipKIT Pmod Shield-Uno. Have you seen all of the Pmod modules offered by Digilent? (You can also get modules from other companies like Analog Devices, Maxim, and Texas Instruments.) These include GPS receivers, 3-axis digital accelerometers, 3-axis digital gyroscopes, 3-axis digital compasses, microphones with amplifiers... basically a bunch of things I intend to add to my robot. At the other end of the spectrum we find the chipKIT Max32 prototyping platform . This little rascal has the same form factor as the Arduino Mega board and is compatible with many Arduino shields as well as larger shields for use with the Mega boards.     The chipKIT Max32. The Max32 board is based on the powerful PIC32MX795F512 microcontroller, which features a 32bit MIPS processor core running at 80MHz along with 512 K of flash program memory and 128 K of SRAM data memory. In addition to supporting 83 inputs and outputs, the processor provides a USB 2 OTG controller, 10/100 Ethernet MAC, and dual CAN controllers that can be accessed via add-on I/O shields. Wow! My head is spinning. I feel like I'm spoilt for choice. To be honest, I actually think I might end up using a hierarchy of controller boards (in addition to the microcontrollers on the sensor boards) with one in overall charge and the others each delegated to focusing on a certain task. This is all going to take some thinking about—watch this space for ongoing developments.

  去年参加的Designspark的比赛，获得的奖品！