ATmega16: timer1: fast PWM not working

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

Hi guys!

I have -guess what?- yet another problem with my ATmega16. I'm trying to use timer1 (the 16 bit timer) as 2-channel fast PWM generator.

ldi acc, 0b00000001
out TCCR1A, acc
ldi acc, 0b00001001
out TCCR1B, acc

This code should be exactly what I need (no COM, I use the ISRs to switch stuff, no FOC as we are in PWM mode, WGM 5/0101 (8 bit fast PWM), no prescalers for now) but the counter counts up to 255 and then counts back down which it shouldn't be doing. We're not in phase correct mode after all.

Has my brain left? I seem to be too blind to find the error... I tried all 16 possible modes for WGM but the counter either counts up AND down or it counts up further than 255. Again, I use the not-too-reliable AVR Studio 4.13 simulator as the hardware doesn't do what it's supposed to be doing and I can't watch a million instructions per second in real-time.

Any ideas?

Markus

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

Further investigation:

The Overflow-ISR is called when reaching zero, the OC-ISR is called when reaching the OC value only while counting up. Nothing happens while counting down. (speaking of interrupt request flags) So it seems to be *almost* fast PWM, only the counting down shouldn't be happening.

Markus

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

You say you are using the simulator. Did you read the ESSENTIAL bit of the manual where it lists the "Known Issues". In particular I'm thinking of the general comment:

Quote:
Timer/Counters
16-bit Timer/Counters on all devices have several problems with PWM, prescaler and output compare. Output compare registers are not buffered properly.

The Asynchronous Status Register (ASSR) is not supported in timers with asynchronous mode. This is due to lack of a generic external clock implementation.


and the specific bit for the mega16:
Quote:
Notes for ATmega16
The USART's UBRRH and UCSRC registers share the same I/O address. Writing to one of the registers will cause both registers to contain the new value, regardless of the value of URSEL. Reading these registers do not work as described in the datasheet.

The JTD bit in the MCUCSR register must be set to the desired value twice within four cycles to change its value. In the simulator the JTD bit can be written directly.

The ADC noise reduction function is not supported. Setting the ADIF flag will not wake the CPU from sleep mode.


Clearly the first of these explains the problems you are seeing. If you want to "see the code running" you'll only get a totally accurate picture if you hook a $50 Dragon up to the JTAG pins on the mega16

Cliff

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

The only thing I found in the ATmega16 datasheet was a problem with timer2 related registers being written and timer2 having a lost interrupt. (pages 342-346) This can't affect timer1 operation modes.

Where did you find your first quote, which manual is it in? I really don't want to waste your time - it seems I'm searching the wrong places. Currently, I use the forum search, Google, the ATmega16 datasheet and the Atmel 8 bit instuction set and a german website's AVR tutorials (mikrocontroller.net) for my research.

Google usually has next to no useful results while this forum and the datasheet fix my problem most of the time.

Markus

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

The manual for the simulator is built into the AVR Studio programs help system (along with wealth of other information!). While using Studio access the help menu and the top "tools user guide". The help on the simulator is a sub-sectoin of that and then the known issues section is within that.

Cliff

