Scripting Part 2

The scripting language is mostly done now.  One new item is start script on power up.  This will be a control bit set by the PC/Mobile.  It can be cancelled by simply sending a HALT script command.  This makes installation for shows and the like, much simpler.  Connect the Brick Controller to a power supply and the script is running.  

Now I need to finish the MP3 section.  I would like to show it at #bricksbythebay.

Daughter Card for Brick Controller 2

Spent more time on this than I wanted.  At first I thought there was a PCB error, then realized I had swapped the two SPI ports from the proto I built earlier.  This meant having to chase down ANSEL, TRIS and port settings on the PIC32.  Once that was solved, the drive registered with Windows and we were off and running.  One interesting item is any SPI baud rate above about 500KHz has no effect on the time to write to the FLASH memory (SST26).  For now I dont care, as long as it reads fast enough to keep the MP3 decoder pipeline full.

Next was to place the MP3 decoder chip on the daughter card.  This again was chasing down incorrect settings on the PIC32, but it was finally started to respond.  Now I need to connect a headphone jack to the board and see if it is decoding properly.  The PCB design has a class D amplifier on it, I just have not improved my soldering skills enough to try it.

Refactoring Brick Controller 2

One my tasks I needed to do was to refactor the PIC32 firmware.  When you build the firmware in Harmony, it places  most of the newly generated code in APP.C and APP.H.  This is not very modular, especially if you want to reuse features in a follow on project.  Here is what I did:

• Moved all of the USB functionality (source and headers) to a separate module.  This contains the Harmony framework state machines for USB Tasks, USB Device Events and USB HID events.  All of the variables are contained in a usbData structure instead of the appData structure.  Finally it also includes generic application level handling of the messages.
• Created a generic I2C header for use by the different I2C modules
  
• Created a module for the LP5569 LED light controller IC routines, state machine and I2C implementation.  This uses the generic I2C header file to create the I2C tasks specific to the LP5569.
  
• Created a module for the motor control and control of LED10, since these are all connected to output compare peripherals in the PIC32.  This generates the PWM control for the motors and LED10.
• Created a module to handle the script execution.  This was not part of the Harmony framework, so it was already on the path as a separate module.
• Created a module for the RN4020 BT Module.  This includes the routines for the USART port that connects the RN4020 to the PIC32. 
• Create a module that handles the MP3 state machines and control routines for the VS1053 MP3 decoder chip.  (This is actually a TODO item, since I have not tested the new board yet.)
• Create a module for the file system that is contained in the SST26 FLASH memory chip that holds the MP3 music file.  (This is actually a TODO item, since I have not tested the new board yet.)

So what does that leave in APP.C.  As you might recall, there is a timer generating interrupts at 100ms, 500ms and 1000ms.  The state machine to handle this in APP.C.  My thinking was this is very specific to the Application, so it should stay in APP.C.  Also APP_Tasks is here, which is the main application state machine.  After initialization, here is the main state

        case APP_STATE_SERVICE_TASKS:
     {
            USBTasks();
            FSTasks();
            MP3Tasks();
            LP5569_Tasks();
            PWMCtrl_Tasks();
            BluetoothTasks();
            NVM_Tasks();
            APP_TIMER_Tasks();
            SCRIPT_Tasks();
            break;
     }

BC II PCBs have Arrived

Received the Brick Controller II PCBs.  Over the next few days I will be doing the necessary static testing to ensure that 1) I designed it correctly and 2) the manufacturer built it correctly.  Follow the progress here as I test these in conjunction with the MP3/FLASH module. 

Brick Buddy PC Software

Started cleaning up the PC software for the Brick Buddy line of controllers.  One single software package will work for the entire line of Brick Buddys, at least as I see them today.  The PC software will interrogate the attached device and determine what it is and then load the appropriate software options. 

When the software first starts and when no recognizable device attached, then the control center window will show this:

At this point the user needs to connect a Brick Buddy device to the PC.  Once the device is connected, the PC will begin to enumerate the device and determine it's identity.  Once the identity is determined, the window on the PC will expand to show what device is connected, device status and what if any options are available.  This is shown in the figure below.

This change should make it much easier for everyone to use the PC based software to program and control their individual Brick Buddy devices.

MP3/FLASH Test Platform (Update 2)

Surprisingly the FLASH portion fired right up and worked.  I am now cleaning up the code.  first step was to correct all the USB descriptors so the Brick Buddy PC software will properly recognize the device.  Since the Brick Controller II will be sold without this module, the firmware had to be modified to only check for the device once and not continually.  Dont need to be wasting PIC32 bandwidth looking for things that are not there.  Other cleanup is needed as I dig into this deeper.  But next I am going to modify the Brick Buddy PC GUI and software to handle the new controller.

MP3/FLASH Test Platform (Update 1)

The PCBs are assembled as shown below.  The MP3 decoder has not arrived yet, thus I will only be testing the FLASH drive for now. 

More later as we progress with the testing.

MP3/FLASH Test Platform

While I am waiting for the main BCII PCB to come back, I am building a test platform for the MP3/FLASH  add on module.  I had developed the code for this module using the Microchip PIC32MX Curiosity Board, a MikroBus Click MP3 module and a MikroBus Click 64Mb FLASH Module.  There is still more code development and I thought it would be better to use the known Microchip Curisoity board to develop on than the new untried BCII PCB. 

I designed a small carrier PCB that would plug into the two MikroBus slots on the Curiosity board and pickup all the signals. 

Then the completed MP3/FLASH module would plug into the carrier board.  Here is a picture of how that will look.

Now all I have to do is assemble the two boards.  The carrier will be easy.  The MP3/FLASH module will be more challenging.  Plus the MP3 portion is handled by a VS1053B and only AdaFruit had them in stock.They are in NYC, so we will see how long this takes for them to come in.

Brick Buddy 2 Daughter Card

The Mass Storage and MP3 player card is almost done.  It is still missing the speaker connector.  The picture below shows what it looks like.

The connector on the left is a place holder until I find the correct 3D model.  Instead of the socket shown, it should be a pin connector on the bottom side. The blank area on the right is for the speaker connection. It will either be a standard 3.5mm jack or some type of push down connection. There is a concern with the height as I am trying to maintain the same dimensions as the Brick Buddy 1.

Previously, I was deciding about the amplifier.  While I had acquired 250 of MAX9711 Class AB amplifiers for free, I was worried about heat and efficiency with those.  Looking around at other options and in particular Class D amplifiers, I chose the MAX98306E.  It was small, relatively inexpensive and has been used by other Makers in projects. Additionally, I was able to get a small evaluation board to play with.

Nothing much else has changed.  The board is a simple 2 layer PCB and about as small as I can make it and still assemble in my lab.

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.