Dear Forum Members,
It's my pleasure to announce the VSOS kernel version 3.19 for testing. There are some major improvements in the kernel and in the tools, as well as a lot of new drivers and libraries for runtime loading.
Nand Flash Driver
Starting from the drivers, Nand Flash (K9F4G) is now supported. The driver comes in two parts: K9F4G.DL3 is the driver proper, it creates the nand flash logical disk. That driver uses the second part of the driver: the NFBADMAP library, which handles the mapping of bad blocks and can also be used to low level format the flash. For more information, see
viewtopic.php?f=13&t=1358.
The Nand flash driver is wear-leveling, e.g. it circularly writes to the entire surface of the nand flash. It currently supports SLC flash, but is written so that it's easily modifiable to support also MLC flash - we are currently working on it at VLSI, making it work together with our Reed-Solomon error correction. This version of the driver uses one-bit error correction.
List of loaded libraries and free memory
The first thing to note in the kernel, is that you can now get a listing of loaded drivers and free memory. Start the updated main menu (INIT.AP3) and press Info, you will see:
- info1.png (5.94 KiB) Viewed 11307 times
The screen indicates that the drivers for the LCD, console, touch panel, stdbuttons, SD card and Nand Flash are loaded. Having loaded those, there is still some 160 kilobytes of free memory (code + data).
30% more program memory for applications
You'll be happy to note that the even with new features added to the kernel, available code memory for drivers and applications has increased from about 64 kilobytes to 84 kilobytes in this kernel version. You'll also see, in the list of loaded libraries, the main menu (INIT) and the program(library) that lists the libraries (LIBLIST). It's a good idea to divide rarely used features of programs into separate libraries, like the liblist.dl3 in this case, to save more memory for those features that are needed all the time. See the source code for INIT for one possible way to call libraries with a very simple method.
Source code for 27 DL3 libraries
And speaking of source codes, a separate zip archive of VSOS 3.19 libraries source code is now published. It contains the source code for 27(!) libraries that extend the functionality of the operating system from those that are already published as VSIDE templates. For most of the libraries, open the .solution file for the library and see the main source file to see a short description of what the library is for and how it should be used.
Unifont International Character Support
The libraries source code also contains various versions of the Unifont font table (UNIFONT.DAT). With the unifont, you can add support for various international character sets, such as Chinese or Korean. Which character set to choose depends on the size of the flash and the size of those libraries that you need for your final product. The smallest unifont font file is included in the /SYS as default, it contains Latin + Chinese and some other character sets. If you need support for Korean characters or a newer set of characters, choose one of the other unifont.dat variants. We can also compile font files with other character sets for you.
New MP3 player demo
One piece of software uses the Unifont renderer so far: An MP3 player example that uses a new StdWidget graphics library. That one is still under development but it can give you some ideas of the types of applications that can be developed under VSOS. Amazing graphics are not the main feature of a SoC with mere 256 kilobytes of RAM, but with careful design, attractive applications for specific purposes can be designed nonetheless. Here's two screenshots of the MP3 player. In the bottom one you can see some Unifont characters rendered.
- selectdisk.png (7.26 KiB) Viewed 11307 times
- CHI4B.png (7.04 KiB) Viewed 11308 times
Multi-format decoder support
For music playing, DL3 libraries for decoding AAC, FLAC, MP3, WAV, WMA and Ogg Vorbis are included. These libraries are released only as binaries, the source code is not included.
MP3 and OGG encoding
This release also contains applications that demonstrate MP3 and OGG encoding. The demo AP3's encode from line in (stdaudioin) and write to E:OUTxxxx.MP3. Again, the source code of the applications should be a good example on how to invoke and use these encoder libraries.
- mp3enc.png (2.67 KiB) Viewed 11266 times
Slave decoder support
From time to time we are asked if the VS1005 can function as a slave decoder for a host microcontroller. To this question we have answered: yes it can, but some software for it needs to be written. We have now included a key piece of such software: a DEVSDI.DL3 library and its source code. This driver creates a logical disk drive, from which you can open an file handle with fopen(). It installs an interrupt receiver for SPI1. When you read from that file, anything that you send to SPI1 with a microcontroller is received by that file handle. This means simply, that you can add, for example, "DEVSDI D" in your CONFIG.SYS and then call any music player, such as "PLAYFILE D:". The devSdi driver creates the disk D: and the PLAYFILE opens a file from that disk (no file name besides D: needs to be given) and plays whatever it receives. You can then stream a file to it from a microcontroller.
Error trapping and tracking
In the depths of the operating system, a new error tracking mechanism is added. Consider for example this simple program which has an error - it tries to call a device without first initializing it:
Code: Select all
/// \file Humbug.c Example to demonstrate error handling
#include <vo_stdio.h>
DEVICE *notInited;
void LetsCrash() {
notInited->Identify(NULL,NULL,0); // DEVICE CALLED WITHOUT CREATING IT FIRST!
}
void main() {
LetsCrash();
}
This program, when run (it's loaded as a driver for this demo), produces this output to the UART stderr console:
Driver: HUMBUG... ZeroPtrCall from 17650(0x44f2), i0=0(0x0000).
Offending lib: Humbug:0.16
Function: _LetsCrash+16
You can see that the kernel traps the invalid call to the uninitialized device. You might wonder how this is possible when the processor has no memory protection. It's possible by a clever trick: VSOS keeps the first 16 locations of data RAM zeroed, so all references to methods via the uninitialized object's self pointer (null) resolve to zero. And location zero in instruction RAM contains a trap to kernel function ZeroPtrCall. ZeroPtrCall then tracks the origin of the call, calls LIBTRACE.DL3 to scan which library is loaded to that address and FIND_ERR.DL3 to scan the symbol table of the library file to show from which function the erroneous call was made. This has great potential to help you to find the reasons for any ZeroPtrCall errors you may get.
Available memory tracking
Another nice thing is that I added code to track code memory usage to the GetMemory function. Whenever a new "record high" I memory allocation is reached and less than 4K words of instruction memory is left, a notification like this is sent to the UART stderr console:
IMEM: only 2768w free!
Let's go!
Ok, this should be enough to get you started in testing the release. We also continue to test and develop. This release has been a major test release in anticipation of VSOS 3.20, which should be more like a "final" version for a while. We're still fixing the fat writabe file's seek and append code, we aim to get that nailed down in 3.20. Then it's time to concentrate on apps development for the OS instead of working on the OS itself. So until then, let's keep in touch and please keep those reports of working and nonworking code coming to us!
Sincerely,
Panu
). And the product we are developing requires compressed recordings of 15 to 30 minute average with a max of 60 minutes. This makes removable and USB mountable mass SD storage far more practical. So we need USB mountable SPI External Flash for program development and field testing and Mass SD storage for runtime user access.