Review of EasyPIC Fusion v7

Table of contents

RoadTest: EasyPIC Fusion v7

Author: antosh

Creation date: 11 Aug 2013

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Microchip Explorer 16, Mikroe EasyPIC v7 Connectivity, Mikroe LV-32MX v6 PIC32 eval board, Mikroe 24-33 v6 eval board, Freescale K70 Tower

What were the biggest problems encountered?: The demo ran once and then would not run again. I plan to reload the demo code and update the score based on the result. I don't expect it to be a problem. UPDATE: Sure enough, it was user error. I enabled all PORT LEDs which caused a conflict with the touchscreen interface. Read the review for details - in short the demos run exceptionally well. UPDATE 2: The other demos had to be recompiled for the new TFT controller. See the RoadTest for details. UPDATE 3: Most SPI channel 2 signals are not connected on the Mikroe PIC32 MCU Card by design. Not sure why...

Detailed Review:

If you enjoyed this RoadTest, please click “like” at the bottom of this page.

*** The pdf is now posted below. The recent website update has helped quite a bit. I am still working on the embedded images below. Still more resizing required!

While the pdf has all of the figures, and better formatting, I am adding the figures to this page as well. It is a time consuming process.

RoadTest of the Mikroe EasyPIC Fusion v7 Development board for PIC24, dsPIC33, and PIC32

By antosh

The Mikroe EasyPIC Fusion v7 is MikroElektronica's latest prototyping board for the Microchip PIC24, dsPIC33 and PIC32 microcontrollers.

This board uses plug-in MCU Modules that house the microcontroller. I have a dsPIC33 MCU Card on order and I paid about $26 for it (plus S&H).

The board is intended for prototyping of designs and pulls upon Mikroe's existing product line that features many accessories that can be used to rapidly prototype a system.

This board's intended audience includes students learning microcontrollers (or programming), hobbyists, and even professional embedded systems engineers who want to rapidly prototype a new design.

I plan to split this review into multiple parts and post them as they are completed. This first part will cover unpacking and first impressions. Next week, I plan to give my experience after using the board for a while and an attempt at migrating an 8-bit design from the Mikroe EasyPIC v7 “Connectivity” board to this board.

Once all portions are complete, I’ll combine everything into one pdf and post it.

Unpacking the board

I’ve been a hobbyist, engineer, and educator of microcontrollers/embedded systems for over 15 years. I’ve collected various development boards over that time and storing them in an accessible fashion is not easy. Many come in strange or odd-sized form factors and are hard to store. Freescale’s Tower comes to mind...

I like Mikroe’s approach with a bookcase-friendly box. It’s not perfect as it won’t store a board with a complex prototype design on it, but the board by itself is easily accessible with this system. Figure One shows the box with the identification sticker on the “spine” of the box that shows which board , microcontroller, and configuration came in the box.

The size of the box is just under 3” wide by 9.25” deep by 11.125” tall.

Figure Two shows the box next to a textbook. You can see the box is a bit deeper than the book, but about the same height. The same box is used for the EasyPIC v7, and they look nice next to each other in my library.

Figure Three shows how the inner box is divided in two with the board packed in an ESD bag on one side and the documentation, USB cable and DVD with drivers plus a trial of MikroC on the other. 

This roadtest came with a dongle-licensed MikroC compiler as well. Its DVD case was placed inside of this box. Figure Four shows the contents of the box. The Manuals, schematic and DVD is inside of printed manual. The manuals and schematic are printed on very quality paper. The DVD case at the bottom left is Mikro C32 PRO compiler with dongle inside.

First Impressions of the Board

I have seen some quality control issues with Mikroe development boards in the past. LEDs that never lit up, bridged solder joints (not fun to troubleshoot) and some poor quality components. I was very curious to see if any of these quality issues arose with this newest board.

Taking the board out of the ESD bag and just looking at it allows appreciation of Mikroe’s pedigree in designing these development boards. I really liked the 8-bit EasyPIC v7 connectivity board’s layout over previous Mikroe boards. They kept the spirit of that approach on the EasyPIC Fusion v7. Signals and LEDs are laid out by port along the bottom of the board. An additional connector for each port is along the right-hand side.  See Figure Five.

Figure Six shows a close-up of Port B. It is laid out with a DIP selecting a pull up/none/down resistor,  LEDs with co-located pushbuttons, and a 2x5 connector which has Vcc and GND. This connector is handy for prototyping and/or measuring signals.

