PDA

View Full Version : serin2/serout2



tazntex
- 19th September 2008, 18:46
Just a quick question, using a 16F628A, does it make any difference which pin I use on porta or portb and on pin porta.4 would there be any issues using it for serin? Thanks

skimask
- 19th September 2008, 18:50
Just a quick question, using a 16F628A, does it make any difference which pin I use on porta or portb and on pin porta.4 would there be any issues using it for serin? Thanks
Doesn't make much of a difference....but it could.
Some pins are TTL, some are schmidt trigger inputs...if your voltages are marginal, some pins might respond while others don't.
All pins are CMOS outputs, except RA.4 which is an open-drain, which could be an advantage in some situations.
Info on this is in the Electrical Specification section of the datasheet.

tazntex
- 19th September 2008, 19:05
Thanks Skimask, the reason why I ask is that I was using ra.3 as serout and all was well and great. After reading the datasheet and seeing that if I later decided to use the usart I would need to use portb.2. Once I changed the pins this morning not it constantly transmits. I haven't changed anything, but portb.2 was an input and porta.3 the output. Once I switch back all is good.

skimask
- 19th September 2008, 19:14
After reading the datasheet and seeing that if I later decided to use the usart I would need to use portb.2. Once I changed the pins this morning not it constantly transmits. I haven't changed anything, but portb.2 was an input and porta.3 the output. Once I switch back all is good.

So, you tried to use PortB.2 for SEROUT and it didn't work? Went back to A.3 and it was working again?
One sentence up there doesn't quite make sense...
- Once I changed the pins this morning not it constantly transmits -
Could you rephrase that a bit? Doesn't quite add up...

tazntex
- 19th September 2008, 19:38
Ok, I have been using porta.3 as my serial out and portb.2 was an input from a switch,when the switch was on data was sent out porta.3. I swapped these two and change serial out portb.2 and connected my switch to porta.3. I changed trisa and trisb to along with my variable. Once I did this, as soon as the pic is powered up portb.2 sends data out forever.
I removed everything from the program with the exception of serout label. It still transmits. That was why I asked whether or not certain pins could not be used or used without adding something to the circuit. Thanks again Skimask, hopefully I am making some sense.

skimask
- 19th September 2008, 19:44
Ok, I have been using porta.3 as my serial out and portb.2 was an input from a switch,when the switch was on data was sent out porta.3. I swapped these two and change serial out portb.2 and connected my switch to porta.3. I changed trisa and trisb to along with my variable. Once I did this, as soon as the pic is powered up portb.2 sends data out forever.
I removed everything from the program with the exception of serout label. It still transmits. That was why I asked whether or not certain pins could not be used or used without adding something to the circuit. Thanks again Skimask, hopefully I am making some sense.

Ok, that makes a bit more sense.
Did you do anything else to PortA.3 to make it work for you?
Anything at all?

tazntex
- 19th September 2008, 19:45
No, nothing at all.

skimask
- 19th September 2008, 19:50
No, nothing at all.

Nothing special about PortA.3 that doesn't apply to PortB.2, nothing at all?
http://www.picbasic.co.uk/forum/showthread.php?t=561

tazntex
- 19th September 2008, 19:58
I have CMCON=%00000111 using porta.3 as serial input and it is working but when I swapped serial in to portb.2 and the switch to porta.3 thats where the trouble began. I have not changed CMCON=%00000111 at all just the tris for in/outputs, hmmm....and the switch when on goes to ground when closed and pulled high externally when open, that way the processor knows the switch is on or off.

skimask
- 19th September 2008, 20:01
I have CMCON=%00000111 using porta.3 as serial input and it is working but when I swapped serial in to portb.2 and the switch to porta.3 thats where the trouble began. I have not changed CMCON=%00000111 at all just the tris for in/outputs, hmmm....and the switch when on goes to ground when closed and pulled high externally when open, that way the processor knows the switch is on or off.

Ok, that's what I was getting at...the CMCON thing.
Post your code... I can guess all day...but quite frankly, I'm not going to.
And if you'll notice PortA.3 is a ST type input, whereas PortB.2 is a TTL input (I might have that backwards). So, it's possible that your voltage coming from the switch is marginal. It'll trip the one pin into the other state, but not the other pin.

