Close
0%
0%

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
Starting from
$12.50
EtPlures has 4 orders / 0 reviews
Ships from Cambridge, GB
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!

  • Benefits or Limitations: The ATmega 328p Pro Mini

    Andy04/26/2019 at 11:33 0 comments

    "Any benefit can become a limitation."
                                                       (Anonymous)

    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!

    [Insert photo]

    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.

    Benefits

    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.

    Limitations

    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.

    ... 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.

    Benefits

    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.

      But.

      Would it fit?

      Limitations

      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:

      Summary

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

      Improvements

      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 3 project logs

    Enjoy this project?

    Share

    Discussions

    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: http://www.electrobob.com/1000-1000-hardware/ 

    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 https://www.instructables.com/id/LoRa-Tooth-Small-Wireless-Sensors/ 

      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 http://www.anarduino.com/miniwireless/ 

      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