[RESOLVED] Can SoftwareSerial work on an Atmega1284p ?

I found 4 old forum threads where people couldn't get any RX pin to work with SoftwareSerial on a 1284 chip. But each ended without finding a solution.

Now I'm having the same problem.

Has an answer ever been found?

Why do you want to use SoftwareSerial? It is one of the worst performing libraries around.

The 1284p has two serial ports. How many do you need?

jremington:
Why do you want to use SoftwareSerial?

It’s the only Serial software I know of for Arduino.
If you have a better software in mind, I’d like to try it.

jremington:
The 1284p has two serial ports. How many do you need?

I need three:

  1. To communicate with the laptop.
  2. To communicate with an onboard 328 AVR.
  3. To communicate with an FN-RM01 MP3 Audio Recorder and Player Module.

((The 328 AVR had been using SPI to communicate with the 1284p, but messed up when the LCD display and SD Card also needed the same SPI wires. I don’t know what that problem was with SPI, but I decided to move the 386 AVR from SPI to Serial communication. I did so because having 4 high-speed data components joined together on a single wire (times three wires) made it too hard to isolate problems. I wanted to make future service and repair easier by separating circuits.))

SoftwareSerial basically should work with 1284, maybe some little changes will be required in library. Did you tried it and what was the problem?
The solution could be also to use Arduino MEGA - ATmega2560 with 4 USARTs.

Budvar10: SoftwareSerial basically should work with 1284, ... what was the problem?

As with the other four threads I found about it on this forum (none of which came to a successful conclusion), the TX pin on the processor works fine, but the RX pin never sees anything.

Budvar10: The solution could be also to use Arduino MEGA - ATmega2560 with 4 USARTs.

I need to use the 1284p because it's a through-hole chip. The others you mentioned are surface-mount, which is too difficult a technique for our little in-home factory.

Firstly just note, there is relatively a new ATmega328PB version with 2 UARTs.

I’d never used SoftwareSerial but 1284P has pin change interrupt (which is used in lib, after brief look into) on all its pins so basically should work. I don’t see any problem in theory. The problem could be in your pin configuration depending on which variant you are using. There is several variants on web (Mighty, Bobuino, I have self…) but none of them is ‘official’ Arduino. Possible reasons I see in pin numbering or interrupt numbering mismatch. I am recommending to focus on digitalPinToPort and digitalPinToBitMask macros which depend on mentioned variant pin and interrupt numbering.

I'm pretty familiar with SoftwareSerial but don't have any direct experience with the 1284. I think Budvar's suggestion is slightly off. The digitalPinToPort and digitalPinToBitMask macros are probably fine since the TX side is working. I would look closely at the macros that convert the pin to the PCICR register and mask: digitalPinToPCICR, digitalPinToPCICRbit, digitalPinToPCMSK and digitalPinToPCMSKbit. If those aren't configured correctly your pin will receive but will never generate an interrupt.

Or maybe it's something else. But it should work in theory. A debugging strategy would be to try and use those macros in the same way as SoftwareSerial does and see if you can generate an interrupt by manually toggling the pin. If not, read and print out the contents of the various registers and see what's what.

Which pins have you tried? Which physical pins do those correspond to? Which core variant are you using?

SoftwareSerial does suck. While receiving data your processor will be doing almost nothing else. Hope you don't need it to do more than one thing at that time. There are better alternatives but if SoftwareSerial doesn't work they probably won't either.

Keep it in hardware - use I2C to talk to the '328P.

Wow! Thanks for the multiple answers, guys. :)

I GOT IT TO WORK NOW!

The suggestion:

Budvar10: The problem could be in your pin configuration ... in pin numbering or interrupt numbering mismatch

gave me the idea that maybe SoftwareSerial was confused about pin numbers, so since pin 15 is my non-responsive RX pin, I added the line pinMode(15, INPUT); to setup(); And that did the trick. (I then took the line out, tried it, put the line back, tried it, just to be sure that was really the fix, and it was.)

But as CrossRoads said, I'd rather "keep it in hardware". So now I'm going to look up what "i2c" is all about, and maybe switch to that. (Always something new to learn.)

PS-- I'm using "maniacbug" Mighty 1284p, in case that's also a necessity.

I've now corrected my "i2c" spelling above, as CrossRoads states I should in the next comment.)

i 2 c, not 1 2 C

Glad you got it to work but your solution leaves the puzzle unresolved.

You added

pinMode(rx, INPUT)

SoftwareSerial does this:

pinMode(rx, INPUT); digitalWrite(rx, HIGH);

That's effectively the same as:

pinMode(rx, INPUT_PULLUP);

So either the digitalWrite(rx, HIGH) somehow doesn't work correctly or else your serial connection isn't happy about the internal pullup being enabled.

Would you mind trying this?

pinMode(15, INPUT_PULLUP);

I made the change as you asked. It works fine with the more correct:

pinMode(15, INPUT_PULLUP);

I know it's resolved as far as you're concerned, but would you humor me and do one last test?

pinMode(15, INPUT); digitalWrite(15, HIGH);

Budvar10: Firstly just note, there is relatively a new ATmega328PB version with 2 UARTs.

Wow thank you! The chip is even cheaper than the 328p-au and pin compatible. A GND and VCC are replaced by two I/O pins that are also doing a second I2C. Also the ADC6 and 7 are now part of the new port E with digital I/O functions and are part of SPI1. Now I can run slow devices like RTC on one I2C and faster ones on the other.

I saw something about the ATmega328PB but then skipped over it, which I should not have since they added some timers as well as the second USART/I2C. So now it has three hardware capture pins ICP1, ICP3, ICP4 (timer3 and timer4 are the 16 bit new ones). I wish they added some SRAM, but maybe we will see 648PB and 1288PB soon.

Thread on the 328PB: http://forum.arduino.cc/index.php?topic=344016.0

No IDE support. Also no compiler support. So accessing the extra hardware isn't as straightforward.

So what if I wanted to use the PB as a P because it's cheaper? I know the signatures are different but can't I just use Nick's hex sd loader to load the code? I am assuming the 328P hex is the same as 328PB so I'll just compile it for a 328P.

Here is a .pdf file about how to use the xplained dev board on arduino IDE. It seems that you just need to install arduino bootloader and pretend you're using arduino Nano. I don't understand why they didn't mention signature difference.

https://spaces.atmel.com/gf/project/avr_xp_mini/frs/?action=FrsReleaseBrowse&frs_package_id=140 Sorry about the intrusion. I'll start a different thread.

jboyton: ... do one last test?

pinMode(15, INPUT); digitalWrite(15, HIGH);

Yes, this works also. For verification, I removed both lines, and it didn't work again.

Thanks for trying it.

It's weird. Adding the lines that are already in SoftwareSerial makes it work. That's not the kind of solution I'd be happy with. It would bug me.

Oh well, maybe the next guy who can't get SoftwareSerial to work on the 1284 will figure it out.

OP,

Sorry for intruding on your post. My speculation: the software serial library didn't map the pin correctly when it sets the pin to input. Is this possible? Can you add code to software serial to print out all port and pin values of all pins just to check against the manicbug mapping? I'm using bobuino mapping. I'll do this when I get time and post how I print them out.