Wednesday, July 8, 2015

Still here - how is YOUR summer?

Just a quick note:  am still here - and have not abandoned this project.    But have been kind of distracted with maintenance needed on our boat after it sat unattended for a full year.  Have also been working a bit on refinements to the Alternator Regulator project.

I do have the new v0.0.3 PCBs on hand, and parts for it all ready to solder up.  But with all that we have 'planned' for the summer there is a good chance I will not have much time to work on this for another month, or even more, but I am still interested in completing this MPPT platform.   So hand in there.

And if by chance there is anyone wanting to pitch in, I do have a couple of extra blank PCBs!

-al-

Friday, April 3, 2015

v0.0.3 posted

Today I posted v0.0.3 of the Arduino enabled solar MPPT controller.  Key changes include:

  1. Continued simplification of power supply - now primary switcher followed by LDO
  2. Inclusion of night-time 'dark' blocking FET
  3. Slight adjustments to FET driving traces, adding back in debug components.

I moved to a 13v switcher followed by a 5v LDO vs. the dual switcher in the last design.  Primary this gives a more stable voltage source into the ATmegaxxM1 for its ADCs - as well as providing a stronger VDD for the fet boost source.     In looking at the extra loss associated with the LDO, when fully active I calculate 175mW loss vs. perhaps 10 for a switching PS.  However this reduces down to the 5mW range when the uC is 'idle' or asleep - likely the in the same area as switcher (or even a little lower).  Given the uC can likely be placed into sleep for a large portion of time (most the peripherals work independently), am looking for low final loss.

Debugging has progresses enough that I thought it was time to add in a night-time blocking diode (using a FET for less loss).  The drive for this is pulled off of the boost ckt for bank-A, anytime that is working the blocking diode FET will get enabled.  It uses the intrinsic capacitance of the FET to keep enabled between pulses, while the 1M resistor provides a turn off after a period of inactivity.

I increased the trace widths of the FET drivers, and added in DC blocking capacitors, as well as 10K resistors between the drivers and the uC.  Idea hear is to provide SOME level of protection to the driver and uC while debugging code.  The final version of the PCB will have these removed.  And I likely will go to a 4-layer PCB for any final PCB as well.





Friday, March 20, 2015

Updated ATmega32M1 / ATmega64M1 support files for Arduino IDE

During debugging of the MPPT controller, I found a problem with the serial port code I adopted - resulting in random hangs while using Serial.Print() or Serial.Write() functions.  Today I posted corrected files (there was a logic error between the ::write object, and the interrupt handler).

I think the code can be cleaned up even more, and may do that later - perhaps using the current 1.6.1 files as a starting point.  But for now, do know there was a  bug which has been corrected.



Wednesday, March 4, 2015

ATmega32M1 and ATmega64M1 support with the new Arduino IDE 1.6.0

Update 2-14-2016:  There has been some fixes around ports usage - see readme.txt for details.  SPI is now demonstrated to work, and have been making progress in a CAN library. 

There are now 3 different 'versions' of the support files to use with different generations of the Arduino IDE, including the latest 1.6.7 w/o warning.

=====================================================================
 March 4, 2015:
This morning I posted up new portings of the ATmega64M1 uC in several variations, as well as support for the ATmega32M1 uC - all enabled at the same time in the new Arduino IDE release 1.6.0

Look under the Arduino Libs resource tab above, and follow the links and readme for the Arduino 1.6.0 IDE.  In short, you will need to copy a subdirectory in its entirety to your local 'arduino' users folder, and you will still need to make some edits with the avrdude.cong file.  But once done, you will find new 'board types' available for the ATmega64M1 and ATmega32M1 uCs.   A couple of details on the optiboot  ports:

  1. The optiboot included has disabled any startup blinking of the LED - in case you happen to have Port 13 assigned to something other than an LED.
  2. Some details on the fuses I selected:
    • Brown-out is set at 2.7v (same as the Arduino UNO), so you should be able to operate at 3.3v (take care of max clock frequency allowed when operating at lower Vcc - hence the 8Mhz versions).
    • The fuses are also set to FORCE  both the A and B outputs of the PSC controllers to a known LOW state upon startup / reset.  (6 output ports:  PSCOUT0, 1 & 2 - both A & B).
    • The clock selected is one of:  16Mhz, or 8Mhz external xtal, or internal 8Mhz osc.


 For the 'core' support libraries, at this time I simply copied over the libs I modified in the v1.0.6 IDE port.  I noted there had been a bit of cleanup with some of the 1.6.0 libs, esp around the hardware serial functions - but it does appear that the existing libs still function w/o problems.  Going forward I will update the core lib functions as errors are found.

