Scripting Part 1

Overview

Multiple things going on, but mostly been working on the scripting language.  I decided to put my head down and work through the issues.  I am finally at the 98% point.  There are still commands to implement and testing to be done, but it finally works.

Converting to 64 bit instructions was a complicated process.  In the original Brick Buddy, there were 4 motors and 4 LEDs.  This allowed for the state of these devices to be coded into one 32 bit command.  Thus on execution, the 4 motors and the LEDs could be updated in a single instruction.  The Brick Buddy 2 has PWM control for both the motors and the LEDs.  The PWM value is contained in an 8 bit value.  Thus for the 4 motors and 10 LEDs we need 112 bits. 

 

Script Structure

The command format needed to change.  The upper 20 bits are consistent throughout.  The upper 8 bits is the command.  Instead of 4 bits in the previous 32bit format, this provides more flexibility for commands.  The next 12 bits is the time stamp.  I considered expanding this, but 409.6 seconds (over 6 minutes) still seems adequate for any script.  I am sure someone will come up with a need for more, but for 99% of the users this will be adequate.  The remaining 44 bits are command dependent.  

The motor command fit nicely into 64 bits.  The lower 32 bits contain the PWM value for each motor.  The next 8 bits contain the motor state (OFF, FWD, RVS, BRAKE) for each motor.  The LED command got more complicated and was broken into three commands, LED 1-LED 4, LED 5-LED 8 and LED 9-LED 10.  Again the bottom 32 bits contain the PWM value and the next 12 bits contain the LED mode (OFF, STEADY, BURST, CYCLE, PULSE).  

The remaining commands for WAIT, INPUT and MP3 functions still need to be worked out, but these are simple compared to the complexity of the Motor and LED commands.

 

Implementation

The major problem in moving from PC/Mobile control to script control, was changing the underlying structure from a single device update to multiple devices simultaneously.  As pointed out earlier, the 32 bit structure with all the Motors and LEDs in one command was identical to what the PC/Mobile control was doing.  But in the 64 bit structure, many devices could be updated simultaneously with 4 commands or more being executed in the same time period.  Fortunately I had built most of the underlying functionality to handle this, but middle layer was geared toward the single control of the PC/Mobile interface.  This is now fixed, but it came at a price of some major reorganization.

 

 

Development - LED Control #3

Here is what the PC GUI end up as.  It is a little busy and I may change the theme to distinguish it from the current version.  I like that it will match the Android app.  Except the Android app has separate screens for motor and LED control.  I went with labeling brightness here, to make the Android APP more obvious.  You generally start with the PC first for development, then use the Phone to do actual control.

Still to do some cleanup and then move on to Motor Control.

Bricks By The Bay - Update #1

 

 

Looks like we will be doing virtual vending at the Bricks By The Bay 2021.  We are starting to work on what we will be showing and what specials we will be offering.  So follow us and Bricks By The Bay to see what is happening and when. 

Twitter

#makerpower  #bricksbythebay

Facebook

@mymakertools  @bricksbythebay

Instagram

#mymakertools  #bricksbythebay_official

 

 

Development - LED Control #2

 After discussing the GUI with a friend who is much smarter than me, this is where I ended up.  I actually like this much better than the old layout.  There is still some minor GUI tweaking to be had as I test multiple devices, but in general it is done.

 

Here we can still see the status of each LED, both the state and the brightness percentage.  By touching or tapping the state, a standard Android Combo Box with Radio Buttons appears on the screen with the choices, OFF, STEADY, BURST, CYCLE and PULSE.  Choosing one will change the state of the LED and use the associated brightness value for STEADY, BURST and CYCLE.  The brightness value is a simple SPIN box.  Tapping either the left or right arrow will decrease or increase the count by 10, respectively.  Pressing the number will bring up the native number pad where any number between 0 and 100 can be entered.  

This layout provides to the user the necessary current state of the LEDs, while providing an intuitive method for them to change the LED state and the brightness percentage.  A bonus to this was a much more elegant code solution in how this is handled.  Which then makes it much easier to adapt this GUI to the original Brick Controller.  Another goal I have for this implementation of the APP.

Next step will be to implement something similar in the PC.  I believe that commonality in the Android APP and the PC makes the transition from one to the other and back that much easier.  While there will always be operations that can only be done on the PC (firmware update for one), commonality as much as possible will always be the goal.

Development - LED Control #1

