Entrance Design - Part 2

Lighting design was a challenge.  The easy part was the conference room, which needed only white light.  The briefing room was done in red.  The third floor area was done in blue to match the transparent light blue windows.  Finally the two side areas that over see the hanger floor were done in white.  Here are the pictures.  First the conference room.

Next is the briefing room.  The red is really bright.

PIC18F46Q71 and I2C

I have been caught up in an I2C nightmare most of the week.  Basically a few years ago Microchip change their implementation of the I2C controller.  Instead of the MSSP which did both SPI and I2C, they now have separate SPI and I2C controllers.  Now it is true that the MSSP probably did not give as much control over the protocol process as one would like.  I am sure the MSSP worked great with all of Microhip's I2C products.  But as with any "specification" it is subject to interpretation, which probably led to a less than ideal mating with other companies products.  The new controller has more settings for SMBUS which is slightly different than I2C in timing and voltage levels.  And it has a more automated mode of working.  It may be better and more flexible. I dont know.  It wasn't that easy to get working in the master state. 

But the PICs I am moving to have this new controller.  There are very few working examples and the firmware that the MCC generator gives you is buggy and hard to understand how to actually implement. It is mostly a cooperative multi-tasking implementation with switch statements and lots of function calls to set one bit in a register.  Now I2C was never straight forward as a protocol, but the MCC code seems to make it more complex than it needs to be.  Sometimes you just want to read an external EEPROM memory and do a simple task.  Not have 10 peripherals running that need to be serviced on a regular basis.

What I found when searching the Internet for working example code was this example on a PIC18F46K42 and a Curiosity HPC.  Since I was working on an HPC this was perfect.  I downloaded the project and started working.  Using my Digilent Analog Discovery 2 as an I2C protocol analyzer, I could see when it worked and when it didn't.   Then I used the driver (.c) and header (.h) files as the starting point for my driver/header files.  Kept modifying these files in the example project until I could read and write the I2C EEPROM I had installed in one of the Click Module sockets on the HPC.  At this point I moved the files back to my project and the PIC18F46Q71 and started testing.  Some minor tweaks to the initialization were needed, but it seemed to work just fine.  

The I2C driver I have running is very basic and runs to completion.  That is it is blocking and will hang the system.  But for now that is OK.  I will need to implement some form of cooperative multi-taksing to get the LP5569 to work, since that is the way it is setup right now.   My only issus is when reading the EEPROM.  The sequence is to write the client address followed by the two bytes that hold the memory address.  this is followed by a restart condition and the PIC resends the client address with read set and starts reading the memory.  Here is the protocol analyzer's view of that sequence.

and just the restart area

The data sheet implies this is OK.  The stop bit is not long enough and all the client IC sees is the restart condition.  We shall see.

 I will leave with this comment form another developer, which was pretty typical of those who posted.

"When you make it hard to use your products, developers will move to other products."

Entrance Design - Part 1

When I first built this Space Base, the design was of a concave setup.  The Entrance was farthest away from the edge of the table and was only dominate because of the large tower structure on top.  Over time it has changed, especially since I decided to change the overall setup to convex.  These next three pictures show the evolution of the entrance.

The second picture shows the beginning of the cliff walls being attached.   The last picture shows the major change I made just prior to the Brick Days event in Omaha.  I built the beginnings of a large entry structure with doors with the Blacktron Logo on them.  It was very simple and very little detail.  But it needed a lot more than what was there.  This post will describe what all is entailed in the entrance design.

This is a view from the back.  You can see the back of the doors .  On the second level is the beginning of two large rooms, one on either side.  

The next set of pictures show the construction of the conference room.  Here parts of the flooring are in place.  The legs for the tables done. I used two 1x1 plates and one 1x1 round brick for the legs.  The jumper plates are for the table chairs and a place for a minifigure to stand.

This has a large table and seating for seven. 

Here the last of the transparent light blue walls are in place.

This shows the final detail of the conference room.  All the attendees are in place.  The video monitor is installed on the left and there is a guard. 

What is missing?  Well the tan wall on the right is bare, there could be something there.  There is not any room for Lego parts, so it would have to be a sticker depicting a map or the station layout.  There could be items on the table, but anything that would attach to a stud would be too large.  You could put the 1x2 cheese slopes with stickers on them to show video screens.  