Refer to the graph at the end of this post for a mapping of the CPU pins to Arduino PORT names/numbers.  Do make sure to check the Arduino Libs resource tab above for any updates.

Versions enabled include:
  • ATmega32M1 - 16Mhz external xtal
  • ATmega32M1 -   8Mhz external xtal
  • ATmega32M1 -   8Mhz internal osc.
  • ATmega64M1 - 16Mhz external xtal
  • ATmega64M1 -   8Mhz external xtal
  • ATmega64M1 -   8Mhz internal osc.




Enhancements to pinMode() and analgoReag() - Differential inputs.

The ATmegaxxM1 line of CPUs have an extra feature to their analog inputs:  3 sets of adjustable gain differential inputs.  The core libraries have extended to recognize three new 'virtual' ports AD0, AD1, and AD2.  To use one simply uses the analogRead() as normal, but passing one of the virtual port names.  pinMode() has been extend to recognize the three virtual ports - with a slight change; when a differential port is passed to pinMode(), it is always assumed the mode will be INPUT - and the 2nd parameter then becomes the gain factor to be used.  Gain factors may be one of these:  GAIN5, GAIN10, GAIN20, GAIN40.   Here is a sample sketch showing their use:

   void setup() {
     pinMode(AD1, GAIN10);              // Differential input channel #1

                                        // With gain of 10x
     Serial.begin(9600); 
   }





   void loop() {
     int i;
 
     i = analogRead(AD1);            // Read differential channel#1
     Serial.println(i);              // Print its value out
     delay(1000);                    // Delay 1 second between reads
   }





New 'Virtual' ports:
  •   AD0  = Differential input of   D9 - D8
  •   AD1  = Differential input of   A4 - A3
  •   AD2  = Differential input of D10 - A6 
New gain parameters passed as 2nd value in pinMode():
  • GAIN5
  • GAIN10
  • GAIN20
  • GAIN40




A few notes on the 1.6.0 release of the Arduino IDE.  Overall I am very happy to see them include a newer version of the GCC compiler - with its direct support of both the ATmega32M1 and ATmega64M1 uC as well as a better optimizer resulting in perhaps a 5% code size reduction.  It does appear they have also optimized the workflow of the overall tool some - I noted a bit better response / less delays when doing various tasks.

However I am rather disappointing they did not upgrade some of the other tools - e.g. AVRDUDE and the OptiBoot code.  You will still need to manually edit avrdude.cong adding in the ATmega32M1 and ATmega64M1 IDes, but at least now you can have both at the same time.  And for Optiboot - they not only did not upgrade to the latest release, but they totally broke the toolsets needed to recompile optiboot under 1.6.0;  it is a mess, with the only option to use a down rev 1.0.x release for the toolset and add in the latest source of optiboot source.

This is what I did for the boot files needed in this porting.

A final note:  I have only TESTED this port using the ATmega64M1-16Mhz xtl, and 8Mhz Osc options; as that is the boards / CPUs I have at had.  As folks use this if you find any issues with the porting I did, please let me know.



Click for larger view.
(Be sure to retrieve latest version from Arduino Libs resource tab above.)


Thursday, February 26, 2015

Time to checkout the Magic Smoke!

I have finished assembling a solar MPPT controller - here are a couple photos:



I really should not have the camera THAT close.
Those Caps look like towers!
Have also been working to clean up the Arduino IDE and the port of the ATmega64M1 CPU.  I think I have most things fixed and will post corrections as I continue the debugging effort.  A bit on that: the porting is to the IDE version 1.0.5 / 1.0.6.   Arduino just released their 'updated' IDE v 1.6.0, and it will be much better - mostly because it uses an updated version of AVRDUDE and the GCC compiler - providing native support for the ATmegaxxM1 series of CPUs.   However, there has been some large changes in the support files - specifically around the hardware serial port, and it will take me some time to work though that all.  So for now, I am continuing my efforts under the 1.0.x line of the IDE.

Just last night I moved to start some live testing using the Solar Panels on Viking Star.  It is perhaps a good time to do this as the weather has changed, and our overcast winter sky's limit the panels output.  So far results tell me there is still a bit of work to do.  Am not happy with the +12v boost power source, and have worked though a fuse or two already...

But will carry on, and see what all I can get working.




Tuesday, February 24, 2015

More on ATmega32M1 and ATmega64M1 support with Arduino IDE