(Atmel seem to have a policy of conglomerating all there latest manuals into the help of Studio. You'll find the latest issues of the manual for things like STK500, Dragon , JTAGICEmkII in there too and these supercede any printed copies)

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

In Studio 4 "Help" -> "Release Notes and Known Issues"

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

Hi,

why do you use TCCRx registers with generating PWM?

Fast PWM is counting up only, but is restarted with zero. No counting down.

Can we see the whole code?
Pleas tell us what you want to do? It´s not clear to me. What works and what does not work as expected?

Klaus
********************************
Look at: www.megausb.de (German)
********************************

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

TCCRx registers are used to set mode (like fast PWM) and prescaler. And as I have to tell the µC what to do *somehow*...

I know fast PWM is only counting up, that's why I was that surprised it did count down again in the simulator!

The whole code is 842 lines, subtract about 1/3 comments for real, actual code. You really don't want me to post 850 lines here, do you? ;-)

The fast PWM for timer 1 is not working in simulator, while on the real chip it does work. In the simulator, while counting up the output is set on zero and cleared on OC, then at TOP direction changes (which should not happen) and it counts down to zero again. On the real chip timer1 and timer2 produce the same brightness, so I am 90% sure the PWM is working right for timer1 in real life.

The project I'm currently working on is a kind of universal 4-bit bus with (hopefully) cheap modules communicating with it. Each module has its own 12 bit address, 4 bit module type and 8 bit package length (for optimal usage - no transfer time lost) and can be attached to:
- 1 RGB light (with pan/tilt if you want to)
- 16 light switches
- 16 wall power outlets (with relais)
- 8 window roller shutters
And whatever else electric (or electrically handle-able) you'll find in the common household.

These numbers can be extended up to 128 byte of data by using extension modules (I'm implementing kind of a serial interface for inter-µC-communication) where needed.

Currently done and working:
-communication with the bus
-loading data from a programmer module (multiplexers and switches)
-doing 3 channels of PWM for direct RGB access
-writing/reading 2x8 bit of data with 2 complete ports

To be done:
-make the serial interface work
-give stored values back to programmer module for verification
-add more PWM channels for servo control for example
-fix some error detection going wrong
-build the (complete, not debug) module on breadboard
-build the programmer module on breadboard
-debug, debug, debug

Markus

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

Quote:
TCCRx registers are used to set mode (like fast PWM) and prescaler. And as I have to tell the µC what to do *somehow*...

My mistake. Sorry. (I was thinking about ICR registers - therefore my silly question)

Your TCCRx setup seems to be correct.

Nice to hear that PWM is working - on the real chip.

Very interesting project.

Klaus
********************************
Look at: www.megausb.de (German)
********************************

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

The big problem about the project is clock speed. Talking to the bus takes quite some time and I want the modules updated 25 times per second for nice color fades etc. For the theoretical maximum of 4096 modules, this sums up to 1.3 MHz bus clock and leaves (at 8 MHz AVR clock) 6 cycles per bus clock cycle.

In real surroundings (you'll almost never need more than 100 modules in one house), I have a few kHz bus frequency and lots of time to handle each cycle. But I still want as much free time as possible. The sleep command seems handy and with 100 modules in a house, there's some current that can be saved.

The end product should be completely invisible (i.e. small modules hidden behind light switches, wall outlets etc.), use very little power and be completely automatic.

When switching on the TV, the lights around should fade down and the matching wall speakers should be switched to audio out. One press of a button and the video out is switched to the beamer and the canvas is rolled down.

When entering a room and it's dark inside (PIR, light barriers, light sensors...), turn a standard light on automatically. Especially useful for staircases and hallways.

When going on holidays, go online with the mobile phone, log in to a web-interface and look if the stove is *really* switched off ;-)

Touchscreens on the wall and WLAN PDA with an intuitive interface (each room seen from the top) will finish it up.

I know this is definitely a lot of work but hey, with less than 10 EUR costs for one module, it's really really cheap when compared to the competition. The master module controlling everything can cost up to 100 EUR, I'll look which AVR I'll use there once the slave module here is working right.

Markus

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

Quote:
I want the modules updated 25 times per second for nice color fades etc.

Maybe you build some intelligent jobs for the modules:
For example:
Send the modules to switch to 100 percent red light.
Now tell many modules "prepare job07: dim down to 30%red within 5 seconds"
now do a broadcast to all modules to execute job07
--> all modules start the dim down at the same time and all modules are finished after 5 seconds. without additional bus communication.

You can even tell one module:
* job07 is to dim up blue to 80% within 5 seconds
and another module
* job07 is to switch on the fan

with the broadcast execute job07 every module starts its own job07

It´s up to you how much intelligence to program into the modules.
Maybe make it update-able via the bus.
And sell different "intelligence" for different prices.
So you are able to sell a basic version very soon while working on more intelligent solutions for a long(er) time

Klaus
********************************
Look at: www.megausb.de (German)
********************************

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

I thought about this one too. While researching, I found "fnordlicht", a circuit from chaos computer club germany (I believe it was cologne) which does exactly that. Send a target and a time to fade there.

But their fnordlicht costs 40-50 EUR and you have to solder it by yourself. For this price, I can get a completely soldered module I only have to program and plug in or even pay someone to program it for me and still be cheaper.

Distributing intelligence to the slave modules sure isn't a bad idea (a central unit managing hundreds of fades simultaneously has to be fast - and expensive) but for now, it won't be necessary.

Still, I kept the specification open for later additions. 4 bit module type makes 16 different modules possible. I have matrix in and out (8x8), 2 byte in and pwm out + 2 byte out combined. Extension modules will extend this, as the name implies. ;-)

The slave modules themselves will all be have the same PCB layout, the same wiring, only the IO hardware (like a board with relais or power transistors or whatever) is different. But that's just plugged together. This way, I can change the firmware at any time and implement some more intelligence to all modules, no need to make new ones.

I also thought about plug'n'play self-configuration but that, too, will come at a later time. Still, there is space to do it. Improveability is a major goal in this project.

For now, I'll create "dumb" modules. Once I see them running (and maybe have a first prototype of a master module so I can actually create a useable system), I'll start improving.

Thanks for your input!

Markus

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

Clawson wrote a blip before regarding issues with the mega16 and the simulator. I am having the same problem trying to get the timer1 in the m8515 and mega 162. I cvannot write to the ocr1a register after I set the wgm10 and wgm11 bits. even if I already loaded the register, one those two bits are set, the register is cleared and no more writes.

Incidentally, if there is only a problem in the simulator, once the code is compiled, shouldnt the code work in the chip when it is loaded into the micro? it does not seem to be the case.

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

Sparky
I too noticed that the counter does not reset like it is supposed to in simulator. I also found another problem with the high byte in the 16bit registers that was pointed out as well. I am going to set up my dragon tonight and see what happens. I hope it is just a software glitch

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

Hey Jim!

What did you find out? Is it just a software problem or is it the hardware?

Markus

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

Speaking of lighting control algorithms, does anyone know what type of commands dmx dimmers send and receive? Can you tell individual units to fade up or down at a certain rate?

Imagecraft compiler user

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

Markus:

Here is what I found out on the PWM/Timer1/Dragon fiasco.
https://www.avrfreaks.net/index.p...

Let me know if this helps

Bobgardner:
Thanks for all your help. The ICC is something I must look at more. I am going to have to buy Smiley's book and get going on it full speed after I finish off one design, and make substantial headway on my other one.

Thanks again

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

Thanks Jim, yes that helps a lot!

And Bob: afaik DMX sends up to 512 Bytes and each device daisy-chained in one row will react to the bytes it's set to. Each device has a start address and a number of bytes/channels. Usually one byte is used per function. Pan/Tilt are often 2-byte values in order to have a better resolution.
http://en.wikipedia.org/wiki/DMX512-A
http://de.wikipedia.org/wiki/DMX_%28Lichttechnik%29

Signal levels go 0V/6V at 250kbit/s, the sequence is:
-break
-mark after break
-startbyte
-max. 512 bytes of data
-mark before break

A data- or startbyte is always one startbit, 8 data bits, 2 stopbits. Oh, and DMX is unidirectional. Data only goes from the controller to the clients (like dimmers, roboheads, strobes etc.)

So to tell individual units to fade up/down, you'll have to look which channel (byte) number beginning from the start number (address) you set on the dimmer is connected to the light you want to dim and then send the target value (brightness) you want to it. For a fade, you'll have to manually send increasing/decreasing brightness values. I bet there also are "intelligent" devices that accept another byte with a time ("fade over 5 seconds") but they're not common, I guess.

Hope that helps.

Markus

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

Markus:
I forgot, I noticed the counters incrementing AND decrementing just as you did as well. I read the datasheet a bazillion times and it does mention the counter doing that in some cases.

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

Hi fellas,

I had the same problem with timer1. I'm pretty sure the values I used were correct also (TCCR1A = 0xE2, TCCR1B = 0x19). So it seems the problem is with the simulator.

WinAVR (avr-gcc) has the avr-gdb.exe. Does anyone know if it is possible to use this debugger instead? Maybe with another IDE (dev-c++ can apparently be used easily with gcc compilers and provides a good simulator interface).

Doug

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

dougy83 wrote:
Hi fellas,

I had the same problem with timer1. I'm pretty sure the values I used were correct also (TCCR1A = 0xE2, TCCR1B = 0x19). So it seems the problem is with the simulator.

WinAVR (avr-gcc) has the avr-gdb.exe. Does anyone know if it is possible to use this debugger instead? Maybe with another IDE (dev-c++ can apparently be used easily with gcc compilers and provides a good simulator interface).

Doug


But why are you surprised about timer1 not working? The simlulator manual says it doesn't work right.

As for other simulators. The one in WinAVR is not avr-gdb (that's the debugger) it is simulavr but I don't think it's that well maintained/up to date.

The best hope of a "good" AVR simulator is the tech preview of V2 in the 4.13.528 version of Studio. It seems a much more accurate representation of the chip (because it's based on the chips actual design files) but sadly all we've got so far is the mega128 and three of the tinys

Cliff