BC2 Integration #2

A quick update.  The LEDs and basic communication with the PC program over USB is done.  I have the same functionality that was present in the original Brick Buddy as far a s the LEDs are concerned.  Plus the same functionality in the control loop is done.  I am not ahppy with the way it works.  It is cross between the executive loop I had before and the Harmony framework of state machines.So some refactoring is in order.

Started the Motor Integration and realized it was not going to be that simple.  I have a Harmony system timer running now, Timer1 and instance IDX0.  The timer is dynamic  The motor test program used Timer 2 as the input to the CCP sections.  However this was also IDX0 and was a static implementation.  Merging these together will be challenging.  i intend to redo the motor test program using Timer 2 as IDX1 and see if that will simplify the problem.  More tomorrow.

Finally once the motor integration is done, the project will graduate to the final name, Brick Buddy 2.  so watch for it.

Brick Controller 1 User Videos

We have received two videos from a user in Georgia,  Considering that the young gentleman is only 10 years old, he has a very bright future as a Lego builder.  Here is one of the videos.

To see the other one and the rest of our video collection go to MyMakerTools.com and scroll down to User Videos.

MPLAB X Harmoney Framework - Lessons Learned

I will not say I am an expert on the Harmony Framework, but I have been using it for about a year now.  All of my experience is on version 2.06.  A couple of things I  have learned.

Copying a Project

Using the project copy feature in MPLAB X seems to be problematic.  I think I am using the standard (default) directory structure, I don't change anything when I created the Harmony project.

Not all of the source code seems to copy over and launching Harmony results in a not valid Harmony project message.  In the end I manually copied it over into a new directory and that seemed to work.  Now I always place files in the project using the relative reference method.  Something left over from the early days of MPLAB.  As added insurance, I renamed the original directory.  That way if any files were absolute referenced, then project would not compile and they would be identified.

Adding Features

My development philosophy is incremental for a software development project like Brick Controller 2.  That is  I get the basics of one feature, BSP, HID, RTCC, MicroSD, etc working and then integrate this into the bigger project.  This way I am not fighting both the feature and how it interacts with the bigger project.  I have found over the years that this is much easier and is, in most cases, how Agile development works. 

This is the approach I took with the Brick Controller 2.  What I discovered was that the Harmony Framework does not like it when you modify code or source files it generates.  In some cases it was trying to replace previous code or code that I placed with new code.  Needless to say, I selected "approve all changes" mode.  While this prevented overwrites of existing code that was needed, it would also prevent me from included new code.  There did not appear to be a way to copy the new segments onto the clipboard or anywhere else for later insertion.  This would lead to missing code and compile time failures.

My solution was to create a new project for every new feature.  This eliminated the code over writes.  It also had the added benefit of testing the feature in a standalone mode, before integration into the larger product.  You will have to go through all of the files in the directory "src" above and copy the relevant parts to the same file in the main project directory.  This does take a little time, but one big upside is that you are exposed to most of the generated code.  Once all of the code is transferred, you can compile and solve the inevitable integration issues.

Bricks by the Bay 2020

As I stated in this post, Bricks By The Bay 2020 will be a virtual affair.  We have signed up to attend.  This is the email announcement that we received.

After careful consideration, we've decided to take Bricks by the Bay into the online arena with a virtual version of the convention starting with an opening ceremony at 7 PM Pacific Friday July 10 continuing throughout the day on Saturday July 11.  While nothing can replace the feel of ABS under our fingertips, we hope to maintain the cool and clarity of our Vision 2020 theme and provide a fun and interesting experience for all of our fans. 

We will have virtual tours of MOCs built by Bricks by the Bay builders, panel discussions, workshops, LEGO Masters participants, talks, games, contests and a chance for you and your family to show off your own MOCs.

You can sign up for the virtual convention on this website (www.bricksbythebay.com) starting June 1.  There is a limit of 1000 attendees.  Registration for the virtual convention (per connection) will be $5.  If you visit us in the real world in 2021 we will have a printed convention brick for 2020 virtual attendees.

Let us know if you would like to be part of a presentation at the virtual convention. We will be contacting people from our recent survey but please let us know again if you do not hear from us.  We are assembling the schedule at this time!

We will be returning to the real world June 17-20, 2021 with our new theme being Looking Back which should allow your Vision 2020 MOCs to remain relevant while also giving you a chance to also build a depiction of history either recent or long ago.  We hope to see you at the Santa Clara Convention Center in 2021!

