Back At It - The Brick Buddy 2

 As always with life, things happen and I have been distracted by work and family.  I have been slowly working on the Brick Buddy 2 platform.  The layout is now complete as the picture below shows.

You can see the TYPE C connector on the right, the Bluetooth module in the center top and the brick interface on the left.

The Brick Interface has four motor connectors using the same style connector as before.  Above that are the four input connectors, using a similar style connector only smaller.  What is good about this connector style is that pre-built  cables are readily available from Digi-Key.  Above that are the 10 connectors for the LEDs.  The first nine are connected to the LP5569 LED controller and thus will have multiple possibilities in lighting control.  This uses the same connector that BrickStuff is using with their LED product line.

In the center left is the connector for the Mass Storage, MP3 player and amplifier, but we will go into further detail about this later...

Finally I changed the external power connector to the same one as the motor connection, since this breaks out to a Power Functions connector.  It allows the Brick Buddy 2 to receive power from any Lego power source. 

In my last post I talked about design decisons that needed to be made.  Here is what happened since then, I went with two spare pins where both are generic inputs and one of them can be an Interrupt input.  If needed I also still have the two programming pins and the Rx pin in the console port.

The motor control pins were complex.  There are only 5 PWM (Pulse Width Modulated) outputs in this version of the PIC32 microcontroller. You could control the motors with one PWM pin on one side of the motor and a static line on the other side of the motor, but I am worried about reliability.  The pins were chosen so that the PWM outputs can be mapped to either side.  Not sure how responsive this is going to be, but I hope it will work.

Next time I will be describing the brick interface in more detail.

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.

HID Problem Solved - For Now

I found the issue keeping the HID interface from working.  Every time you receive a HID report, you need to rearm the read interface, which I knew and thought was implemented.  This also needs to happen at the beginning in initialization.  There were several calls to his in the switch statements, but either the code never passed through these case statements or did so at the wrong time.  I put printf statements in the HID event handler and the USB task case statements so I could watch the startup process.  The only HID report that was happening was Set IDLE and then the interface would hang.  So I added the rearm in that event and it all works now.  The PC program and the PIC32 device exchange messages and the PIC32 device is initialized.  Not sure that is the correct place for it, but that is where it is for now.

I coded the MP3 player portion and ran some tests.  When commanded the, PIC32 loads the file, reads it in and sends it to the VS1053.  When it is done, the file is closed and the USB is reconnected.The player code was hung up trying to stop the VS1053, but for a first run, not bad.  Now I need to verify that VS1053 is initialized correctly and the data is going to the right ports.  Time for the logic analyzer.

Observation:
I have noticed that the demo apps are not consistent in implementation.  I have been through about 5 or 6 of them now as I worked on getting the SPI to work, SST26 FAT, a basic HID and then HID and MSD.  They are good at showing functionality, may not be as good at robust production code.  And when you combine two different apps to get combination functionality, you can run into some quirks.

Mostly Working MP3 Player (VS1053) and HID Problems

In the last week I have made good progress on the VS1053/1063 MP3 Harmony style driver.  I am talking to it, have completed the software initialization and load the patches.  The next step is to implement the player.  At first this is going to be direct processor control.  Eventually down the road, I will convert to DMA, but I need working software first.  Once I am finished with this I will publish the driver here and on the Microchip Forums so other people can get head start on implementing a hardware version of an MP3 player.

For the next step of getting the player to actually work, I need to bring the file system on line and temporarily disconnect the USB MSD (for now).  So to do this I decided to use the HID interface and the PC program I have.  When I last looked at this, Windows had recognized the HID device, the generic HID test I have could read all the configuration data.  My PC program saw it was connected and would send a message.  Some crazy output started, but I had seen that before when the PC and the HID device got into a loop of not recognizing the data they were sending.  So I moved on to the MP3 driver because I thought that was more important.

Well there was more to it.  There always is.  The HID events are not firing after the first one.  I went back to the simple HID test program I did and it works as expected.  The HID events fire and data moves between them.  So the first thought is the MSD portion is getting in the way somehow.  The MSD works fine.  I have compared the HID test program and the HID_MSD program I am now testing and cannot find a difference.  I may have to start from scratch again, except build the HID interface fist and then add the MSD.  Not sure what I am going to do yet, but the next few days are going to be interesting.