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.

 

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.

 

 

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.

 

Building Common Libraries

Brick Controller 2

Brick Controller 3

 Light Buddy 1

Light Buddy 2

 I am up to four devices now that have some form of common LED lighting.  Two of which have motor controllers, the basic PWM interface.  As I keep developing new LED lighting effects, going back to each one of these devices and making the changes is getting too time consuming.  Not to mention that I am not getting consistent effects.  

Earlier I started on a quest to make a common library of firmware that can be updated and then automatically apply across all the device platforms.  After a few days of work and frustration 😎, I have achieved success.  Though there is still some testing to be done, but the basics work.  Here is a short description of how I got there.

The two LED controllers I am using right now are LP5569 and LP55231.  I use these because they are mostly firmware compatible with each other.  Though one is a low side driver and the other is a high side driver.  When I am not using these LED controllers, I use the built in PWM controllers in the PIC processors.  Finally when the LED is very basic, either off or on, then the control is the generic IO control of the PIC processor.  Regardless of the driving source, my hardware designs abstract the source away and present a consistent hardware interface of a low side driver.  

Both the LP5569 and LP5231 have I2C interfaces.  These were the only devices in any of these designs that had an I2C interface, thus the I2C driver was intertwined in the LP55xx code. The first step was to extract the I2C driver code and make it a standalone module.  While this was not difficult, it take some time to "unwind" all the code.  Now I can add other I2C devices, without having to include I2C driver code. 

Next was to unwrap the the LED effect (STYLE + FEATURE) from the driving source (LP55xx or PIC).  This meant creating two different modules, one for the LP55xx and one for generating the LED effect.  As has been described in previous posts, the LED effects reduces to a PWM value in either the controller or the PIC processor.  Thus the module I call PWMCtrl, generates this single PWM value for any 100ms time slice.  Then if a LP55xx is the destination, the value is passed to that module for writing into the LP55xx IC.  (Actually because of the way these ICs are set up, all nine channels are updated in a single transfer.  Thus I wait until all the LP55xx LED channels have their PWM values updated before transferring data.)  If the destination is the PIC processor, then it is a simple register update.

The final change was actually splitting the PWMCtrl module into a common section and a local section.  The local section contains all of the device initialization, the cooperative task function and any hardware dependence.  The common section is mostly the LED effects generator.  This code computes the PWM value needed. Thus I now have one place where all effects are calculated, which provides consistent looking effects.  I have not looked very carefully at this split.  There probably is a way to combine these through some MACRO definitions.  But that will be for later.....

Light Buddy 1 - Operation

 

This video was taken with a standard HD Webcam (Logitech C922).  It does not do a very good job at closeups, which is why the device is slightly out of focus.  Additionally the LEDs, when on, tend to overwhelm the auto white balance.  One of these days I will get a better camera for this type of work.

This is a short video the Light Buddy 1 in demo mode.  Attached are the LEDs we sell in 1 x 1 and 1 x 2 plate format.  All of the LEDs have an integrated resistor.  Here is what is happening"

1.  The white LED in the upper left is on STEADY.

2.  The small blue LED left side center is in one of the pulsing modes.

3.  The purple LED in the lower right is in CyCLE mode then pulsing mode.

4.  The small blue LED on the lower left side is in CYCLE mode

5.  The green LED in the upper left is in STEADY then BURST mode.

Sometime later I will put together a series of videos that show the different LED modes that are possible.

 

Light Buddy - The PCB

 

Got my latest PCBs on Tuesday.  I knew before they arrived I had a problem.  I assumed (should be a four letter word) that PPS would allow any function on any PPS pin.  Well PIC18 may come close to that, but PIC32 does it in blocks.  So now I have 10 boards that are really not very useful.  Fortunately the USB and the console port could be used.  This one is very similar to the Brick Controller I cant build for lack of parts.  The Motor interface is missing and the BT (RN4871) is superset of the BT (RN4020) module on that Brick Controller.  The PIC32 is from the same PIC32MX family, just in QFP44 instead of a QFP64.  So this one is a high end LED controller with 15 LED channels.  I had previously mentioned this. 

I started pushing code into it, using the previous BrickController and MPLAB X Harmony Project I started.  Just in case the startup code for this PIC32 was unique.  Amazingly the USB HID came up right away.  I could not move data back and forth, but the PC recognized that a HID device was connected.  On the next day I was moving data and my Win10 App was talking to the device.  There were some USB connection issues.  They may have existed before I just never noticed them, but I decided to make this rock solid.  The PIC32 USB/HID implementation is more flexible than the PIC18 and this is OTG, which I am not using.  There are 3 state machines at the App level, two of them are callbacks from the USB/HID driver implementation.  The third is the real App level state machine.  It took a few days to get this working.  It was a simple matter of getting all three state machines in sync with each other and realizing that the two callbacks were actually running as the result of ISRs and those totally asynchronous to the App it self.

Once the USB/HID was working, merging in the other code for the other peripherals is easy.  Will need some conditional compiles, I dont like maintaining multiple code bases if I dont have to.

More later.

Light Buddy 1 - The Design

I have been working intermittently on a new Brick Controller, that I documented in multiple blog posts, this being one of them.  Well since parts are impossible to get, I moved on.  Got a quote from one of the robber barons for the LED controller (TI LP5569) with an MRSP at Digikey of $1.65 in qty 1.  They wanted $55 for an MOQ of 25.

