Why does ASF TWI interface use interrupts?

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

Maybe I am missing something.

I am working on adding the TLV320AIC23B CODEC driver to a FreeRTOS project on the EVK1105. It uses an TWI interface to control the AIC23B. It was hanging in a busy wait loop for TWI to finish a write. As I tracked this further, turns out the TWI master write function assumes global interrupts are turned on. The initialization happened during start up when the interrupts were still disabled.

Manually enabling the global interrupt got things going. I will work around this but it prompts the question.

If the routine is busy waiting for the interrupt to finish, why is it using an interrupt to start with? Just loop on the status bits. I did find an older version of the TWI software that did this.

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

I have never used an AVR32.

Most ARM apps will always have interrupts running. You simply enable/disable a particular interrupt source as required.

So I would assume that most peripheral drivers will service the appropriate interrupts. This makes for efficient code and a pleasant user experience.

That is how your PC manages to handle screen, keyboard, disk, USB, ... and still appear to be running multiple applications all at once!

If you want to run your chip without interrupts, you can always poll the appropriate TWIF flag. And clear it manually.

David.

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

David, thanks for the comments. I believe you may have missed my point. I understand the use and utility of interrupts. They are usually used so the processor can being doing other useful things until an interrupt occurs. The interrupt insures the processor responds promptly to the event.

The point that struck me as odd about the ATMEL implementation is that it simply looped waiting on a software flag from the interrupt routine. It was going to a lot of code to get back to the equivalent of polling a status register.

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

Sorry. It is difficult to judge the level of experience.

However 'efficiently' you handle any peripherals, it is often the case that the application wants to 'block'. e.g. prompt for user, wait for click / key / or whatever.

Whereas a common approach is:
1. check not busy
2. issue command to peripheral.
3. go off and do other things.

You often want:
11. check not busy
12. issue command to peripheral.
13. wait till operation has completed.
14. get on with the rest of your life.

A simple way of implementing (13) is to do (1), (2), (1)

In fact, many simple apps take this approach.

If you are familiar with different RTOS algorithms, you can rearrange your calls in a more intelligent manner.

David.