MPLAB X Issues

I thought I would get a head start on the firmware for Brick Buddy 3 while waiting for the PCBs to arrive.  I would use the Curiosity HPC development board I had originally used in the Solar Shed project.  The HPC is on the right.

This is the only development board I have that would hold a 28 pin PIC.  I decided to just go with a PIC18F46Q71, which is the 40 pin version.  The attractive part is the two Mikroe Click sockets on this board.  One could be the RN4871 Bluetooth module and the other would some generic I2C Click board (I2C EEPROM memory) so that I can work out the I2C driver.  This was also driven by the need to check out the new common libraries I discussed earlier in this post. The Q71 family has the improved full featured standalone I2C module instead of the standard MSSP that has been in PIC18F for a very long time.  The PIC18F Q71 offered great PWM capability, 28 pin SSOP, good amount of memory ( FLASH and RAM) and some other goodies that escape me now.  Oh and I could buy it.  

And the fun begins.  There are now two versions of this Curiosity HPC.  All of the Curiosity boards have built in PICkits.  Well version 1 ( what I have) is based on PICKit3 and the version 2 on PICKit4.  And wouldn't you know it, version 1 of the HPC will not support the PIC18FxxQyy devices.  No biggee, there is a 6 pin ICSP header. I removed R13, R14, R15 which were the resistors on PGC, PGD and MCLR.  These three resistors connect back to the built in debugger.  Removing them isolates the built in debugger hardware.  I soldered on a 6 pin header to the ICSP pads, connect my PICKit4 and I should be good.

Well that was awful naive of me.  First off only the latest versions of MPLAB X will program these chips.  The earlier versions were happy to compile the code, but connect to the PICKit4, not happening.  So I downloaded the latest version MPLAB X  6.05.  It connects, blank tests, reads the memory, but when you program/debug it just hangs at the programming the configuration memory, which is the first memory area it tries to program.

This mess started last week.  I tested another 40 pin dip I had (PIC18F46K40), no issues.  So the connection is good.  So I must have damaged the PIC18F46Q71.  What else could it be.  

I was not smart enough to order two PIC18F46Q71 parts when I ordered the first one.  So another Digi-Key order and wait for arrival.  Side note: USPS delivered in 3 days, 1st class.

I then started again.  And the same result.  Posted in the Microchip Forums, not much help.  After trying all kinds of stuff, I finally went to another computer.  Maybe the computer is corrupted.  But instead of version 6.05, I installed the supposedly buggy 6.00.  And it works.  Went back to the original computer, removed 6.05, installed 6.00 and it works.  For grins, I re-installed 6.05 and it still doesn't work.  So not sure what the definition of "buggy" is anymore.

At this point I claimed victory and will just stick with 6.00 for this one project.  Filed a case and updated the forum with my results. Maybe it will save someone else the hassle. If you have acces to the Microchip forum and want more details, search for "SOLVED : PIC18F46Q71 will not program"

More than I thought to just get a simple development board up and running, but that seems to be always the case.😊

It was a Cool Idea

 

A few weeks ago I mused on whether I had a crazy idea or something cool (Oh so 1960s).

Well I think it is very cool, especially in its first incarnation.  The picture above was the 3D rendering of the assembly.  Here is an assembled PCB

This is the size of 1x2 Brick plate. If you solder from the back, as I will in implementation, then a 1x1 plate/tile will fit in the center.  If you solder strictly on the top, then a 1x2 plate/tile will fit.  The four solder points on the right are a little tight and some care will have to be taken when attaching wires.  Using a 250W Weller Soldering gun and 0.1" diameter solder will be challenging.

The different colors on this discrete part have different illumination characteristics as shown here.

As I suspected, some experimentation was needed to arrive at the correct resistor values.  I have set a current limit of 15mA per resistor for all of my designs.  Most of the the Light Controllers have a minimum drive current of 25mA.  So the 15mA limit sets a nice margin.  As the chart above shows, the GREEN LED is the brightest of the RGB.  It appears to be equivalent with the white.  The RED has a lower Vf, which required a larger resistor to keep the drive current under 15mA.

I needed something to test in.  I have been playing with this Design.

I started modifying this to accommodate the LED PCB.  First it needed to be in the center of the 8x8 plate.  Then I needed a way to suspend the 2x2 transparent light blue round bricks over the center, so that the light will go straight up the column and out the spire (Antenna 4H) on top.  Finally there was going to be some stack up issues when using plates and bricks and I need a way to extend the round bricks.

Here is the first step.  A 4x4 plate with a 1x1 round plate in the center.  The round plate is needed, since it fits inside the 4 studs at the center of the 4x4 plate. I glued a 1x2 tile on to the back of the PCB.  Since there are no tubes on the back of that tile, it can slide on the 1x1 round plate.  After centering the PCB I placed 1x2 bricks on the left, right side and the top left corener.  I used 1x1 round plates in stacks of three to finish the top section.  This allows the wires to pass through the gaps.  Then at the bottom (in the picture above orientation) I used 1x1 round bricks at the corners and the same stacks of 1x1 round plates in the two center positions.  This was needed to accommodate the wires that I soldered on the top, with the wires coming straight off the PCB.  If I had soldered then from the bottom, then a 1x4 brick would have worked. 

This picture shows the 4x4 assembly attached to the 8x8 plate that is on the bottom and the surround support wall, with a gap for the wires.  Now I need to support the transparent round bricks.  Modifying a brick was a possibility, but then I remembered technic plates.  They don't come in Tan, but I am not sure that matters here.

