Brick Controller 2 Schematic

Working on the two schematics for the Brick Controller 2.  One is the main PCB that has the PIC32MX470, motor control, LP5569 LED controller, BLE interface and the Type C USB interface.  The other is for the Sound interface daughter card, which has the SST26 Flash memory, the VS1053 MP3 player and a Class D amplifier. 

The daughter card is almost done, just need to make a final decision on the Class D amplifier.  I had 250 of MAX9711 Class AB amplifiers, but I worry about heat and efficiency with those.  So I am looking at some others from Maxim and TI.  More later on this once I make a decision.

The main board is also almost finished.  After struggling with connectors for the LED portion last year on the Light Controller, I decided to use the same connectors that Brick Stuff is using for the PICO LEDS.  They are small and I can stack them.  Plus users can either use Brick Stuff LEDs, or get cables from them, or get cables from Digi-Key.  That makes it as as easy I can.  If I were to go back to the push in type connectors on the original Brick Controller, it would take up a large amount of space and I dont want this to be any bigger than it is already.

Another design issue that came up is that I have used every pin on the PIC32MX470, 64 pin version.  This always  make me nervous when I do a design and all the pins are taken, before the first build.  I know I have forgotten something or will find that I need another control line.  The only two pins left are the PGC and PGD programming pins.  I will connect these to pads on the PCB that I can get to and place zero ohm resistors in the path.  These will be my two spares.  I can do 95% of the debugging with printf statements out the console port.  And in a desperate moment I can steal the console port Rx pin since it is very seldom used.  Moving up to the 100 pin part, just seems like a waste.

More on the design in the next few days.

MP3 Working, on to the Schematic

I was fairly convinced that MP3 quality problems were due to data rate, that is I wasnt feeding the VS1053 fast enough.  So I played with a lot of things in the loop to increase the idle time.  But nothing worked, no matter what I did, the quality never changed.  Then I remembered that the FLASH SPI clock was still running at 200K from when I was just trying to get it to work.  Because of the resistors in the PIC32MX470 curiosity board, going much above 1MHz causes the waveforms to degrade.  (I need to jump these on the SPI bus.)  After moving the SPI clock up to 1MHz, I get near CD quality, at least for my poor hearing (too many years in Naval aviation). 

I still need to optimize the idle time, since there are still motors, LEDs and the BLE interface to service.  But that come with time.  Right now I am working on the schematic, so I can get the PCBs out to fab and built.

MP3 is Working, Maybe

Last time I described my basic plan of attack to solve this problem with the MP3.  There has been some progress.

The VS1053/1063 allows for a sweeping frequency tone output, which I didnt think was working.  After putting a scope on it, I saw that it was.  The frequency starts very low and slowly increases.  It was taking almost 60 seconds to get to an audible range. (After 20+ years in Naval Aviation, my audible range is not what it used to be.)  After seeing this on the scope, I finally heard it.  So the VS1053 is working.

I still could not get the MP3 file to play.  So I moved the Click board to an HPC Curiosity board where I had direct control of the SPI on a PIC18F47K40.  After fighting a K40 errata error I forgot about, I finally was able to play a very short MP3 file, 1695 bytes.  The MP3 file was embedded in the code.

I then moved back to the PIC32MX470 with the embedded MP3 file.  Still no sound.  Now I started putting printf statements everywhere to watch the buffer action.  I had double buffered the file.  The VS1053 will accept at least 32 bytes if DREQ is high. Thus I use a small buffer (we will call Buffer32) to transfer the file .  Thus I always transfer 32 bytes to the VS1053.  But to cut down on overhead, I read from the file in 512 byte chunks, except the first time where it is 1024 bytes, into another buffer (we will call Buffer1024).  The idea is to read 512 bytes in to Buffer1024 every time the pointer crosses 512 or 1024.  Then the play function reads out of Buffer1024 into Buffer32 and sends this to the VS1053. 

Well the buffer pointers weren't even close to doing what I wanted.  Just really dumb errors.  After cleaning that up, I am now listening to Tube Snake Boogie by ZZ Top.  The quality is not great, probably some problem with the data flow is not fast enough yet.  But at least the basics are working.

The driver needs a lot of cleaning up and it may be awhile before I get there.I am committed to publishing this driver so either watch here or the Microchip forums for more info.

MP3 Output is Hard to Get

I always debate about writing about trials and tribulations of getting something to work.  Mostly I just wait until I solve the problem.  But it has been a while, so here goes.

I have the VS1053/VS1063 driver coded.  And as far as I can tell from the logic analyzer, the data is being transferred correctly.  The driver is doing what it is supposed to do.  I see the file open, the file size determined, and then the buffers are filled with data and transferred to the mp3 player.  When the all of the file data is transferred, the player gracefully shuts down.  Also the mfg start up routine is working, in that I can read and write registers and I get the results I expect.

So next I coded some of the chip test routines that are provided natively in the chip.  Baiscally it is supposed to generate a sine wave.  Cant hear anything, but will look at it with a scope today. 

This seemed simple and the logic analyzer gave me confidence it was working.  Next step is to peruse some other samples of working code looking for a gotcha.  If that doesn't work, I have a self contained program, mp3 file included as a constant, that works on a PIC18F,  Pull out the HPC curiosity board and see if I can get it to work there.