Go Down

Topic: PB6 and PB7 as serial problem (Read 338 times) previous topic - next topic

anxietyscroll

Hello everyone. I'm having problems using PB6 and PB7 as digital IO for serial communication with my SIM800L GPRS module with my ATmega 328p. After doing some testing I've got this information: PB6 works as RX and TX. PB7 is unable to work as RX or TX neither. Serial communications work well using PB6 as RX and PD5 as TX or PD5 as RX and PB6 as TX. I want to ask if someone knows about this behavior and how could I fix it. For now, I'll patch it at the PCB.

This are my fuses configuration:
low_fuses=0xE2
high_fuses=0xDA
extended_fuses=0xFE

westfw

Pb6 and pb7 are normally connected to the crystal.  Are your fuses setting the chip to use the internal oscillator?  And is this custom-built hardware?

DrAzzy

#2
Sep 14, 2018, 09:16 pm Last Edit: Sep 14, 2018, 09:17 pm by DrAzzy
Yeah, he's using the internal oscillator, E2 is internal 8mhz. If he had it set to use a crystal, his board wouldn't be working at all

If it's not custom hardware, did you remove the crystal or resonator?

What core/board def are you using, and what software serial library?
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

anxietyscroll

#3
Sep 16, 2018, 04:01 pm Last Edit: Sep 16, 2018, 04:08 pm by anxietyscroll
What core/board def are you using, and what software serial library?
I'm using ATmega 328p from the "MiniCore" board package. I stopped using the arduino's core because I wasn't able to disable BOD whenever I set the fuses to OFF, maybe some bootloader overwrite.

Also, I'm using the standard software serial included with arduino, "SoftwareSerial.h (formerly NewSoftSerial.h)" but with a 256 bytes buffer (It should not be the problem :D)

Ah! I forgot to mention, I can use both pins for normal digital writes. Today I'll try digital reads, I think it is something related to internal pullups. BTW, if it is not that, I'll asume the pins are not able to change states fast enough to deliver serial communication. I wish I could try it at AVR Studio, but the learning curve is high enough to prefer modifying the PCB.

Also, is completely custom hardware, except for software :P

anxietyscroll

#4
Sep 16, 2018, 04:52 pm Last Edit: Sep 16, 2018, 06:05 pm by anxietyscroll
Update:
Using NeoSWserial give the following results: PB6 transmit, no receive. PB7 transmit, no receive.

Also, the digital input readings:
Code: [Select]


pin PB6 PB7
GND VCC UNCONN GND VCC UNCONN     

no internal 0 1    *RANDOM 0 1 *RANDOM
pull up

internal pull   0 1 1 0 1 1
up

*Strange thing is, when no pullup and unconnected, after feeding VCC to ports they remain for a while in HIGH (as expected), and then fall down to LOW, but, they don't start to read random HIGHs and LOWs, it is just like they where pulled down. If I do the same exercise on PB5 and PB4 I get the expected "random" HIGHs and LOWs. So, I think PB [6:7] are the best for wiring buttons xD (pun intended, unconnected pins are ALWAYS unpredictable).

jremington

Why do you care what is read by an unconnected input?

Everyone else connects inputs properly, using pullups or pulldowns, or active circuitry to define the voltage levels.

anxietyscroll

#6
Sep 16, 2018, 05:16 pm Last Edit: Sep 16, 2018, 05:23 pm by anxietyscroll
Why do you care what is read by an unconnected input?
When you experiment with something is necessary to test all possibilities. For example, if unconnected pins while not using pullup rose to HIGH would mean a problem on pin state behavior, so next check would be to test voltage on pins. Since there is no problem, I don't need to read them. That's how I sample some maybe-useful data and saved a couple of steps, the ones I spend writing this xD

Edit: It was also necessary to test internal pullups, and, well, there is only one way to test them, right?

Edit 2: I'm working with just an atmega 328 wired in a breadboard. Breadboard capacitance is assumed to do not interfere with serial communication (has demonstrated with serial in other pins)

