Bridging the Table Gap Part TWO

 In Part ONE, I explained the problem I am trying to solve and what my solution is.  Now I am going to take it a step further.

Here I have built a portion of a cliff over the double hinge.  The right side is four studs wide and the left side is one stud wide.  You can also see how the single stud wide left side slides up and down from the discontinuity in the picture.

Here the hinge is separated and the left and right side are connected to the modules that they will join together.

It was at this point I decided that a single stud width of a full cliff was not going to work.  Transporting and assembling that would be very difficult.  Rebuilding it at every show would be time consuming and not practical.  So I made it two studs wide.  While that may not sound like a lot, in the Brick world that is a  100% improvement in structure stability.  

The final result from the front.  I used several layers of cardboard to simulate the table gap.  From experience it has taken about this thickness of cardboard to attempt to compensate for the table gap, mostly unsuccessful since the remainder of the MOC would have to elevated also.

I have pointed out the discontinuity.  It goes together nicely, but the connection is not on an even stud count.

As this picture shows the 2 x 4 sand green tile is not lined up and the vertical distance is not an even stud distance either.  Thus there is no way to use plates or tiles to secure the connection.  What is holding it together is the bar/clip arrangement that was discussed in Part ONE.

 

Bridging the Table Gap Part ONE

 One of the big issues when setting up for a show is bridging the tables.   Normally the display is over 14 feet.  The only true bridge is the one from the end module to the Space Port.  But this is towards the end of the display and never falls on the table gap.  Normally it will come some where after the main entrance and before the display starts to curve.

There are two main issues.  First is the obvious table gap and the fact that two tables are not necessarily the EXACT same height. Remember that Lego dimensions are extremely precise.  Also we have seen tables that have a small (1/8 to 1/4 inch) rim around the table, which is causes a height imbalance.  The other issue is the weight of the MOC.  Some tables, especially the plastic fold up tables, will sag in the middle because of the weight.  This causes the module interface to be rising on an angle when the module on the other table is flat.  Connecting the two becomes difficult.

If I try to place the table gap underneath the middle of a module, then both ends of that module are placed in distress.  There is just not a good answer with the existing design.

My solution is a hinged connector.

 What this is a double hinge.  If you look carefully at the first picture, the goal of this connector is to connect an edge any just about any angle to another edge at a different angle.  One hinge joint will not do this.  It will take to serial hinges to adjust to the level and angle.  Obviously these is a limit to what can be compensated.  Also there is no guarantee that the linear distance between the two will be a Lego dimension.  But that can be compensated for with scenery and landscaping.

These two pictures show the connection between two cliff modules.  It is very similar to the other connections that will be made.Technic bricks are used to connect to the modules on either side.  Then a 1 x 2 modified plate with bar and one with two clips are used to connect and form the movable hinge.  There are three connection on the right side.  This is meant to be the more permanent side.  The left side with only two connections, is meant to be where final connection is made.  It will be easier to make two rather than three connections.

 

Kaos not Harmony

 

For multiple reasons I am resurrecting what was my second Brick Controller.  This was started in 2019.  But between our moving from the Bay Area and Covid, it never got beyond the original PCB.  That PCB had issues in the design. Here is a link to one post, but there is a whole series of posts in 2019.

The firmware was developed with Harmony version 2.06.  This version is no longer supported. The Light Buddy 1 had a similar processor, a PIC32MX270 vs a PIC32MX470 in the Brick Controller.  The Light Buddy 1 firmware was developed using Harmony version 3.0.

Here is my setup

• Win 11
• XC32 4.40 and 2.40
• MPLAB 6.25 uses PICKit5 and custom PCB
• MPLAB 6.10 uses PKOB3 on Curiosity PCB
• Debug using only hardware breakpoints

I took the original PCB and used the Light Buddy 1 firmware as a basis  to start the upgrade in Harmony 3.  The original design with multiple peripherals did not work. I stripped it down to nothing except CORE, UART2, System Console and DEBUG. As long as app.c had nothing in it, the program would generally run. If I added a SYS_CONSOLE_PRINT command or even toggle a GPIO port, then it would throw an exception. Generally 0x07 or 0x0A. For a while it was at a consistent address, but when trying to look at disassembly, the address would move.

I moved the code to the Curiosity board with exactly the same results.  Please note the Curiosity board has a built in debugger.  Also note this is a generation 3 debugger so I was limited to using MPLAB version 6.10.  But this also means the debugger is probably not driving the problem.

But if i just program the custom PCB with the firmware it works as expected.  this includes the toggling of the onboard LEDs and using UART2 for a console message output.

I  tried

• Slowing down the clock speed
• No prefetch
• Longer FLASH wait states
• No interrupts
• deleted the linker file and used the default one

and probably a few other things I have forgotten about, since I had been at it for multiple days.

I posted in the Microchip Forum and received and interesting reply.  They suggested I use the following menu item in MPLAB. 

 

And the debugger starting working, kind of.  In MPLAB 6.25, the debugging process was slow and sluggish.  If I closed out the project and then loaded the project into MPLAB 6.10, it worked more as expected.  Occasionally the exceptions would come back and I would have use the above menu item  

My conclusion is that in MPLAB 6.25 the debugging process leaves some errant code in the processor.  While starting the debugging process erases memory, evidently what gets erased by starting a debug session and what this menu item does, are different.

On to testing everything else. and working on the schematic design of the upgraded PCB.

 

Lighting Up Your Bricks

 

I have added the presentation I made at Brick Days for Lighting Your Bricks.  The link is below.  You will have to scroll down the page until you reach "Other Goodies" section that will contain a PDF of the presentation. 

Link to presentation 

More Harmony

 

Before getting here, there was Kaos again.

