AVR Custom Interrupt (USART)

[packtronic]

Hi All,

I am really not familiar with the C language. Several times I started to write USART interrupt driven apps in Flowcode AVR.
I tried to use the configuration settings as written in the relating help section (see Custom Interrupt...).
I modified the handler codes, based on the used AVR chip's datasheet provided by Atmel. Without success.
(For me it is interesting: nowhere is mentioned the "disable code" and the "handler code", however these fields must be filled out in Flowcode)
I wrote a small, simple program (see the attachment). How it is working? It contains an endless loop. If any serial interrupt occured, first it is indicated by PORTB.0 LED.
If the character is "A" , then the status of PORTD LEDs will be changed for 1 sec. THEORETICALLY!
...but indicating interrupt on PORTB.0 or PORTD never happened...
I don't know why. C is a mystery for me, and I cannot eliminate C during programming in Flowcode.
Different AVRs needs different interrupt handlers???

If You have any working routine for serial interrupt please share with me.
Thanks in advance.

Istvan

[Sean]

Hello Istvan,

First the good news:
Your program very nearly worked. I have attached a slightly modified copy that now works correctly when downloaded to a target device.

The changes are:
Addition of an extra line in the interrupt enable code block to enable the RX interrupt (RXIE). This is required in addition to RX enable (RXEN).

A change of the interrupt vector name to USART_RX_vect. This is controlled by the chip manufacturer and is slightly different from the equivalent interrupt for the ATMEGA32 (USART_RXC_vect) used in the help files. This type of data needs to be obtained from the device data sheet or files used by the compiler.

The LEDs and I/O control of Port D moved to Port C. Port D is used by the USART.


The disable code is correct for the receiver interrupt enable (RXCIE). You could also disable the receiver in the same command (RXEN).

Now the bad news:
Due to the use of C code, this type of program will not simulate correctly and can only be tested by downloading to a target device.

We are planning to provide improved support of interrupts due to their increased use in applications.

[Sean]

Oops!

int_usart2.fcf_avr

(9.5 KiB) Downloaded 513 times

Here is the modified program

[packtronic]

Hello Sean,

You are my friend! Thank you for the quick response...
Yes, I thought I will have problems with C.
After you modifed the file, I dig out deeper in the Flowcode folder (...\\Matrix Multimedia\Flowcode_AVR\Tools\avr\include\avr) and saw there are a lot of header files for different devices. This is the nearly maximum that I know about C.
I saw also, the "brother" devices has different registers, different definitions, some of them defined as groups (for example >> iomx8.h)... etc.
...not easy. Hard to find all the differences between different devices. Atmel's datasheets are just for guide, not really detailed for me. If I am not experienced in C (as I am not), I have small chances.

So, I tried to use the file modified by you, I downloaded it to the uC, ...not working.
I checked the fusebits (they are default). I tried to test with different baud rates - without success.
By the way, how can I adjust the baud rate? Is it neccessary to integrate to the enable code ... or which way?
I am using ATmega48V 10AU (TQFP). What is your fuse settings (High byte/Low byte)?
I need to investigate what is wrong....

About the "bad news":
It is not bad news, it was clean for me. As I discovered Flowcode months ago, I saw 9 of 10 projects, forum topics, etc. are for PIC. Flowcode AVR is mostly for bullet-headed guys as I am. ...but I am an Atmel fan. It was risky to invest money into buying the software without deeper experience, but I did, because I wish to develop nice applications.
I am sure that FlowcodeAVR will be better and better! ...and you answered to my unwritten question about the improved simulation and interrupt support. Thanx!

Istvan

[Sean]

Hello Istvan,

The original program was configured for a 20MHz clock in the 'Chip -> Clock Speed' menu.

Baud rate and other settings can be accessed via the 'Properties' page of the RS232 component. The default is 9600. This relies on the 'Clock Speed' parameter being set correctly.

The factory default fuse settings for most AVR devices causes them to run from their internal 8MHz RC oscillators, with the frequency further divided by 8.
The chip will actually be running at 1MHz.

Our standard fuse settings for an external crystal are:

0x0, 0xDF
0x1, 0xFF

These values can be entered via the 'Chip -> Configure' menu, and will be sent to the device when the 'OK and Send' button is clicked. (0x0 is the high byte, 0x1 is the low byte, the extended byte can be left at its default value)

My program ran on an ATMEGA48-20PU with a 20MHz crystal.
RS232 communications with Hyperterminal was at: 9600 Baud - 8 data - No parity - 1 Stop - No flow control.

The header files you found are a very good source of information. You will need this information, along with the device data sheets, if you want to tackle these more advanced programming topics.

[packtronic]

Hello Sean,

Sorry for not replying for your message immediately. I was so disappointed...
Definiately, my plan was to use the internal oscillator, not any external crystal. This was the base point.
The program you wrote was optimized for external 20MHz crystal. The maximum frequency for my chip (TQFP) is 10MHz.
After lot of experimenting, it seems I found the neccessary settings for my application.

So, with these settings in Flowcode I have no problem:

Clock speed: 1000000 Hz
Baud rate : 4800 bps

config fuses:
0x0,0x62
0x1,0xdf

Notes:
By the fuse settings the clock speed is divided by 8, so probably the real clock frequency is 125kHz.
But, if I set the clock speed to 8000000Hz in Flowcode ... nothing is working at any Baud rate.
Why 4800 bps is the maximum? In this case the error rate is 0.16%, if I would use 9600 then the rate will be 6.99%.
This problem is caused by the relatively low clock speed. I thought...
If you enough curious about these things and you have time, please try it with your chip without crystal and let me know about the results.
Thanks.

Istvan

[packtronic]

Mea culpa.

Another solution that works.
(The power consumption will be a little bit higher, because of the higher clock speed)
Setting the internal oscillator >>> not to divide the clock pulse by 8.

>>> set config fuses:
0x0,0xe2 (low fuse changed)
0x1,0xdf

Now increase the Clock speed to 8000000 Hz, and it is possible to set the Baud rate to 9600 bps, or up to 38400!

Huh...

[Sean]

Thanks Packtronic

Using your fuse settings does allow the chip to run from its RC oscillator at the full 8MHz.

I have tested the example program using these settings, with the Flowcode Clock Speed set to 8000000, and everything worked - though not reliably.

the problem seems to be the accuracy of the RC oscillator. The oscillatorcan be calibrated if required, but my sample chip, with factory settings, generated regular read errors.
Changing the fuse settings back to the external xtal values, and fitting an 8MHz xtal, provided 100% success using the same program.

Note:
The Flowcode Clock Speed setting does not control the clock speed of the target device. It is used to inform Flowcode of the target device clock speed.
If the fuses are set to use the 8MHz RC oscillator, and the DIV8 fuse has been programmed, then 1000000Hz is the correct value for Flowcode.

The RS232 Baudrate error is caused by the target device hardware. The clock frequency can only be divided by a range of integer value to generate the Baud rate clock. A 1MHz clock can not be divided precicely to 9600Hz, so there is a relatively large error (7%). 8MHz can be divided more accurately, so there is a much lower error (0.16%). We often use a 19.6608MHz (Baudrate) xtal, which has an integer division to the common Baud rates, and produces 0% error.