16F877a portb.0.1.2.3

is it true that these pins cant be put high or cant be put low?

Do i need a resistance to ground or ro VDD to be able to use them in 2 ways??

Regards,

Tks

PORTB is a standard 8bit Bidirectional TTL compatible port, that can be set to Log Hi or Low without problems. Where did you get this idea that some PINs can't be set Low...

But, make sure that you don't use some internal features of 16Fxxx, that reserves some I/Os. (such as LVP or ICD, read the Sticky for more info).

Also read the datasheet, it explains the capabilities of each port and pin.

mhhh

i'm making a really complex car computer for my KitCar,

Nigel will recon the car idea (Locost, S7)

And i cant get my serial modules to work!
Its really strange every thing is working except the last comm line to the automatic gearbox...

I use on one side a Pic16F877a Pins D.5 and D.4

on the main pc its a Pic18F452 Pins B.2 and B.3

and what puts me thinking is Nigel that the last time it was neccesary to put a pull up on the line.

Anyway i cant get the comm working, and i'm now already 4hours trying searching, changed the pins.. but no result.

It cant be the sending side because when i put my listener (max232 debug board to commport ) on the line.
i recieve my sended out message ( [1020 )

Sow it looks like the problem is on the 16F side...who don't recieves

mhhh..

Tks

p.s. i don't use any special feutures (as i'm aware of offcourse)
p.s.2 i use the Tiny bootloader just as you say

So why won't you just upload your schematic and source code(s) so that we can have a look?

p.s.2 i use the Tiny bootloader just as you say Very HappyVery Happy

Click to expand...

Yep, it's the best!

No problem in doing that,

The only BIG problem is that i use a compiler
and the ASM file is full of ****

also the main programm is like 9900 WORDS sow not exactly what you would like to see i imagine??

If you want help me searching if i have conflicting settings in the recieving side??:


Do i enable special settings on portd??? especially port 5 and 4???

The sheme is easy i cross wired both channels sow Rx on the main is directly connected to Tx on the other board.
Same for Tx on the main is connected to Rx on the other board.

When i watch Tx with my max232 ==> com1 i see the message i send
(its the warmup value for the engine's cold start)...

The communication just simple Software synchronous, sow only one line is used at the time...

looks like something is wrong on the 16F side but cant find it.

TKs

p.s. looks like i found it already: Bit 4 of port e ==> PORTD in parralell slave mode??
looks like a 0 will fix allot... (gen purpose I/o mode)

TKS said:

p.s. looks like i found it already: Bit 4 of port e ==> PORTD in parralell slave mode??
looks like a 0 will fix allot... (gen purpose I/o mode)

Click to expand...

You mean TRISE,4. This has to be '0', so you have a problem there...

yeah!!

it now works!

finally everything alright what a stupid mistake..

Also the led works again (thought it was broken or something)

but the led was also on the same port and didn't responded to the High or Low command...

I'm sure that it is fine the Parallel Slave mode but it was sucks for now!!

Tks

mhhh i thought i had it al sorted

Nigel / Jay,

Do you know what is the best state to put the Tx pin in when not using it??

i mean before the real program starts i put it low is that a good idea??

should i put it high? i realize that when putting it low the Rx pin on the other side is also low??
Both Rx pins are in the input state just after boot.

but what to do with the Tx ones???

The problem is that i wrote some code to verify the data, The main sends the value, and then wait to get it confirmed from the other side.

But i see in my debugger that it sends only ones and then it hangs.

I have used the Software commands to boot to a time-out label to be able to retry the sending. I also put in the label the command to wait for a character and after that charater start putting the bytes in my word.

It looks that it keeps waiting because it thinks the data is on the way something like start bit?

Could it be because of have ing the otherside always low???
Should i put it high??

Tks

Hi,

It shouldn't matter. But I recomend to keep it high, so you won't generate any Fake Start bit.

Teoreticaly it could be left set as an input (due to Schimtt trigger inputs), but this might make it suscipicous to noise.

EDIT: I wrote bad RS-232 default state

Re: mhhh i thought i had it al sorted

TKS said:

Nigel / Jay,

Do you know what is the best state to put the Tx pin in when not using it??

i mean before the real program starts i put it low is that a good idea??

Click to expand...

You should put it to a 'stop condition', this is how RS232 should be when no data is being sent, the start bit signifies it's no longer stopped.

Assuming you're using the hardware USART?, STOP is high.

I'm using software

With other words

A normal pin connected to another normal pin.

..now testing it with pins high..

Tks