I have to say I really like the 8-bit connectivity board’s LED layout of one row of eight LEDs. The LEDs lighting up in this manner act as a very basic logic analyzer / logic probe to see what your code is doing. The Fusion board changes this up a bit with a “two rows of four” (2x4) approach. I’ll see how much this matters as I continue to the road test.

While Mikroe did reduce the number of connections on each pin from three on the 8-bit connectivity board to two on this fusion board, I see that as a fair trade for the added features of this board. I’ve  never used more than two connections per pin anyways and Mikroe has a couple of add-on boards that will provide extra connectivity if needed. I’ll cover some of those as this road test continues. Two connections per pin allows for a logic analyzer or oscilloscope to be connected simultaneously to a prototype with off-board hardware.  I often use Mikroe’s EasyPROTO “board” which is a 1x10 breakout cable to take the 2x5 port connectors to a breadboard for rapid prototyping. Watch for it in the near future as I migrate an 8-bit design to the PIC32 on the Fusion board.

Another item that jumps out at me is a drastically reduced number of jumpers on this board over the 8-bit v7 connectivity board. The 8-bit board has a plethora of jumpers for selecting which ICD, oscillator sources, where on-board peripherals connect to the PIC. I’ll keep an eye of how this affects the flexibility of prototyping on the Fusion board. The 8-bit board supports many more PICs (I think it is over 250) with varying pinouts using different sockets on the board. The Fusion board supports 65 microcontrollers on plug-in modules, which likely reduce the need for so many jumpers. Figure Seven shows an example.

The Fusion on-board pots are higher quality over the 8-bit connectivity board. The 8-bit board has “scratchy” pots that are noisy while adjusting. While the Fusion board pots; shown in Figure Seven, are not exceptional quality (i.e. audiophile), they are better than the previous ones used. I’ll see how noisy they are as this review continues. Figure Seven shows one of the pots used. There is a similar one for the GLCD.

First Impressions of the Board (continued)

The board dimensions are 10.5” wide, 8.875” long/deep and about 1 inch tall. The EasyTFT screen is the highest profile part on the board.

This board is worthy of the “fusion” name. It has quite a list of peripherals and connectivity, including:

                Ethernet

                2x mikrobus

                microSD

                Audio in/out 1/8” / 3.5mm connectors

                mikroPROG ICD USB

                3x power options (barrel, direct wire, USB)

                DS1820 digital thermometer 3-pin header

                LM35 3-pin header (or LM34 for those who want degrees Fahrenheit)

                2x USB UARTs

          USB Host

          USB Device

          External ICD connector for Microchip’s ICD3

          CAN bus screw terminals

          Buzzer

          Four-way switch with center pushbutton

          Analog input pot with jumper to select input pin

          easyTFT display (320x240, 262k colors) with pot for adjustment

          MCU Card module. This board came with a PIC32MX795L

I pulled the “Easy TFT” display and was pleased to see the interface has changed from the 8-bit board. This touch screen board has two SIP connectors—one for the display along the top and one for the touchscreen interface along the bottom. This is much more robust than the 8-bit version which has a thin, fragile ribbon cable for the touchscreen. Figure Eight shows the TFT interface on the Fusion board.

Figure Nine shows the MCU Card Module with the microcontroller. It is in very firmly with four 2x13 headers. Underneath is a warning *not* to install the microcontroller with power turned on.  The MCU Card has a small portion that hangs out of the top like a flag to aid proper alignment. In the Figure Nine, this “flag” has the words “EasyPIC v7” on it at the top. It appears possible to plug the MCU Card in incorrectly and this flag makes it much less likely to do so. In its proper orientation, the PIC32 appears upside down and half of the pin labels are sideways. This is not a critique—just an observation. I’ve seen parts installed incorrectly due to issues like this and while the flag is a pretty good idea, I think it would be a good design approach to make it impossible to install the MCU Card improperly—especially for a board that could be used in an academic setting.

The board has a spot for an “optional rubber foot” on the back—just behind the MCU Card. Given that board is designed for changing  PICs, users could place stress right in this unsupported area of the board. If you never remove or replace the MCU Card, this is probably okay, but given that the board is designed to support different microcontrollers by changing the MCU Card, it’d be nice to have the foot populated to support the board during the stress of changing the

MCU Card.

Documentation

So far, I have spent a lot of effort looking at the hardware, but have not really said much about the documentation.

The documentation is available at: http://www.mikroe.com/easypic-fusion/ scroll about half way down the page.

