PIC16F628A to PIC16F84A communication problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View


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

Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it

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




Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it

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.

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.

Quoted text here. Click to load it
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.

Skylinux


Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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

Quoted text here. Click to load it
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.
Quoted text here. Click to load it
Alexander



Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it

That's why I'm not using PORTA, 4
Quoted text here. Click to load it

I'm a Computer Science major, I know C, C++, VB 6, VB.Net, PHP, ....
starting a count form 0 or 1 does not make a difference to me. I also
have a diagram matching each port the one connected so that I don't get
"confused".

Quoted text here. Click to load it
I did not say that the delay time was of relevence, I just mentioned it
to dismiss this commenct "PORTB,1 PORTB,2 are high, this could result in
a blown H bridge :S". I use the delay everythime I switch Ports.

Quoted text here. Click to load it
Why? What's the dirrence?
Here is one of my samples how would GOTO instead of CALL make it
"better" if it does something it would add WAY more code. Pleas explain.
SwitchB1:            ;Respond to sensor on RB1
    movlw    b'00000001'    ;Store where the obstacle is
    movwf    robot_bump    ;Store where the obstacle is
    call Off    
    call Reverse
    call delay_long
    call delay_long
    call Off
    call Right
    call delay_long
    call Off
    call Forward
    return
Reverse:
    bsf PORTA, 1    ;Reverse
    bsf PORTA, 3    ;Reverse
    movlw     b'00000101'        ;Robot is moving reverse, update motor_status
    movwf    motor_status
    return

Quoted text here. Click to load it
That's what I'm doing, GOTO sleep and turn on RED LED.

Quoted text here. Click to load it

The chips work on their own. It should be a problem related to
connecting the pins or pin states when two chips are connected.

Skylinux

Re: PIC16F628A to PIC16F84A communication problem


Quoted text here. Click to load it

That does not sound like a good idea. Unless you have a heap of F84A's
you'd be better of using just 628A's, because they are cheaper, and
they have PWM hardware which can be very usefull to control a motor.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

Re: PIC16F628A to PIC16F84A communication problem


Quoted text here. Click to load it

The reason I wanted to use the three 84s I have for something like this,
is because I ordered them to start with PICs. Since then I have spoken
to others which have recommended the 628, more space, more features and
it's cheaper. But since the 628 have PWM, which I did not know, I will
most likely use one of them instead.

Unfortunately there will be no more testing tonight since my programmer
just died.

Later

Re: PIC16F628A to PIC16F84A communication problem


Hi skylinux,

there is a typical beginners mistake using the i/o ports. Consider that
all write operations are read-modify-write operations. Please read the
manual, section 5.1.

HTH
Michael

Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it

I'll look into it, thanks.
I'll keep you posted.
Skylinux

Re: PIC16F628A to PIC16F84A communication problem


Quoted text here. Click to load it

Michael refers to bsf and bcf write operations, if you write a value to a
port you don't have that problem.

Explaination of the problem.
bsf:
first the port is read (current value's so low if externally pulled low (by
a short) or high if externally pulled high and not the previously written
data)
Then the port is XOR-ed with 00010000 where the place of the 1 corresponds
with the pin.
Finaly the new value is written to the port.



Re: PIC16F628A to PIC16F84A communication problem


Quoted text here. Click to load it

I'll try all your suggestions in a few days, my programmer died and I'm
waiting for the replacement to get here. I really hate when this kind of
stuff happens while I'm in the middle of work. Although it is nice to go
to bed before 2am. Usually I build as long as my eyes are not too tired
to write code or build circuits.

BTW, any recommendations on a backup programmer I can build? I currently
have a Olimax PIC-MCP-USB but a serial would do, too. Serial would give
me the opportunity to upgrade it to USB later on.

Thanks again, I'll keep you posted.
Skylinux

Re: PIC16F628A to PIC16F84A communication problem


Hi skylinux,

Quoted text here. Click to load it

That is my Prog-HW (Less than 10 € or $):
http://www.rotgradpsi.de/mc/picprog/picproge.html

It's very simple and works fine for my need, but for LPT.

A good and useful SW for many HW (not only the one above) can be found
there:
http://people.freenet.de/dl4yhf/winpicpr.html

The SW burns many 10/12/16/18/30F, and I made a configuration for the HW
above, that is includend in the current version. The SW can help to test
  the HW by setting the signals manually.

Furthermore I build a very simple ICD2 clone, but it includes a PIC, and
that will not helpfuly for you this time.

Michael

Re: PIC16F628A to PIC16F84A communication problem



Quoted text here. Click to load it

With some work you can make this circuit also suitable for ZIF-sockets.
I suggest another Power circuit, the 78L05 is not as well protected as a
LM317. Perhaps better is a voltage regulater with a DC-OK signal suited.
Place the caps as close to the voltage regulaters as possible and also check
the caps for the 74LS14 and the pics to be programmed.

The circuit given is a good base to make a circuit that suits your needs
(add status-leds or ICSP capabilities).

Alexander



Re: PIC16F628A to PIC16F84A communication problem


Hi Alexander,

Quoted text here. Click to load it

You are right.
Did you see, that the 18 pin socket can als used for PIC 12F and 14 pin
16F too?.

I made some extentions:
- used a connector instead of the sockets, at this some small
socket-boards for  or a ISP cable
- on the 18 pin socket I placed resistors between pin 9,10,11 and ground
(to avoid problems if LVP mode is enabled), do this similar on the 40
pin socket
- on the 18 pin socket-board I placed a diode in /MCLR line, to lower
the low voltage level (had some 12F629 which somtimes not enter
programming mode)
- used a 7805 instead of 78L08, saver to drive power if used for ISP


With the named SW it is possible, to expand the HW if you need:
- 2 state LEDs (error/OK)
- 1 Button
- production grade programmer verify
...


Michael
--
Schreibt zusammen, was zusammengehört.

Site Timeline