This morning I have posted up a refreshed set of 'files' to enable the ATmega64M1 uC in the Arduino IDE.  See 'Arduino Libs' resource tab above.  Specifically I have made edits to pins.h, and the wiring.c files scrubbing port names and how they are handled.  I also desk-confirmed the macro's needed to support software serial.  At this time I have touched a good portion of the Arduino IDE stack, and think most is 'ported' in support of the Arduino IDE - the two areas I have not touched, but perhaps will work fine due to how things are written, is the basic PWM and timing functions.

If you have downloaded the porting files before, you should do it again as there has been some significant corrections made in the area of how port names and numbers are defined.

I have also expanded the supported variants to include:  8Mhz, and 16Mhz external crystals, and an 8Mhz internal oscillator variant.  

All these changes are in support of the Arduino IDE version 1.0.x.  Going forward, I am working to bring up the SmartMPPT controller and as I find issues I will continue to update these files.  I also want to make a set of files targeting the new 1.6.x series of Arduino IDE's  as that will simplify things given their usage of more current compilers and ARVDUDE and as a result better native support of the ATmegaxxM1 uC's.  However, there are some major changes which have been done and porting to the new environment will take some time.







Monday, February 9, 2015

Expanding Arduino analogRead() and pinMode() to support the differential inputs on the ATmega32M1 / ATmega64M1

A nice feature of the Atmega32M1 / ATmega64M1 line of uC's is the addition of a differential input amplifier as one of the options for the ADC.  No longer must one take two measurements and subtract them in software, the 'op-amp' can do it for us.  Plus these differential inputs have a selectable gain from 5x to 40x.

On the Solar MPPT controller I use this capability to measure the battery and solar panel currents via a simple low ohm resistor.  Add in a small RC low-pass filter, and that is all that is needed...  (Using the ATmega32M1 uC allowed me to remove several other components typically used in other approaches, current measurement being one of those areas).

There are three differential channels: 0, 1, and 2.  I have extended the Arduino IDE's wiring_analog.c to recognize three new 'virtual ports'**:  AD0, AD1, and AD2.   Reading the value of these differential analog ports one simply uses the oh so familiar analogRead() function, example:

    solarAmpsRaw = analogRead(AD2);       // Read raw value of Solar Amp Shunt.


pinMode() has also been modified to recognize AD0, AD1, and AD2, with a slight change:  the 2nd parameter no longer specifies a 'mode' - as differential reads are always input.  Now the 2nd parameter is used to specific the amplifier gain to be used:  GAIN5, GAIN10, GAIN20, GAIN40

  pinMode(AD2, GAIN40);                 // Enable diff-amp #2, with gain of 40x


** Do take note that when enabling the 'virtual' differential analog inputs, two actual hardware ports are repurposed:


  • AD0 returned results of:  (  D9 - D8)   * gain
  • AD1 returned results of:  (  A3 - A4)   * gain
  • AD2 returned results of:  (D10 - A6)   * gain



Summary of changes:

  1. analogRead() expanded to recognize differential virtual ports AD0, AD1, and AD2
  2. pinMode() expanded to enable AD0, AD1, AD2 and set the gain with: GAIN5, GAIN10, GAIN20 or GAIN40.








An example sketch:

#define SOL_AMPS_CHAN AD2               // ADC channel to read solar amps
                                        //  (Differential channel #2)
#define SOL_AMPS_SCALE (1/(40 * 0.002)) // Channel gain of 40x, 2mOhm shunt


void setup() {
   Serial.begin(9600);                  // open the serial port at 9600 bps:
   pinMode (SOL_AMPS_CHAN, GAIN40);     // Set up the differential channels.
}






void loop() {
  Serial.print(" Solar Amps are now: ");
  Serial.println(analogRead(SOL_AMPS_CHAN)*(int)(SOL_AMPS_SCALE  * 5/1024));
                                       //read and convert Solar Amps
  delay(1000);
}


Saturday, February 7, 2015

Turning the PCB - and Arduino internal ADC accuracy

I have found enough errata to want to do a turn of the PCB.  v0.0.2 was send to OSHPark Thursday, as with a Mouser order.  Should have them in in a couple of week.  I will work on porting Tom Nolan's simple MPPT software (https://web.archive.org/web/20140324221651/http://www.timnolan.com/index.php?page=arduino-ppt-solar-charger)  to the SmartMPPT controller in preparation.  v0.0.2 has several changes, including:
  • Corrected SMT footprints
  • Cost reduced power supply, USB designs.
  • Removal of SERVICE port (functions could be accessed via ICSP port)
  • Improved voltage sampling buffering ckt - removal of offset errors in op-amps
Overall cleanup of board, and improvement in tight Hi/Low FET layout.

