Can I use Software Serial on pins 0 and 1?

Hi, I made a pcb and made some mistakes :confused:
My board has a Dfplayer to play musics. The pcb has an Atmega328p where I use all pins to do the board logic and I’m using pins 0 and 1 to talk to the DfPlayer, because the communication with the Dfplayer needs a simple serial connection.
Ok, the big mistake is that I connected the Rx pin on the 328p (arduino pin 0) to the Rx pin in the Dfplayer. The correct way is to connect Tx-Rx. The same goes to the Tx pins.

So I tried to use a Software Serial in pins 0 and 1, instead of the hardware “Serial”, and I changed the pins order, so pin0 should be Tx and pin1 Rx. If this is a valid solution then I don’t need to change the pcb.

I’m still debugging, but it’s still not working.

So, someone knows if I can use a Software Serial on pins 0 and 1 and in the inverted order (pin0 Tx and pin1 Rx)?

The code snippet related to this solution is something like that:

  SoftwareSerial mySoftwareSerial(1, 0); // RX, TX
  pinMode(0, OUTPUT);
  pinMode(1, INPUT);
  mySoftwareSerial.begin(9600);

  if (!myDFPlayer.begin(mySoftwareSerial)) {  //Use softwareSerial to communicate with mp3.

Thanks…

You should be able to, in theory. You can configure pins 0 and 1 as general purpose digital input/output. But the bootloader may mess with the hardware serial port and leave it enabled so it conflicts, just a guess... but it would be good to test it independently from the DF Player to make sure there isn't something bad on that end.

Now, by "it's not working", exactly what are you seeing? It being a prototype, the troubleshooting is more global.

And, of course, you can not use Serial... since it will define it the other way around. This means not debugging serial output...

Despite what aarg says, the short answer is no and the long answer is that it is the dumbest move you can ever make. But the pins are yours, and I guess your get out of jail free card is to rewrite your programme to use pins 0,1 as they were intended - hardware serial - and then put jumpers on the PCB.

Hi, thanks for the reply.

Nick_Pyner, could you be more specific? Why it’s the dumbest move and the answer is no? Can’t we change the mode for pins 0 and 1?
Like I said, I’m trying this solution to use the pcb as is, otherwise I need to put jumpers on the pcb, like you said.

I don't think it is a goer. Using software serial on the hardware serial pins is a seriously bad idea, and totally unnecessary. It is also surprisingly common and, if there was a way around it, I guess it would be common knowledge by now. I recognise that this is not the real mistake, and I was actually wrong to say it is the dumbest move you can make.

If possible, I would cut the traces and solder some thin wire to correct the mistake.

When I was still designing hardware, that was what was done with pre-production boards.

Alternatively you can lift the pins of the 328P and solder wires on them.

I did some testing here with an Arduino board and a DfPlayer and we can use a Software Serial on pins 0 and 1 and in the inverted order. No problem.

But it’s not working on my custom Pcb. I did some basic testing, only printing something to a software serial and the serial window only prints garbage. Something is off.
I’m using an external clock, so maybe something is wrong on that front? I remember changing the bootloader and fuses to use an external clock. I’ll check it again.
Any ideas are welcome.

Thanks…

Sorry, the reason of the garbage problem was that I chose the normal Uno board, but I need to choose a new board I created to set the correct clock I'm using, like the line below:

newboard.build.f_cpu=11289600L

The normal frequency for Uno is:

uno.build.f_cpu=16000000L

Ok, Now I can debug and I can see that the Dfplayer is not starting correctly. I need to find out why.
Till the next chapter.

Nick_Pyner:
Despite what aarg says, the short answer is no and the long answer is that it is the dumbest move you can ever make. But the pins are yours, and I guess your get out of jail free card is to rewrite your programme to use pins 0,1 as they were intended - hardware serial - and then put jumpers on the PCB.

Ok, I admit I didn’t research this because normally it wouldn’t make sense to do it, but isn’t the question of whether it’s a good idea different than the question of whether it actually works or not? Why would it not work? Does the software serial library intercept and/or prohibit it actively?

Oh, wait, I just saw reply #7

aarg:
Ok, I admit I didn't research this because normally it wouldn't make sense to do it

l'm sure you are dead right about that.... I believe the evidence is in - it is a recipe for disaster. If OP actually suceeded, which everybody else has good reason to doubt, it will be a first, but probably of minor and short-lived significance. But who would ever know what is really going on here? If this circus was ever going to go round, one would expect it to be on a custom PCB, not the other way round, but apparently not....

Nick_Pyner:
l'm sure you are dead right about that.... I believe the evidence is in - it is a recipe for disaster. If OP actually suceeded, which everybody else has good reason to doubt, it will be a first, but probably of minor and short-lived significance. But who would ever know what is really going on here? If this circus was ever going to go round, one would expect it to be on a custom PCB, not the other way round, but apparently not....

Sorry, it makes no sense to me in this context.
Again, I'm trying to use a Software Serial this way because I'm doing a personal project and I swapped some pins on the Pcb, so I'm trying to be pragmatic and finish the project and learn some new tricks on the process. I have 20 boards here, so I want a software fix instead of soldering 20 pcbs to swap the pins. But this is not something you should do in a real project in your job. This is a personal project I'm doing for fun.

Ignore the boomers.

Short of re-ordering a new set of PCBs, if it can be done in software, that's the route I'd go too.

Well, I am pre-boomer, so I will sit back, suitably ignored, and await results with only faint interest. I might point out that hrz.. doesn't actually say it can be solved in software, only that it would be a good idea if, which is the bleeding obvious and about the most useless answer you will ever get. I might also point out that the (inevitable) grief incurred by using software serial on hardware serial pins doesn't necessarily materialise immediately. I have no idea why, but it might be something worth researching sooner rather than later. It is also faintly possible that this explains why you had "no problem" before.

One thing you can be sure of is that fixing a mistake like this doesn't get any easier even if you are just doing it for fun. The problem is the same, and the fun is likely to run out when you still have 19 boards to go.

Since you are using a 328P, you may be programming it elsewhere, which means you may not have, and surely don't need, an on-board UART. This might put you at an advantage, but I am just guessing, not encouraging.

We all have made mistakes like that.

Make another board, with the pins correctly chosen and routed, and chalk it up to experience.

Software Serial is by far the worst performing of the approximately four options.

Thanks for the answers.

I have an working version now. I was facing two problems.

The first one is that I was using two software serials, one for debugging and another for the communication with the Dfplayer, but seems that we can only have one software serial. The first one you use works fine, but the second one doesn't work. I need more testing on this front.

The second, and main problem, is that the Dfplayers aren't working (haha). Before I assembled this Pcb, I was testing in a protoboard, and the Dfplayer I was using in the protoboard is working fine. So I bought a lot of 50 new units of Dfplayers, but for some reason they aren't working like the previous one. I exchanged the working Dfplayer in the protoboard with a new one, and it doesn't work! I tested four units and all four doesn't work.
So I soldered on the Pcb the working unit and now it's working on the final Pcb with the software serial on pins 0 and 1 in the inverted order.

Now I need to find out why this new lot of Dfplayer aren't working. Maybe it's a new version and I need to do something else in the software.

To me all Dfplayers should work the same way, so I was not suspecting this was the problem at the first place. Took me hours to narrow down this problem.

we can only have one software serial.

You forgot to check the documentation. Only one instance of Software Serial can be receiving at any time.

jremington:
You forgot to check the documentation. Only one instance of Software Serial can be receiving at any time.

Yeah, but the main problem was the defective Dfplayer unit. I put this second software serial to debug the first problem, but it inserted a new layer of bug.
I'm searching for information and I've found some pages relating problems with Dfplayers. Seems I got unlucky with this lot. I hope I can use some among these 50 units. :confused:

I think I found the problem. In the protoboard I was putting a 10k resistor in series with the RX/TX pins to remove the noise. The 10K resistor worked and it removed all the noise. I remember that I tested with a 1K resistor in the beggining and it removed like 95% of the noise, so I tested with 10K and kept the 10K.

In the Pcb I was using a 1K resistor to play safe, but it was not working (the problem I related).

Now I was testing in the protoboard and no unit was working, only the original one, like I related in my previous messages. I thought all units from this lot was bad, because I tested eight and all of them didn’t work.

So I bypassed the 10K resistor and plugged the RX/TX pins directly and the units started to work! I tested all eight again and six are working and two are bad, including the one solded in the Pcb in the beggining.

So I was unlucky to chose a bad unit in the first place :confused:
And 10K seems to work with some units, but none from this lot I bought.

So now I can continue on the project.

Hope this help someone in the future.

Thanks

I think I found the problem. In the protoboard I was putting a 10k resistor in series with the RX/TX pins to remove the noise.

In reply #1, I asked "what are you seeing". I feel you should have mentioned this right away. Do you have adequate and correct supply voltage bypassing on your board? Good ground plane, star grounding topology?