This picture shows the beginnings of the briefing room.  There are chairs for nine members plus the briefers.  There is also a video screen installed.

Now you can see the desk in the back of the briefing room.

This gives a different perspective.  Here we can see the podium and the briefer with his pointer. 

What the above picture also shows, along with this one below, is the start of the third floor. 

This shows the third floor complete.  There are desks on either side with laptop computers on each.  The center area has three personnel standing watch over the entrance with a control panel.

This is what the current version looks like.

 

I still see changed coming for this.  Behind the columns on the left and right, were intended to be large power generators, like the Warp Core generators in Star Trek.  This still has to be done along with some minor updates to the color scheme.

LED lighting has been added and will be discussed in Part 3.

Platform Connectors with a Variable Angle

 

I found this in a brick pile years ago.  After examining it for a few days, it spawned the idea of the space base.  The idea that I could slowly bend independent modules in a curve was very intriguing.  I discussed this idea in multiple posts, here, here, and here.  I only had two angles and I was hoping that when the curve got to the 90 degree point it would be perpendicular with the front.  But as you can see that did not happen.  This was going to make any cliff wall behind these modules more difficult.  It was already not going to be easy and this just dramatically increased the difficulty factor.

Thus I started out trying to design a sort of variable platform connector.  I started out with the basic connection which is just two wedges and a hinge plate.

I used the 12 x 3 wedge plate because I knew the larger width wedge plates (6 x 3 and 8 x 3) would have to large of a minimum angle.  That would place the module beyond the 90 degree point.

Then I slowly move the module to the 90 degree point and lock it down so it wont move.

This shows the opening of the two wedge plates.

The next step is to find a position for the front hinge plate to connect.  Ideally you want to use the position with three studs in the row, but you can move up one row to the first row with two studs in it.

As you can see neither of these opens the connector enough to achieve the 90 degree setting I want.

Next step is to add a 1 x 2 plate to extend the hinge plate.

This will open up the angle as we see here.

But that is too much angle.  I moved the module to the correct position, but that puts the hinge plate in an undesirable position.  Also the hinge plate is rotating on the single stud connection to the 1 x 2 plate.

I changed out the 1 x 2 plate for a 1 x 3 plate, that at least keeps the hinge plate from rotating on the extension plates.  But the entire hinge plate is still not in a good position.

Now I moved up one row

This is very close, but there is only one stud on each wedge plate.  I need a more stable connection and to verify that this will be where I want the module.   So I swapped out the 1 x 3 plate for a 1 x 4 plate.  This grabs the hinge plate with two studs and grabs the two studs on the wedge plate.

This has the hinge plate in a buildable position and places the module very near the 90 degree point.  

Now I can build the detail that will cover the two (one on each side) platform connectors.

Cliff Wall Update - DONE!

 

 For now I am done with the Cliff wall building.  These pictures show the four pieces.  How not disappointed in ho they turned, but I think they can be better.

As I noted in the earlier post, I managed to achieve a good level of randomness. I wanted one cliff to have an entrance/window in it.  I settled on the window for now.  I am not sure I am happy with this.  It was a design choice between a flat window or a curved window.  I went with flat because it made more sense.  I will eventually build an opening that the Blacktron guys will go through to get to the launch module.  Also a smaller door for Mtron guys to move back and forth.

I also wanted to have some streaking of a different color in it.  And with the tan color parts running low, an opportunity to focus on this happened.  As you can see on the right side of the cliff with the window in it.  On the next picture down there is just a small streak in one section. When I did my first cliff sections, I actually did one with several color shades.  But I also did it vertically (see the next picture).  Well that is generally not how nature works, since things get laid down in a horizontal pattern,  Now it is true that you can have uplifts, but that just causes a shit in the horizontal pattern.

Now many years ago when working on my HO train layout I did the same thing as you can see in these two pictures.  But I did it geologically correct.

I am sure that these will change over time.  One my skill level might improve,😋 and two new techniques will be developed along with new parts.

How Not To Code

 

This is going to be a detailed technical post on MPLB X, XC8 PIC C compiler and how not to code a project.  Or to put it simply, how not to be stupid.

The above picture is a Curiosity HPC Development Board that I talked about in this post.  This was to help me get most of the code structure working for the Brick Buddy III as shown here.