Attendees

So how is this going to work. Don't know, but it could be interesting.  Unfortunately I will not have anything new done in time.  So I will be attending as a viewer and not a presenter.  Going to the presentations will be fun, though I probably should have volunteered my presentation from 2018 on the the Planetary Space Port.  If they are anything like the Zoom meetings, the discussions might be more robust than a typical in person lecture.  How they are going to do MOCs will be interesting to see. 

I can see where this can even be applied next year to a full convention, where you can get people to attend from around the world, that otherwise could not go. 

Vendors

Bricks by the Bay is also considering some type of virtual presence for vendors.  This will be limited to a non interactive vendor hall.  But in the future this could be interactive with the right technology.  As soon as I know how this is going to work, I will update everyone.

BC2 - Integration Begins

Started integrating all the code that I developed earlier on the PIC32MX470 Curiosity Board.  First up was getting the HID device to work.  Well did not go exactly as planned.  First the transferring from the Curiosity Board to the BC2 Proto by changing the BSP files there was a small burp.  So I had to start that all over again. 

Two things happened:

1. Using the project copy function in MPLAB X, did not do what I thought it should.  The code would not compile and the Harmony framework would not start.  Web searches showed I was not alone in this.  In the end I just manually copied the directory and then went into MPLAB X and made sure all files were relative and not absolute.  To make sure there was no absolute references, I renamed the original directory.
2. The Harmony framework will on occasion  will want to overwrite existing code with what it thinks are changes.  In reality these could be additions that were added.  I assume the process is to never modify the files Harmony generates, but at least for me, this seems impossible.  So when the BSP changed, other code segments I had added were deleted.  Had to start over and be more diligent about the changes I approved.

With that hurdle overcome, compiling and running worked up to the point that the PC was to enumerate the USB HID device. The device was reset, but never configured and the PC announced the device was recognizable.  MY first thought was the same problem I had encountered on the Curiosity board.  But after examination that was not the problem.   I spent a day and half looking at everything I could think of.  Prepared another BC2 proto board just to see if there was a problem in assembly.  Reviewed the layout and the connections, this was my first working USB Type C connector board.  Everything was where and how it should be.  My only clue was that it seemed to be running slow, but I assumed that some loop was taking to long since the USB wasn't working.

I had long ago connected a serial port to spew the debug messages from the Harmony framework and the ones I put in it.  But now this was not working either, bits were coming but the baud rate was wrong.  Curious!  Checked all the code to make sure the baud rate was set correctly, no issue.

Then the light bulb went on, the clock setup had to be wrong.  Even the though the code indicated it was running at 80MHz, looking further into this segment, showed it was only a #define.  Now with the running slow I noted earlier, I went to look at the clock setup.  Sure enough it was using the setup from the Curiosity board.  Changing that to correct values and the USB HID connected to the PC followed by the PC software recognized the proto as a Brick Controller 2.  Now integration can truly begin.

BC2 with Basic Motor Control

I have basic motor control working.  Motor Port 2 has some issue in the forward direction.  Looking at the pin on a scope shows the waveform, only at a few hundred mVolts.  I suspect there is a short to ground somewhere but I have not spent the time to look for it.  The other 3 Motor Ports work so I moved on for now to testing and driver development. 

When I first started testing, the PWM frequency was 20KHz, but on the scope it did not seem as though LB1836M motor driver could handle it.  I eventually lowered the PWM frequency to 5KHz, which seemed to work better.  I have read where Lego is using 1150Hz.  After finishing some driver cleanup, I am going back to retest the PWM frequency and generate documentation for no load motor conditions.  Just so I have it for future reference.

Here is a video that shows the basic driver going forward and reverse.  The motor starts at 100% and then slows down 5% every second.  It is actually easier to hear the change than see it.  This particular MOC I use at shows for customer interaction.  I have the Android App (modified for show use) running on a small tablet and the customers, mostly kids, can rotate the turret left or right and then fire the cannon.  It also has a clear front so you can watch the large (multiple gears) gear train work.  Because the gear train is so large, there is a large amount of the slop and slip in it.  This slop was always obvious when it changed directions in that you could hear the motor turning but the turret was not moving.  Then once the gears caught up it would move in the new direction.  I suspect this is also happening even when going in the same direction.  As the motor slows down in small steps, the gear train takes time to catch up.  I need to run this test by increasing the motor speed and see what happens.

