mikromedia Plus for PIC32MX7 (PID: MIKROE-1399)

[solveering]

Some review/comments on the mikromedia Plus for PIC32MX7 (PID: MIKROE-1399):

I am currently working on a project/prototype in the medical field that involves the use of a touchscreen and found the mikromedia Plus for PIC32MX7 to be a good fit for the intended purposes. Specifically, I was looking for a unit with a fairly large memory space for any down-the-road changes/additions as well as a moderately fast processor and a number of peripherals. So I ordered two (one for the prototype and one for verification of any future software changes once the prototype was delivered).
Unfortunately, the device did not meet my expectations and it took a lot of effort to get it to perform as intended. Upon setting it up and working with it, I found a number of issues, which I will explain here:
- The datasheet clearly states that there are 3 available PWM pins. That is not the case!!!. Though it is technically possible to turn them into (Software) PWM outputs (something along the lines of using a timer/interrupt to determine the on/off state), I do not consider that a PWM. There are a total of 4 PWM modules available on this PIC32, but one is used for the touchscreen (rightly so) and the other three are (-quite stupidly) used with an RGB LED to show a color range. I do not see the use in such a RGB capability other than for educational purposes. The output could have been multiplexed with some kind of solder bridged connection, but that wasn't done.
- Almost all of the GPIO pins are in fact outputs from the port expander. Though they can strictly be used as GPIOs, they cannot be used together with the library items. For example, what I wanted to do is add a second (mini) LCD and address it using the GPIOs. Luckily, there were just enough Analog pins (then configured in software as digital pins) available to do so. Similarly, the SPI output is not one of the other available SPI modules, but the one multiplexed with the SPI used for the SD card (so if you need to run two with different configurations, you are SOL). It would also have been nice if the USB connection would have allowed customization as it sits on the side of the unit, so if that is not where you can access it, you need to de-solder it and then figure that out for yourself. A few spare pads would have been nice...
- The examples in the one library that I could find is very vague in how a number of the functions of the board are being used. For one, all examples are written in C whereas I am using BASIC. That's fine as I can read C and translate to BASIC without too many issues, but that isn't what I consider useful support. Several items (on-board memory, Ethernet, RF(?),etc.) are not further illustrated or difficult to find without a mikroC for PIC32 license (as the IDE doesn't do a good job at jumping to the definition without compiling the source).
- The SD card slot is what I would consider essential to the proper function of the unit. For one, most developers would likely want to store any media such as images and similar on the card. Unfortunately, this did not work as intended. For one, the configurations in the example files for working with the FAT system over SPI were not correct (or not correct based on my debugging experience). The default, high speed interface was in fact too fast for my SD card and thus did not work (any items on the screen that were meant to be stored on the disk simply didn't show up). Upon moving all the media onto the processor, things work out. Additionally, I received an 8GB disk while the help files say that the SD capabilities are limited to 2GB cards. Whether that is an additional issue, I don't know. I resorted to using an older 512Mb disk which may have contributed to the issues (speed may be lower). But what is clear is that the combination of original disk + original SPI settings did not work for me.

Lastly something about the physical device. Overall it looks nice and is well done albeit slightly on the pricey side considering that the total of parts likely ends up around 50% of the retail cost and that most will likely not use all modules. Aside from that, the unit is difficult to fit into an enclosure (too many components that have the same height as the display that are mounted on the same side - which I had to remove) and the mounting holes are too close to an M3 size to allow any wiggle room (though they can be increased as I ended up doing to get better access). The components are inconsistently mounted on one side or the other or placed so that the unit cannot easily be mounted in an enclosure.
The solder pads on the board are quite small and make it difficult to re-solder if you need to modify something. Larger pads would have been appreciated. The same goes for thermal pads on all the ground pins. I generally dislike thermal pads as they will require a far larger amount of heat to be applied with the soldering iron before you get a good connection.

If I were to give this a rating, I would give it a 3 out of 5 stars. If I could ask for a simple change (i.e. no changes to the PCB which would leave the PWM issue as it is), it would be to also offer the same board but with a minimalist configuration (i.e. leave out all but the PIC, SSD1963, SD card and touchscreen controller and any components that they directly rely on such as resistors and capacitors). This would make for a cheaper board and would allow more manual changes to be added. Additional support and corrections to the schematic/documentation should be considered a must-have.

[lana.arsic]

Hi,

- The datasheet clearly states that there are 3 available PWM pins. That is not the case!!!. Though it is technically possible to turn them into (Software) PWM outputs (something along the lines of using a timer/interrupt to determine the on/off state), I do not consider that a PWM. There are a total of 4 PWM modules available on this PIC32, but one is used for the touchscreen (rightly so) and the other three are (-quite stupidly) used with an RGB LED to show a color range. I do not see the use in such a RGB capability other than for educational purposes. The output could have been multiplexed with some kind of solder bridged connection, but that wasn't done.
- Almost all of the GPIO pins are in fact outputs from the port expander. Though they can strictly be used as GPIOs, they cannot be used together with the library items. For example, what I wanted to do is add a second (mini) LCD and address it using the GPIOs. Luckily, there were just enough Analog pins (then configured in software as digital pins) available to do so. Similarly, the SPI output is not one of the other available SPI modules, but the one multiplexed with the SPI used for the SD card (so if you need to run two with different configurations, you are SOL).

Port expander was needed because lack of the pins, since many pins
are used on SSD1963 which has parallel 16bit interface.

- The examples in the one library that I could find is very vague in how a number of the functions of the board are being used. For one, all examples are written in C whereas I am using BASIC. That's fine as I can read C and translate to BASIC without too many issues, but that isn't what I consider useful support. Several items (on-board memory, Ethernet, RF(?),etc.) are not further illustrated or difficult to find without a mikroC for PIC32 license (as the IDE doesn't do a good job at jumping to the definition without compiling the source).

I'm sorry because of missing examples in mikroBasic and
thank you for all your suggestions regarding manual and design, I read them carefully and
I have forwarded them to our developers for consideration.

- The SD card slot is what I would consider essential to the proper function of the unit. For one, most developers would likely want to store any media such as images and similar on the card. Unfortunately, this did not work as intended. For one, the configurations in the example files for working with the FAT system over SPI were not correct (or not correct based on my debugging experience). The default, high speed interface was in fact too fast for my SD card and thus did not work (any items on the screen that were meant to be stored on the disk simply didn't show up). Upon moving all the media onto the processor, things work out. Additionally, I received an 8GB disk while the help files say that the SD capabilities are limited to 2GB cards. Whether that is an additional issue, I don't know. I resorted to using an older 512Mb disk which may have contributed to the issues (speed may be lower). But what is clear is that the combination of original disk + original SPI settings did not work for me.

If you are referring on default example, it uses FAT32 library,
did you try to format SD card as FAT32 and then to load Ext_reso.RES file?

Before shipping, the board is tested with SD card, but we don't test SD cards,
I'm sorry if the one which you got didn't work properly,
you can send us a ticket so we could resolve this issue.

Lastly something about the physical device. Overall it looks nice and is well done albeit slightly on the pricey side considering that the total of parts likely ends up around 50% of the retail cost and that most will likely not use all modules. Aside from that, the unit is difficult to fit into an enclosure (too many components that have the same height as the display that are mounted on the same side - which I had to remove) and the mounting holes are too close to an M3 size to allow any wiggle room (though they can be increased as I ended up doing to get better access). The components are inconsistently mounted on one side or the other or placed so that the unit cannot easily be mounted in an enclosure.
The solder pads on the board are quite small and make it difficult to re-solder if you need to modify something. Larger pads would have been appreciated. The same goes for thermal pads on all the ground pins. I generally dislike thermal pads as they will require a far larger amount of heat to be applied with the soldering iron before you get a good connection.

Position of USB and other components are decided by our developers
in order to achieve the best performance.
I understand that it may be difficult to enclose the board in a case because of that,
but this is a development board and it is not meant to be used as a final product. It is not impossible,
but it requires few tweaks...

The components are using landing patterns which are defined by standard
for high density boards. It is not possible to use bigger pads -
if you were speaking about the header and component pads.

If I could ask for a simple change (i.e. no changes to the PCB which would leave the PWM issue as it is), it would be to also offer the same board but with a minimalist configuration (i.e. leave out all but the PIC, SSD1963, SD card and touchscreen controller and any components that they directly rely on such as resistors and capacitors). This would make for a cheaper board and would allow more manual changes to be added.

We also have displays with SSD1963 in offer which can be connected on MCU:

https://www.mikroe.com/search?search_qu ... erway=desc

Kind regards,
Lana

[solveering]

Lana,
thank you for you comments. Just a few things I would like to point out:
1) the default behavior for the VisualTFT settings (Edit Project>VTFT Settings>Resources) uses the FAT library, not FAT32. As the code is not extensively documented, making the switch to FAT32 is not trivial.
2) I understand the use of the Port Expander to provide more I/O. But either you will need to include an option in the Software Libraries that allows a P/E to be used rather than directly accessing the processor's pins or the P/E should be used with the 'additional' features of the board. My recommendation would be to bring out all the components to a separate pad so that they can be bypassed (especially for important items such as the PWMs).

What I have an issue with is where you state

regarding manual and design, I read them carefully and
I have forwarded them to our developers for consideration

This is something I have come to understand is a default behavior. The issue with the PWM pins has been raised before:
viewtopic.php?f=12&t=67375&p=269931&hil ... wm#p269889
but the issue in the datasheet has not been addressed in the almost 2 years since. This is not the first time that I raise an issue such as incorrect documentation or bug in the software (of which there are A LOT). The standard reply is always 'thanks for bringing this to our attention, we have forwarded this to our developers and will fix this as soon as possible'. I've spent literally hours putting together information about bugs in the IDE, when they occur and how they manifest, but no action has been taken. I was told that the developers will put together a fix for the reported issues (deleted code, jumping around, missing references, incorrect extensions, etc.) in the next release, but now I've seen the roadmap for the next release and not a single item that I mentioned is being addressed. Basically: any reports of issues go into some black hole. If you want to have a good product, you have got to address major issues in a timely manner.

I'm sure you can do better... I know this isn't trivial but having used your products for the past 5 years or so (I own a license for every PIC-BASIC combination and a number of H/W items) I am astonished how little effort has gone into actually fixing issues with the IDE...

Thanks.

[lana.arsic]

Hi,

1) the default behavior for the VisualTFT settings (Edit Project>VTFT Settings>Resources) uses the FAT library, not FAT32. As the code is not extensively documented, making the switch to FAT32 is not trivial.

I'm sorry for the misunderstanding, I was referring to default example from our website, where FAT32 is in use.

What I have an issue with is where you state

regarding manual and design, I read them carefully and
I have forwarded them to our developers for consideration

This is something I have come to understand is a default behavior. The issue with the PWM pins has been raised before:
viewtopic.php?f=12&t=67375&p=269931&hil ... wm#p269889
but the issue in the datasheet has not been addressed in the almost 2 years since. This is not the first time that I raise an issue such as incorrect documentation or bug in the software (of which there are A LOT). The standard reply is always 'thanks for bringing this to our attention, we have forwarded this to our developers and will fix this as soon as possible'. I've spent literally hours putting together information about bugs in the IDE, when they occur and how they manifest, but no action has been taken. I was told that the developers will put together a fix for the reported issues (deleted code, jumping around, missing references, incorrect extensions, etc.) in the next release, but now I've seen the roadmap for the next release and not a single item that I mentioned is being addressed. Basically: any reports of issues go into some black hole. If you want to have a good product, you have got to address major issues in a timely manner.

I sincerely apologize, I understand your dissatisfaction, but we really appreciate when
you report some issue, we also sometimes spend hours in order to reproduce them,
and then we forward to our developers.

All bugs are reported, and our developers always consider which ones
will be corrected for the next release, there is no software without bugs,
but our developers really put a lot of effort in order to resolve as many as possible
and also to implement new features.

And all your suggestions/reports from this thread are forwarded to our developers,
and each one will be considered for sure.

Kind regards,
Lana

[solveering]

Lana,
I appreciate the sentiment.
If it were up to me, the IDE would need to have the following items fixed on an ASAP basis:
- Consistently work as a text editor. As it is, depending on what edits are made (large copy/paste operations, etc.), large sections of my code get deleted (without option of undo). Any time I need to make changes other than simple entry, I switch to Notepad++ to make those changes and then re-load the file.
- The ICD has unreliable breakpoints. When I run a program (with Zero optimizations), the program sometimes stops where I set a breakpoint, but usually does not. Run to interrupt does not work and Run to cursor runs to "somewhere near" cursor. Additionally, the program will for strange reasons stop at a location that is not a breakpoint which is a problem if I try to run a method that has timed events.
- Automatically expanding all subroutines when a change is made somewhere above them... well that is just plain annoying. As there is no option to 'collapse all' as almost every IDE has, I have spent too much time scrolling around and collapsing methods to keep the IDE clean.
- When you have something like code-completion, it should work. Otherwise don't include it. Every time I pause when adding a "." after a variable name, I get the code completion window. If I just keep typing, the text will initially look ok but then change to something completely different (like 'foo.0' will change to 'foo.R' after adding a space at the end).
- The same goes for strings. If I have some USART command that I want to send "A", if I start typing the " character, I have about 1/2second before I need to also type the closing " otherwise the cursor jumps to somewhere else in my code. Why? Just let me enter my text, I don't need it to be evaluated as I am typing.

If it isn't possible to fix issues with the IDE, it would be greatly appreciated if these 'helper' functions could at least be disabled. I don't need the text editor to do much for me other than to mark what is code and what is a comment.

Thanks for the continued consideration.

P.S. it may appear as if I have strong negative feelings about these products, but I actually quite like them and will continue to use them. If only you could get annoying and seemingly simple issues fixed... it would make my work so much easier.

[lana.arsic]

Hi,

- The ICD has unreliable breakpoints. When I run a program (with Zero optimizations), the program sometimes stops where I set a breakpoint, but usually does not. Run to interrupt does not work and Run to cursor runs to "somewhere near" cursor. Additionally, the program will for strange reasons stop at a location that is not a breakpoint which is a problem if I try to run a method that has timed events.

I will test this and let you know about the results.

Regarding another issues, these are reported to our developers,
and I'm sorry for all unpleasantness.

- When you have something like code-completion, it should work. Otherwise don't include it. Every time I pause when adding a "." after a variable name, I get the code completion window. If I just keep typing, the text will initially look ok but then change to something completely different (like 'foo.0' will change to 'foo.R' after adding a space at the end).

This issue is also reported, but if you want you can turn off code completion
(Tools -> Options -> Editor Settings -> Enable Code Completition).

- The same goes for strings. If I have some USART command that I want to send "A", if I start typing the " character, I have about 1/2second before I need to also type the closing " otherwise the cursor jumps to somewhere else in my code. Why? Just let me enter my text, I don't need it to be evaluated as I am typing.

I'm sorry, I couldn't reproduce this issue,
I have tested in mikroBasic PRO for PIC32, which compiler did you use?

Kind regards,
Lana