- 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