Below is the result.  Not sure I can get everything for it right now, but it will be good enough for demo purposes.  There was no way I was going to build any of my new Brick Controller.  So I switched to an LED controller.  This is a subset of what the Brick Controller was, just no motor control.  This made power much easier since I did not need to make 9VDC.  The LEDs are powered from VUSB, ie directly from the USB bus.  The PCB is 48x64mm and is designed to fit exactly on a 6x8 LEGO plate. 

The differences from complete design freedom are:

1.  Had to put in a new BT module, the one I have been using (RN4020) is not available for years if ever.  MIcrochip does not appear to be upgrading it for BT 5.x spec from 4.2.  The BT SIG has deprecated 4.2 already and wont certify any 4.2 after 1/1/2023, according to the Microchip website when you look at the old BT module.  This BT module(RN4870/RN4871) is BT 5.1 but the smaller version cant be found, so I am using the larger version.  I have about 15 of these I bought months ago as a hedge.  They claim firmware compatibility, we shall see.

2.  The processor is a PIC32 of the same family as the new Brick Controller and I am hoping the firmware changes will be minimal.  There seems to be lots of these floating around.  Hopefully tomorrow they will still be there.

3.  If you look carefully you will see a small square IC (U1).  That is the LED controller (LP55231).  This a previous version, but is firmware compatible with the one (LP5569) I used on the new Brick Controller.  I bought 20 of these months ago from one of the robber barons.  For whatever reason they were only 3x in cost.  The biggest issue for me is that this controller is a source to the LEDs while the newer version is a sink.  While this might not seem like a big deal, it actually has large implications in the wiring of a LEGO display.  At least I try to minimize the number of wires running through a LEGO build.  Using 36-42 gauge wire, you want to minimize the number of wires that can break.  So in my case, I minimize the number of source wires since this is the common wire.   All my previous designs used an N-FET to sink drive the LEDs, that way I can parallel up multiple LEDs and not worry too much about the current load.  So I added N-FETs to the output of the LP55231.  I give up the current control the LP5569 provides, but I use PWM to control intensity anyway.  With the VUSB supplying the drive voltage, a 120 to 150 ohm resistor provides the necessary current to brightly light the LED.  When the LP5569 controller becomes available, those N-FETs and one resistor per channel will go away.

4.  I added 5 more LED channels using the 5 PWM controllers in the PIC32.  These would normally control the motors, but they work nicely with LEDs also.  So this gives me 15 LED channels, which sounds like a lot, but I can get very carried away with lighting effects.

5.  I added 4 inputs, 3 digital and one analog.  Though the analog can be made into a digital.  The 3 pin connector has 3.3VDC, ground and input to either a Schimdt Trigger or an unity gain OP-AMP.  This shroud provide all the input I can use.

Back to the Blog

 

It has taken to long to get back to this.  Right after Bricks by the Bay 2022, we hit the road for an extended period of time.  Gone for two weeks back for one, out again for 17 days back for two weeks, gone for over a month, etc etc etc.  Some time after Thanksgiving, the road trips stopped and I have been trying to regroup ever sense.

Off to make a concerted effort to keep this Blog going at least until May.  Here are the topics that I hopefully am going to cover.

• Added a Solar Panel to my outdoor Shed
• Did a major upgrade to the sewing room
• Made progress on the Brick Controller for LEDs
• Made a much smaller LED controller
• General Software progress
• Observations on Android updates
• Train updates
  
• General musings on developing electronic projects 
• Plans for Lego conventions this year

 

 

And finally

 

Bricks by the Bay - Recap

 

The first live Bricks by the Bay since 2019 (@bricksbythebay_official).  It was the same and then again it was different.  The venue was the same as the last few times, so that was the same.  All the MOCs were in the center of the ball room and the vendors were around the sides. 

The MOCs were arranged by theme.  Unfortunately we were busier than in times past.  So we were not able to take as many pictures. (Actually my free time was spent in the two brick piles searching for parts.  I should have been taking pictures, but the draw of the brick pile was just to strong to overcome.)  

The one I should have taken pictures of was an interesting "mixed media" presentation.  To recreate a lot of the StarWars scenes, Dagobah, Ewoks, etc, they used a form of Japanese Bonsai trees with extended above ground root structures.  These roots were then woven into the MOC for an extremely realistic effect.  This is something that could not be done in pure LEGO.

The attendance was of reasonable size given the circumstances.  Not as big as in the previous years.  Traffic was much better on Saturday than it was on Sunday, which is fairly typical of these events. We would have like to see more people, but the ones that were there were highly motivated.  There was a lot of interest in what we were working on.  The softwear side had lots more interest than in the past. While our basic controller and USB power devices always draw lots of questions, there was a lot of interest in the Lighting effects we were showing.  Besides our MOC display, we had a demo of the new light controller.  Here is a video of it running the demo script.

One of the most visited vendors are those with bulk LEGO or brick piles.  Placed on a table or on the floor, people of all ages will rake through the Bricks looking for that one piece they need, select colors to fill out their inventory or just pick out every part they can find.  While the competition for select parts can be fierce, it is always a congenial competition.  I think the Bricks just brings out the best in people.  It does not even come close to Big Box stores on Black Friday.

 

 

Here is a quick video of the display we used to attract people to the table.I only brought three sections, the new Main Section that I first showed in Omaha in April, the Vertical Generator, the Space Port and the areas behind the cliffs.  These areas behind the cliffs are yet to be finished and are only the beginnings of a larger space that will exist behind the cliffs.

As I indicated earlier, I did spend a lot of time searching for parts in the brick piles.  Here is my collection prior to some washing and sanitizing.

 That is it for now, looking forward to next year.