Re: PIC16F628A to PIC16F84A communication problem

"skylinux" <(E-Mail Removed)> schreef in bericht
news:Ud1Te.8048$(E-Mail Removed) ink.net...
> I'm currently building a new robot, this time I would like to split up the
> load of driving the motors and sensors to different PICS. Plans are to use
> a 16F628A as the "main" MCU and use one 16F84A to control the motors and
> one or more for the sensors.
> The way it's supposed to work, the robot triggers an event, bumps the
> wall, the "main MCU" sends commands to the "driver MCU" to navigate around
> the object. I don't need any data transmissions yet, still trying to
> figure out the basics.
>
> And here is where I have the problem.
> The code in the "main MCU" and the "driver MCU" will control the motors
> when connected directly to the h-bridge, one at a time. Once I connect the
> "main MCU"(RA1) to the "driver MCU"(RB2) the motors no longer work.
> Each PIC works on it's own but they don't work together.
>
> Here's how I'm trying to do it:
> Main MCU Driver MCU
> RA0 => RB1
> RA1 => RB2
>
> RA0 is for forward command, RA1 for reverse
>
> I think that my problem is here with the I/O settings of each PIC
> Main MCU:
> startup:
> clrf PORTA ; Initialize port A
> clrf PORTB ; Initialize port B
> bsf STATUS,RP0 ; RAM bank 1
> clrf TRISA ; All pins port A output movlw 0xff ; Make Port B
> Input
> movwf TRISB ; All pins port B input
> bcf STATUS, RP0 ; Back to RAM bank 0
> movlw 7
> movwf CMCON ; Comparators off, all pins digital I/O
> clrf motor_status
> main:
> bsf PORTA, 0 ;Go forward
> call delay_600 ;Run 600ms delay to drive motor
> bcf PORTA, 0 ;Turn Motors off
>
> Driver MCU:
> startup:
> clrf PORTA ; Initialize port A
> clrf PORTB ; Initialize port B
> bsf STATUS,RP0 ; RAM bank 1
> clrf TRISA ; All pins port A output movlw 0xff ; Make Port B
> Input
> movwf TRISB ; All pins port B input
> bcf STATUS, RP0 ; Back to RAM bank 0
> clrf motor_status
> INPUT:
> btfsc PORTB,1 ;Check for High on Port
> call SwitchB1 ;Forward
> btfsc PORTB,2 ;Check for High on Port
> call SwitchB2 ;Reverse
> btfsc PORTB,3 ;Check for High on Port
> call SwitchB3 ;Left
> btfsc PORTB,4 ;Check for High on Port
> call SwitchB4 ;Right
>
> goto INPUT
>
> Please, any help will be greatly appreciated.
> Skylinux

Perhaps you test the wrong pins in the Driver MCU, shouldn't you start
testing with PORTB,0????
Further if you go forward you can go immediatly into reverse if both PORTB,1
PORTB,2 are high, this could result in a blown H bridge :S

"skylinux" <(E-Mail Removed)> schreef in bericht
news:8MsTe.8709$(E-Mail Removed) nk.net...
> Alexander wrote:
>
>> "skylinux" <(E-Mail Removed)> schreef in bericht
>> news:Ud1Te.8048$(E-Mail Removed) ink.net...
>>>And here is where I have the problem.
>>>The code in the "main MCU" and the "driver MCU" will control the motors
>>>when connected directly to the h-bridge, one at a time. Once I connect
>>>the "main MCU"(RA1) to the "driver MCU"(RB2) the motors no longer work.
>>>Each PIC works on it's own but they don't work together.
>>
>> Perhaps you test the wrong pins in the Driver MCU, shouldn't you start
>> testing with PORTB,0????
>
> I made sure that the pins are going where they are supposed to go. Are
> there any rules I should follow when I connect them? Do they need to be
> pulled up or down in a special way? Right now it's for example:
> RA2 => RB1 connected via a wire without a resistor.
>
This can be seen on the datasheets, you should take a good look at
RA4/TOCKI, at least this pin is an open-collector driver.
On the schematic of PORTA you see one FET missing for this pin. Guess what
kind of resistor you need??? The value depends on the load of this pin.

> I'm keeping RB0/INT open for further growth of the project. I'm almost
> certain that it does not matter which ports I choose unless I need certain
> features, like RB4-7 have interrupts.
Always a good idea, but it might be confusing that you don't have a one on
one pin translation.
Perhaps you could start with PORTA,1

>
>> Further if you go forward you can go immediatly into reverse if both
>> PORTB,1 PORTB,2 are high, this could result in a blown H bridge :S
> I have searched for delay values on how long it takes for a transistor to
> switch but was not able to find something. Currently I'm using a 10ms
> delay. Forward => Stop => delay_10 => Reverse
> 10ms appears to be enough, I have not tried lower values yet.
>
The delay times doesn't matter, you should solve this in software and
hardware.
Solution in software use GOTO instead of CALL and at the end of the "CALL"
GOTO the point after the choice.
Make a failsave in software if non switch is active don't change anything or
shut everything off.
Solution in hardware, use an XOR (and the inverse) before the H bridge with
the to FET above eachother. This way only one can be active and they will
not short together. Of course in some designs you want more control over the
H bridge.
> Skylinux
>
Alexander