After crashing the entire PIC32 firmware with an innocuous change ("I did not touch that piece of code!") that hung me up for a few days, I made progress today.  I appear to be able to control all 9 of the LEDs that are connected to the LP5569.  Have not tested all of the slots, but the five I have tested all work correctly.  As an added bonus I can set them from the Android APP and change them on the PC and vice a versa.  And the innocuous change cleanup has also improved the serial interface between the PIC32 and the BT module.  Thus for now it all works as planned.  As an unforeseen bonus, I have managed to keep the BT messages down to 32 bits for now.  

My next task is the Android GUI.  On the PC, screen space is almost limitless, but this is not true on a phone.  I started by expanding the design of the original GUI.  One block of controls (radio buttons) that select/show the state of each LED.  But on the smaller phones I have, 10 did not fit, I only had four LEDs  before.  I suppose I could reduce them down some more, but then any one with fingers bigger than a baby would have a hard time selecting the correct radio button.  The two images below show the screen.  The second image shows the screen scrolled up to reveal LED 10, which is controlled differently than the other 9. Direct PIC control instead of I2C to the LP5569.

 This format does not allow for the brightness value (PWM setting) of the LED, which can be applied to the ON, BURST, CYCLE states.  This is a value from 1 to 100.  On the PC this is done with a slider.  I will probably only use steps of 10 for this.  When I first tested this, there was no discernible change intensity with steps less than 10.

One of the ideas I am thinking about is to place the status of all 10 LEDs (state and brightness value) down the right side.  Touching on the display over an LED Status will cause a single display similar to one of the above along with a slider to appear on the left side.  You can then set the new state and change the brightness value.  

While this idea will take less screen space, it does not provide the quick access that the current format does (multiple presses vs one press).  But you get it all LEDs on one screen with no scrolling.  I guess I need to prototype this out and see how it looks and performs.

Setup Progress #4 Moving on to Development

 

I solved my last problem.  It was fairly complex and was directly tied to how RAD studio implemented the Bluetooth GATT characteristic writing.  Originally all of the BT communications was done as 4 bytes.  Only the Heartbeat notification was done as 2 bytes.  As the API documentation showed, all of the payload formatting was in a 32 bit format.  It has become obvious that this was no longer going to work with 10 LEDs and the expanded script commands.  However, I wanted the Android APP to control both the Brick Buddy I and II.  Also some commands did not need to go to 64 bits.  Thus some 32 bit payloads were going to remain.

When I started testing the 64 bit transfers, I noticed that once I made a 64 bit transfer, all subsequent transfers for that BT GATT Characteristic would be 64 bits, even though I may have requested a 32 bit transfer.  After tracing it down into the system libraries, I found the function that was causing the problem.  The payload value was a dynamic array of bytes, meaning the length had to be set programmatically.  The library function did not set the payload value arbitrarily, it appeared to take the last payload value sent and determine its length.  Then it would look at the length of the new payload value and expand the dynamic array if needed, but it would never shrink the dynamic array.  Thus while the first 4 bytes in a 32 bit transfer would be correct, there would be 4 more bytes and they would be the same as the last 64 bit transfer.  This was causing issues with the PIC32 code, since it was expecting 32 bits and getting 64 bits and not knowing which 32 bits it was supposed to use.  I solved this by always setting the length of the dynamic array to 1, prior to setting the new payload value.  This forced the system library function to always expand the dynamic array to the correct size, since every payload transmission I do is great than 1 byte.

We move on to development.  Here is the general path I will follow.

1. All 10 LEDs working in Android and PC software
   
2. Verify Motor Functionality in Android and PC software
3. New MP3 functionality
4. Script Functionality, especially in Android
5. Package it all up

One Note, I will be working on the MOCs also, so it is not 100% coding.

Should be fun!!😅

 

Bricks By The Bay 2021

 

The announcement of Bricks by the Bay 2021 was made a few days ago.

Here is there announcement

Bricks by the Bay 2021 continues the virtual adventure!

With the pandemic still underway (though moving in a positive direction) we will continue with our virtual version of the convention over three days: June 18-20.
Seeing as how we weren’t able to return in person this year, we have decided to push the theme of “Looking Back” to 2022, which will still allow “Vision 2020” MOCs to remain relevant while pulling in anything depicting history. The forward-looking theme for 2021 is “Adventure Awaits!” We would love to see your MOCs about exploration, optimism, hope, and yes, adventure. Show us what stirs your soul!

We will have virtual tours of LEGO MOCs, panel discussions, LEGO Masters participants, presentations, games, contests and a chance to show off your own MOCs.

You can read more about it at their website  www.bricksbythebay.org

Unfortunately when they moved to the new website, very little was transferred.  So you will have to re-register and build a new account.  As noted in the announcement this is a virtual convention and there are only 1000 openings at $5 each.  If you think you might be going, now is the time to do it before they are all gone.