Brick Interface

The Brick interface consists of three parts.

1. Motor Control
2. LED Control
3. Input Control

Motor Control
The Motor Control is similar to the motor control in the original Brick Controller.  There are connectors for up to four motors.  In the original Brick Controller the motor control was either on or off, that is it was full speed or off.  In this version, I have implemented Pulse Width Modulation (PWM) control, thus allowing for independent speed control of each motor. I suspect that the first version of firmware and app software will not have this implemented yet, but will be an upgrade.

LED Control
There are controls for 10 LED sources.  LED 1- 9 are controlled by the LP5569 LED controller.  LED 10 is controlled by the PIC32 and is connected to a PWM generator in the PIC32, so it will have some lighting effects.  The LP5569 provides a wealth of capability.  I suspect like the motor controller it will be implemented in stages as the firmware and software coalesce into a working application.  If you want to see what the capabilities are, search the blog for LP5569.  There were 9 entries in the spring of 2018 where I was working on this as a standalone LED controller.

Input Control
While this was implemented in the original version, it was not very clear how to use it.  This time I put some more thought into it.  It is still very basic and it may still evolve.  Mostly I will need to verify that there is sufficient electrical protection on each input.  What I would like to see is a two fold interface.  First is an ON/OFF type input.  The user will connect the input to ground, provided in the connector, which will casue the running script to do something.  Second is to provide a variable voltage, 0 to 3.3VDC again this in the connector, to an input.  As the voltage changes, the running script will do something. The first option was implemented in the in the original version.  The second will take some thought as to how it will be implemented and thus will probably be an upgrade in the future.

Electronics and Soft Wear, Why?

If you visit the Web site or see us at an event, we are easy to find because we always have colorful theme shirts on.  Additionally we are showing theme shirts, unique pillow cases and even quilts.  We are the definition of a Maker.

Gears and Monsters Adult Shirt

Our theme shirts were inspired by aloha shirts. Early in our life, we lived in Hawaii while one of us was in the Navy and the other an accountant in a local (and colorful) CPA firm.  But large tropical prints or iconic beach scenes aren’t appropriate to every occasion. There are times when you need something besides a t-shirt. These shirts are comfortable. They’re colorful. They’re a way to make a statement. They’re fun. They can make you chuckle, like an inside joke or a belly buster to share. They’re a way to say, hey,  I’m unique, I’m fun. They help you stand out in a crowd.

Child's Brick Builder Shirt

For our first Maker Faire event, we wanted a way to show our commitment to the cause….we’re creative and fun and proud of it. I found fabric with gears similar to the logo on the business cards, and the rest is history. We received many enthusiastic comments, so I made a few more for the next event, and even sold a few! And in kids sizes too. 

Large Brick Builder Theme Quilt

At our next event, done forget to stop buy and see the Soft Wear side of what we Make.

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.