Brick Fest Live San Diego - Begins

 

 

Since I mostly got around the XC8/MPLAB problem I was having, I have spent the time getting ready for Brick Fest Live San Diego.  The last time we were there was in Nov 2021 and it was actually in Del Mar.  This year it is at the convention center down town.  This where Comic Con is every year.  

I finished the updating the Space Port and floating platform as far as it was going in this round.  The space port was converted to a Brick Buddy 3 controller that is buried in the base, instead of a huge Brick Buddy 1 on the outside.  Also modified the back side for the eventual connection to a tunnel into the mountain.

The other important item I finished was a new electrical connection method using the old 9V Black motor connectors.  This is now used to power the Maintenance Shed.  It cannot be attached during transport, so I needed a simple way for this to work.  I intend to use this method for the large mast lights on the floating platform also.

After the show, I will be writing up several posts on the space Port Conversion, the Maintenance Shed and the new electrical connection methodology.  

More info on Brick Fest once we get to San Diego and start setting up.

MPLAB and XC8 - A Tale of Woe

Where I have been for the last week or so, on another barefoot journey across a LEGO pile with MPLAB and XC8 compiler.  Bottom line,  beware of C compilers claiming improved performance.

My very small Light Controller was depending on the 256 bytes in the EEPROM for config and script storage.  After config storage, that left about 220 bytes for the scripting.  But each LED takes 5 bytes to describe the time, command, state, features and PWM setting.  So a single time slot with all 6 LEDs changing can take 30 bytes.  Thus in 7 time slots all the memory can be used.  I had over 4K left in flash, so I decided to move the scripting there.  I had done this in one of the PIC32s that did not have EEPROM.

And the fun begins.  Harmony in the PIC32 had libraries for doing this, it was fairly easy.  I had written a boot loader for an older PIC, so this cant be that hard.  Well after 3 days on and off trying to make this work, I decided to change course.  Brand new MPLAB project with only the FLASH writing routines and using the MPLAB Code Configurator to generate the FLASH routines.  Their routines were essentially the same as what I wrote.  I could not see any difference that would make it work over what I had done.

But this did not work either.  I spent a huge amount of time trying to debug this with no change.  Then I spent a day reading every FLASH routine posting I could find.  90%+ were using the MCC routines I had generated.  Most problems were related to other things that I had already implemented.  Then I finally found one post where the person could not get FLASH to work.  Microchip told  him to change compilers.  There was an issue in 2.35 and that 2.36 fixed that.  Well 2.36 was a transitory release and I had a choice between 2.40 and 2.41.  Knowing that x.x0 and x.x5 is Microchips release schedule and any other numbers are bug fixes, I went with 2.41.  And what do you know, the dedicated program started writing to the FLASH.

Could it be that simple, of course not.  Compiled the Light Controller and it still failed.  Now to be fair I had slightly rearranged the MCC generated code to fit my overall structure.  So I went back to the dedicated program and pointed all the FLASH routines at my revised code.   Also renamed all the FLASH routines in this dedicated program directory so there was no way they would be included.  And it works just fine.  I then made sure the configuration bits were the same in both programs.  The last thing I did was copy the oscillator startup code from the Light Controller to the dedicated program.  Still works.

Startup code, project properties, compiler settings were the first things to look at and these were all the same.  Something in the startup code?  I cut out the test routine of the dedicated program and placed it as far in the front as possible.  Still would not work.  At this point almost a week has gone by and I am getting no where.  I have been taking breaks to work on other things, one to clear my mind and two to have some sense of progress. 

At some point I remembered some quirky things I had read about EEPROM unlock sequence.  Back to the dedicated program to trace through the assembly code to see how that worked.  The unlock sequence is 0x55 then 0xAA then set the write bit.  The green is the C code and the rest is assembly.  Nothing exciting here, what I would expect.

Then to trace through the Light Controller.  Both are using the exact same code base, there is no difference, no #ifdef, no changes at all.  There are two differences, either of which could cause a problem. Line #187, the BANK command.  Why is that there, that should have been before the sequence started.  Then the real problem is Line #193, another BANK command and inserted just before the write bit.  My understanding is that the unlock sequence is timed and set for exactly 5 instructions.  At a minimum, setting the write bit has to be the next instruction after loading 0xAA.

After some more reading I came up with this assembly code sequence for the unlock.  The C code using inline assembly is in green.  As you can see the generated instructions are exactly 5 instructions long and it works as expected.  

So after a week of messing around with this, it finally works.  I will probably go back and replace the unlock sequence elsewhere with this assembly version, just to make sure that somewhere in the future the compiler doesn't change it's mind and change the C code.
 

Antenna Care

 Here is the issue.  This Antenna (Part Number 2569) is fairly rare and thus expensive.  Prices in the US start at $4.00, while the black version starts at $0.01.  These parts can bend very easily if not stored properly.  I have had the solid color version (red, black yellow) have minor bending when a large number are all placed in single bin.  Thus I am concerned about how to store these.

