Has anyone tried the AtMega328PB on a Moteino board?

[TomWS]

A quick glance makes one think this could be a drop-in replacement for the AtMega328P and with:

• Lower Cost ($1 cheaper at Mouser in low qty)
• 3 Two more timers
• one more SPI
• One more UART
• One more I2C
• Four more PWM channels
• plus PTC (Peripheral Touch Control)

it sure looks like a BIG improvement over the 328P!

Tom

[kobuki]

But to start contributing something to your <strict subject>, please look at this thread and awe at my mad Google skillz (I'm suggesting a sudden shot at mr.
Crackn's posts). 1 minute search revealed that it's sadly not a drop-in replacement, as far as the Arduino platform is concerned. Actually I wanted to post it earlier when I found it but something came and I forgot to post.

[TomWS]

But to start contributing something to your <strict subject>, please look at this thread and awe at my mad Google skillz (I'm suggesting a sudden shot at mr.
Crackn's posts). 1 minute search revealed that it's sadly not a drop-in replacement, as far as the Arduino platform is concerned. Actually I wanted to post it earlier when I found it but something came and I forgot to post.

You're right, Mr. Crackn's post seems to indicate that it wouldn't be a drop-in without change.  Thanks.

To use it on an R4 with existing libraries, some changes will be needed (I forgot about chip-id impacts). However, the question still stands.  Has anyone tried it and, if so, what changes are necessary?

Tom

[TomWS]

From a hardware perspective, the Moteino R4 PCB could be used as-is as long as PE0 and PE1 remain unconfigured (these conflict with GND and VCC respectively). This means that I2C #1 wouldn't be available, but, to my mind, this was the least of the value add to the 328PB anyway.  There will need to be some updates to configuration files and I'll research and enumerate these soon (if someone else doesn't get to it sooner).

I suspect that, while the chip-id may 'break' everything, there are probably simple workarounds to get existing libraries working without change (by mapping __AVR_ATmega328PB__ into __AVR_ATmega328P__, at least temporarily).

avr_dude uses a config file that should be easy to update (although I haven't looked at the specifics yet).

Net:  I think this is possible and very worth pursuing.

Tom

[OSBSS]

Has there been any update on this? I think this new chip has potential if it isn't too much of an effort to rewrite existing libraries. the price is also very appealing.

[joelucid]

I had ordered a couple of 328pb a couple months back. Today I flashed one with my boot loader and soldered it with a si7021 and a rfm69cw onto a TH Mote board. I loaded the existing firmware onto it and it worked right away, reporting temp and H nicely.

The only thing I needed to do was to specify -F with the avrdude command line when burning the bootloader to force it to proceed without chip id test. This doesn't say very much about how compatible the chip is with the 328p binary Arduino universe at large, but I was surprised how easy it went.

Since the chip is so much cheaper I expect to use it by default going forward. I did notice one issue: power save mode with 32.7k clock XTAL at 3V uses 1.3uA on the 328pb vs 0.9uA on the 328p. That's quite a regression  - so if frequency hopping is a must the ab1815 should be considered for low power applications.

Joe

[TomWS]

The only thing I needed to do was to specify -F with the avrdude command line when burning the bootloader to force it to proceed without chip id test. This doesn't say very much about how compatible the chip is with the 328p binary Arduino universe at large, but I was surprised how easy it went.

The chip id should be different because it is a different chip with some pins changed from the P version.  What is wrong is that the Arduino IDE is unable to be easily adapted to a new chip ID as a 'clone' of the P.  The PB version has been around for almost (more?) than a year and we still don't have specific IDE support.

Tom

[joelucid]

There are packages to add 328pb support to Arduino - https://github.com/amoehl/uino-atmega328pb for example. But as first step I wanted to see whether it worked as drop in replacement for the 328p. Which it does for my th mote modulo the chip id issue. More to come.

[joelucid]

I found that the current platformio arduino package already includes the 328pb files for the toolchain. However their SPI library then doesn't compile. But use the SPI / Wire libraries at https://github.com/watterott/ATmega328PB-Testing instead and everything builds and runs fine. This package also includes support for Wire2 / SPI2.

I suspect just adding the package https://github.com/watterott/ATmega328PB-Testing to Arduino > 1.6.10+ would likely also work, but I haven't tried that.

Some minor mods in LowPower.* were needed. All in all not too difficult to get to work, but not quite seamless either.

Joe

[Felix]

Thank you all for being persistent with the PB, I am watching this space with interest.

[SadE54]

I'm currently designing a node with it but I hust saw that :
"
0 - 4MHz @ 1.8 - 5.5V
– 0 - 10MHz @ 2.7 - 5.5.V
– 0 - 20MHz @ 4.5 - 5.5V"


It's the same specs than the 328P but does this one is running as well as the P at this speed ?

[james_s]

Apologies for necromancing an old thread here but this kept coming up in my google searches on the topic.

I built my own Moteino R6 (thank you for open sourcing this cool design!) and realized after I had assembled it that I had accidentally gotten m328pb chips instead of the more common m328p. So I figured I'd just build it up anyway and that the 328pb should work as a standard 328p, unfortunately that does not seem to be the case for me. I try to send it a sketch and the IDE just sits there and then eventually times out.

I used my STK500 to load 'DualOptiboot_V5.0_atmega328_BlinkD9.hex' onto the AVR and then used the following fuse settings:

low_fuses=0xDE
high_fuses=0xDC
extended_fuses=0xFD
lock_bits=0xCF

I have verified that I have +3.3V on Vcc and I scoped the clock pins and see a 16MHz signal. I verified that the tx and rx header pins are electrically connected to the corresponding pins on the AVR, the Reset pin is pulled up via 10k and there is 0.1uF measured between Vcc and Rst. Is there something I'm missing? Maybe I need different fuse settings to make the 328pb work? At the moment I don't care about any of the enhancements, if it works as a standard 328p I'll be happy.

[TomWS]

You need to create a new boards.txt entry for the PB version because it has a different chipid than the common 328p.  This will allow you to use the PB as if its a 328P.  It won't provide support for the additional peripherals (one of which conflicts with a 328P power pin IIRC).

[james_s]

I figured it out, I had used a 0.1uf cap where it needed a 1uF on the DTR line. I ended up removing the delay cap on this one and just leaving the 0.1 and now it works fine.

I don't need the additional features offered by the 328pb, I'm happy just to have it working as a standard 328. I'll order some 1uF caps next time and build a batch properly.