Searching for a better Pro Mini

I LOVE the Pro Mini! But it has limitations. To overcome some of them, I’m designing the Pro Mini XL & Pro Mini nRF52. What do you think?

Similar projects worth following
I LOVE the Pro Mini!

It’s been a veritable electronic Swiss Army Knife for many of my DIY/HA/World Domination projects.

But it has its limitations.

So I’m currently designing more Pro Mini boards in an attempt to try to overcome some of the limitations I’ve encountered.

My headline requirements are that the new boards be pin- and size-compatible with existing ATmega 328p Pro Minis.

The idea being that the new Pro Mini boards would be physical drop-in replacements - with benefits!

So far, I’ve come up with initial prototypes for the following microcontrollers:

- The Pro Mini XL uses an ATmega 1284p.

- The Pro Mini nRF52 uses an nRF52832.

Since this is my first time designing boards like this, I’d really appreciate any constructive feedback or advice to help improve them and/or make them more useful.

If you’re interested, please join me in the ongoing project logs and discussions below.

Quick Links

I’ve written some preliminary project logs and provided quick links to them above.

If there is enough interest in what I’m doing here, I plan to update the list as I post more.

This should help you navigate around the project.

Future Project Logs?

If there’s not sufficient interest, I’ll have to redirect my labors elsewhere.

So with that in mind, I thought I would ask you first what you wanted to hear more about.

Some suggestions to get you started:

  • Using the Pro Mini XL & nRF52 with MySensors for Home Automation
  • Pro Mini nRF52 + e-Paper + SI7021 = Low Power Wireless Environment Monitor with Display
  • Building an Endurance Quadcopter with the Pro Mini nRF52
  • Board Stacking the Pro Mini XL with SPI Flash, ATSHA & RFM69HW
  • Unlocking, Debugging & Developing with the nRF52832 using a Blue Pill BMP
  • A Pro Mini STM32?
  • A Pro Mini SAM?
  • Something else?

Rather than (potentially) balloon the comments section of this initial page, please head-on over to this Google Form and let me know what you want to hear more about there.

Where Can I Buy...?

I’ve had a few eager people buy some of these boards from me - even though they’re still in development.

