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.

Setup Progress #3 Transition to Development with 64 bits

 

 

 

I have made good progress in the last few days.  The Brick Buddy Module is actually more responsive than before the pause.  I am quite happy with the BT performance and the USB HID connection.  The Android App connects crisply as does the the USB HID connection to the PC.  So it all looks good now.  

While looking at the changes needed for 10 LEDs and the motor performance I would like to do, it has become apparent that the BT interface is going to have to change to 64 bits.  When the first Brick Buddy was developed, that was a PIC18F 8 bit processor.  Forcing it to do 64 bit manipulation did not make sense.  The RN4020 BT module will transfer up to 20 bytes with each characteristic read/write, so this was not the limiting factor.  With a PIC32, manipulating 64 bit values, is not stressing the processor.  While PIC32MX is a native 32 bit process, it does a nice job of handling the simple integer operations I will be doing.

I started modifying the Android App and the PIC32 code to use both 32 and 64 bit transmissions.  I have the 64bit working, having to solve the little/big endian issues between the PIC32 and the Android implementation.  Once that was solved, it became very easy to parse the command payloads.  Once I settle on the new command payloads, the documentation will have to be updated.  

The only issue I have come across is that once you start 64 bit transmission from the Android App, it seems to always send 64 bits, with the upper 32 bits zeroed out.  This is probably some issue on how I am decoding whether the transmission is 32 or 64 bits.  That will be the next thing I need to solve.

Once the 64 bit conversion is finished, the setup process will be complete and I will move on to pure development of the Brick Buddy 2.

Setup Progress #2

 

 

I setup the system and connected both the Bluetooth and the PC and let it run over night.  This morning it was still connected and running.  I have a stable platform.  My final step is to cleanup a few more items that were left over from last fall.  There are several debug statements that are in callbacks and thus disrupting the normal flow of debug messages.  These need to be stored and then the print function moved to the main loop.  This will clean up the debug message stream and make it more usable.  There are a couple of other changes needed in the UART response loop from the RN4020.  Once this is done, I can start implementing/verifying features.

Setup Progress #1

There is progress.  As explained in the last blog post, the Brick Buddy did start.  Since then, I manged to compile the PIC32 firmware and achieve some success.  After a few days of working on the PIC32 firmware and learning it again.  (Almost forgot how to code in C).  I discovered that the PIC32 was just too fast for the RN4040 BT Module.  This had always been unreliable since I started working on the BT portion.  Some times it would work and sometimes it would not.  In the PIC18 based Brick Buddy I, this was not a problem.  A small delay and it worked flawlessly.  Also there was limited code space/free RAM in the PIC18 design and examining the BT Module response would have consumed valuable memory.

I restructured the code to wait for the RN4020 response.  I am not examining the response in all cases yet, but that is the plan.  There needs to be a path in the initialization state machine for the every response to be verified before proceeding to the next.  If it continues to fail, then a message needs to be sent out the USB port for the user.

In the process of doing this, I also slightly restructured the USB initialization.  I am undecided if I am keeping this.  Right now the BT Module is completely initialized before the USB module.  There might be some advantage the other way around for messaging to the user.  Right now I use a serial console port for this.  It wont be exposed in the final product.

I was able to connect via Android to the Brick Buddy, though the new controls are not implemented yet.  That is the next thing that needs to happen.  I also need to come up with a user interface for 10 LEDs.

I had my second COVID shot yesterday and as the day wore on, I could tell I was beginning to feel the effects.  I will close this entry out now and continue the update tomorrow.