01/05/2017 at 09:51 •
It would be interesting to explore a few ideas that came during the development:
1- Verify if a higher resolution (16-bit samples) can be supported given the limited buffer space available (without cheats such as assuming linear FAT clusters allocation etc.)
2- Experiment with SD card "read multiple" command to request entire clusters at once and/or issuing asynchronous read commands (request a read of the next sector before the current buffer is emptied)
3- Test a Class D amplifier topology using the device many analog and digital CIP (core independent peripherals) to improve sound quality and S/N ratio in particular.
4- Test using the NCO to perform freq. shifts, changing sound pitch and other similar effects... (see experiments performed in the PICSPEAK project)
01/05/2017 at 09:42 •
1- The (FAT16) file system has been here further optimised to reflect the lesser degree of scalability expected from an ASM project (required to fit in 1Kbyte of code). Funny how when I wrote this code first (Early 2003) it was for a PIC18. I then ported it to PIC24 (featured in the Flying PIC24 book) and then to the PIC32 (featured in the Exploring the PIC32 book). It even served as an inspiration for the earliest MLA libs. Now it has gone full circle and returned to an 8-bit PIC16.
2- The audio play samples read back from the SD card is actually quite fast, so much in fact that I can afford to perform the playback of 44kHz sampled PCM WAV files with ease, giving good sound quality (20kHz bandwidth).
3- MPLAB Code Configurator (despite producing C code) was very useful to produce the required peripherals configuration templates that I then translated into ASM, saving a ton of time and guess work. Who wants to read data sheets anymore?
01/05/2017 at 09:41 •
Porting (down) a C code base to ASM has been a great exercise for my ASM muscle that was getting really close to complete atrophy!
Even though some of the work turned out to be rather low level repetitive translation of the C constructs to PIC ASM, the need to handle two (overlapping) large RAM buffers (512 bytes each) turned out to be a good test of the agility of the modern PIC (14-bit) core.
The PIC16F18855, like most/all of the PIC models released in the last five years, sports a fourth generation PIC core (Enhanced Mid Range or EMR or more simply the "F1") with an improved instruction set supposed to enable better C compiler efficiency.
In fact I had never programmed any of the devices in this (large) family in assembly, but only exclusively in C!
So this was my first real experience with "Linear Memory on a PIC" and it turned out to be quite simple and powerful. You will find a few "bankselect" statements left only in the initial peripherals configurations, where it is still most convenient, but all the rest of the code is addressing RAM using the "linear pointers"!
As a more general note, the player code had been extensively tested and hacked in several previous projects (in C), so the debugging phase turned out to be focused exclusively on my general ASM level of "rustiness".