Liberty Ends

 

I have been traveling and performing mundane tasks of life that have been put off for a while. But that is ending now and we are back to blogging and working.

I have taken some what of break with the Space Outpost and Lego in general as a way to recharge my creativity.  Part of this is working on the train room and advancing the layout.

So more on all of this as the week progresses.

 

 

On Liberty

                                                                                                                            Image by Gallant890 from Pixabay
 

Garbage on the Space Outpost

As past of the effort to detail the space outpost, garbage handling came up.  There are two approaches to detailing, fun action related things, ie building walkers, attacking the aliens, etc.  Or you can work on the "hum drum" that makes any large complex run, ie, maintenance support, food service, gym, showers, sleeping quarters and garbage handling.

My idea was incinerators and maybe a garbage crusher.  These two pictures above show the beginnings as I play with incinerators and the openings.  I saw these circular openings elsewhere and decided it was perfect for this.  It gives the illusion there are doors in them that will close when needed.  The bottom picture shows three different possibilities.  I settled for the one on the right as the basis.

Here is the close to final design, without the circular openings.  There is an incinerator on either side and the garbage crusher in the middle.  There is a control panel for operation.

The circular openings have been installed.  There is still detail to be added inside each compartment.  The circular opening makes it hard to see the garbage crusher.  The is something that will have to be worked on.

This is installing the lights.  I went with cool white on the incinerators and RGBW Led on the crusher.  Except I only connected the RED and BLUE.

Here it is with the LEDs on.  You can also see some of the detail that is included is included in the incinerator rooms.  After seeing this, I am going to look at putting the small LED controller in to varying the lighting.  The garbage crusher also needs work.  Unfortunately, there is no place to put a motor, that would be ideal for the crusher.

 

Loose Ends #7

 

This is the first attempt at the fueling station for the Space Port.  Still needs some work.  I did this at the last minute before Brick Days, using only the parts I had on hand.  Thus there is room for improvement.

Here is another perspective while fueling the cargo transport.

What follows are some random ideas that came up while building with the grand kids.

I am not sure what these creations will lead to.  But one of the overall treatments needs to the so called greebling, and that is probably where this is eventually heading

 

Just Harmony

                                                                                                                                                                                        Designed by Freepik
 Well after a few weeks of work,   I may be there.  The software component lefty to implement is the script manager.  This is mostly software with a dependency on the Non-Voltaile Memory driver.  Since that is working with the config data, what remains is verifying it works on the larger memory needs of the script manager.

The last problem child was the Bluetooth and the RN487x interface.  First the UART driver did not work anything like the previous model.  As a result the Tx function is blocking, kind of, for now.  Not sure how important that is.  In the RN487x implementation, I wait around for the CMD prompt before executing the next instruction.  I could have the ISR process the flag the main loop when this happens, but this is only important on initialization.  For now I am just going to leave it as an inline process that runs to completion.

The Rx function works like before with an ISR that processed the Rx queue from Harmony.  I did have to use the Ring Buffer  implementation.  The normal implementation required that you submit a read request, instead of just using the call back when a byte came in.

There was another problem, but this had to do with Android software  I had thought I had solved this problem several years ago, but it came back.  It has to do with how many bytes are transmitted when writing a Bluetooth Characteristic.  Once transmit 8 (the maximum I set up), then in that session it will always transmit 8.  If you send 4 bytes, it will just stuff the other 4 bytes with the last 8 byte transmission.  You can read about this issue here.

Time to move on and finish this to the point I can start to assemble the new PCBs.  I have a place for at lest on of these 15 channel LED controllers.

 

More Harmony, Less KAOS and some Stupidity

 

                                                                                                                                                                                         Designed by Freepik

I have spent the last few days working on the I2C driver that I need for the LP5569 LED driver.  This is one component that received a major change from Harmony v2 to v3.  Most of API had their names changed and few things were added/deleted.

First for Brick Lights 1, I changed the board to eliminate the individual connectors for each LED that used the very small two pin connectors, the working proto is shown here. 

I used the 2mm header (2 x 5) that I used in the Brick Buddy 3.    I also changed the BT module to the smaller RN4871.  This also allowed for the board dimensions to shrink 8mm.  This is the new layout.

 

The first picture is the device that I am using for the development, while I wait for the new PCBs to arrive.  I should mention that under Harmony v2, most if not all of this proto was working.  So I know that the design was good.  

After generating all the I2C components in Harmony 3, I started the process of implementing the application layer code.  While Harmony generates the drivers and middleware, you still have to implement the application layer.  That took over a day to get to the point that it would compile  and at least appeared to communicate with the I2C drivers.  This I2C implementation is interrupt driven which for the most part makes it non-blocking.  