One area I struggled with a little was the voltage sensing design - based around using the Arduino's built in A/D.   In short - how much $ vs. desired accuracy?   One might noticed I backed off from the 0.1% resistors in the voltage divider, and now just use 1% devices.  This saved about $1 in BOM cost.  And here was my thinking:   The ATmega32M1 is able to selected one of two sources for its A/D converter reference:  External (Vaa, or +5 in this design), or an internal 2.56 source.   And there is the basic issue.  The internal source is known to be rather stable over time and temperature, but not all that accurate (2.5-5% or so).  Using Vaa tied to +5, even with the filtering, can present a significant error its self (And is dependent on the accuracy fo the +5 supply to boot).

All told, using high precision components in the op-amp ckt seemed kind of like putting silk on a pig's ear.  Additional cost could have been added by adding an external voltage reference (i.e. LM4040) - but I think even then we would not know the BATTERIES voltage, only what we see at the output of the MPPT controller.

So, I have  backed off - and accept a few % error in absolute accuracy for voltage readings, but still look for stability.  As far as the MPPT logic is concerned, it is trying to maximize a value - and it really does not care too much how accurate that value is, just that it is repeatable.


For accurate battery voltage information, to say decide charging states and accommodate voltage drops over the battery cables, will look to the CAN BMS device attached via a simple CAT-5 cable.
http://smartbms.blogspot.com/





Sunday, January 25, 2015

atmega32M1 / atmega64M1 and the Arduino IDE


This series of blog entries will document the enhancements of the arduino IDE to support the ATmega32M1 and ATmega64m1 uC.   Make sure to follow this link to see all the changes and enhancements:
http://smartmppt.blogspot.com/search/label/xxM1-IDE



I selected the atmegaxxM1 uC for this solar MPPT controller for three reasons:
  1. An very nice PSC (Power Stage Controller) module that can do tightly locked driving for the H-bridges - much more advanced then the standard PWM modules in say the atmega328p
  2. Built in CAN controller
  3. High degree of robustness as it was designed primary for automotive applications.
  4. Being part of the atmega line of uC's, it is a close cousin to the atmega328p as used on the Arduino UNO
This last point is attractive as it could allow one to use the Arduino IDE to program the smartMPPT controller.  Only problem is - the atmega32/64M1 uC is not currently supported by Arduino.  Compounding this is that the serial port is a bit different - rather then a 'standard' UART it has a serial controller which can assist with UART functions, but also provide support for another type of bus used in automobile applications, the LIN bus.

All of this means  - one can not just plug things in and it will work.  Google turned up a few folks who looked into this, the one making perhaps the most progress was: http://spaces.atmel.com/gf/project/arduinoallegro/

Over the past few days I have been successful in porting the optiboot bootloader to the atmega32/64M1 uC, integrated the start of the environment from Stuart (specifically his work around Serial.print() functions.) and successfully have been able to use the Ardino IDE to flash in a bootloader, and then download sketches via the serial port!

Look under the resource tab above 'Arduino Libs', and select the  directory called 'atmegaxxM1 Arduino IDE'.  In there you will find an optiboot bootloader, modifications to the avrdude configuration file, as well as the Arduino IDE (boards.txt, etc..) and instructions on what to do with each.  I suspect there is a bit more work to do with the Arduino libs - beyond Serial.print(), and as I find and update those will post revised files to the resource tabs above.

I also have modes needed to support the atmega32M1, and once things are a bit more proofed out I will post a set of files needed to support that uC in the Arduino IDE.

==========================================================

Additional Info Feb 2015:  I have tracked down a bit more details re: the atmega64M1 uC support by the tools selected by Arduino for their IDE.   Bottom line:  In the 'main' release of Arduino uses gcc version 4.3.2, which does not have in its known list of uCs the atmega64m1 - but does have the atmega32m1.   My current 'work around' was to configure the above files for the atmega64m1 and 'spoof' to the compiler think it was a atmega32m1.  This works OK, but prevents me from defining both the 32M1 and 64M1 at the same time.

In the beta version of Arduino (1.5.8, etc) is an updated the GCC compiler (version 4.8.1?)  which has been updated to include many more uCs, including the atmega64M1.  For now I will continue to work with the  the 1.0.x releases, but in the future (and depending on what the Arduino team ends up doing) will perhaps switch to the 1.5.x versions for more complete support.

More additional info March 2015:  I have completed a porting over to the 1.6.0 release of the Arduino IDE - and was able to enable BOTH the ATmega32M1 & ATmega64M1 uC at the same time.   See here:
http://smartmppt.blogspot.com/2015/03/atmega32m1-and-atmega64m1-support-with.html