The processor on the PCB is a PIC18F26Q71.  Fairly new, but with a very nice of features and lots of program FLASH and RAM.  But it was going to be weeks before I received one from assembly.  Thus the HPC was put into use.  Instead of putting a PIC18F26Q71 in the HPC (it does have a 28 pin socket underneath the 40 pin DIP), I chose to use the 40 pin version, a PIC18F46Q71.  The only difference between the two, besides the physical 28 pins vs 40 pins, is the PIC18F46Q71 has an extra PORT (PORT D).  

The Brick Buddy III code is a derivative of Brick Buddy II and Light Buddy II.  I have not started a project completely from scratch in a long time.  Using common libraries as I explained in this post means that only the main control loop and the hardware initialization is unique, unless there is a new peripheral of some kind.  Once I updated the initialization, I started compiling the code with the PIC18F26Q71 as the processor.  This PIC has the new I2C controller and thus there was a few days of just getting the code to compile.  During the compilation, there were multiple error messages having do with available PIC ports.  Brick Buddy II is a 44 pin device and thus has a PORT D.  All of this had to be changed to accommodate the PIC PORTS available on the PIC18F26Q71.

Once that was done I started trying to see if I could get some of the basic structure working.  This include the serial interface to the PC, the I2C EEPROM that stores configuration and scripts (which would also validate the I2C software driver for the LP5569 IC LED driver).  Finally working on the Bluetooth code for the RN4871.  This BT module is similar to the RN4020, but I am sure there will be some minor road bumps.

Once I had my standard LED heartbeat running, I moved on to the serial interface.  The PCB contains a FTDI USB to UART interface IC.  So I used one of my lab ones to connect the PC to the HPC Development Board with three jumper wires (Rx, Tx & GND).  And nothing worked.

Most PICs have a Peripheral Pin Select (PPS) module.  This allows you to move digital peripheral  features to different pins.  It is basically a large switch matrix.   Some PICs can move the peripherals to any pin while others will restrict a peripheral to a subset of the PORTS.  Thus there is code at initialization that has to be executed to move the peripheral output to the desired pin.  This is shown here

        #if defined(USE_PCB)
            INT2PPS = 0x01;         // assign INT1 to RA0
            INT0PPS = 0x08;         // assign INT0 to RB0
            U1RXPPS = 0x0B;         // assign Rx1 to RB3    --RN4871
            U2RXPPS = 0x0C;         // assign Rx2 to RB4    --Console
            I2C1SCLPPS = 0x13;      // assign SCL1 to RC3        
            I2C1SDAPPS = 0x14;      // assign SDA1 to RC4

            RC3PPS = 0x20;          // assign SCL1 to RC3
            RC4PPS = 0x21;          // assign SDA1 to RC4
            RB2PPS = 0x15;          // assign Tx1 to RB2    --RN4871
            RB5PPS = 0x18;          // assign Tx2 to RB5    --Console
            RC2PPS = 0x0D;          // assign CCP1 to RC2
            RC5PPS = 0x0E;          // assign CCP2 to RC5
            RC6PPS = 0x0F;          // assign PWM1 to RC6
            RC7PPS = 0x11;          // assign PWM2 to RC7
        #elif defined(USE_DEV_BRD)
            INT2PPS = 0x15;         // assign INT1 to RC5
            INT0PPS = 0x0C;         // assign INT0 to RB4
            U1RXPPS = 0x10;         // assign Rx1 to RC0    --RN4871     
            U2RXPPS = 0x0D;         // assign Rx2 to RB5    --Console
            //U2RXPPS = 0x19;         // assign Rx2 to RD1    --Console
            I2C1SCLPPS = 0x13;      // assign SCL1 to RC3        
            I2C1SDAPPS = 0x14;      // assign SDA1 to RC4

            RC3PPS = 0x20;          // assign SCL1 to RC3
            RC4PPS = 0x21;          // assign SDA1 to RC4
            RC1PPS = 0x15;          // assign Tx1 to RC1    --RN4871
            RD0PPS = 0x18;          // assign Tx2 to RD0    --Console
            RC2PPS = 0x0D;          // assign CCP1 to RC2
            RC5PPS = 0x0E;          // assign CCP2 to RC5
            RC6PPS = 0x0F;          // assign PWM1 to RC6
            RC7PPS = 0x11;          // assign PWM2 to RC7
            RD1PPS = 0x00;
        #endif

