I have received a couple of requests recently for support interfacing a PIC32 or a PIC24 to some popular MP3 decoders/codecs from VLSI technology. Since I had a PIC24 MicroMedia board on my desk that begged to be used, I took the opportunity to give it a test ride and put the VS1011E chip to its pace.
Every now and then I get a chance to talk to the guys at Mikroe and they never fail to surprise me, both for the amount of work they get done in a short time and most importantly the quality of it.
Here is a quick update on projects they completed since I last met with them in Nuremberg during the Embedded World show.
- MikroMedia Workstation (The Monster Media )
- Two new mikroMedia boards with new powerful 16 bit enhanced MCU’s.
- New EasyPIC v7 for dsPIC30, 7th generation of development board for dsPIC30 family
Also they added WiFi software support for MRF24WB0MA in bundle with MCW1001:
- WiFi PLUS Click <http://www.mikroe.com/eng/products/view/872/wifi-plus-click/>
The support package can be found on Libstock: http://www.libstock.com/projects/view/356/network-wifi-library
- Few interesting demos and videos of WiFi in action can be found here:
It has been a long journey for me to learn about modern interpreted object oriented programming languages, first on the desktop (see post here), later on industrial control and data acquisition applications (see post here) and now I feel like I have finally closed the circle: Python programming on an embedded control (32-bit) microcontroller thanks to the “Python-on-a-chip” project!
Dean Hall has been working at this project for several years now. He has demonstrated the possibility to run a small Python interpreter even on 8-bit architectures and others before me have ported the (well written) code to 16-bit microcontrollers like the PIC24. But since all Python interpreters have a huge thirst for RAM, it is only in the flat an (virtually) unlimited addressing space of a 32-bit microcontroller that Python starts really to make sense in my opinion.
So I have created a clone of the project (Mercurial) repository for the purpose (link) and developed a new PIC32 port for the v10 revision of the project. While describing the whole project would take a while, it is interesting to note that the time I spent to “port” the PIC32 code in itself (from pull to first successful build) was less than an hour!
Actually most of the time for me went into figuring out how to use Python effectively to wrap existing libraries and get a useable, or I should say a useful, package to develop applications on the PIC32 MX4 Micromedia Board.
At the moment I have demonstrated good real time support for the following features:
- QVGA Graphics Primitives
- Touch screen input
- Joystick input
- LED output
- Serial input/output
- Accelerometer input
- Temperature sensor input
- Audio (work in progress)
Eventually the project begs to be recompiled for a PIC32MX7 Micromedia board (128K of RAM!) where I could even dream to attempt a port of the PyGame libs to make development of little interactive applications real fast…
Please feel free to review the code and send your comments… but beware this is not a project for the faint of heart!
You will be required to master the following tools/application libraries:
- MPLAB X
- C32 Compiler
- PIC32 peripheral libs
- Microchip Application Libraries (GFX, MDD File System…)
- Scons project manager
- Mercurial versioning tools
- Doxygen automated documentation generator/manager
After more than a year of inactivity, I have only recently checked the version number of the latest Microchip Graphic Library release and to my horror discovered that I was far behind. The major revision number had jumped (from 2 to 3) and this typically is not a good sign. Let me rephrase that. It is good to see that major work is being done on the library, it is bad for me, as I am so lazy, lots of changes mean a lot of work to fix something that “was working before”.
The relationship (if so we can call it) between me and the Graphics Lib developers is somewhat similar to a marriage of convenience. They need users, I need developers to maintain the library. But our best interests don’t always coincide, or at least their timing is not always perfectly synchronized with mine. A friend recently gave me a definition of marriage that in fact seems to describe the situation perfectly: “Marriage is solving together problems you did not have before”.
An example is the revision step from 1.x to 2.x of the lib that was driven by the launch of the PIC24DA series and the need to include a whole new set of custom features specific of that architecture. I could not care less.
The last revision step to 3.x though is different. This time it seems the developers have spent some real effort in improving the inner structure of the lib something that eventually benefits my project more directly. In particular I appreciated the separation of the display interface from the graphic controller detail (I/O vs. PMP 8 vs. PMP16 etc…). This used to be all mixed up in the graphics drivers with potentially messy results. I am pretty sure the problem must have popped up on the developers radar when attempting to extend the library to the dsPICs series (which is lacking a PMP port) and is now fully supported.
From an egoistic point of view though, the new libs also mark an increased attention to the PIC32 efficiency, as now the display drivers can use atomic I/O controls (reducing code size and increasing speed) in the low level macros or at least they are suggesting it as eventually it is up to us to define them properly in the hardware profile.
This is a segment of a new hardware profile (3.02 compatible) for the uMMB32 board I have been working on:
// display type #define GFX_USE_DISPLAY_CONTROLLER_HX8347D // interface #define USE_GFX_PMP #define USE_16BIT_PMP #define PMP_DATA_SETUP_TIME (30) #define PMP_DATA_WAIT_TIME (30) #define PMP_DATA_HOLD_TIME (30) #define DISP_ORIENTATION 90 // Definitions for reset pin #define DisplayResetConfig() TRISCCLR = _TRISC_TRISC1_MASK #define DisplayResetEnable() LATCCLR = _LATC_LATC1_MASK #define DisplayResetDisable() LATCSET = _LATC_LATC1_MASK // Definitions for RS pin #define DisplayCmdDataConfig() TRISBCLR = _TRISB_TRISB15_MASK #define DisplaySetCommand() LATBCLR = _LATB_LATB15_MASK #define DisplaySetData() LATBSET = _LATB_LATB15_MASK // Definitions for CS pin #define DisplayConfig() TRISFCLR = _TRISF_TRISF12_MASK #define DisplayEnable() LATFCLR = _LATF_LATF12_MASK #define DisplayDisable() LATFSET = _LATF_LATF12_MASK
Notice the nice parameterization of all PMP details and how the RS, CS, and RST lines of the display are now controlled by macros (DisplayConfig(), DisplayEnable()…) so to enable the use of the atomic I/O control registers (i.e. LATF-CLR)
Now for the part I don’t like:
- The display driver selection now requires an extremely verbose “GFX_USE_DISPLAY_CONTROLLER_HX8347D” which at 35 characters is exactly 30 characters too long for my taste.
- The I/O definition macros require us to specify 3 x times (three times, three time, three times) the port we are selecting, which is exactly two times too many:
LATFCLR = _LATF_LATF12_MASK
While the first one is just a personal preference and since it is used only once in each project it has virtually no chance of producing any damage (read bug), the second one is a symptom of something bigger. In fact you will soon discover that for each of the N I/O ports of each PIC 32 model, there are now 4 x 16 (one for each bit for each atomic control register) macros that define each bit listed in the corresponding .h file. It simply escapes me why we would need to distinguish the mask for bit 15 in port A SET register (0×8000), from the mask for bit 15 in port B SET register (0×8000), or any other register for that matter!? Bit 15 is bit 15 is bit 15, in every word!
So the declaration above would be:
LATFCLR = BIT12_MASK
Where is the harm? It’s a simple pilot’s rule: “Everything that has to be repeated more than once (by a human) is an opportunity for a mistake”. We humans are simply not good at repeating things consistently. Sooner or later we get distracted and skip one… An example, this is an actual simple typo that did cost me several hours to hunt down, when I converted the hardware profile from a demo project of the new graphics library to the uMMB32 I had to change the following line of code:
#define DisplayEnable() LATBCLR = _LATB_LATB9_MASK
From addressing bit 9 of PORTB, to addressing bit 12 of PORTF, I typed :
#define DisplayEnable() LATBCLR = _LATF_LATF12_MASK
Do you see any problem?
I have finally cleaned up and posted the code for the Audio and Video player for the PIC32 uMMB board. It is perhaps the shortest code example among the many I have developed for the Mikroe boards, yet so many consideration and so much experimentation went into it.
Far from being completely documented, let’s consider it a start….
It’s about time for an update on the latest and greatest demo boards for the PIC24 and PIC32.
they introduced a PIC32MX7 version (adding Ethernet connectivity)
and shortly after that a “microMMB” version with the MX4 processor:
so small that it barely gives you room for four screws around the display to fix it to a panel.
These boards are great to experiment with the Microchip Application Library (MAL) and in particular with all things graphics, touch, audio and USB. But they are also ready for being mounted in your embedded control application and to became it’s user interface if not the brain.
I wrote a lot of code for them and I intend to share it and document it gradually in the coming weeks to show you how to get the basic functionality (user interfaces) but also to show you things that many believe would only be possible with much more expensive and complex systems.
You can get a glimpse of it on the new page of the Exploring PIC32 web site dedicated to the Multimedia boards and the Multimedia demo projects. I am so fond of them, that I have decided to help MikroElektronika re-sell them and to provide documentation and support on this blog and on my two companion web sites.
So I am still investigating the animation capabilities of the PIC32 and the MikroElektronika multimedia board… and having a lot of fun.
Do you remember how to solve the Rubik’s cube? Enjoy!
I must admit, the MikroElektronika PIC32MX4 Multimedia Board has recently stolen the little that was left of my free time. I found myself toying around until late at night with it, and I have resurrected a number of old projects. The little QVGA display is so attractive, and I could not resist but try to port some of my favorite graphics programs to it.
Basically, if you have seen the MikroE web site, you have already seen a screenshot of the Mandelbrot project ported to the PIC32MMB. But if you have tried any of the advanced projects I posted on the PIC32 explorer web site, then you already know what I did next.
Graphics animation is more fun! It is different from basic graphics GUI design and support, because you have to add a real time element to it. To provide fluid motion you have to use double buffering techniques, and if there is 3D, linear algebra needs to be mixed in.
While this is all still very much a big work in progress, I would like to share with you a couple of previews of the kind of things you can do with the PIC32MMB.
This is the basic wireframe 3D cube animation (link)
There are four more videos for you to explore:
A more complex 3D wireframe (link)
More objects animated in 3D (link)
Using the onboard accelerometer to move around objects (link)
And finally a Solid (filled faces) rotating cube with hidden face removal (link)
Now things are getting real entertaining… any ideas?
It’s out! They did it!
The new PIC32 multimedia board from MikroElektronika has been officially announced today! http://www.mikroe.com/en/tools/pic32mx4-multimedia-board/
MikroE is world reknown for its well designed, documented and fully featured demo boards and development tools for all Microchip microcontroller families. But if you liked their Big Boards… you are going to love this “small” one.
For less than $150 you get a board that can truly put the PIC32MX460F512 chip to work, allowing you to exercise all its peripherals, including:
- Drive a TFT QVGA (320×240) display with a fast 16-bit parallel interface
- Read Touch screen input or Joystick inputs
- Play and record sound interfacing to WM8731 16-bit audio codec (including headphone amplified stereo outputs)
- Access files on SD/MMC cards
- Access files on USB memory sticks (USB Host)
- Connect to a PC (USB device) using HID, CDC or MSD classes
- Connect to a Mouse, Keyboard or printer (USB Host)
- Connect with a IEEE802.15.4 (MiWi/Zigbee) wireless network
- Access additional 1Mbyte of serial flash memory
- Access 1Kbit of serial EEPROM
- Exercise the Real Time Clock and Calendar with a 32kHz external crystal
- Interface to an MCP9700 temperature sensor
- RS232 port selectable (UART1/2)
- Interface to a 3 axes accelerometer (ADXL345)
- Use an ICD2/3, Real ICE or even a simple PICKit2/3 to program and debug
- Further expand the board using standard 100mils spaced side connectors
Also you can take full advantage of the entire set of Microchip Application libraries to create complex applications fast! In fact the board is designed to be compatible with the following Microchip (free of charge) libraries:
- Advanced Graphics Libraries
- USB Framework (Host/Device)
- MDD File System (FAT16 and FAT32)
- MiWi / Zigbee
- 32-bit Audio library
- Peripheral library (I2C, SPI, UART, RTCC, PWM…)
I want one!… CORRECTION.., I need one!… CORRECTION I need a bunch of them!