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.

 

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 2 Functionality

Light Buddy 2

When I built LB2, I developed some unique LED features as explained in an earlier post.  This image shows the current setup of the Windows APP.

 LB2 was originally setup as four pulsing LEDs and two "conventional" LEDs.  LED_A thru LED_D would have one of the following LED Styles

• OFF
• STEADY
• PWM1
• PWM2

Not sure if the difference between PWM1 and PWM2 will be more than different timing.

LEDs LED_1 and LED_2 being "conventional" would have the following LED Styles

• OFF
• STEADY
• BURST
• CYCLE

What you can do is add features to these LED Styles.  

STEADY - allows you to add the features SAWTOOTH and TRIANGLE.  The other two do not make much sense, the LED is always on.

BURST - allows you to add the ALWAYS ON and REPEAT ON.  In the future TRIANGLE might be added.

CYCLE - allows for all four.  The red LED on the top of dome in this video, is CYCLE STYLE with a TRIANGLE/ALWAYS ON as the selected FEATURES.  One use for this a heartbeat type effect.  A definition of the different STYLES and FEATURES can be found in this post.

I have other ideas for LED Lighting effects, just need the time to work them out.

 

 

LED Styles and Features

 This is a video I posted earlier about the functionality of Light Buddy 2 in this compact generator detail.

 

In the process of building and programming LB2, I further developed the concept of different LED styles.  In the end, it is all about turning the LED on/off and how long it is on and how long it is off.  In this process I have come up with attributes that I call LED Styles and LED Features, for lack of any better words.  Along with these Styles and Features, there is a PWM parameter that effects the brightness of the LED.  When the PWM parameter can be applied is a function of the particular controller.

LED Styles

There are ten LED Styles as described here.

• OFF - the LED is off.
• STEADY - the LED is on. Brightness may vary by using the PWM parameter.
• BURST1 - the LED does a quick burst of LED on/off.  The intensity can vary with the PWM parameter.  This simulates a Laser weapon.
• CYCLE1 - the LED cycles on and off in equal on and off periods.  Brightness may vary by using the PWM parameter.
• PWM1 - the LED is varies in intensity as does the on and off period.  All three LED attributes are randomly varied, intensity, on time and off time.  The PWM parameter has no effect.  This simulates an arc generator or Tesla effect.
  
• BURST2 - same as BURST1, just different timing.
  
• CYCLE2 - same as CYCLE1, just different timing.
  
• PWM2 - same as PWM1, just different timing.
• Program - future style.  Some type of user programmability.
• ON/OFF -  future style.

LED Features

There are four LED Features as described here.

• Sawtooth - the LED will increase (slowly, though this is a relative term) in intensity.  When it reaches maximum intensity, it goes back to OFF immediately.  The PWM parameter has no effect.
• Triangle - the LED will increase (slowly, though this is a relative term) in intensity.  When it reaches maximum intensity, it then will decrease in intensity until it reaches the minimum intensity.  The PWM parameter has no effect.
  
• Repeat - when applied to a feature, the feature will repeat at some interval, with an off gap in between.
  
• Always ON - when applied to a feature, the feature will repeat at the minimum interval.  For Sawtooth and Triangle the next cycle will start immediately.
  

 The features were all possible in the script language.  Though they would be cumbersome to implement especially at the fine detail the direct implementation is done at.

 

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.