jremington

#7
Sep 16, 2018, 05:21 pm Last Edit: Sep 16, 2018, 05:35 pm by jremington
Quote
When you experiment with something is necessary to test all possibilities.
That is impossible, because you can't control all the details.

What an unconnected pin sees depends on contaminants on the board, the IC package, the wiring or circuit traces, moisture, local electrostatic and electromagnetic fields, etc. and is different for every pin.

Connect your pins properly and verify proper operation under those circumstances.

As a general rule in working with ICs, unused pins should ALWAYS be properly terminated unless you are specifically directed to do otherwise by the manufacturer (and the pin will be marked NC).

anxietyscroll

#8
Sep 16, 2018, 05:47 pm Last Edit: Sep 16, 2018, 05:57 pm by anxietyscroll
That is impossible, because you can't control all the details.
No, it is possible as far as our knowledge can extend during experiment design.

What an unconnected pin sees depends on contaminants on the board, the IC package, the wiring or circuit traces, moisture, local electrostatic and electromagnetic fields, etc. and is different for every pin.
And this is why you test them in controlled arrangements to see if they behave as expected. An unconnected pin should behave as an unconnected one: unpredictable but not stable.

Connect your pins properly and verify proper operation under those circumstances.
Did you even read the other 2 tests, I mean, they where tested connected to VCC, GND through 330 ohm resistor.

As a general rule in working with ICs, unconnected pins must ALWAYS be properly terminated unless you are specifically directed to do otherwise by the manufacturer (and the pin will be marked NC).
"experiment explanation" again

In any way, I can't see how your discussion about why not to test an unconnected pin when testing unconnected pins is going to solve my serial comm problems. So I hope you have something valuable for this topic rather than trying to feel superior to other ones.

[Edit:] Tip: Go on and try using PB[6:7] for serial comm between two atmegas 328p by yourself, because I've tried with more than 3 different and the result is the same.

jremington

#9
Sep 16, 2018, 05:49 pm Last Edit: Sep 16, 2018, 06:35 pm by jremington
Quote
No, it is possible as far as our knowledge can extend during experiment design.
Please don't confuse other beginners with your inexperience.

Things tend to work if you follow the rules.

anxietyscroll

Please don't confuse other beginners with your inexperience.
I see, maybe you're going for the "buttons" sarcasm. I'll edit it, so any beginner will know it was a joke over an experiment. You know, there's always a beginner who gets confused why are they reading unconnected pins.

westfw

SoftwareSerial uses Pin Change Interrupts.   I suspect that those don't work correctly on PB6/PB7...
They're defined as D20 and D21, right?  And it looks like the PCxxx macros (in pins_arduino.h) have been updated to include pins up to 21, but I don't see any logic to force them back into PORTB (PCMSK0):



Code: [Select]
#define digitalPinToPCICR(p)    (((p) >= 0 && (p) <= 21) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 2 : (((p) <= 13) ? 0 : 1))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) (((p) <= 7) ? (p) : (((p) <= 13) ? ((p) - 8) : ((p) - 14)))

anxietyscroll

SoftwareSerial uses Pin Change Interrupts.   I suspect that those don't work correctly on PB6/PB7...
Ok, I'll check down how Interrupts behave at different frequency (IMO frequency is not a thing, because baudrate configuration isn't modifying result at all), maybe there is something I missed on the datasheet. I could check that port mapping macro or do it by hand just to be sure. Taking in account that the way pins behave is relative to library, it likely points to be a software-thing. I think NeoSWserial don't use pin interrupts, but I'm not sure, so I'll take some readings and post results. Thanks

This is my board pins macro (mostly the same):
Code: [Select]

#if !defined(__AVR_ATmega8__)
#define digitalPinToPCICR(p)    (((p) >= 0 && (p) <= 21) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 2 : (((p) <= 13) ? 0 : 1))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) (((p) <= 7) ? (p) : (((p) <= 13) ? ((p) - 8) : ((p) - 14)))
#endif

Go Up