tazntex
- 19th September 2008, 20:21
INCLUDE "MODEDEFS.BAS"
@ DEVICE PIC16F628a,XT_OSC
@ DEVICE pic16F628a, WDT_OFF
@ DEVICE pic16F628a, PWRT_ON
@ DEVICE pic16F628a, MCLR_ON
@ DEVICE pic16F628a, BOD_ON
@ DEVICE pic16F628a, LVP_OFF
@ DEVICE pic16F628a, CPD_OFF
@ DEVICE pic16F628a, PROTECT_OFF
define osc 4
CMCON=%00000111
trisb = %11111011
trisa = %00011111
serpin var portb.2
nokey con %11111111
synch con 254
address con %1010101010101010
address1 con %1010101010101010
tx var byte
keyin var portb
keydata var byte
E VAR PORTB.0
D VAR PORTB.1
G VAR PORTA.3
A VAR PORTB.3
B VAR PORTB.4
C VAR PORTB.5
F VAR PORTB.6
na VAR PORTB.7
PreAmble CON $A5

Initialize:
keydata = %00000000
tx = 0
repeat
serout2 serpin,16572,[$AA,$AA,$AA,$AA,$AA,$AA,synch,address,address1,_
keydata,keydata]
tx = tx + 1
until tx > 120 || keyin != nokey
goto findkey
findkey:
if keyin != nokey then pressed
goto findkey
pressed:

if A = 0 then
keydata.3 = 1
else
keydata.3 = 0
endif

if B = 0 then
keydata.4 = 1
else
keydata.4 = 0
endif

if C = 0 then
keydata.5 = 1
else
keydata.5 = 0
endif

if D = 0 then
keydata.1 = 1
else
keydata.1 = 0
endif

if E = 0 then
keydata.0 = 1
else
keydata.0 = 0
endif


if F = 0 then
keydata.6 = 1
else
keydata.6 = 0
endif


if G = 0 then
keydata.2 = 1
else
keydata.2 = 0
endif
gosub transmit
goto findkey
end ' IS THIS NECESSARY??????????
transmit:
serout2 serpin,16572,[$AA,$AA,$AA,$AA,$AA,$AA,synch,address,address1,_
keydata,keydata]
return

skimask
- 19th September 2008, 21:20
Looks like a lot more switches than just PortB.3...

tazntex
- 19th September 2008, 21:38
yes, you are correct but when I deleted them all but that one for testing, well you understand. Anyhow I am back to the original will porta serpin and the switch on portb, all seems well, BTW, about using MCLR and WDT when I set the config bits, other than the PBP manual that basically says to pull the MCLR high with a 4.7k what determines when to use it and I read here on the form PBP by default keeps clearing the watchdog, but also when should I be using that. Skimask, please don't say read the manual because page 8 says in general it should be on. I would like to know where I can find more specifics.

Thanks for your help and time Skimask

skimask
- 19th September 2008, 21:45
yes, you are correct but when I deleted them all but that one for testing, well you understand. Anyhow I am back to the original will porta serpin and the switch on portb, all seems well, BTW, about using MCLR and WDT when I set the config bits, other than the PBP manual that basically says to pull the MCLR high with a 4.7k what determines when to use it and I read here on the form PBP by default keeps clearing the watchdog, but also when should I be using that. Skimask, please don't say read the manual because page 8 says in general it should be on. I would like to know where I can find more specifics.


I will say read the manual...and the PIC datasheet.
PBP clears the WDT by inserting CLEARWDT instructions at strategic points in the code (i.e. whenever it can).
The watchdog timer is for code that 'runs off by itself'. If the code gets stuck in a loop that doesn't have a CLEARWDT timer command, it'll get stuck by itself doing nothing.
If you've got a WDT, after X seconds, the PIC will reset itself and at least do something.
MCLR - turn it off if you want another pin, simple as that.

tazntex
- 19th September 2008, 22:01
LOL, I was expecting that, Thank you again for clearing that question up for me. I sure hope that by now you realize that I do read the manual and the datasheet and google etc.., maybe I don't understand what I have read, but a lot of us here are learning from scratch and not someone that says "just give me the code". again, thank you