void SoftwareSerial::setRX(uint8_t rx)
{
pinMode(rx, INPUT);
if (!_inverse_logic)
digitalWrite(rx, HIGH); // pullup for normal logic!
_receivePin = rx;
_receiveBitMask = digitalPinToBitMask(rx);
uint8_t port = digitalPinToPort(rx);
_receivePortRegister = portInputRegister(port);
}
The begin method calls this function. So if pinMode and digitalWrite both map the wrong pin, then you are out of luck. But that is impossible. You used these functions to fix the problem. I'll look further. Meanwhile, can you post your code?
jboyton:
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.
Well, in other areas beyond SoftwareSerial, I've had to carefully arrange the order of initializing things in setup(), or some won't work. That should not be happening, libraries and instances are supposedly independent.
So I figure it's the ORDER in which your SoftwareSerial lines are being called that makes the difference; another example of what I just explained about initializing things in Setup().
liudr:
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?
Some weeks back, I created a sketch that let me turn each of the 1284p pins positive and negative one at a time (and print the active pin number in the Monitor window). I then checked each pin with a scope, verifying it against the number in the window. All pins were correct.
liudr:
...can you post your code?
Can't share. My sketch is currently 3440 lines long, and wouldn't run without the peripherals I have attached to the processor. And shortening the sketch to fit your needs would defeat the purpose of learning what's really going on. (sorry)
CrossRoads:
Keep it in hardware - use I2C to talk to the '328P.
I want to give you heart-felt thanks once again. First, you told me about the 1284p, which changed my whole world, no longer stuck with a group of 328p's, enabling my project to expand in ways never thought possible.
Now you tell me about i2c, when I thought spi and serial were the only hardware data lines available. I have now implemented i2c, and it works wonderfully!
Do you have any more of these astonishing secrets I would never dream existed if not for you?
CosmickGold:
Well, in other areas beyond SoftwareSerial, I've had to carefully arrange the order of initializing things in setup(), or some won't work. That should not be happening, libraries and instances are supposedly independent.
So I figure it's the ORDER in which your SoftwareSerial lines are being called that makes the difference; another example of what I just explained about initializing things in Setup().
Some weeks back, I created a sketch that let me turn each of the 1284p pins positive and negative one at a time (and print the active pin number in the Monitor window). I then checked each pin with a scope, verifying it against the number in the window. All pins were correct.
The order shouldn't matter with pinMode. If you set a pin to INPUT now or later it will be INPUT, regardless of what you do with any other pins.... provided you aren't overriding the pin in question with an alternate pin AVR feature (e.g. SPI). The one-at-a-time testing of pins you described wouldn't expose a dependence on order of initialization.
There's something fishy. Either the 1284 core has an odd bug with regard to how pinMode works or else you're doing something unkosher in your code. Given that there have been past reports of SoftwareSerial issues with the 1284 it's hard to ignore the possibility of the former. But since we can't see any part of your sketch it's also tempting to suspect the latter.
Like I said, if it were my project I'd keep looking, partly out of curiosity and stubbornness and partly out of concern that whatever was going on might reemerge later.
I follow this threat and I can't see the solution. I have am atemga1284p-au and I have problems with the SerialSoftware library.
What's the solution?
Regards
The solution I was referring to, was to use i2c instead of Software Serial to make that final data connection. i2c has been working perfectly for me, and it's already built into the ATmega chips.
CrossRoads:
Keep it in hardware - use I2C to talk to the '328P.