With a rewrite of most the cost base under way in preparation for the first stable release, USB code, the new filesystem, and the new bootloader, I have become overwhelmed. It is time to take on help. Could that be you? I am looking for a few good C/C++ programmers. Experience is good, but desire is better. I can’t teach you to code, but I can teach you ARM and embedded systems, if needed. If you already have experience with embedded systems, firmware, or ARM development, then you place high on the list. Anyone can use or modify Pygmy, it’s open source after all. What I’m looking for are a few additions to the core team. If you are interested, please send me an e-mail at email@example.com and sell me on why you should become part of the Pygmy core development team. If accepted as part of the team, I will provide you with a Nebula development board.
Recently I’ve been frantically coding to prepare Pygmy for it’s first stable release. A few structural issues I felt strongly about are currently “under the knife”.
I have separated the xmodem driver from the bootloader into it’s own source to allow easy implementation on the application side.
I’m separating the filesystem into two groups of source, allowing a clean io abstraction layer between the filesystem and the hardware. This is to allow support for additional Flash and SRAM ICs to be added.
The real improvements have been to the SPI and I2C interfaces. The I2C interface has been heavily reworked and tested against a variety of devices as well as a protocol analyzer. The SPI interface has also been heavily reworked to simplify usage and reduce overhead by nearly eliminating the need to write wrappers for specific devices. The devices which handle high level transactions, such as address then data and chip select toggling are named Put and Get. Low level transaction used by the high level or to create wrappers are named Write and Read. Example spiPutChar(). Both SPI and I2C also support port selectable address width, 32bit/16bit/8bit for SPI and 16bit/8bit for I2C.
A few parting notes: Support for Python is now on the list but will take some time. The bootloader will be released in a 16KB version with the addition of the socket interface and a new descriptor interface. An event system will be added to support the GUI, xmodem and socket interfaces. The command queue will be revamped to handle internet connections more reliably.
As of today, Pygmy OS supports floating point formatting. The keystone of string handling, print(), now supports %f through access to convertStringToFloat() and convertFloatToString() in pygmy_string.h.
I’ve been falling behind on my post, but have many posts coming in the near future. Currently the GUI lib is under heavy development. I am adding support for vector drawing, an event handler for the widgets and forms, wrappers for print(), as well as a variety of sensor and memory libs.
With microcontrollers, dynamic memory allocation is often not used, or simply not practical. I found as the Pygmy GUI lib progressed, that dynamic memory allocation was going to be necessary. In Pygmy’s GUI lib, widgets such as buttons, labels and check boxes, are contained within forms. Forms inherit their basic properties from the global GUI structure and each widget inherits from it’s parent form. Forms are effectively pushed and popped from a stack to maintain drawing order. Disabled forms, or any individual widgets may be marked as visible or invisible to prevent wasted stack processing.
What does all this have to do with dynamic memory allocation? Well, to start with, the form stack would have to become static without dynamic allocation. This is problematic enough ( as I found when developing the sprites ), but becomes a nightmare when you consider that each form would then have to have a static stack of widgets as well. To prevent the cascading waste of memory that ensued, I added support for the standard GNU ARM malloc(), realloc() and free(). This involved new linker scripts, making the scripts more board dependent. Also, since planned Pygmy devices will include RAM that the standard lib will be unable to directly allocate, the functions must be “wrapped” to prevent conflicts.
Thus, sysAllocate(), sysReallocate() and sysFree() will mirror the functionality of malloc(), realloc() and free(). The dynamic support is currently only tested on the Nebula HP boards, but will soon be tested on the standard Nebulas as well. Additional enhancements related to the dynamic memory allocation slated for the near future will be a recoding to take advantage of dynamic allocation in the tasking, messaging, command and sprite interfaces.
Recently I was working on a demo game to showcase and test Pygmy’s GUI lib. After making some progress I decided I wanted to share an image of the current state of the game. I could have taken a picture, but it seemed more appropriate to add the capability to capture the screen to a file. Since 24 bit windows were already supported in the GUI lib ( for file creation ), I added guiSaveScreen() which captures the screen and saves it to a 24 bit windows bitmap with an auto-generated name. Here is the first test capture:
Note that there are some stray pixels in the text located in the upper left corner thanks to an oversight on my part concerning guiClearArea(). Also, the image was converted to PNG to post to WordPress which doesn’t support BMP. Support for JPEG, TGA and PNG is currently under development.
The last revision of the Nebula was mostly a success. The one disappointment was the Microchip LiPo charging IC, it performed poorly and seemed somewhat unpredictable when load on the output was inadequate. This forced us to use LiPo batteries with all the prototypes, even when the application didn’t warrant the use of a battery. A redesign was put through to upgrade to a superior TI battery management IC.
Well, the latest PCBs have arrived, been assembled and tested! The TI part functions perfectly, it provides improved protection, a rock steady output and high current capability.
Another first was tested with the most recent proto PCBs: The first XL Density STM32F103s for the High Performance Nebula. These MCUs have 1MB of Flash, 96KB of RAM, and run at 72MHz. Initially, the bootloader failed to flash code into the XL devices. Errata notes and the updated programming manual show that the internal flash configuration changes at512KB to 2KB pages in the HD and XL and 2KB pages arranged in dual-bank configuration for the XL. This hardware change required a minor re-write of the bootloader, which I completed today. The bootloader was already capable of detecting the MCU ID and self configuring to adapt to hardware variations, the update leveraged that ability and new peripheral defines to extend compatibility to the XL line.
Pygmy has always had a basic GUI lib, even before I decided to move from the MSP430s to the ARM Cortex M3s. Now with the new color graphic LCD Shield for the Nebula, it’s time to revisit the GUI code. Just tonight I added animated sprite support. Just today I added support for animated sprites. Pygmy has support for a wide variety of images, including raster fonts and image strips ( sequences of images, or collections of images within one file ). The sprites leverage this pre-existing code. A sprite, in this context, is a sequence of images stored as an image strip that is drawn with a specified delay between frames, thereby producing an animation. Sprites in Pygmy may be any number of frames up to 65535 and any resolution ( practically limited by the screen ) and color depth. Further, sprites may be drawn in any number and in multiple locations on the screen. Each sprite is created with a mutable array of coordinates for each frame. When the sprite is drawn, each coordinate pair is iterated through. So, for a row of sprites representing waving grass, only one sprite need be created, with the coordinate pairs for each block of waving grass stored in the array. If the sprites are intended to move, only the coordinates need to be updated. To create such a sprite, only two function calls are necessary. First, the file or resource must be loaded. Second, the file handle is passed to guiCreateSprite() with the coordinate array and desired time between frames. Each sprite runs as a separate thread. Each thread is spawned by guiCreateSprite() and drawing is handled in the background by the OS. In short, Pygmy Sprites make is painless to draw animated graphics with any supported LCD.