This shows the technic plate in place.  Next was a mismatch in the round brick height and the large  top (8x8 dish) that goes on top.  The round bricks actually hold this top in place, it doesn't seem to want to grab the studs on the macaroni pieces.  In the stack up that was needed to capture the LED PCB and the technic plate caused the transparent round bricks to be on plate short.  So I placed four light blue transparent 1x1 round plates on the technic plate as the picture above shows.  At first I thought I would have to drill out the technic plate hole to let more light through.  Then these four 1x1 plates sort of restrict it even more.  But as the videos below show, there is plenty of light.

So that brings back to this.

You can see the Light Buddy 2 controller on the right.I am not sure this is the final iteration of this design.  I would prefer to have the controller embedded in the unit.  Four of the six LED Channels are used, so there is no need to have it control other devices.  With some more thought, I am sure I can come up with other uses for those two LED channels.

So here are the videos. The first is in minimal background light and the second is almost full background light.  Unfortunately the camera does not have a large amount of dynamic range in light.  Thus the LED lights tend to over power the camera.  It looks much better live, but these videos give a good indication of what it can do.

Now that I see what this can do, I already have come up with RGB specific effects.  More on that later.

Minimal background light. 

 Full background light.

Solar Shed Update

 

A quick update on the Solar Shed progress.  The snow has melted and there is some sun.  I have not been formerly taking down readings, but in general the battery has charged to slight over 14VDC on it at the day and about 13.8VDC in the morning.  Which is comparable to what I saw on the bench.

Moving to the real world is always going to bring on new issues.  What problems did I have, well 😛

• For the switch that turns on the LED Lighting, for some reason the weak pullups on that input was off.  The overhead LED  lights would go on and off randomly.  I was never a fan of those weak pullups, not sure why I did not just put a 10K or 100K pullup there.  Space and cost were not a driving factor.
• Next this switch does not wake up the PIC.  When is the PIC sleeping, at night .  When do I need the light, at night.  It is a simple fix, but I am waiting to gather more changes before fixing this.
  
• I had added a relay for selecting power source for PIC and etc, from either the battery or the solar panel.  I implemented the logic to use the Solar Panel as the power source whenever it is above about 8VDC.  But forgot to change the TRIS register for the drivers to an output.  No wonder I could not drive the relay to change the source.  Now as long as there is sufficient solar panel voltage, that powers the PIC and etc.
  
• All of the conversion constants moved a little, again.  1% resistors are nice, but they are still only 1% accurate.  Another change is to add an OLED screen that shows the ADC count instead of a calculated voltage.  Maybe that will help refine the conversion chart I showed earlier.
  
• The 7.5F supper cap took over 2 mins to charge the first time.  I thought there was a short somewhere since the voltage would not rise.  Then I remembered that an uncharged cap is a short. 

I have been thinking of a good test for the super cap.  What I am thinking now is around 8PM disconnect the battery.  The sun will be down, so no solar power.  Then before the sun lights up the solar panel, check if the PIC is still in sleep mode.  One way is to press one of the buttons that will illuminate on the LEDs.  It is a left over debug routine, that is actually quite useful.  The other is to measure the voltage at the Suoer Cap and see if it is providing sufficient voltage.  Then this test needs to be repeated without the OLED installed.  

The process continues.

 

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.

 

Solar Shed - Assembled

It is mostly assembled now.  First step is test the ADC inputs and make sure they are working correctly.  I built this spreadsheet.  

• Column A is Vcc=3.29VDC and ADC size is 1024 counts
• Column B is Battery input voltage
• Column C is Battery voltage at the ADC input
• Column D is the ADC counts for that voltage
• Column E is LT1085 voltage at the ADC input (input voltage is from column B)
• Column F is the ADC counts for that voltage
• Column H is Solar Panel input voltage
• Column I is Solar Panel voltage at the ADC input
• Column J is the ADC counts for that voltage

Finally the three numbers in row 2 (0.2015, 0.2035 and 0.1286) are actual measured voltage ratios of the voltage input and what is present at the ADC input for each input. Even though I used 1% resistors, there is still +/-1% over the marked resistor values.  And to be fully transparent, even though there are unity gain low bandwidth (10KHz) OP-AMPs driving the PIC ADC, the layout probably could have been better.  It is as tight as SMT0805 resistors/capacitors would allow and is surrounded by ground plane.  But not being an Analog Guru, it is probably just OK.  Below the table You can see the layout for the three ADC inputs. (It;s late and my hand is not quite steady, s the picture is a little fuzzy)

 

Then I compared these numbers against what the ADC was reading.  Finally I tweaked the Vcc number a few millivolts to get  a more consistent match of the table values to the actual ADC readings.  During this process I noticed that I had left the weak pullups on the three ADC input pins on.  After turning them off, the readings were much more consistent.

The next issue was going in and out of sleep.  Just needed to make sure that everything I turned on/off before sleep, was turned off/on after coming out of sleep.  So at least on the desk it seems to work as before.  There are a few enhancements and more testing that are needed

• When the solar voltage is high enough, run the PIC from the solar panel.
• Install the super cap and test it.
• Maybe the PIC runs from the solar panel all the time and the battery only powers the LED lighting in the shed.

Ran the system in sleep all night.  Starting battery voltage at 10PM was 13.68VDC.  At 8AM the next morning the voltage was 13.51VDC.  Now in LiFePO battery system this doesnt mean much.  Unless you have a calibrated battery gas gauge IC connected, there is no way to know how much battery life was consumed.   We must remember that a LiFePO battery discharge curve is quite flat until the inflection point.  What is important is the current numbers from the previous post, the system with OLED and in SLEEP, consumed 2.25mA from the battery.  That should be equivalent to 18mA-Hr.  Fully charged (and new) the battery is rated at 9.6A-Hr.  So over night we used about 0.2% of the battery.  

I will be interested to see what the super cap does.  That will be the next test.  Still waiting for the sun to appear and the snow to melt.