1. Home
  2. Microcontroller Discussions
  3. PIC16F628A to PIC16F84A communication problem

PIC16F628A to PIC16F84A communication problem

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

Reply to
skylinux
Loading thread data ...

"skylinux" schreef in bericht news:Ud1Te.8048$ snipped-for-privacy@newsread3.news.atl.earthlink.net...

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

Reply to
Alexander

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

-- ------------------------------------

formatting link
Webshop for PICs and other electronics
formatting link
Teacher electronics and informatics

Reply to
Wouter van Ooijen (www.voti.nl

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

Reply to
skylinux

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.

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

Reply to
skylinux

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.

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

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.

Alexander

Reply to
Alexander

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

Reply to
Michael Lange

That's why I'm not using PORTA, 4

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".

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.

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

That's what I'm doing, GOTO sleep and turn on RED LED.

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

Reply to
skylinux

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

Reply to
skylinux

"Michael Lange" schreef in bericht news:dfnd3g$ps3$ snipped-for-privacy@online.de...

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.

Reply to
Alexander

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

Reply to
skylinux

Hi skylinux,

That is my Prog-HW (Less than 10 ? or $):

formatting link

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:

formatting link

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

Reply to
Michael Lange

"Michael Lange" schreef in bericht news:dfrcv5$24l$ snipped-for-privacy@online.de...

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

Reply to
Alexander

Hi Alexander,

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.
Reply to
Michael Lange

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.