MPIDE vs MPLAB X Performance

[Geomancer]

Greetings!

I have an Pro MX7 that I want to use as a development platform for a project and have a question on performance differences between MPIDE and MPLAB X. From what I understand, MPIDE is an Arduino-like environment that works with a lot of Arduino libraries. I like the sound of that because it could make things "easier" to just use a library than create it all myself and Arduino seems to be the "go to" platform for hobbyists.

However, I wonder if MPIDE suffers from poorer performance than I'd get trying to do the same thing in MPLAB. A classic example with arduino being digitalwrite() being "expensive" in terms of performance versus directly working with the I/O port. But there are more direct ways right?

I've tried messing with MPLAB Harmony, which has libraries to cover most things I need, but to be honest I'm finding it a big confusing. I also don't know if they'd be any better/worse than arduino libraries?

The project I'm wanting to tackle is a complex one (at least for me) although on the MCU side it isn't too complex. It's a pinball machine. So, in essence it has to do the following:

1. Play background music
2. Play sound effects mixed with the music/other effects
3. Display animated graphics on a 128x32 dot matrix display (these need constantly refreshed at ~70Hz like a video interface, they do not store a 'frame' locally)
4. Read all the above from a microSD card
5. Control an LED matrix, probably at least two shift registers for 8x8 = up to 64 LEDs
6. Read from a switch matrix, again probably 8x8 = up to 64 switches
7. Control open drain FETs for solenoids (probably again via shift registers). Around 10-12 or so. However, I'm toying with the idea of using PWM to control the power of solenoids.

The first 3 I worry about consuming a lot of cycles because switch closures for #6 can not be missed. So my question is, would using MPIDE be viable, or do I need to work at a lower level to get enough performance? Is it doomed regardless and a second MCU would be needed to handle the A/V functions?

[xc6lx45]

Hi,

I'm no expert on the platforms you mentioned. That said, "hobbyist" libraries ease the first steps on the learning curve but at what price? All too often you spend most of the time on the few "hard" problems (e.g. achieve reliable realtime performance) and realize you've locked yourself into "easy" solutions that have become a liability.

One interrupt handler for the "realtime" stuff and everything else in C is what I would do...

[JColvin]

Hi @Geomancer,

I can't personally tell you which IDE will be better for your development needs, though I will say that the chips may be fast enough to run all of your tasks by itself, provided that you can read from the SD card fast enough. We (Digilent) ran a 900 (30x30) LED display off of a WF32 through MPIDE to play the "Snake" game and have it communicate with LabVIEW over serial to keep track of high scores. To be fair, the library written to control all of the LEDs was written in Assembly, so that certainly helped with the timing.

In the end, you may want to go with some direct register manipulation since there will be some extra overhead and other checks that are made when using the macro'd commands provided by MPIDE (though Digilent now uses the Arduino IDE with the Digilent Core since MPIDE is depreciated). As @xc6lx45 mentioned the "hobbyist" libraries help ease some first steps and help catch mistakes that you may not consider when first starting out. I'm not sure how expensive the predefined macro's are timewise though, so maybe it's not a huge issue for you.

I also haven't worked with Harmony and Digilent hasn't done a lot of work with MPLAB in recent years so we don't have a lot of support on that end.

Good luck,
JColvin

[xc6lx45]

On 3/12/2018 at 8:39 PM, xc6lx45 said:

>> "hobbyist" libraries

BTW I don't want to put a stamp on anything here - as mentioned before, I don't know the libraries. Take it just as a general observation.

[JColvin]

Don't worry, I only personally consider them as "hobbyist" (loosely defined) libraries myself (as opposed taking and running with your term), because of the idea that much of the work that goes on behind the scenes is abstracted away, making it easier for a wider audience to use. I tend to use them quite frequently myself since they get the job done just fine for what I do and I don't see a need to re-invent the wheel if it's only purpose is to hopefully make the wheel a little rounder than before so my code goes faster; the time sink usually isn't worth it for me.

So I guess @Geomancer, probably either set of libraries will work for your application, but since you are a doing a lot of display refreshing/updating, I would definitely recommend making sure that there are minimal blocking delays occurring so that everything can be triggered at the appropriate time.

Thanks,
JColvin

[Geomancer]

Thanks for the information. The display is really the killer. With 4096 pixels that's quite a lot of data being thrown around to refresh it at ~70+ Hz. Its too bad these dot matrix displays don't have their own controllers that auto-refresh the display until they get new data, just like how most LCD character and more modern graphic displays work.

But that's just the way it is, so I'll have to find a way

I've also considered pairing it with an FPGA (the Spartan 6 CMOD looks nice) to do these kinds of parallel tasks while the processor just controls things.

Another consideration I had forgotten about is I'd be using the free version of the XC32 compiler, which does not have any optimization. That may give MPIDE an edge.