If you’d like to join them, please let me know and surrender an email address here.  No spam.  Promise!

  • Power-down of <1nA? with Just-in-Time Regulation

    Andy11/28/2020 at 12:35 0 comments


    I took advantage of the ATmega1284p's wide operating supply voltage (e.g. 1.8v to 5.5v) and low power sleep state and developed something where the microcontroller can actually sip it's power-down supply current from an automatically rechargeable low-leakage on-board capacitor until more power is needed, effectively lowering the average power-down current *from the battery* to less than 1nA.

    (Yes, that ATmega1284p is actually on and in power-down mode - video at the end of the log.)

    Part One

    Phew.  Was that really a TL;DR?!

    Those following along will remember the above photo from the end of the last project log.

    And yes, that ATmega1284p on one of my Pro Mini XL (v2) boards really is "on" and in power-down mode.

    Don't believe me?  Let's wake it up then by grounding INT0...

    See the LED light up despite drawing less than 1nA?  It's alive alright!

    So what's going on?!


    Have you ever noticed that after you disconnect power from some devices, they remain on for a little while?

    See that power LED on your phone/laptop charger slowly fading off in to the abyss of nothingness?

    There can be a number of reasons for this.

    But the one that interested me recently was that of the remaining charge stored in the on-board capacitances.

    On-board decoupling capacitors, for example, for the ATmega1284p are typically 100nF, maybe an additional 1µF thrown in there too.

    You might also have a 10µF sat on the output of your boost converter or LDO!

    It occurred to me that all those capacitances are just energy stores that a powered-down microcontroller could be happily sipping.

    If it's powered-down state was low enough, say, less than 1µA...

    So long as the voltage this capacitance supplies doesn't fall below the microcontroller's minimum, well, why not make use of it?!

    But how to stop it from eventually falling below that minimum?

    Why, with some nanoamp-sipping intelligence to periodically measure the supply voltage available and recharge the capacitor(s) up again - but only when necessary!

    The charge level could then be configurably and/or programmatically set (even by the microcontroller itself!) and then this new supply voltage system - a sort of "Just-in-Time" Regulator - could be forgotten about when powered-down.

    And that's exactly what the video below demonstrates.

    There are no huge electrolytics hiding in there, just the ordinary capacitances associated with a regulator and decoupling.

    But you could, of course, add one if you wanted to extend maximum potential power-down period.

    I've set the "regulated" maximum and minimum to 5v and 1.8v respectively, and am using a switchable boost converter to get 5v from those two AA batteries - that's why the in-rush current is in mA.

    I'll update this log with more details about what's going on in the video, probably on Monday.

    But I've been able to successfully power additional nA circuitry, for example, custom battery measurementreal-time clocks and sensors from this just-in-time regulator (JiTR?) all without too much impact on the maximum potential power-down period.

    More details on all that soon!

    And again, thanks to various awesome Internet folk and resources including Nick GammonJean-Claude Wippler (JeeLabs)Charles Hallard (ch2i)Pascal Moreau (MySensors) and others - you all helped make this possible.

  • How Low Can It Go? Pro Mini XL and nA Power-Down

    Andy11/27/2020 at 18:17 0 comments


    I got the Pro Mini XL (v2) to power-down below 100nA and still wake up from an external interrupt - photos, video and code below.

    Your mileage may vary (YMMV) because the ATmega1284p is only spec-ed to power-down at 150nA from 1.8v in the datasheet, but here's the proof some of their chips can operate lower:

    In More Detail

    In the photo above the Pro Mini XL (v2) has been fused to run at 1 MHz with it's Brown-out Detection (BoD) turned off - allowing it to operate, seemingly happily from a fresh 1.5v AAA battery.

    The video below shows it first powering up, doing a bit of low-power housekeeping and then powering-down to less than 100nA:

    Board pin 2 (INT0) had been configured as an active-low wake-up interrupt and so when I ground it, you can see that the board springs to life again, before powering back down.

    The code (available here) would actually light the on-board LED if the forward voltage was high enough, sadly 1.5v won't cut it so it appears off.

    But the photos and video below shows the same board, same code just with a regulated 1.8v supply drawing roughly 1nA more whilst in power-down and the "proof-of-life" LED being lit (bottom corner) when it's awake.

    It's awake - honest!

    And by way of comparison at 3v, running directly from those two AA batteries, it just peaks over 100nA:

    Again, same board, same code - just varying the supply voltage:


    Thanks to various awesome Internet folk and resources including Nick GammonJean-Claude Wippler (JeeLabs)Charles Hallard (ch2i)Pascal Moreau (MySensors) and others, I've also been developing something that enables any Pro Mini to draw these few nA from an automatically topped-up "storage" - a sort of "just-in-time" regulator - cutting the power-down battery draw to basically zero.

    I'll write more about it soon, but here's a photo and video (to follow) to whet your appetite:

    Believe it or not, in the above photo, the board is actually in power-down and can happily remain there for a configurable amount of time.

    Again, same board, same code, but watch what happens when I trigger the interrupt...

    See the LED light up at the bottom corner of the board - it's alive!

    I'll update this log with more details soon!

  • No Pain, Just Memory Gain:Using the Pro Mini XL with The Things Network

    Andy07/04/2019 at 00:38 0 comments


    I got the Pro Mini XL working with the Arduino-LMIC library. It’s performing OTAA to The Things Network over LoRaWAN. And it’s reporting temperature and humidity measurements from an SI7021 sensor - with 80% program memory to spare!

    (Note: There’s no SI7021 sensor connected in the central photo - I added it in later when my extra female pin headers finally arrived!)

    In Brief

    I’ve been running out of memory.

    Whilst trying to develop/debug a Pro Mini 328P-based low-power temperature/humidity sensor node on The Things Network over LoRaWAN, I’ve been reaching the 32KB program memory limit and 2KB dynamic memory (SRAM) limit.

    Then it occurred to me.

    Why not test the pin-compatible, drop-in replacement benefit of the Pro Mini XL?

    Essentially, all I needed was more program memory and SRAM.

    So I updated the pin-mappings, replaced the 328P for the XL, recompiled.


    Everything just worked!

    And now my existing Arduino sketch was only using 20% of the program memory!

    Now to add more sensors: GPS. Altimeter. Barometer.

    Hmmm, what else could I fit, I wonder...?!

    Gettng Started

    I began tinkering with all things LoRaWAN back in 2016 during a commercial farm monitoring project.

    Farmer "Dave" needed to monitor the temperature and humidity of a 120+ acre farm.

    But it was approx. half an hour’s drive away from the main HQ.

    Initial research into low-power, long range radio transceivers led me to LoRa and LoRaWAN.

    I soon discovered that I had just missed out on a Kickstarter campaign for The Things Network (back in 2016), but I pre-ordered myself a Gateway, Node and Uno anyway.

    Whilst I waited for the official development devices to arrive, I did what any impatient "Tech Tinkerer" would do...

    I DIYed my own.

    Using a Raspberry Pi 2 and LoRa concentrator board for the gateway (more on that below!) and a nice supply of Pro Mini 328P clones with Hope RFM95 radio modules for the nodes, I was all set.

    So I set up a LoRaWAN system of solar/battery powered nodes and a gateway to provide the environment visibility Farmer "Dave" needed.

    All was ticking along nicely.

    Until one day a blaze of fire consumed one of the barns and almost all of the tech perched on top of it!  (Thankfully, no one was injured and the fire was contained quickly.)

    So I was invited back to upgrade and reinstall a new one.

    The (Main) Problem

    In a word: freezing.

    Farmer "Dave’s" farm sits at over 4,000 feet up in the mountains, so it gets cold.

    Very cold.

    Especially at night.

    It can get so cold that it will freeze the fruit buds when they’re just starting to emerge… and then that’s it.

    Your entire crop is gone - for another year!

    So how to stop the buds from freezing?

    You can only resort to defensive measures (e.g. water sprinklers, etc.) when you’re almost positive a freeze is imminent.

    That's because it might actually cost tens of thousands of dollars to do so.

    Especially in a state with severe drought like California.

    In a perfect world you would monitor as much about the local environment as possible to help you predict when freezing might occur.

    Temperature, humidity, altitude, barometric pressure, wind speed, etc. all play a factor to a greater or lesser degree.

    You might also want some sort of location information from a GPS perhaps, to tie all that environment information to a specific area.

    On large scale farming, you could get micro-climates specific to one area of a field that differ from another area - depending upon the geography and topology.

    However, using the Pro Mini 328P as the microcontroller for the LoRaWAN nodes had previously constrained the number of sensors I could comfortably hang off it.

    With only 32KB program memory, I ended up limiting myself to an SI7021 to monitor temperature and humidity.

    But now I was revisiting the problem with my freshly minted Pro Mini XLs.

    I wanted to see how easily I could...

    Read more »

  • Benefits or Limitations: The ATmega 328p Pro Mini

    Andy04/26/2019 at 11:33 0 comments

    "Any benefit can become a limitation."

    I’m sure you’re all pretty familiar with the ubiquitous Pro Mini.

    Or at least, this guy, his cheap (~$2) counterfeit cousin!

    Based around the ATmega 328p, the “trusty” Pro Mini quickly became a feature of many of my DIY electronic projects.

    There wasn’t a sensor or actuator I couldn’t connect to it via some sort of associated circuitry.

    And then there were the libraries!

    Awesome people around the world had written code to interact with almost anything and everything else.

    But that was sometimes where I would hit my first limitation.

    32KB Program Memory

    Over the years, feature-creep™ has resulted in some of my projects pushing the limits of the 328p’s 32KB program memory.

    For example, pan/tilt stepper solar-powered sun-tracking long-range wireless over-the-air programmable crop monitor...with camera and display anyone?!  ;p

    Once I started stacking libraries, adding features and increasing the number of external entities I was interacting with, my compiled code size (understandably) started to balloon.

    Sketches that would get too far above 90% of the program memory fell prey to memory leaks.

    Others would, of course, simply exceed the compiled 32KB limit altogether.

    At first, I would attempt to fix the memory leaks, then it was optimize the code, add #IFDEFs to debugging portions and finally play with compiler flags.

    If you’re wondering at this point whether all this effort was worth it, well, quite frankly so was I!

    Learning to write better code is great.

    But I could see the other members of the ATmega family of microcontrollers like the 2560, 1284p (and even the 644p) glittering off in the distance like so much fool’s gold.

    [To be continued with…]

    No Built-in Wireless

    The Need for Speed

    Running Out of GPIOs

    Fixed Pin Position Interfaces

    That Regulator & Power LED

    Why Pin-Compatible?

    Why Size-Compatible?

  • 32-Bit & Wireless: The Pro Mini nRF52​

    Andy04/25/2019 at 14:07 0 comments

    Above: Pro Mini nRF52 (right) shown next to a Pro Mini 328p clone (left).

    (Note: An early development Pro Mini nRF52 shown with edge SMA, through-hole and U.Fl antenna pads.)

    In the beginning

    Shortly after the Pro Mini XL was born, I could feel the 32-bit world calling with its technological siren song.

    Microcontrollers in this space boasted faster speeds, even more program memory, DMA, etc.

    All very enticing for solving my Pro Mini problems.

    One of the realizations I came to after creating the Pro Mini XL, was that I was obviously still board-stacking.

    Many of my more recent projects had gone wireless, especially in the area of Home Automation.

    I found myself adding nRF24s, RFM69s, 95s or RN2903s to get the range and/or protocols I needed.

    And then there was encryption, “uniquification”, and over-the-air updates.

    I had boards with ATSHAs, EUIs and additional SPI Flash amongst other things.

    Add power distribution, monitoring, battery charging and actuators and we’re already at a 5+ board stack!

    So I took the 32-bit world’s red pill (or rather “Blue Pill”) and began to explore.

    I decided to focus my initial efforts on 32-bit microcontrollers that had built-in radios that I was already using.

    This lead to the natural selection of Nordic’s nRF52832.


    The nRF52832 is a 64MHz ARM Cortex M4 CPU (with FPU), 512KB flash (!) and a built-in 2.4GHz transceiver.

    The transceiver also supported Bluetooth 5, Bluetooth Mesh and ANT - which all sounded interesting.

    Scratch one radio board from my stack.

    Just as interesting was 128-bit AES/ECB/CCM/AAR (for encryption), 64KB RAM and 32 configurable GPIOs.

    Scratch at least one more board from my stack.

    All of this board-scratching sent me ferritting about for how to best get my hands probes on one.

    What confronted me was a veritable sea of modules and dev. kits, many of which were breadboard hostile.

    Most of the modules I saw had castellated pads requiring mounting to another PCB before use in my stack.

    A Pro Mini-sized board only leaves approx. 13mm between the right and left hand side edge pins.

    Modules that had metal shielding (for FCC certification, etc.) were simply too wide.

    Did I care about metal shielding or FCC certification?  At this point, no - I just wanted something to play with.

    So all the modules were either too wide to fit between the pins or I was going to be looking at some sort of oversized mounting PCB with 2.54mm SMD pin headers.

    Other dev. boards in the line up that were 2.54mm pin-friendlies like Adafruit’s Bluefruit or SparkFun’s Dev. Board weren’t Pro Mini pin-compatible.

    They made up a sea of different pin-out and board layouts

    All-in-all, rather non-friendly to an 8-bit Pro Mini native seeking his fortune in the 32-bit land of opportunity!

    So, I decided to roll my own.


    Since the nRF52832 was available in a QFN-48 package, this gave me more routing room than the 1284p.

    But I’d never worked with a QFN package like that before and didn’t know whether my “skillz” were up to it.

    Not one to shy away from a challenge though, I sketched out Nordic’s reference circuit schematic and began.

    I opted for the extra DCDC componentry to enable some lower power operations for later experimentation.

    After a rough place-and-route, the essentials fit quite nicely between my self-imposed prison of Pro Mini pins.

    However, the question then became, what exactly to route out, and where to?

    SWD vs. FTDI

    First on the list were the SWD programming pins.

    I had very limited JTAG/SWD experience coming, as I did, from the FTDI-world of the 8-bit ATmega.

    So my first thought was whether there was some sort of half-way house to ease my transition.

    Nordic’s SDK for the nRF52832 described a bootloader that could update the firmware of the device via UART.

    That sounded ideal.

    The device simply needed to be “reset” into a state in which...

    Read more »

  • 8-Bit Bigger Brother: The ATmega 1284p Pro Mini XL​

    Andy04/25/2019 at 12:47 2 comments

    Above: Pro Mini XL (right) shown next to a Pro Mini 328p clone (left).

    (Note: An early development Pro Mini XL shown with ATmega 1284, without crystal osc. or reset switch.)

    In the beginning

    My first attempt at another Pro Mini became what I’ve come to call the “Pro Mini XL.”

    When compatibility is a key for ease of use, it makes sense to simply traverse a microcontroller family tree, if you can.

    The ATmega family members above the 328p that stood out to me were the 644p, 1284p and 2560.

    Upon initial investigation, the 2560 was immediately taken off the table.

    At 100 TQFP pins, it would simply never fit.

    A Pro Mini-sized board only leaves approx. 13mm between the right and left hand side edge pins.

    And even the smaller 64-pin QFN package of the 2561 at 9mm² would be too tight to route around.

    I didn’t want the extra expense of moving to a 4-layer board, mainly because I had a lot of 328p Pro Minis to replace.

    The 644p looked more promising in it’s 44-pin TQFP and QFN packages, but only when compared alone.

    For the same sized package (12mm² TQFP or 7mm² QFN), the 1284p was simply superior in every way.


    You can play your own game of 328p vs. 1284p spec sheet summary “Top Trumps” and note the differences.

    Those that mattered the most to me were:

    • 4x the Program Memory
      • 128KB vs. 32KB
    • 8x the SRAM
      • 16KB vs. 2KB
    • 4x the EEPROM
      • 4KB vs. 1KB
    • One extra UART
    • One extra 16-bit Timer

      Moving to a larger package, had the natural benefit of more programmable I/O pins to wiggle (32 vs 23).

      Upon further investigation, some other notable benefits that peaked my interest were:

      • One extra interrupt pin
      • Two extra analogue ports
      • JTAG interface

      And all this was purely additive to the 328p’s features (low power, PWM, WDT, QTouch, etc.) without forfeiting any of note.


      Would it fit?


      All this extra memory and added features came at a size cost.

      Or at least it did, way back when the 1284p was first released!

      Although my initial back-of-the-envelope calculations showed that 12mm TQFP pads would “likely” fit between approx. 15mm pin-to-pin through holes, the devil is (as always) in the details.

      You can see from the photo above that the 1284 in a TQFP is almost half the size of the whole PCB itself!

      Underneath that chip is a veritable spaghetti-junction of tracks and vias to try to route everything in and out.

      And I didn’t manage to route every pin.

      But even forfeiting as much as 8 pins (and some admittedly useful chip features) was still worth the benefits of extra program memory, etc. in my mind.

      I ended up having to stretch/bend/throw-up on some PCB design constraints that I usually set in stone.

      Things like routing into keep-out areas and on the outside of edge pins, just to name a few.

      I’ve not encountered any issues with “flexing” them yet though.

      Filtering caps should be much closer to the chip and I’d like more of them too.

      But, of course, the 800Lb gorilla in the room is the lack of an on-board regulator.

      I thought long and hard about this one whilst examining many of my existing project PCBs.

      In the majority of cases, I was handling project power elsewhere, usually in some sort of distribution board.

      Once a project had grown in size and scope, I rarely tapped anything off of the 328p Pro Mini’s regulator anymore.

      So, in the end, I bit-the-bullet and abandoned trying to fit one and the Pro Mini XL was born:


      • 8 unrouted pins.
        • 25, 26, 32, 33, 40, 41, 42, 43.
      • Compromised design constraints.
      • No on-board regulator.
      • Fewer filtering caps.


      Pad size is a problem; everything is much bigger than I think it needs to be.

      Decreasing TQFP pad size by half might enable me to get some more pins/tracks routed.

      The same goes for the crystal and reset switch.

      Better part selection might...

      Read more »

    View all 6 project logs

    Enjoy this project?



    electrobob wrote 05/10/2019 at 15:05 point

    Hello Andy. Good work here!

    I am (slowly) working on some HA things as well and went through some similar decisions and options as you did, so maybe it helps: 

    My experience is that best way is to have a sub GHz radio and a micro with sufficient memory so you can include a lot of things, even OTA bootloader. I set on the SAMD21 and RFM69 and is is working a lot better than the low power 2.4GHz radios. And quite few always on powered things I run on ESP8266/32. 

    Considering the NRF52 i found this project interesting 

      Are you sure? yes | no

    Andy wrote 05/14/2019 at 15:22 point

    Hi Bogdan,

    Thanks for liking and following!  And for pointing me at your 1000² HA project.

    I’m still reading my way through all your posts on it and doing so with interest.  I really appreciate how you’re walking the reader through your design decisions and hardware choices - definitely food for thought!

    Re: Sub GHz vs. 2.4GHz Radios

    I love the Hope RFMs, just wish they were size compatible with my Pro Mini footprint requirements...

    Where I currently live, the 2.4GHz band is pretty sparsely populated (for now!) and so interference isn’t an issue.  I just set my channel far enough away from anything else and I’m good to go.

    When I did some work on a farm project that needed a longer range, I used a whole bunch of RFM69HWs attached to an adapter board that plugged into my PCB stack.  You can see one hiding behind a stack of boards on this page with an edge SMA on the board adapter.

    I had thought about trying to build my own into a more convenient form factor, probably designed around the SX1231H - inspired by Felix’s attempt - but am trying to balance reward vs. effort.

    Re: LoRa Tooth Small Wireless Sensors Instructable

    Really enjoyed reading through Eric’s pages on this too.  I see he’s using the nRF51 though instead of the nRF52. I prefer the nRF52 personally - here’s Nordic’s post on the new features they added.

    The ones that swayed me were lower power (via DC-DC enabled), more RAM and a faster processor for only a marginal increase in price.

    How are you getting on with the SAMD21s?

      Are you sure? yes | no

    electrobob wrote 05/18/2019 at 19:00 point

    I am glad that for you that 2.4GHz is still good to use. I think in this case you can use the smaller radio modules or the NRF51/52 to get a compact solution. BTW, RFM69 also comes in the CW version which is smaller, but still not small enough. 

    Out of curiosity, why full size compatibility with arduino modules? There are designs with radio modules where they keep the pinout, but the headers might be further apart to accommodate the radio. See 

      Are you sure? yes | no

    Similar Projects

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates