4 Serial Ports on 16F1828

[greeniemax]

Hi,

I'm trying to make 4 Serial ports working, but when I use the wizard, it only configures 2 and when I try to make it work on C5 and C4 are working.

I can't change port using fprintf, but I used 2 ports on PIC16F684, it worked perfectly fine, with no problems, but it's not working at all with PIC16F1828, thought it's a newer Microprocessor.

Any clue,

Thanks in Advance guys.

[temtronic]

rule #1, Always post your compiler version...

rule #2, Always post a short,compilable program with the problem.

comment, That PIC only has one hardware UART,so the other 3 must be software UARTs.Depending on required speeds of the serial ports and use( full duplex, one way only, ??) you will run into some serious timing issues.Though you can get 4 serial ports up and running on it.

comment, Please give a brief description as to what you need to accomplish.Details like baudrates per serial line,amount of data,polled or interrupt driven, what else the PIC has to do,etc.

The more details you provide the better responses we can give.
example, You may need to add I2C UARTS to the PIC,choose another PIC,or it may just work for you!

hth
jay

[Ttelmah]

Odds are the pins he is trying to use are defaulting to something else. More complex chip, lots more that has to be turned 'off'.
C4, and C5, are the hardware UART pins, and if these are selected, the compiler will automatically configure the pins for UART use. For other pins this won't happen.

Best Wishes

[greeniemax]

Compiler version I'm using is PCWH 4.140

I want full duplex communication, at 9600 Baud.

Here is what I get when I set it through Wizard.

[RF_Developer]

As Temtronic said, these PICs have only one hardware UART, which either uses B5/B7 or C4/C5. You cannot get both sets of pins to work with hardware at the same time as there is only one hardware UART. There is NO solution with these PICs that uses hardware UART for more than one full duplex port, though its perhaps possible, but complicated, to implement transmit only over two ports with one UART by steering the pins on the fly.

So, you can only have one hardware UART configured. All the rest have to be software. In your case, the fourth UART definition is overriding the first, so it works, but the first doesn't.

The second and third may not work due to other settings of the hardware.

With these PICs on CCS C you need to use "UART1" or "UART2" to select which pins the hardware UART uses. To set up four UARTs, one hardware on the first set of pins, i.e. B5/B7, and three software UARTs for transmit only you would need to do something like this:

[Ttelmah]

As a key comment. The software UART implementation is _half duplex only_.

So you can have one 'full duplex' UART (the hardware one), and any number of software UART's, each of which is half duplex, and only one can be doing anything at a time. These latter are 'ideal' for simple things like just sending a configuration message, but not for anything much more complex.

To get four full duplex ports, you need to either add three external UART's (I2C), or switch to a chip with teo or more hardware UART's, and also add external UART's for the other ports.

Best Wishes

[temtronic]

comment: Since you're controlling 4 RC servos via RS-232, I'd use 4 software UARTS( xmt only) as the configuration. This leaves the hardware UART for duplex PC communication(future option ?) and only uses 4 I/O pins, freeing up 4 (the servo->PIC rcv lines) pins for other uses.
It also means the code for all servos is the same.

just another option

hth
jay

[Ttelmah]

Or (of course), forget RS232.
Use one of the little 8pin PIC's that has I2C, to control each servo, and a single I2C port on the master chip can send commands to each. Identical code for each servo (use a couple of pins to control the 'address' on the I2C bus), and the master needs only to use two pins.

Best Wishes

[temtronic]

hmmmm: I was thinking his RC servos have RS-232 interface. Be nice to know the make/model info of the servos as 'regular' servos work fine off any PIC I/O pin.

hth
jay

[greeniemax]

The motor is from Rhino It's RMCS-2203

http://robokits.co.in/shop/index.php?main_page=product_info&cPath=2_71&products_id=367


I tried controlling it with I2C actually didn't work because they had some software issues on their I2C and I had already bought the motor.

I'm actually planning to use 2 Pins that are used for RX and TX as my DIR and STEP for next motor so I'd actually use the current motor with RS232 but next motors I'll use two pins for controlling the movement.

[Ttelmah]

OK.
Somewhere along the thread, somebody said 'RC servo'. This isn't. 'DC smart servo', yes. 'RC servo', no....

Now first key thing is that this doesn't need 'full duplex'. It uses half duplex comms. It only sends data when asked for it, as a 'reply'. So 99% of the comms is output only, which the software ports can handle fine. They can also accept a reply like this, since you can request the data, and then sit waiting for it to arrive, which the software serials can also handle fine. Since no data will arrive on the other ports, while this is happening, again OK.

Now, on your second comment, remember on a step/dirn controller, you have no knowledge that the motor is actually doing what you ask. With a servo, you can ask it. Then that the step/dirn will need to be ramped, starting slowly, accelerating to the speed you want to do, then decelerating as you near the target position. Moving a motor smoothly at good speeds with step/dirn involves a lot of work. The servo does this for you. Packages like Mach3 on the PC, have an interrupt running at typically something like 40000+ times/second, issuing the step pulses, based upon the speed currently needed.

So, on the comms, you haven't actually posted a little 'test' program to show what you are trying to do. Ideally something like basic fuses, and processor defines, then a little program that configures one software port, and sends a command to one servo saying 'go here', then waits for a nice time for this to complete, then asks the servo where it is. With such a program we can probably tell you what is stopping it working.

Also in fact, since you will only ever issue commands to one servo at a time, and listen to this servo, you could do the comms using a hardware multiplexer on the hardware port. Simple 2-4 line switching, and just output the 'servo address' on two lines to control this, then send the data.

Best Wishes

[greeniemax]

I'm not reading anything from the servo, I'm maintaining all the data inside the PIC, my PIC reads information from External EEPROM and based on data move the Servo to the location by giving it "G"+STEPS*0.2.

My Motor would actually only move maximum 15 Deg on either side.

So commands are simply like this...

[Ttelmah]

First, this job needs to be all done outside the interrupt. Then you are still not showing us a basic, simple, complete program.
Then you are missing the point about step/direction. This implies a stepper controller, not a servo. A servo will apply extra torque as needed to get 'where' you want it to go, and will do it accelerating slowly to the requested speed. using step/dirn, _you_ are going to have to do this control. Step even a tiny bit faster than the motor can handle, and it'll miss a step. The servo will recover when this happens, a stepper won't....

[greeniemax]

That the only thing that is going to Servo other than settings when the system starts or when EEPROM is plugged in.

It sets Motor Speed to 255 and Dampening to 0. Which makes it run at highest speed (100 RPM) and Stops without slowing down as I only have 200ms to move the motor into position.

That is simply sending...

3 second delay to make sure Servo is ready to accept the commands.

[Ttelmah]

You are still not showing us a basic program. 'Ready to go'.
It is almost certainly the _setup_ stuff in the program that is causing the problem (as I said right at the start), so you need to show us this.

The problem about doing things is the interrupt is not the time involved (though if the signal comes from a push button for example, there may well be problems because of 'bounce'), but the effect it has on everything else. Because you use the print in the interrupt, with a software UART, this uses delays. Then other things in the main will have interrupts disabled etc. etc..

Actually setting the deceleration to zero, may actually make the motor take _longer_ to get to position. The motor physically can't stop instantly, so will overshoot, and then hunt....