Now that the Italian North East air space has been opened up a bit removing (at least during the week ends) massive restrictions that represented the legacy of the cold war era, flying a small two seater (Tecnam P92) from the foot of Alps to the Adriatic sea is a privilege and a joy.
The two shots above are taken in proximity of Conegliano (those vineyards you see are Prosecco in the making…) and Eraclea’s beeches!
During the WWDC 2014 event this week, Apple unveiled a new programming language called Swift. This is meant to complement the Objective C programming language that has been serving Apple developers for the past 20 years and eventually replace it as the main tool for apps creations both on iOS devices and Macs. Getting rid of the “C” part, as Federighi put it during the keynote, is quite an understatement. The transition from Objective C to Swift looks to me more like the transition from programming in Assembly to programming in C back in the ’80s (or in the late ’90s if we look at the embedded control industry). Swift takes many more things from Python, Ruby and the many other ‘scripting’ languages in use today than Java and C# did in the previous generations and goes well beyond.
There is one major difference though between Swift and all of the above languages, it does compile to a binary executable.
The Swift designers did care about ease of use and interactivity but were not willing to compromise on performance. So while Java, Ruby and Python eventually compile to byte-codes (an intermediate binary of sorts for a ‘virtual machine’) that needs to be interpreted at run time, Swift emits actual binary code for the target machine. Portability (across the iOS and OS X platforms) is obtained by using an LLVM based compiler which can be (easily, if you are Apple that is) retargeted to different CPUs as needed and through the extensive use of carefully architected libraries.
What has all this to do with the embedded control world?
They tell me that every good author should have a Twitter account and should tweet early and often.
They say a good author should use Facebook too! Now that might be stretching it for me, but I can give Twitter a try.
I have connected the blog to Twitter automatically using TwitterFeed, so if all is working, this post should produce my very first Tweet!
Or the second one, ops!
In the last three chapters of the Flying PIC24 book, I developed a simple audio (WAV) file player. What most readers might not know though is that that code was really written first for an 8-bit micro controller back in 2002, when I had my hands for the first time on a PIC18F8720 engineering sample. This was for me the first opportunity to work with a PIC microcontroller with 4K bytes of RAM. In truth I had developed the file system code almost a year earlier on a smaller PIC18 model but connecting it to a Compact Flash card and using an external (parallel) static RAM memory chip (8K bytes).
Traces of that code, that I used to access the external RAM memory “expansion”, can be found today (14 years later) in the latest version of the MLA File System library , just look for the ReadWord() and ReadLong() functions.
As my confidence and understanding of the FAT file system and audio playback grew, I reduced the RAM usage from 8K down to 4K (eventually replacing the CF cards with SD cards) before I migrated it all to the PIC24 first and (much) later to the PIC32. Eventually the code was optimised further to use less than 2K bytes of RAM including both file system AND audio ping/pong buffers.
On the PIC32, RAM scarcity (so to speak) became a factor again only when I tried fitting/porting the Helix MP3 (soft) decoder algorithm in the 32K RAM available on the early PIC32MX4 series. I conquered that challenge too eventually but that is another story.
Only very recently I got the request from a reader to bring the PIC24 WAV player down to the smallest possible PIC microcontroller and this got me interested once more in closing the circle and going back to 8-bit solutions.
I spent a few hours this past weekend testing the new “Graphics, Touch, Audio and USB” book examples on the PIC32 Mikromedia Plus board. Here is a short summary of the discoveries and the few changes required take advantage of the gorgeous 4.3″ TFT display and other platform differences:
HardwareProfile.h and all graphics primitives will scale automatically.SSD1963.c for the occasion.touchscreen_StTMPE810.c module for it.PICconfig.h set of pragmas used for initial configuration (must select the RMII Alternate configuration).HardwareProfile.c file.All in all, with the exception of the new Touch controller, it was my first encounter with such a device, it turned out to be a relatively quick porting exercise. This is testament to the flexibility and power provided by the MLA!
Soon, I am going to complete the testing of all projects for the two PIC32 Mikromedia variants and I will post the new repositories and archives for you to download and enjoy.
P.S.: The 4.3″ screen is simply gorgeous!
While originally managing a separate web site for each book (plus the blog) seemed a good idea, with the fourth book published, the situation was getting a little complex…
So I have decided to unify them all under the WordPress umbrella.
I have done my best to preserve the complete functionality but I am pretty sure there will be some broken links here and there…
Should you find any, please let me know! Thanks!
A rainy Sunday afternoon gave me the perfect motivation to begin re-testing the projects and code examples of the “Graphics, Touch, Sound and USB” book with a PIC32 Mikromedia board to verify the claimed portability of the whole experience across 16 and 32-bit platforms.
The first step was to create a new PICConfig.h file to set the proper PIC32MX460F512L configuration bits, easy!
Next was adapting the HardwareProfile.h to the specific pin assignments used on the PIC32 Mikromedia: just a few touches here and there (80MHz, 16-bit PMP, a pair of I/Os…). Mind I had done all this before (actually long before the PIC24 MIkromedia existed) but years have passed, MLA revisions have changed, and even the PIC32 Mikromedia has changed a little since the early prototypes I had been privileged to play with and test.
The uMedia.c support module was my next adaptation. The PIC32 cache needs to be initialised, interrupt mode must set, Jtag port has to be disabled, so it is a good idea to call the uMBInit() in every project right from the start.
Then I began re-testing starting from Chapter 3, when the MLA Graphics lib starts flexing muscles. Obviously Bitmaps and Fonts need to be re-packaged for the PIC32 using the GRC tool with the 32-bit setting. Note that any individual resource that is smaller than 32K can be packaged directly in 32-bit mode and will be accepted by both XC16 and XC32 (see the LCDTerminalFont.c as an example!).
Chapter 4, the Touch support module required the first use of interrupt (Timer3 sets the touch scanning state machine rithm) and the PIC32 uses a different pragma syntax:
#define _TIMER3_ISR __attribute__(( vector(_TIMER_3_VECTOR), interrupt(ipl1), nomips16))
But also the timer3 interrupt flag ‘shortcut’ (_T3IF) is missing in the device definition and I ‘d better use the full spelling: IFS0bits.T3IF.
More, the PIC32 interrupt mechanism requires a specific interrupt priority level to be assigned (the default is 0) or no interrupt will be generated regardless of the enable bit state: I PC3bits.T3IP = 1;
Chapter 5, SD card and Serial Flash worked as a charm.
Chapter 6, exercising the Audio Codec required a few more changes to the support module V1053.c because of the rearranged SPI registers. Note, lesson learned, this was one of the places where using the peripheral libs from the very beginning would have paid off!
Chapter 7, GOL at this point was a walk in the park, but I have left the GDD projects for later as I rushed to check the last two USB projects in Chapter 8. Once the USB PLL is turned on, adding a pragma to the PICConfig.h, all is well and both the CDC Serial Port emulation and the HID Simple demo worked right away.
In summary, a few rough spots were identified here and there, mostly punishing me for going too low level with the Audio Codec and the SPI/Timer peripherals.
I recently got a few inquiries regarding an old project about a AVI Video Player for the PIC32. I had done the initial work in 2009 on one of the earliest prototypes of the PIC32 Multimedia board and later updated it for the PIC32 Mikromedia in 2011 (blog). At the time I achieved a refresh rate of 15 frames per second with a 16-bit colour resolution in a 320*240 screen (upscaled from an un-compressed AVI stream of 160*120), 8-bit audio mono. Considering I was using a “Mobile” display (COG) and an SD card in SPI mode and an 80MHz processor with 32K of RAM, this was pretty much the best that could be obtained thanks to some significant sw hacks (including mods to the MDD File System lib and the Graphics lib).
The bottleneck of the system was easily identified in the SD card interface used to read the AVI file. The SPI port at the maximum operating speed (given the processor 80MHz clock) was limiting the peak data transfer to 20Mbit/s but the SD card itself (seek time) and the (MDD) file system were adding overhead keeping the effective throughput below 9 Mbit/s.
With a very simple back of the envelope calculation it can be found that a (160*120) RGB video stream needs 8Mbit/s and then the audio stream must be interspersed. Upscaling the stream to 320*240 was all that the PIC32 could do in the few ms left after each frame.
Replacing the SD card media with a more ‘parallel’ Compact Flash media was an obvious path to higher performance and one that I had been dreaming of for a while. In the past I had used Compact Flash cards extensively, in fact that was the original media I had used (with a PIC18) to develop what eventually became the File System presented in my books for the PIC24 and PIC32. This was eventually adopted and greatly expanded in the MLA libraries as the MDD File System but, in recent years CF cards lost the favours of the embedded control community as SD cards become so inexpensive and their form factor being so much more convenient. A Compact Flash card can be accessed using an 8-bit parallel bus or a 16-bit parallel bus, and that theoretically would directly increase the bandwidth available to a clock limited processor by a factor of 8x or 16x over the serial (SPI) interface used on the SD cards.
To test this assumption I used a board developed to my specifications by Peter Szilard, a master of PIC32 applications and a friend. The board features a 4.2 inches mobile display (using a COG controller: IL9326) and most importantly has a Compact Flash slot. Both are interfaced to a PIC32MX795 via a shared 16-bit Parallel Master Port. I quickly ported the MLA display Driver module to the IL9326 controller so to take advantage of the graphics libraries (see picture above).
The first benchmark came from the graphics controller itself. Using sequential pixel access mode for fast line drawing, I could demonstrate that filling the 432 x 240 pixel screen (16-bit color depth) required only 10 ms.
Porting the MDD File System driver for CF cards to the new hardware proved trickier than expected. All my previous examples had used only 8-bit mode, and in fact did not use the PMP either. After spending a few hours pouring over the old CF card specs still in my possession, I ended up rewriting quite extensively the low level sector read/write routines to perform full 16-bit access to the control register set and to get the fastest transfer possible. The results were quite rewarding: a random 512 byte sector could be read in less than 300 us on average, almost a 5x improvement over the SD card speed, but still far from the theoretical 8x/16x.
The next step in performance was achieved once I realised that the majority of the time spent when reading a sector from the media was waiting for the CF card to process the request (something comparable to the seek time of a hard drive) rather than the row data transfer. The standard ATA SectorRead command does in fact allow for multiple sequential sectors to be requested at once and, when that is done, the seek time is incurred in only once, at the beginning. Combining this notion with the understanding of how a FAT16/32 file system works, that is using contiguous groups of sectors, known as ‘clusters‘, to fragment files across the media, it follows that the best performance can be achieved by reading back a file by clusters rather than by individual sectors. This could be easily verified by benchmarking the time to read a cluster of 8kBytes of data at a time, which took on average less than 800us. In other words, we are talking of a 10 Mbyte/s throughput (see in the figure above the 79ms indication for 100 repeats).
With these results, we can see how a full 432 * 240 pixel frame (16-bit colour depth) consisting of 207 KBytes, would require less than 20ms to load , which added to the 10ms for the display update would allow for up 30 frames per second (fps) continuous video (and audio) playback!
Next, putting it all together and actually playing back a full colour and resolution (432 x 240 x 16) 25/30 fps video…
P.S. If you are wondering why the MLA (MDD File System) does not use a cluster buffering mechanism by default, here is the quick answer: RAM scarcity, determinism. Each open file needs a buffer and its size is dictated by the smallest block of data that can be retrieved from the media. For most media that number is 512 bytes if a single sector is fetched at a time. Using cluster buffering makes the buffers much larger (4K bytes, 8K bytes .. 64K bytes…) but even worse, makes their size media dependent as each disk/card can be formatted with a different cluster size
Faster than I had expected, Amazon has already started listing the new book!
Now I wonder how the 20% discount on the cover price on Lulu.com will compare with the free shipping options available on Amazon.com (at least to the ‘Amazon Prime’ customers)…
Let me know…
Graphics, Touch, Sound and USB – User Interface Design for Embedded Applications
Since the very first “Programming 16-bit micro controllers in C” (aka the Flying PIC24) book started shipping in the US, I began receiving from my readers requests for a follow up title that would include new and more advanced peripherals such as USB, and would help introduce complex libraries such as those contained in the Microchip Library of Applications. At first I got busy with the PIC32 book, and soon it was time already for a second edition of the PIC24 book. But all along I had been collecting material and ideas and started creating projects using the Mikroelektronika Mikromedia boards.
In the book you will learn how to interface to color graphics displays (TFT), read touch screen inputs to design compelling graphical user interfaces for your embedded control applications.
Ordering the book directly from Lulu.com (this is a print on demand service using a world wide network of printing facilities to ensure quick delivery in all continents) you will get an automatic 20% discount off the regular price of USD49.50 (39.50).
For those of you that prefer Amazon or Barnes and Noble, please be patient, it will take a few more weeks until the full distribution network is enabled and primed.
Eventually it took me almost 5 years to put together the material for this book, but I truly hope you will find it worth your time (and money)!