I started with these two ideas. 

The ball at the end of antenna barely fits through the 1/2 length Technic pin.  Antenna removal required removing the the three 1x2 Technic Brick with Holes.  Removing the bricks was not easy and would often stress the antenna as the ball tried to pass through the Technic pin. 

Next I removed the Technic pin.  Now there is ample room for the ball end of the antenna to slide through the Technic Brick.  But Technic Brick would still be hard to remove and then the sudden break of the brick connection would again put stress on the antenna.

 

Which led to this implementation.  There are 1x8 Technic Bricks with Holes on each end.  Each 1x8 brick has the 1/2 pins inserted.  The antenna is inserted from one end.  Some minor pressure is exerted to make the ball end pass through the 1/2 pin on the other end, but it is very minor to none.

This shows the other end.  With a 8x10 plate arrangement (combined 6x8 and 4x8) the entire antenna is captured.

I noticed some flexing of the built up 8x10 plate.  I changed the arrangement to have three 1x10 bricks across the bottom to give it structure. 

This is the final version.  I noticed that when I reached three bricks high on the 1x8 Technic Bricks, they started to lean in or out.  So I placed a 6x10 plate every two high.  I also changed up the end the antenna is inserted, to make removal easier.  So far it seems to work.  

As long as I can keep direct sun and excessive heat, this should work.

Light Buddy 2 Scripting

Scripting is now coming in two forms.  

1. Static LED that is time invariant
2. Time based LED action

The time invariant scripting means that the user will setup the LED actions using this screen.  They will assign the LED effect, any features and the brightness (when available).  Using the LED option on the menu, they will store these settings in the Light Buddy 2.  When the unit powers up, it will load these settings and run forever.  This is equivalent to a one line script that is on repeat forever.

Time based is the normal scripting.  The user assigns the LED action at a given time, saves the step, increments the time base to the next event and continues.with the next LED event.

The issue with the Light Buddy 2 is the script storage.  There is no room for an external EEPROM.  The internal EEPROM storage is about 200 bytes once all the configurations data is set.  That leave about 40 script instructions.  But every LED effect takes an instruction.  If all six LEDs change at one time interval, then 6 bytes are used and that would allow for only 6 time intervals. 

There is about 4K bytes of program space left.  If I allocate 1K to script storage, that would allow for four times the storage.  Writing into program memory on a PIC is not difficult, but care must be taken as to not overwrite program storage.  This is my next task, so that I can increase the available script storage.

Floating Platform - Maintenance Shed

 

I have taken this as far as it is going for now.  I have other work to do and this is in a state that I am happy with.  Also it will give me some time for the design to sink in.

I am leaving the left side "under construction".  Adds some interesting detail.  Also until I am showing at any event with a "dark mode" (turning off the overheads to show the lighted models) there is no rush to finish the left flood light.

One thing this picture highlights is that there will have to be lighting.  If you look a the right side, you can see one Minifig sitting at the window, but you cannot see anything other details in that area.  One LED light in the ceiling will make all the difference.

Here is the back side before the glass is installed.  As you can see from these two pictures, there is not much room for added detail.  The area behind the seats would not allow for any detail texture in depth.  This may be why Lego has used decals/stickers on the large panels.

This shows exactly the same problem of trying to add detailed texture in depth.

More closeup shots.

The backside with the rock formations, glass windows installed and the two satellite antennas.

That is all for now.  More software development is order.

Floating Platform - Cargo Packs

 I received all the parts for my cargo packs.  In this picture you can see the three different types of cargo packs.  There is a Blue one, a Lime one that follows the standard color scheme.  But I did 2 of the Bright Green, something special.

This is a closeup picture of the Blue ones sitting in a corner of landing platform.

This smaller one, was done with transparent neon green and will fluoresce under UV/Blue LED light. This ideal for dangerous cargo.

Here is the open end on the connector plate.  This open end is toward the front of the display, that is closest to the viewers.  Right now there is a returning scout vessel in the right corner.  I am thinking of turning this open end of the connector plate into a delivery dock.  This picture implies the four cargo packs were just delivered.  Where the scout vessel is now, I would put a small crane to lift the cargo packs from the delivery vehicle and on to the platform.

This is just a wider view of the area.  

Light Buddy 2 - Update1

Light Buddy 2 is almost done now.  As previously noted here and here, the software and firmware are very close to being finished.  The picture above shows the addition of two new development tools for Light Buddy 2.

First is a six channel LED display.  This allows you to work on the lighting scheme, whether it is a static display or a  script, and test it.  

This is a communications interface.  This will allow a USB port on the PC to control the Light Buddy 2.  Using the Brick Controller PC software you can setup a static light scheme or you can download/retrieve a script.  This makes configuring the the Light Buddy 2 quite easy.

Obviously you only need one of each to setup an infinite number of Light Buddy 2s.