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.

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);
}

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/

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

Status of prototype build.

We are now in the Portland OR area and could fetch mail (and boxes) from our mail drop.   Most all the components have arrived, and the PCB should be here soon.   But there is one delay:  the inductors from CoilCraft are on back-order until the end of January... 

Oh Well, will give me time to play with other parts of the bringup.

v0.0.1a of hardware design released

Today I edited this BLOG to put in the resource links above, and also posted the final release hardware design for the initial build v0.0.1a:

See 'Schematic' link above for larger image .pdf file

And here are some 3D renderings:

Top view

 

Bottom view

The module is approx 3x4" (actually, 80mm x 100mm), utilized 100v FETs and caps (I am suggesting keeping solar panel voltage below 85v), and can support up to 25A battery current.  These give it the following range of charging support per module:

• 12v battery:         345W capacity
• 24v battery:         690W
• 32/36v battery: 1,000W
• 48v battery:      1,380W

 To each the above capacities one or more solar panel can be used.  Example, for a 12v system one could use a single large 280W panel per controller.  For a 48v system, 4 such panels could be deployed in a combination of serial/parallel connection.

The costed BOM come to $73.30 + price of PCBs, which could be found for under $10 using overseas supplier.  I expect parts to arrive some time in December and will start assembling one unit then, and when I return to Viking Star will be able to start playing with trial runs on our solar panels as well as start developing the more advanced firmware.


For those interested there is a LTSPICE model of the buck converter using in this design under the CAD resource tab above - kind of fun to play with.

Final 'Rough-Cut' schematics #3

Tonight I posted what I am calling the last of the 'Rough Cut' schematics; last as I have completed my initial review of the switchers - and am well underway in PCB layout.  Next step will be to release v0.1 of the design, along with the CAD files.

Over the past weeks or so I have been focusing on the FETs and doing a bit of SPICE modeling, paying attention to the transitions.  As a result I swapped out the FET driver ICs for ones that are able to drive the FETs harder, removed any imposed gate resistance, and also removed the bypass diodes around the lower FETs.  This last step might seem odd, but in refining things I have been able to greatly shorten the dead-time, currently looking at using 35nS as a very safe starting point.  This short time seems contrary to some folks thinking for such large FETs, but actually is in line with start-of-the-art designs - Drive the FETs Fast-n-hard, and with the right drivers (ala the LT's I am now specifying) am able to get real tight switching w/o any adverse effects.

A higher resolution PDF file:

https://drive.google.com/file/d/0B5GiaoeXCQ3vclRRaFFEUXhQQXc/view?usp=sharing

 
Some other small changes include:

• Finalization of 5V and 13V power supplies. (though may need to change out 10Ohm R3, am just trying to reduce the number of different parts used)
• Addition of 'Service Port' which can be used instead of populating USB
• Upgrading all FETs to 100v parts, allows use of two common panels in series for 24v/48v batteries.
• Reduced some of the large switching  CAPs, still have plenty for the design.
• Changed Amp Shunt resisters from 1mOhm to 2mOhm for better use of ADC ranges

With these changes, the .xls sheet is indicating 98.6% - 98.7% conversion in the core.  SPICE modeling seems to confirm this, will see with actual hardware.


I have also been revising the layout of the core switching elements to minimize current paths.  I still have some work to do, and may end up modifying the schematic some, but largely I think this is close to what the finial design will be.

Note how some parts are still not places, I need to work on the drivers a bit more - but overall am happy with how this layout is shaping up.

We are about to begin our move from Minnesota back to Washington (and Viking Star) - with a stop in Portland for the Holidays.  It is likely I will not have too much time to put into this over the next few weeks, hence I wanted to get what I had posted.   But I do intend to finish this in time to order up some PCBs and parts so I can start playing with hardware after the new year, and when I am back at the boat with the solar panels!