Mega168 CPU load

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi.
Is there any way to get a reading of the CPU load my program is using? I think I might have some problems with drift when it comes to timing in a SW UART, but it would be nice to know if the CPU load was the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For that matter, is it normal that the microcontroller will slow down slightly when the software gets more and more extended? If so, is it good programming practice to "adjust" the timing in the software UART to compensate for the drift?

The reason I'm asking is that if I've made a few screwups in the code, I want to fix the screwups instead of just compensating for them.. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know what are you thinking but you're asking and answering by yourself :mrgreen:
You must protect the software UART routine that being executing from other execution outside it (eg: disable other interrupts).

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m23402027 wrote:
I don't know what are you thinking but you're asking and answering by yourself :mrgreen:
You must protect the software UART routine that being executing from other execution outside it (eg: disable other interrupts).

Yeah, well, I guess I should've just edited the first post instead of replying to it.. :)

I've been very careful with what you're saying, about enabling and disabling the interrupts, to be sure of that the timers are running as they should. But I spoke with my manager about the problem, and he thought it might be a priority problem. I'm using TCNT2 for the RX part of the SW UART, so activity on TCNT0 and TCNT1 would probably make TCNT2 drift. I hadn't considered that.. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'm using TCNT2 for the RX part of the SW UART, so activity on TCNT0 and TCNT1 would probably make TCNT2 drift. I hadn't considered that..

Nor I consider that?! I think that is not the major problem. How can timers that don't connect each other could interfere logically?

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'm using TCNT2 for the RX part of the SW UART

When using an interrupt SW UART it is always going to be next to impossible to have completely reliable communication if other interrupts are being used as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Quote:
I'm using TCNT2 for the RX part of the SW UART

When using an interrupt SW UART it is always going to be next to impossible to have completely reliable communication if other interrupts are being used as well.


Yeah, I've noticed. :) But I followed m23402027's advice and disabled an interrupt that's just running continuously (for interrupt timeout purposes), and the stability seems to be improved quite a bit. I'm using this for managing a TV set, and it kept switching off because of serial miscommunication. At least now it keeps being turned on. :)

But I'm thinking of rewriting the entire software UART eventually. You're saying "interrupt SW UART". Is there another way to time a SW UART - perhaps without using interrupts at all - which is less prone to instability when using other interrupts?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m23402027 wrote:
I don't know what are you thinking but you're asking and answering by yourself :mrgreen:
You must protect the software UART routine that being executing from other execution outside it (eg: disable other interrupts).

I followed your advice and tried disabling a continuously running interrupt while receiving serial data on the SW UART, and is seems to work out quite well. Thanks a bunch! :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't really mean to imply "just" interrupt SW UARTS. The same problems exist using the alternative method of polling. Is the builtin UART already being used for something else?
If possible, I would do away with the other interrupts and just poll the respective flags. Of course this depends on the timing sensitivity of your other interrupts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a big drawback of the AVRS, that no interrupt priorities can be assigned.
So you have always only 2 execution levels (main and interrupt).

If you can, disable all other interrupts during software UART activity.

Also you can look on my UART solution, which avoid jitter accumulation:

https://www.avrfreaks.net/index.p...

In general on the AVRs you should held all interrupts as fast as possible (doing all things inside the main loop, which must not be done instantly).

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
I didn't really mean to imply "just" interrupt SW UARTS. The same problems exist using the alternative method of polling. Is the builtin UART already being used for something else?
If possible, I would do away with the other interrupts and just poll the respective flags. Of course this depends on the timing sensitivity of your other interrupts.

Yes, unfortunately it is. The AVR is sitting in between a larger processor and a TV, and the HW UART is already in use for communication between the larger processor and the AVR. So a SW UART is my only option.

What did you mean by polling, by the way?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
...

If you can, disable all other interrupts during software UART activity.

Also you can look on my UART solution, which avoid jitter accumulation:

https://www.avrfreaks.net/index.p...

...

Peter


Thanks, Peter! I'll have a look-see at the UART a bit later. Maybe I'll snag an idea or two when I start writing a new SW UART.. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My mental model of the sw uart is a counter that increments at twice the uart bit rate... the handler increments the counter, if the count is odd or even or something, you are on the edge of a bit time, so set the new send bit hi or low, or if in the middle of the bittime, look at the receive input, shift in a 1 or a 0, and return. Should be easy to stay within the requied 2% or so

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, that is more or less how I do it today. But I'm counting upwards at exactly the UART bit rate. Well, the very first time it counts 1.5 bits to skip the start bit, and starts to count 1 bit from there.

I'm not sure I understood the purpose of counting the "in between bits" though. Why would I want to do this?

I assume you would use one of the hardware counters here then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it counts more than twice per bit. My recollection is 3 or more (odd number).

The reason is that you want to identify the value of the bit based on a majority of the samples. If you have an odd number of samples, there will ALWAYS be more of one than the other.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Software UARTS are always a pain. When I had to create them with "The other micro(PIC)" we used the external interrupt pin as the RX input and then used the timer0 to count where to sample the bit near the half bit point. It is extremely time consuming, and in most cases in this day and age, unneded with todays micros.

Can you elaborate on the need for a SW UART? The processor? Might help us help you.

The 'other' Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Without knowing exactly what else your program has to do and the timing requirements it's hard to really give a definite direction. The easiest solution would be to switch to a device with 2 UARTS such as the Mega162.

As far as polling goes it depends on what else your program needs to be doing. Polling normally involves just sitting in a tight loop checking flags to see if a condition has been met. The problem with other interrupts being enabled means it's always possible to miss the start bit by about 8+ cycles (usually more). If your running at a very fast clock rate and using a slow baud rate then it won't have as much impact, but the odds are most always going to be against you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro brings up another good point.

The 'other' Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One can also use the input capture/output compare to do serial i/o with some software assistance that is more tolerant to other activity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign: It's just basically a system where the AVR is functioning as a communications interpreter between a larger processor and a TV set. I see that the choice of Mega168 instead of an AVR with 2 UART's might have been a poor one, but I'll have to make do. At the moment, at least..

CirMicro: So you mean that using polling in an SW UART environment, is just basically checking the RX line continuously for the start bit, and sample the bits at a 1x/2x/3x/whatever rate from there on out?

As for my earlier problem with instability, the problem was solved when I disabled a continuously running interrupt/counter during the 1 ms (9600 bps) when a byte is received on the SW UART.

Thanks for all the help, guys. I like the atmosphere at this forum. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bassmus,
If the EXTINT0 pin is available then use that for your SWUART rx pin. This way when there is a transition, the interrupt routine can accurately shift in the bits. Should make life much easier.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Bassmus,
If the EXTINT0 pin is available then use that for your SWUART rx pin.

But the ICP works even better.
Then you have the exact time stamp without any interrupt latency.
I use it on my example code.

Without ICP, the start bit detection can be delayed by other interupts and the data bits also.
This doubles the error.

With ICP a delay of up to 50% bit time can be accepted.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peter,
As always, there is more than one way to skin a cat!!

Good one

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user