PIC12F675 Timer PWM + UART input

FJMSoft · Joined: 20 Oct 2013 Posts: 36

Hello there.
I'm trying to implement a PWM using timer0 and at same time receive some UART data.
The PWM is implemented and working well.
Problem is with the UART, as uC dont have a hardware UART it also dont have an interrupt for serial.
How can I achieve this? Ideas?

Using just getc is not working.
I also tried INT_EXT and a hand coded UART but something is going wrong (maybe my error as I'm new to this language).

No problem to stop the PWM while receiving the UART data, but I cant freeze uC waiting for the data.
To be more specific, the application is simple, PWM duty will be directly set to the UART data, this will happen at random time.

Thank you.

alan · Joined: 12 Nov 2012 Posts: 357 Location: South Africa

Have a look at the code Thelmah posted about a day or so ago, using Timer2 as a software UART.

Regards

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

You might even be able to use the same timer for the PWM.... Smile

Best Wishes

FJMSoft · Joined: 20 Oct 2013 Posts: 36

I have not found the thelma post :(

As long as I understand, the INT_EXT is the best option, but I really dont care if it is INT_EXT or timer, as long as it works.

The code I tried is this one, but it does not work, I dont know why.

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

1) Don't use delays in interrupts - a search here will find a lot about this.
2) Never _ever_ _ever_ use 'enable_interrupts(GLOBAL) inside an interrupt this is _forbidden_ on the PIC.
3) No you don't need to clear the interrupt.
4) The code hasn't got a hope of working. The shifts and other code will take far to long to have even the faintest chance.
5) The first variable to the shift is meant to be a variable _address_.
6) Then you are rotating 8bytes. Ur....
Do some forum searching on how to generate a software PWM.

FJMSoft · Joined: 20 Oct 2013 Posts: 36

Oh god, I dont know where to run now :(

1) I thought if all interrupts were disabled the delay would not be a problem.
2) I didnt know about this, I used to program 8051 before, disabling interrupts inside interrupts were very common.
Problem is disabling global or any interrupt? Could I disable only PWM timer so?
4) Serious? Oh god! I thought this was very fast, in 8051 were 1 or 2 cycles.
5) How can I do this?
6) My mistake! I misread byte as bit.

My pwm is working well, I'm using Timer0 to increase a counter and compare with the value.
pwm is not the problem, but the combination PWM+UART.
Anyway, I have done a search in the forum about the pwm as you said but havent found anything helpful :/

dbotkin · Joined: 08 Sep 2003 Posts: 197 Location: Omaha NE USA

Are you completely bound to the 12F675? The 12F1822 is a FAR more capable chip, pin compatible, is actually a little cheaper in quantity, and has a hardware EUSART in addition to many, many other improvements. Even little things like a WPU on the MCLR pin make life so much easier.

C Turner · Joined: 10 Nov 2003 Posts: 40 Location: Utah

I've implemented "software" UARTs inside ISRs, but it takes a bit of planning before-hand.

If at all possible, set the ISR rate to be an integer multiple of the baud rate of the UART. If you are using it only to transmit, this can be a 1:1 ratio, but if you are making a receiver, it needs to be at least 3x the baud rate so that you can make "early-on time-late" determinations and adjust timing as necessary.

In one instance I had a PWM and ISR both running at 19.53125 kHz (e.g. 20 MHz clock, Timer 2 with a divisor of 0 (which is 256) and an ISR post-divisor of 1.)

For synthesizing a software UART I used 16x oversampling (an baud rate error of 1.7% or so) and in the same ISR that the PWM was updated, I also serviced the incoming/outgoing bits. If I found that a received bit was slightly early or late, I would bump that 16x oversample counter up or down as appropriate to keep the transition of the incoming data within the "center" sample.

In theory I could have probably gotten away with up to 4800 baud with the 19.53125 kHz ISR - but not much higher (with a standard baud rate, anyway) unless I'd re-done my ISR rate such that it equaled a multiple of the desired baud rate. The problem with doing this is that if you use Timer2 for this you can impact your PWM resolution adversely if you aren't careful: This is discussed in detail in the part's data sheet.

In my case I was using A/D and PWM to perform some rudimentary DSP audio processing and in this case I could use ONLY one ISR lest I suffer severe timing jitter. The A/D read - then A/D start was always followed by a PWM value calculated the last time I'd been in the ISR. Once I got those portions out of the way that were clock-cycle critical in when they had to occur, I was able to do the other portions that were less "jitter sensitive" such as update system timers and service the "software UART."

* * *

As has been pointed out on this board before, if you *do* have a time-intensive ISR occurring, the more conventional "software UARTs" (e.g. those outside the ISR and using printf, getc, etc.) often fail since the DELAY being calculated by the compiler based on clock speed will be WRONG because some of the available clock cycles used to time the delay will be eaten by the ISR.

In some cases - notably for low baud rates *AND* where the ISR was very consistent in how many clock cycles it ate up and occurring at a a rate much higher than the serial bit rate I was successful after I wrote a test code that used the DELAY function to toggle a pin, outside the ISR with nothing else going on. Precisely measuring that pin's transition rate with a frequency counter and/or scope I was able to calculate how much the ISR slowed the software delays and calculate the equivalent speed and plug that into the #use_delay statement.

Again, the caveat with this is that the ISR may cause a bit of timing jitter and if both the baud rate and ISR utilization percentages are high, you could end up with lots of timing variance (or variations of effective clock speed - or if you were to change the ISR so that more time was spent within it) and see dribbling errors in the communications: In general, the lower the baud rate, the more forgiving to jitter since it would integrate out over time.

CT

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

On 4, what I was referring to, was that he was rotating 8 bytes.
A single byte can be rotated one bit in a couple of instructions, but to rotate 8 bytes, takes a lot longer. To do this eight times, and the overall time is getting worse.

What I have to ask is what he really wants to do?.

In the routine, he uses the pin number as if it is a variable (he is actually shifting a fixed bit from the pin number value, not the input value).

He also hasn't told us what CPU clock rate is being used?.

Now the entire serial receive he shows, can be replaced with a single CCS instruction, if he is prepared to have the PWM stop (as he says), using:

FJMSoft · Joined: 20 Oct 2013 Posts: 36

I have gave up of the idea, it was not worthing the work anymore.

I tried as Ttelmah said but sometimes was getting junk bytes, I believe because of PWM interrupt working time + external interrupt latency.
Even in 2400baud I was getting junk bytes.

Maybe if I could set external interrupt priority this could work...
But this is offtopic here, I may ask in another post.

Thank you anyway.