It is very common now for manufacturers to provide only a disk or a link to a website with the technical information. Mikroe, on the other hand, does an outstanding job with their documentation. The user guide is beautifully printed on quality paper. The format is 8.5" x 11" landscape with each system receiving a full page. The schematic is also very well done. It is printed on what is about three landscape pages laid out horizontally. The schematic uses pictures of the components in many locations to ease the ability of new users to understand it.  In an attempt to simplify the drawing, almost all signals are grouped together in buses and the user can't just "follow the line" to where the signal goes. This results in some hunting - i.e. "where is TX-FTDI1 off of SW12?" when the picture of the FTDI chip is (correctly) labeled as FT232L. A new person to world of embedded systems may have trouble associating the TX-FTDI signal to the FT232L. The alternative would be to show every line between components, which would result an incredibly complex drawing - if it could even be represented on a single page - it would be very daunting to a new user. I think Mikroe has struck a good balance with their approach.

When I looked for the port pull up/down resistor values on the schematic, I noticed it wasn't present, but the value (4.7k ohms) is present on the I/O group page of the user guide. I'm sure this was a minor oversight by Mikroe and it appears that the most relevant information about the board is available on either the schematic and/or the user guide. I applaud Mikroe is taking the time and effort to produce such quality documentation.

The included DVD has an auto-running index.htm. The disk is very nicely done, albeit a bit slow on my computer. Users should be aware that the disk covers all of Mikroe’s development boards, books, and compilers. The topmost board shown is the EasyPIC v7, which is not this board. To find the material for this board, you’ll need to scroll down to the dsPIC Development Boards Section to find the EasyPIC Fusion v7. I suspect that will confuse some users who don’t notice the missing word “Fusion” and have to scroll past some books to reach it.

The Fusion board section of the disk contains all of the MCU card manuals, the schematic and user’s guide, as well as example code and the mikroProg software.

Hardware items that are not included

While you don't need these items to use the board, I point out that they are not included. The usefulness of these items will be driven by your specific project and your preferences.

• Power supply. The board can be powered by the USB cable, but the total current draw will be limited to 500 mA. The board can use a power supply with a 9-15 VDC or 7-12 VAC at 1.5 amps with    connection via a barrel connector or with wire leads to benchtop power supply. The barrel connector diameters are 5.5 mm outer, 2.1 mm inner and the connector is 11 mm long. I like the ability to power the board without a computer.
• Stylus - calibrating the touch screen will be imprecise without one. I use a stylus from another device.
• DS1820 One Wire temperature sensor - I suggest you request a sample from maxim semiconductor at: http://www.maximintegrated.com/. They may even ship your sample to you for free.
• LM35 (or LM34) analog temperature sensor - the LM35 gives a result calibrated to Celsius while the LM34 is calibrated to Fahrenheit.
• Ethernet cable
• On Mikroe's website for the fusion board, they list jumper wires as another optional item.

The pre-programmed demos

When the board is powered on, the user is greeted with a quick, two-step calibration of the TFT touch screen. See Figure Ten. The display is sharp with nice color and contrast. After calibration, a main menu of six options appears. See Figure Eleven. This main menu is laid out well with enough room to use a finger to select the options.

The first demo I ran was the basic LED Blink demo. After selecting a demo, the user is shown a screen with some instructions on it. Usually these are to setup jumpers or DIP switches on the board. This is where my problem with the demos arose. I enabled the LEDs on all ports for this demo. However, this conflicted with the touchscreen interface on Port B and I was unable to select anything until I turned the PORTB H/L LEDs off—just as the directions stated! To err is human! This demo does what it says— it blinks the LEDs on and off.

The next demo was the buzzer demo. This demo allows the user to select between two short tunes that play on the buzzer. See Figure Twelve.

The third demo was the Joystick demo. See Figure Thirteen. After setting the DIP switches (which have a nice positive click, by the way), the joystick is used to move a small round “ball”

through a simple maze.

The next demo was the ADC demo. In this demo, turning the analog input moves the “needle” of an analog type of meter on the display. I didn’t see any jumpiness as I moved the pot, but there could be some filtering going on in the code. This demo also demonstrates another display object—the analog meter. See Figure Fourteen.

Next, I ran the Ethernet demo. I plugged the board into my desktop switch and matched the board obtain an IP address and then it prompted me to go to the IP address of the board. This showed a simple web page with a simple user interface to toggle virtual LEDs on and off. See Figures Fifteen and Sixteen. These virtual LEDs are shown on the TFT display.

