Bricks by the Bay 2020 - FRIDAY

Today was the first day.  Some admin discussions and reminders of what is on the schedule for tomorrow.  Only two items were on the schedule today, Meet and Greet and a presentation on the state of BrickLink's Studio software by someone on the BrickLink team.

The presentation on the Studio software was very informative.  They have some very interesting features compared with LDraw, which is the software I have experience with.  Plus he showed some features they are working on.  The most interesting was the illuminated feature. You can choose the illumination and the color and once the model is rendered, this shows up.  In the presentation, he had built a small SUV.  Once rendered, the headlights were on as were the taillights.  This is something I will need to check out.

The remainder of the night was a virtual meet and greet.  Tomorrow starts at 10AM and is a long day.  There are multiple presentations I want to attend, so there will be more tomorrow.

Brick Buddy 2 Serial Port Integration

As I stated in this post, the serial port integration turned out to be a little harder than I had hoped.  Brick Buddy 2 uses two serial  ports (USART in PIC32 terminology).  USART #2 is setup as the console port.  This is only to be used during code development and has limited value in the final product. USART #1 is used as the interface to the Bluetooth Module.  This interface is critical to the operation of the Brick Buddy 2.

The system console port is setup as basically described in this document.  The USART is setup as a static driver that is blocking.  This is the simplest setup possible and thus has the fewest dependencies.  At this point this implementation has been integrated for a while.  Changing it now would require a lot of changes I am not interested in attempting.

The BT Module serial interface needs to be very responsive. In the original Brick Buddy (PIC18F implementation), this was an interrupt driven process on the Rx side and a blocking function on the Tx side.  The Tx was limited to 4 bytes at a time, though. This USART will also be a static implementation, interrupt driven with call backs.  This will allow for Tx and Rx buffers to be used to move the data in and out of the BT Module.  Of the three transfer models described here, the byte-by-byte model seemed the best to use.

I created a new project and implemented the System Console and the System Debug services.  Then tested the firmware to make sure it was working.  Then I created a second project that implemented the BT Module USART.  Currently I have no way to test this, so compilation was the only test.  Then I started to merge the second project into the first project, doing a manual code merge and incrementally testing to verify that the console port was still working.

The first attempt failed miserably. Harmony would not let me change the  USART index to 1 in a single USART project.  Thus after creation, I had to go through the code manually and change all the references from 0 to 1.  Not all references were the same, so a global find and replace wouldn't work and I missed a few, in files drv_usart_mapping.c, drv_usart_static.c and drv_usart_static_byte_model.c.

Then there were single case switch statements that had been created by the first project for the console.  They had to be expanded to include the BT USART.  While 80% were just cut and paste, some of them were different from the console implementation.  This is where attention to detail is important. Some of these functions might not be called until much later and remembering what I did today, then, will be very problematic. 

Next step is to test this whole integration.  One way is to install the BT module.  The other is to connect the BT module development board I have.  Need to think this over some and see what will get me through the verification the fastest.

Bricks by the Bay 2020

Tomorrow Bricks by the Bay starts.  It is all virtual.  This might be an interesting concept even for future in person conventions.  I am looking forward to this as a change of pace from working with the Harmony framework.

So what looks interesting from my viewpoint. 

1. Well obviously I will want to browse the MOCs.  I would have very much liked to have done something new as indicated earlier.  But time has not been n my side.  I hope by next year I will have at least started the Planetary Station upgrade, using the new Brick Buddy 2.
2. 12 Noon  Micropolis
   
3. 2PM The LDraw session is also somethng I want to attend.  I have used this in the past and it is a very useful tool for creating MOCs and most definitely for documenting a MOC.
4. 3PM Catcus Brick
   
5. 5PM I will be very interested to listen to the LEGO Masters TV show discussion with Richard and Flynn.
6. 6PM Alternate slopes workshop
7. LEGO 3D database

@bricksbythebay

Brick Buddy Two Integration

With the successful integration of Motor control, the only missing functionality from Brick Buddy One is the Bluetooth interface and the scripting language.  The scripting language is going to take some thought, so I will do the BT interface first. 

Below is a quick video of LEDs bursting, cycling and pulsing along with one motor working at reduced speed.  You can see there are some issues with the green LED.  Right now I am going for functionality, then the code needs to be hardened.

The biggest issue was integrating a dynamic timer for the system timer (100ms, 500ms and 1000ms timing loops) and the static timer needed for the PWM, as explained in this post.  Harmony does not allow you to do this, so I had to do it manually.  How this was done is a topic for another post.  Then it was cleaning up the PC software to accommodate the speed functionality.

I suspect the BT is going to create it's own issues with the introduction of another serial port.  Right now a serial port is used to put out debug messages ( the ubiquitous printF type statements).  The BT module is on its own serial port and getting that installed will probably be as challenging as the second timer was.  Fortunately the debug port is static and I intend to make the BT serial power static as well.  So maybe it will be a little simpler.

After the BT is done and before I start the scripting, I am going to back into this code and start some cleanup.  There was some "hacking" done to get things to work and that needs to be fixed.  I am starting to see issues when the ICD3 is attached that I dont see when the board is just running.  I would like to spend some time with that also.

and the video

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.