What this also shows is that I have a conditional compile. One version for the PCB and one for the HPC Development Board.  What I found was that UART2 Rx pin would not work on any of the PORT D pins, even though the data sheet clearly indicated that it good be moved to either PORT B or PORT D.  The UART2 Tx pin worked on any of the PORT D pins I placed it on.  I verified that there was a signal present using my Digilent Analog Discover 2 (which I highly recommend).  Thus I moved the UART2 Rx pin to PORT B and all was good.  I needed to make progress, so I moved on.  Though I did post in the Microchip Support Forum what had happened.

Well someone commented on the post.  When I read the comment, I immediately knew that person had the correct answer and I had fallen again for what I discussed a month ago in this post.  Embarrassment does not even begin to describe how I felt.

Here is the initialization code with the issue

    TRISA = 0xFF;
    TRISB = 0xFF;
    TRISC = 0xFF;
    LATA = 0;
    LATC = 0;
    ANSELA = 0x00;                //all digital
    ANSELB = 0x00;                //all digital
    ANSELC = 0x00;                //all digital
    ADCON0 = 0x00;                //A2D off
    ADCON1 = 0x00;                //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
    mLED_TRIS = OUTPUT_PIN;       // make it an output
#elif defined(USE_DEV_BRD)
    mLED_B_TRIS = OUTPUT_PIN;     // make it an output
    mLED_Y_TRIS = OUTPUT_PIN;     // make it an output
#endif
    

I had the foresight to place a conditional compile for the heartbeat LED (mLED_B & mLED_Y) to control the TRIS control for the pin.  But if you look directly above that, you will notice there is no mention of either TRISD or ANSELD.

Now TRISx controls whether the PORT pin is an input or an output.  The default is INPUT, but I always like to set them all to inputs and then let the code determine which pins are inputs and which are outputs. ANSELx controls whether the PORT is an analog input pin or a digital I/O pin.  The default is analog input pin, but again I choose to make all port pins digital I/O and then let the code set those pins that will have an analog input..  But this code fragment does not set PORT D to digital I/O and thus all the PORT D pins are analog inputs.

Now the quirk in these PICs is that a digital output (TRISx = 0) will override the analog input selection.  But a digital input will not override the analog input selection.  If you think about this, that only makes sense.  When you want an analog input ( e.g. ADC input) you will set the TRIS register to input and the ANSEL register to input.  The only setup for the processor to know that you want a digital input is the ANSEL register has to be set correctly.  So here is what the code fragment looks like now.

    // Make all digital inputs for now and let init routines set the tris bits that  need to be outputs.
    TRISA = 0xFF;
    TRISB = 0xFF;
    TRISC = 0xFF;
    LATA = 0;
    LATC = 0;
    ANSELA = 0x00;                //all digital
    ANSELB = 0x00;                //all digital
    ANSELC = 0x00;                //all digital
    ADCON0 = 0x00;                //A2D off
    ADCON1 = 0x00;                //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
    mLED_TRIS = OUTPUT_PIN;       // make it an output
#elif defined(USE_DEV_BRD)
    TRISD = 0xFF;
    LATD = 0x00;
    ANSELD = 0x00;                // all digital
    mLED_B_TRIS = OUTPUT_PIN;     // make it an output
    mLED_Y_TRIS = OUTPUT_PIN;     // make it an output
#endif
 

Live and learn, maybe😕

Cliff Wall Build Update 1

This is a simple update to show how the cliff walls are progressing.  I don't sit down and do one wall.  I find that I get into a pattern.  By working on different walls at different times, the pattern seems to stay more random.  The wall is 6 studs deep from the edge of the sand green walkway to the top of the cliff.  There are 3 studs at the base up to the first level.  Then one stud of depth is added.  This goes to the base of the top where another one stud depth is.  Finally at the top is the final single stud of depth.  Thus the cliff is fairly steep. 

Here is the start of one of the cliff walls.  This wall start is non-traditional as it has non rectangular slopes in it.  I tried to do something a little different.

Here this wall continues.  There is also a non-traditional portion of the left side.  Then I added a small platform for details to be added.  In this case it is minifig for now.

Here this one is done up to the final level going to the top.  This was finished with more traditional cliff techniques.

Here are two sections that are now done.  This one  is done in traditional techniques.

And this one has some non-traditional techniques.