This all started with the Light Buddy 2 firmware development.  When I did this first time, there were several functions that were never quite finished.  In particular the three digital inputs and the analog input.  The digital inputs I had done on the Brick Buddy 3, so that was just a matter of linking in some common code and setting up interrupts.  That went as expected.  The analog port is connected to the ADC in the PIC32MX270.  While I have done many of these ADC implementations in the past.  The ADC modules in PIC micros, continue to evolve.  In particular, lots of hardware implementation of what used to be firmware.  This is good, but can be bad also.

After I got all of the components installed, I set the input to the port at 3.33VDC.  Here is the schematic.  The input is pin 2 on J19.

This is setup to cut any voltage by 50%, thus if 5VDC accidently gets connected, the maximum voltage at the OPAMP input will be 2.5VDC.  As added insurance, there are clamping diodes to keep the voltage below 3.33VDC and above GND.  There is a basic low pass filter on the output to keep any jitter to a minimum.  We will not be looking at high frequency inputs 😉.  I check the inputs and outputs with a meter, On the left side of R36 the voltage is 3.33VDC.  On the right side of R36 the voltage is 1.66VDC.   On the left side of R38 the voltage is 1.66VDC. So far everything is good. 

Well as expected, nothing showed up in the ADC.  My go to here is the IOview in the MPLAB debugger.  When I look at the ADC, it appears it is not even installed in the PIC32.  Trying to change any bit in the ADC was not possible. I could not even turn it on.  Many hours go by with no success either in an a Web search or playing with registers.  Then I saw a register called PMD1.   When you search the data sheet, mostly what you get is a reference to Parallel Master Port Data.  Eventually you find Peripheral Module Disable registers.  

Harmony set these registers to disable the ADC.  So I must have not told it I wanted to use the ADC.  Though some of the firmware for the ADC was installed.  In the process of restarting this project and setting up a new computer I either lost the Harmony configuration file or corrupted it.  I also moved this from Version 206 to Ver 3.  So now ADC is showing input, success.  Well..................

Except what it is showing is 1.88VDC.  The left side of R38 is still showing 1.65VDC, so something is messing with the output.  First thought would have been the JTAG/PICKit pins, since they can be moved on this PIC32.  But that was not it.  With the PIC32, Microchip went a different way with the data sheets.  The part specific data sheet has limited info on the part, you have to dig out the PIC32 master datasheet, which is surprisingly hard to find on their web site directly.  And it is done is sections, so I have been downloading these as I need them.  

Buried in the Input Change Notification section of I/O pins are these little nuggets of info

It appears this applies to Analog inputs as well.  Because once I made sure the pullup and pull down on RA0 was off, it worked as expected and I got 511 as the ADC count, which is what I would expect.  I also got burned by Harmony again, because it's generated code is what set these registers, not sure how it determined what to do.  But going forward I am going to be setting all the pin registers (TRIS, CNPD, CNPU, ANSEL) individually so I can see them, instead of just loading the register with a hex number.  I do this for all the PIC18F processors now.   

 One final note that made this harder.  Using the IOView in the debugger these SFRs,CNFD or CNPU, were shown.  So that never triggered my thinking to look for that.  Plus no one else seems to have run into this problem, since I could not find anything on the Web about it.

 Onto installing the RN4871.

 

Serial Sniffer - Part ONE

 

While I was waiting for the tariff things to settle out, I designed another PCB that I have always wanted, but could never find at reasonable price.  An RS-232 serial sniffer.  Now that USB is the standard, these dont really exist.  But for embedded, I still use serial to talk to the BT modules and as a logging port.  So this thing has two Serial to USB converters (FTDI based) and then two more Serial ports that are connected to a PIC processor.  The last two will be used to "sniff" a serial port under test.  Then the PIC will arrange the Tx and Rx data in time order and send either to a custom program or to something like TeraTerm.  It also has Mikroe Click port on it, so I can add other modules down the road.    Probably could have found something close, but this way I get exactly what I want.  

 

Brick Lights ONE - Redo

I finally got around to working on this again.  When I first did it, parts availability just killed it.  There were several parts I could not get, including the processor.   I first discussed this here and then a few months ago here, where I discussed a lot of issues with the firmware. Now that has changed, I went back to it.  I made some changes to make it more closely line up with what else I was doing.

As a recap, this was the first iteration.  It has a larger BT module and individual LED connectors.  Looking at the picture at the top, you see that the LED connectors have been consolidated down to three 2 x 5 connectors, which is what I use on the Brick Buddy 3.  Also I have added a standard power connector.  This allowed the entire PCB to shrink down to a 6 x 7 stud size instead of the 6 x 8.

Once I finished this, I sent it out to FAB at my usual fabricator in China.  This right before all the tariff stuff blew up.  I am sure I was not the only one that was trying to squeeze in under the deadline.  Well the PCB that came back had a short between 3.3VDC and GND.  Not good.  After going back and forth with the vendor, they said they found a place where the tolerances were not met. How they missed it, they never said and how my design software did not flag is also a mystery.  Any way drilling out a via fixed the issue.

It required that I put a jumper wire in to power up the section that the drilled out via cut off.  So went on and slowly assembled it one section at a time.  In the very next section, I found another short this time in a signal to GND.  I was not successful in drilling this via out and I called it quits on those boards. 

So I started looking at US sources, the only one that came close was OSH Park.  But that is 3 PCBs.  So I waited to see how this whole tariff thing was going to play out.  The downside to OSH Park is that they do not want inner power planes in negative.  Which has been the standard for years.  I guess toomany instances where the fabricator thinks it is an inner signal layer and does it as a positive.  I redid the inner power planes as signal planes and polygon pours for the power/ground.  We shall see how this works.

Finally it looked like the tariff stuff settled enough, I went ahead and ordered new boards using the signal layers instead of the power layers.