No matter what I tried, the driver would report an I2C error when transmitting a simple command.  Trying to follow the execution path down into the driver was not yielding any useful info.  After two frustrating days, I decided to try a different approach.  I have a PIC32MX470 Curiosity board and there was an I2C EEPROM example.  Also the Curiosity board allowed me to connect my Digilent Analog Discovery device very easily.  This device has an I2C decoder built in, thus I can see the commands and the protocol to determine if it is working correctly.  While the EEPROM was responding correctly, the firmware still not see it.  Stupidity number ONE.  The comments for this example were very specific to make sure the CLICK sockets were connected with ZERO ohm resistors.  Well they were not.  The 1K resistors were just enough to screw up the PIC32 read.  Once I got the example code running, I modified it to more resemble the code flow I was using.  Now that I know this was working I could go back to the proto with some confidence.

Well still not working.  Attached the wires for SDA and SCL so  I could watch the I2C protocol exchange on the Digilent device.  First thing I see is the device address is wrong.  With a 7 bit I2C address in Harmony v2 the user was required to shift 1 bit left, but in v3 the driver does that.  Thus the device address had been all wrong.  Stupidity  number TWO.  Once this was changed the I2C exchange started to work, but would not complete.  

Side step, when I first started using TI LED Drivers, I was using the LP5569.  Then COVID and they disappeared. But I could get LP55231, and earlier version that was 90% firmware compatible, though the outputs were inverted.  THE LP55xx driver that I wrote would mostly do both, though I had not completely tested it on the LP55231 since the LP5569 became available again.  The new layout will use the LP5569.  This proto was the only device that actually had the LP55231.

Looking at the  I2C trace, I could see that the final ACK was not coming in.  After hours of research, I found that the LP55231 required a software Chip enable for some commands to work.  How this worked before I am not sure, but I decided to just move on.  I modified the startup loo.  Stupidity  number THREE.

Now the entire initialization of the  LP55231 completes and the status read back shows all the registers are where they should be, just not at reset.  I still need to check if the LEDs actually light up, but for now I have high hopes it will work.

On to the BT module.

 

Harmony or Kaos

 

                                                                                                                                                                                        Designed by Freepik

Short missive on the framework Microchip calls Harmony 3.  Not sure if this is Harmony or is it a cruel replay of KAOS from Get Smart.

While Harmony 2 for PIC32 was tolerable, this new version is lacking.  I have read several forum entries where "experts" are expressing concerns that it may or may not work. And if it works today, no guarantee it will work tomorrow.  The "code suppositories" are just that.  Anyway I need to move to the next version of XC32, but that would require completely replacing about half of the Harmony 2 libraries and that was a non starter.  So a few days ago I started to build a simple project, USB HID and a console port.  Two basic things I need.

Now I admit I rarely used the code configurator for PIC18 projects. So using this for Harmony was a different thing.  Harmony 2 was mostly a text based configurator, except  for the clock and pins.  The documentation of Harmony 3 is mostly for previous revisions and implementations.  Instructional videos from Microchip do not match with using MPLAB 6.25.  The content creator is needed to download what you need for the framework.  Well the latest content is incompatible with the PIC32MX270 and it's components, at least that is the message I kept getting.  That was a day just trying to figure out how that worked.  Then there is a Project Graph where you have to connect the components.  I was an avid user of Borland's Object Vision in 90s, so graphical construction is not new to me.  But this was not intuitive.  When I finally got all the wires drawn on the GUI configuration, it failed to generate all the .h files and thus would not compile.  The first thing I figured out was I did not need the FreeRTOS component.  One thread in the project, no need for an RTOS, but I have to keep deleting it, since the configurator thinks I need/want it. 

I finally stripped the project down to just a console and then all the .h files were generated.  It appears once you get them generated, then the configurator will continue to update them,.  The trick is to get them generated.  Then I added the USB back in, generated the files and it still compiled.  A few more tweaks and the USB HID registered with the laptop and the console port started displaying messages.  So I have a basic system running.

But there is more fun ahead.  They have changed all the names of the common .h and .c files to something else as well as restructured them.  A lot of the common calls/types/functions have changed names.  It appears that many components that used drivers, no longer use them.  So the SysObj model for projects has changed.  When they said there was no compatibility between v2 and v3,  they meant none.  

One final hurdle.  The debugger will not load with MPLAB 6.25 and XC32 v4.40.  The message was 

 [ BootFlash ] at 0x1fc00490, expected 0x409bf800, got 0x00000000.
Could not enter debug mode because programming the debug information failed. Invalid combinations of config bits may cause this problem

which looks like a failure to load the Boot Loader memory, which I believe is where the debug module resides.  The config bits were the ones I have been using for a long time with this PIC32.  I thought this had something to do with the linker or the compiler version.  So I told the configurator not to generate a linker file.  That worked once.  I admit I did not go through this methodically, but in the end it looks like MPLAB 6.25 is the problem.  MPLAB 6.10 works every time, regardless of XC32 version.  I am still not generating a linker file so it using the default linker configuration.  

Not sure what lies ahead, but I am sure it will be challenging and frustrating.