Finally, I ran the MP3 demo. This demo also showed some instructions on how to use it. See Figure Seventeen. After placing an MP3 sampled at variable bit-rate on a microSD card (not included), and pressing “start application”, a simple user interface of two buttons and a volume slider appear. See Figure Eighteen. The sound is as you’d expect from an MP3 player.

All of the demos worked wonderfully. It is a testament to Mikroe that I did not have to refer to anything other than the board itself to get all of the demos running—just be sure to follow the directions exactly!

This set of demos did a good job of exhibiting the biggest features of the board.

This demo source code is accessible on the product DVD included with the board, or on the Mikroe website.

Under the MikroC directory, there are twenty demos for the PIC32MX795F512L. The additional demos include: USB UART (A/B), USB, TFT, Sound, Serial Flash, One Wire, MMC, Mapping, LM35, GLCD, EEPROM, CAN, and Button.

There is also a set of demos for the PIC32MX460F512L. There are also demos for dsPIC33EP512MU810, dsPIC33FJ256GP710A, and the PIC24EP512GU810. These directories have eighteen demos in them.

There are also directories for MikroBasic and MikroPascal. Since you can download the examples from Mikroe’s website, you can look at them if you’re interested in a specific feature, demo, language or device.

In the next portion of this RoadTest, I’ll load up some of these other demos (such USB, One Wire, and the Flash / EEPROM Memories) to investigate them further.

ICD Comparison

You may recall that I want to migrate an existing 8-bit project I have over to this board. Before I do that, I decided to read the current contents of the memory of the microcontroller so I could restore it quickly.

I have two options to do this: use the on-board MikroProg ICD or use my Microchip ICD3.  Both Microchip and Mikroe have their own device programming environments, primarily intended to program .hex files onto microcontrollers. Microchip’s is called the Integrated Programming Environment (IPE), which installs with MPLAB X and Mikroe’s is called the MikroProg Suite. Since both have the ability to read out the memory contents (among other capabilities) I used this read-test to compare the two ICDs. I tried four combinations:

1. 1. The Microchip ICD3 with the Microchip IPE.
2. 2. The Microchip ICD3 with the MikroProg Suite. The Microchip ICD 3 was not recognized.
3. 3. The on-board MikroProg ICD with the Microchip IPE. The on-board ICD was not recognized.
4. 4. The on-board MikroProg ICD with the MikroProg Suite.

Since each programmer only worked with its own software, I conducted two read tests. The Microchip ICD 3 took about 15 seconds (8 seconds on subsequent reads) while the MikroProg ICD took about 87 seconds consistently on multiple reads. That is not a typo; it took about an order of magnitude longer than the ICD 3’s subsequent read time. At least I feel justified in my investment in the ICD 3!  The .hex files generated by these reads were identical in size: 1.43 MB.

However, for those who don’t want to invest more money in an ICD 3, the MikroProg ICD appears to be a capable, fully featured ICD. In debugging resources, both ICDs have 6 program breakpoints and 2 data breakpoints. Other than the speed advantage, the Microchip ICD 3 has unlimited software breakpoints when enabled in the project settings of MPLAB X. The MikroProg ICD does not support software breakpoints. This is not a huge issue, as the 6 hardware breakpoints are quite a bit to debug problem code. The main reason I see to purchase an Microchip ICD 3 is for the speed advantage. While a hobbyist may not mind the extra minute of time (just think of the money you saved), professionals (or those who develop embedded systems a lot) may value the time savings. The nice thing is the MikroProg ICD is very capable right out of the box, so there is no need to buy a separate programmer or ICD to start off with.

Both programming environment software suites are professional, polished tools. The MikroProg suite has a device overview that shows high level features of the microcontroller and has links to the proper datasheet. It also shows and allows changes to Configuration bits. See the Figure below

Microchip’s IPE requires an extra “Connect” step before the ICD 3 can be used. See the figure to the right. When the tool is first started, the “Disconnect” button shows “Connect” and the options below are grayed out. The memory contents (including config bits) are visible in the advanced mode of the IPE; available under the settings menu and requires a login. The Config bits can be changed here as well. In order to save memory read out into a .hex file, the option had to be enabled under the advanced settings screen. This configurability to hide functionality is an advantage in a production or academic setting.

PIC32 in DIP packages!