BC2 with Basic PWM

Hard Lessons Re-Learned

After the I2C was working I moved on to PWM for the motors and the single LED controlled by the PIC32.  This seemed very easy from looking at the examples in the Microchip Harmony Framework.  I used my Digilent Analog Discovery 2 USB device to watch the signal.  These are great devices that can be a 2 ch scope, 16 input logic analyzer, waveform generator, etc.  For looking at signals under 2MHz, this much easier than pulling out my Tek Scope.  See here for more information https://www.analogdiscovery.com/

And here is where the fun began.  The circuit I was testing was a single pin driving a FET with 196 ohm current limiting resistor in the path as shown here.

I was using the Digilent USB device hooked up as logic analyzer.  Nothing would show up at the two pins where the LED connects, J13.  Then using another lead and probing the gate and the source pin on the FET, the expected signal was there.  But on the other side of the current limiting resistor nothing.  After a few hours, it becomes clear this is an open collector driver, of course there will be no signal because it is an open circuit.  I dug up a 330ohm resistor to put across the connector, J13, and still nothing.  So I changed to scope mode and the signal is there.  But since there is a current limiting resistor and I was measuring between the current limiting resistor and the 330ohm, the signal did not return to zero, actually a little over 1V.  So the logic analyzer portion of the Digilent wont work, as one would expect.

Well after a day and half of this, I verified that it all works.  It actually always worked,  I just did not know it.  Next step is to get all 4 motor ports working in forward and reverse and then write a driver for the PWM portion. 

Here is a quick video of the PWM signal incrementing from 5 to 100%, in 1% steps.  The PWM frequency is 20KHz, not sure it needs to be that high.  LEGO seems to use 1150 Hz, but I am afraid that will generate unwanted audio tones.  But that is easily changeable and have setup constants that will do all the necessary arithmetic.  At 20KHz there are 2000 steps with this PIC32, much more resolution that we will ever need.

BC2 and LED Control with I2C

After a successful power up, I moved on to the I2Cbus interface.  On the I2C bus is the LED controller, LP5569, and the USB Power Controller, STUSB4500.  The STUSB4500 was not in ready stock anywhere, so that was a DO NO INSTALL during assembly.  The STUSB4500 is only accessed once and that is during PCB configuration, at least that is the current implementation.  So I built the Harmony 2.0 driver around the LP5569.  What I have now is a very basic driver that does the following:

• RESET
• Initialize
• Configuration (enable/disable)
• Register Dump
• Update all PWM registers
• Basic Write Register
• Basic Read Register
• Read/Modify/Write Register

There is still a lot of clean up work and optimization that needs to happen.  This is a standalone program for now, which means it will need to be integrated with the other pieces.  But I am quite happy with the current state.

There were some development issues.  The PICKIT4 does not seem to like MPLAB 4.2 very much.  It would hang occasionally and does not the PIC32 register or SFRs.  Changing back to the PICKIT3, at least solved the register and SFR issue.

The LED control in Brick Controller 2 consists of 10 LED ports.  In the original Brick Controller there were only four LED ports and this was not sufficient.  The LP5569 will control 9 LEDS either individually or in up to 3 RGB groupings.  Port 10 is under direct software control and is connected to a PWM port on the PIC32.  The intention is to have ON/OFF, Burst, Cycle and the PWM functionality on all 10 LED ports, but we will see how this goes.  The LP5569 is a much more capable device with multiple types of controls, but these advanced features will have to wait until the basic BC2 is done.

The next step is implement the PWM features of the PIC32 that will be used with the 4 motor ports and LED port 10.  I will be using LED port 0 as the prototype, since in this implementation it is much easier to observe.

Here is a quick video of a single LED with varying intensity.

BC2 Power Up

After checking for shorts on the PCB and finding none, I applied power.  I suspected it would not work without the USB Power controller and I was correct.  But grounding the control for the P_FET brought 5 VDC to the power section and all the DC-DC converters powered up. 

Then I built the Board Support Package for the Microchip MPLAB X Harmony system.  Finally did a very simple program to blink the BLUE/YELLOW USB connection LEDs that I use in all of the MyMakerTools products.   The result is below.

Next is to build the I2C driver and the application code for the LP5569 LED controller.  I have this mostly done from a previous prototype, but need to convert it to the Harmony structure.

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.