I was surprised to learn PIC32 microcontrollers are available in SPDIP (skinny PDIP) 28-pin packages. Apparently, that has been the case for a couple of years now. There are currently eight PIC32 devices available in this package. At the bottom of the range is the very capable (when compared to 8-bit devices) PIC32MX110F016B, which has 16 KB of flash with 2x UART, 2x SPI, 2x I2C, LIN capable, Real-Time Clock Calendar, mTouch, PWM channels and more, running at up to 40 MHz. At the top of the range is the PIC32MX250F128B  which has 128KB of flash memory, similar peripheral set and runs at up to 50 MHz. Neither is as capable as the PIC32MX795F512L included on the MCU card on this board, but having DIP parts available for the PIC32 takes away one of the big reasons I still use the PIC18 8-bit parts. It’d be nice to see Mikroe come out with an MCU card for the PIC32MX250F128B or perhaps a blank MCU card for these smaller footprint parts. Then, prototyping could happen on the EasyPIC Fusion v7 board followed with an easy transition to a standalone breadboard or proto-board. If you search for PIC32 parts in the DIP package with the Microchip Advanced Part Selector (http://www.microchip.com/maps/microcontroller.aspx), be sure to select SPDIP as the package type at the bottom of the screen.

MikroC PRO Compiler for PIC32

I installed the MikroC PRO compiler for PIC32 and was disappointed to see that it is not recognized by MPLAB X.  I hoped to use MPLAB X with the Mikro Compiler just like other 3rd party compilers in MPLAB X. If anyone has a way to do it, please let me know! I’ll review the MikroC Compiler and IDE later. As I continue the review and begin migrating my 8-bit project to this board, I’ll use the XC32 (v1.21) compiler in MPLAB X since I’m familiar with the IDE and the XC compilers.

Running Some of the Other Pre-Compiled Example Demos

I attempted to load some of the examples from the included DVD. First I loaded the USB UART A demo and fired up RealTerm to see the result. I was greeted with a simple “Start” message followed by a simple echo function that returned any characters I typed in.

Next, I loaded the OneWire Demo and then the LM35 Demo to test them out. Both of these demos are supposed to display the temperature on the TFT screen. Both gave the same result—a solid white screen with nothing on it. I wondered if the problem might be with the ICD 3 somehow, so I tried the on-board MikroProg with the same result. Then I reloaded the original demo and it worked fine. I then checked online to see if Mikroe had updated the examples from what was on the DVD (ver 1.01) and they had version 1.02 online. However, those example programs did the same thing. Finally, I checked the forums to see if there was a solution posted. There was.

It seems the TFT controller was changed recently, requiring a change to a function call in the code. The MikroC Compiler is required to re-compile any demos using the TFT Display. In the C Code version of the examples, look for the line that says “TFT_Init(320, 240);” and change it to: “TFT_Init_ILI9341_8bit(320, 240);” then re-compile the demo. You’ll need to do this for every demo that uses the TFT display. I verified that this fixed the OneWire and LM35 demos. See Figure Twenty-one for the DS1820 one-wire demo.

It is unfortunate that Mikroe hasn’t fixed this yet. I expect this will be a source of frustration for new users.

Once running, the examples are good demonstrations of the board’s capabilities and also a good source of sample code for new users. Of course, some of the function calls (such as TFT_Init_IL9341_8bit()) are only available in the MikroC compiler and are not available in other compilers, such as the free ones provided by Microchip with MPLAB X. If you’re using the trial of the MikroC Compiler, you may want to recompile all of the demos that use the TFT screen before your time runs out. I expect Mikro will fix this in a future version of their sample code.

Prototype Migration from PIC18 to PIC32

Earlier in this review, I have mentioned an 8-bit prototype design that I plan to migrate to the PIC32 using the Fusion v7 board.

The prototype design is a lightning sensor based on the AS3935 IC. I have a breakout board based on the reference design in the IC's datasheet that I obtained before Mikroe came out with the "ThunderCLICK" board which uses the same IC and easily integrates onto the board using the MikroBUS Specification.

Hardware Migration

However, since my breakout board is not based on the MikroBus, I need to figure out how to interface my AS3935 board with the Fusion v7. On my 8-bit connectivity board, I used PORTD for the SPI interface and RB0 for the external interrupt (IRQ). See Figure Twenty-two. The Figure shows the $6 Mikroe EasyPROTO breakout cable I used to interface the PORT connector to a small breadboard. Then I jumpered the signals across the breadboard to the AS3935 breakout board. Since I used RB0 for the external IRQ, I wire-wrapped from PORTD to RB0. I could have used a female to female jumper wire, but I like the low profile, stable connection of wire wrapping. I kept the SPI interface speed low enough that using the breadboard isn't an issue.

On the Fusion v7 board, I want to use the same breadboard and breakout cable. Ideally, I'd use a port with an external IRQ (INT) line with a SPI interface. This is where I began to run into some interesting aspects of the Fusion v7 board. There are four SPI interfaces on this package of the PIC32MX795. However, Microchip split two of them across ports and the other two are spread across the low/high bytes of the ports. In short, there is only one SPI bus that is completely accessible on a single PORT header (SPI4 on PORTF), thanks to some thought by Mikroe on assigning pins.

Then, out of curiosity, I looked for which SPI interface the MikroBus connectors use. The MikroBUS is comprised of two 1x8 headers about an inch apart with SPI, I2C, UART, INT, PWM, AN(analog), Reset, Pwr, and Gnd signals. This allows for small boards about 2 square inches in size to hold an entire prototype. Mikroe has over 65 boards in the CLICK family that use this interface. It was a bit of a challenge to find which SPI interface the MikroBUS uses. While the schematic shows the MOSI,MISO, and SCK lines, it does not say which pins they go to on the MCU - which is dependent on the MCU card itself. I then looked for a schematic for the MCU Card, but I was unable to find one on the Mikroe website. However, I did find it on a reseller's website. The MCU Card schematic shows the MikroBUS uses SPI3 with separate chip select lines as labeled on the MikroBUS headers.

I spent a bit of time looking at the PIC32MX5XX/6XX/7XX family datasheet to figure out which Port pins were available for SPI, I2C and INT interfaces. You'll want the pin name table from the Microchip Datasheet to help with this, such as Table 6 of the Microchip PIC32MX5XX/6XX/7XX datasheet. I created a small table of how the serial I/O is mapped to the Port Pins. See Appendix A for the table.

The next problem was finding a SPI interface with all of the signals present on one PORT connector. Happily, Mikroe anticipated this and put all of the proper signals on the sole PORTF header - by skipping some pins so the PORTF header has RF0-5, RF12 and RF13 on the same connector. This shows the thought Mikroe put into the board layout. While PORTF does not have an external IRQ pin, PORTD does, so I'll jumper a wire across the ports just like I did on the 8-bit board. Eventually, I may get a MikroBUS prototyping board since the MikroBUS has all of the signals I need for this prototype!

One alternative approach is to use a Mikroe SmartADAPT I/O re-assigner board in between the Fusion board and the breakout cable. The dual version (SmartADAPT2) connects to two ports on the Fusion v7 board and by placing jumpers, allows reassigning how those signals are connected to the re-assigner board's two output ports, but of course, you can connect the breakout cable to only one output of the I/O re-assigner board. This would allow one EasyProto breakout cable to utilize the signals from two Fusion v7 board port headers. The dual I/O re-assigner costs about $13. There are also two versions of single port SmartADAPT board as well that cost less. Figure Twenty-three shows the SmartADAPT 2 board. A fourth version has a GLCD connector as well.

Of course, another alternative is to wire-wrap from the AS3935 board direct to the Fusion board, but I want to be able to remove and reinstall prototypes fairly quickly.

This exercise really shows the strength of the Mikroe Fusion v7 board. For this simple prototype that requires a SPI interface, and INT line, 3.3V, and Ground, I came up with four different ways to interface the hardware to the board. 1. Direct wirewrap. 2. Use an EasyProto to a breadboard. 3. Use a SmartPROTO to a header or to a MikroBUS Protoboard. 4. Use a SmartADAPT2 to an EasyProto breakout cable to a bread board.

I went with option 2 (with one wire-wrap) for now, but will probably eventually migrate the prototype to a MikroBUS interface.

For finished (or stable) prototypes, the SmartPROTO board is an option to connect to the 2x5 port headers. See Figure Twenty-four. It’d be nice if Mikro would come out with something like the

SmartPROTO Board that connects to the MikroBUS connectors.

Software Migration

I have this project working on the 8-bit connectivity board. I wrote a handful of functions in MPLAB X using the XC8 compiler. For this migration, the idea is to minimize re-writing code. I expect once I have UART and SPI initialization and write functions, the functions I wrote specific for the AS3935 should work fine.

The first iteration of the project will use USB UARTA (which is UART2) as the output device. Later I'll use the TFT display to get the board to work alone, removing the need for a PC to act as a terminal.

The biggest change for me (moving from 8-bit) were the new register locations and names for the PIC32. To get started with this, I created simple projects to use the UART and SPI interfaces. I found Lucio DiJasio's Programming 32-bit Microcontrollers in C; Exploring the PIC32 book to be very helpful here - especially with the important underlying details such as configuring the clock system.

I wish I would have had it up and running earlier this week since I had a significant thunderstorm move through the area a few days ago and none since!

SPI Channels not connected ?!?

As I started to connect the prototype hardware to the Fusion board, I quickly realized I didn't take into account that USB UART A uses the same pins as SPI channel 4. So, I moved the SPI to Channel 2. While SPI2 spans two port headers, I figured it would work as an intermediate step until I have the TFT display up and running and I won't need the UART interface anymore.

I was able to get the UART up and running fairly quickly. While the clock and system configuration bits are different from the PIC18, it wasn't too much to figure out what I needed to get it running at 80 MHz with a 40 MHz peripheral bus clock. While the peripheral library for the XC32 is also a bit different than the 8-bit version, it wasn't much to move over.

However, I was unable to get SPI2 to send anything. What was perplexing was the SCK signal would transmit as expected, but nothing went out of MOSI (SDO) and /SS never changed states. See figure twenty-five.

After trying different methods of initializing the SPI bus - I took a close look at the MCU Card Schematic to find that the /SS2, SDO2 and SDI2 pins are not connected! It is not immediately apparent to me why this is the case. I have updated Appendix A to reflect the NCs that affect the serial interfaces. Be aware that there are other NCs as well. This seems odd since there are sufficient pins on the MCU Card headers. I also find it interesting that the dsPIC33 MCU Card does not have any NC pins. I plan to contact Mikroe about this.

As soon as I moved to SPI Channel 1, all three versions of the SPI init code I wrote worked fine. Figure Twenty-six  shows a quick test I had in the code to send 0xAA out on MOSI1.

I moved the 8-bit AS3935 initialization code over to the PIC32, adjusting for the different plib syntax. I wrote a  quick AS3935 init routine to get the part  up and running. As a quick test, I read back the contents of the AS3935 register zero to verify it is working as before. See Figure Twenty-seven, which shows the quick init routine going out and then the last part is a read back of register zero. The AS3935 correctly responds with 0x38.  My next step is to add back the register preservation steps I took out of the 8-bit code to get this test up quickly.

Mikroe’s response

I emailed Mikro’s tech support and asked why the NCs exist on the PIC32 MCU card. I received a response very quickly, but unfortunately, it was along the lines of  they can’t accommodate everything on a board of this type and must make trade-offs.  A response in the forum stating SPI2 is dedicated to the onboard memory chips doesn’t make sense at all since the PIC32 SPI2 is not connected to anything on the board.

However, the support team member did say that there is a good chance that a prototyping board for the MikroBUS will be released.

I looked at dsPIC33 MCU card I have (but haven’t used yet) and see that it has all pins connected. The difference on the dsPIC33, is that like the PIC24, many of its pins are multiplexed and the developer must chose what physical pins are connected to the hardware subsystems on the microcontroller. For example, SPI1 could appear on any peripheral pin select (PPS) pins in code by the developer. That flexibility will work very well with this board.

More SPI Challenges

Once I had the Spi Channel transmitting, I thought I had it done, but then I couldn’t read any values coming back from the AS3935. I could see them on the logic analyzer, so I knew the part was responding and my code worked on the PIC18, so it took me awhile to figure out what was happening. Basically, I noticed the SPI Overflow (SPIROV) flag being set. It turns out in the PIC32 (maybe a setting somewhere?) with each transmit expects the read register to be read, otherwise the next transmit will cause an overwrite of the receive register. I’ve never seen this behavior before, so I wasn’t expecting it. The fix was easy once I figured it out—I just read the receive register after each write even if I don’t need the result.

So, now the AS3935 is initialized in the same manner as I had with the PIC18. The SPI problems cost me a bit of time, but being able to use the breakpoints in MPLAB X with the ICD3 is what allowed me to figure out what was going on.

Interrupt Requests (IRQ)

Happily, the External IRQ went a lot smoother, as I move up from the 8-bit PICs to the PIC32. The Peripheral  library in Microchip’s XC32 compiler worked fine. I ended up using INT 3 on RA14 for the AS3935 to signal the microcontroller with an IRQ. To test it, I started with the Fusion Board’s Port pushbutton switches. The AS3935  pulses the IRQ line with a 3 ms logic high pulse. See Figure Twenty-ewight. The AS3935 datasheet states to look for the falling edge. By setting the Fusion board’s PORT A&C dip switch to low (for pull down) and setting SW10.1 (“Button Press Level) up so the pushbutton puts +3.3V on the line when pressed, I was able to simulate this behavior and verify the IRQ works without trying t o get the AS3935 to generate an IRQ. This is the power of this board, the ability to reconfigure it quickly to enable prototyping work.

It’s Alive!

Next, I connected the AS3935 IRQ line to RA14, reprogrammed the PIC32 and tested it with a fluorescent light, which is detected as a disturber and then as a noise source. Figure Twenty-nine shows the output from USB UART A. I have a few short messages that show the initialization status and then the program waits for an IRQ from the AS3935. When that happens, the PIC32 reads the AS3935 SPI register to determine what type of event (disturber, excessive noise, or lightning event). For each event type, a message is displayed, an LED is lit for a short time.

For a lightning event, the AS3935 provides an estimate of how far away the storm front is (not the lightning itself). This is provided in km, which I display and I also convert the km to miles via a short lookup table and display that as well. Also for a lightning event, the buzzer sounds briefly to indicate it detected the lightning strike. On the PIC18 board, it was interesting to hear the buzzer sound coincidentally with the flash of the lightning.

Figure Thirty-one shows the AS3935 Lightning Detection prototype. The AS3935 is at the bottom of the figure on a small breadboard using male to female jumper wires to access the three Fusion board ports needed for all signals. Along the right-hand side is the USB logic analyzer which is connected to the convenient pins on that edge of the board.

Two Months Already?!?

Sadly, this weekend marks two months passed since I received the Mikroe EasyPIC Fusion v7 board, and I’ve worked with the board almost every week since I received it and written about 18 pages of roadtest review material. Those who have been following along have seen this review grow since I started to post it in late August.

This week I plan to fulfill one reader’s request to code the same project using the MikroC PRO for PIC32 compiler and compare code sizes. Since I am at the same level of functionality I had on the PIC18, this is a good point to do that. I should have that added to this review next weekend.

I’ll also go back and look at the code loading time comparisons between the ICD3 and the MikroProg. One reader suspects my measurements are unfair against the MikroProg.

I did not get to implement the TFT screen on this project yet. Trying the use the TFT screen on the PIC18 board using Microchip tools was quite a task (no drivers, no library, etc) so I never got far. That experience tempted me to get MikroC for the 8-bit devices. I still want to utilize the TFT library in the MikroC compiler and I may have some time this week to do that, but I won’t promise it’ll make it into this roadtest.

Last impressions

The PIC32 has a ton of serial interfaces, but board doesn’t allow access to many of them (see the appendix). On the PIC24 and dsPIC devices, this will be less of a factor since they multiplex the  peripheral pins and the developer can move functions around to accommodate the board. I think this board would be a great dsPIC board since it has audio in/out jacks, onboard flash/eeprom, microSD card interface and serial interfaces such as USB UART. For the PIC32 though, I’m not convinced. It could be a good academic board for the PIC32 using on-board features and perhaps limited off-board prototyping. Another approach on the PIC32 would be to use software interfaces, but I like being able to use the hardware interfaces when they’re provided.

I do hope Mikro produces some type of protoboard for the MikroBUS. If they don’t soon, I’ll probably design one myself.

Between Mikro’s demos and my own effort, I used every feature of the board except for the CAN bus terminals. They all worked fine.

Overall, this is a quality board with some limitations. Take a look at Appendix A to see what is available off board for the PIC32. Other than that, I have no reservations recommending this board. I look forward to using for PIC32 and dsPIC33 development in the future.

VOTE!

Some readers have lamented the lack of in-depth reviews on RoadTest. I sign up only for RoadTests that I believe I can provide a worthwhile review on within two months. I hope you have enjoyed this review and found it useful.

If you enjoyed this RoadTest, please click “like” at the bottom of this page.

Hopefully, this will allow element14 to see your opinion and possibly help me be selected  when (if) I apply for a future roadtest.

Thank you again to element14 and MikroElektronika for sponsoring this RoadTest.

APPENDIX A

Table 1. PIC32MX795F512L Serial I/O between MCU Card and Mikroe Fusion v7 Board

Compiled by Cory Antosh as part of an element14 RoadTest

This table shows the PIC32 serial interface mappings between function and I/O pin. Lines in red are not connected on the PIC32MX795F512L MCU Card v1.01 produced by MikroElektronika for their EasyPIC Fuaion v7 board. The signals bold and highlighted in yellow appear at the interface on the right side of the table.

*** The pdf below is formatted properly - particularly the appendix, which I have found to be helpful printed out.

If you enjoyed this RoadTest, please click “like” at the bottom of this page.