Pages: [1]   Go Down
Author Topic: FHT Issue  (Read 582 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, everybody. I'm new to Arduino, so please bear with me. I'd like to make use of the Open Music Labs Arduino FHT Library for an application that requires me to play audio and do an FFT on it at the same time (strictly speaking, I could record audio samples and do the FFT later). I'd thus like to have an interrupt generating my sound and have the FHT run on the main thread. The programming example has been very useful thus far, but I don't want to disable all interrupts (line 26). How do I only disable the UDRE interrupt? Thanks!
Logged

North Queensland, Australia
Offline Offline
Edison Member
*
Karma: 69
Posts: 2166
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Depends what device, but UCSR0B may be what you need,
It can take the RXCIE0, TXCIE0, UDRIE0 flags.

Find your device datasheet, then look at the register summary.
Logged


Offline Offline
Jr. Member
**
Karma: 2
Posts: 97
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

you could also just try getting rid of the cli(); line, and see how much slower it actually runs.  it might work fine for your application.  or use the beta version of ardiuno which didnt have that issue (arduino-0022).
Logged

USA
Offline Offline
Sr. Member
****
Karma: 13
Posts: 365
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I tried it, and I didn't find any slowdown with either 1.5.2 or 1.0.  It would seem that whatever issue once existed has been resolved.  With general interrupts enabled, and the Timer0 interrupt enabled too, I didn't find enough interrupt latency to interfere with analog acquisition.  I can see, though, that you'd want to avoid doing too many interrupt-driven things while a sample was being acquired, and to keep the ISR's short.

The linked code sample mentions jitter, but I don't see how jitter would be introduced.  The ADC is set to free-running, so the ADC's hardware clock triggers each sample without interference from the program.  I see the code sample setting ADSC each time through the loop, though, as if it were triggering a conversion.  It appears that this bit is ignored because an automatically-initiated conversion is already in progress.  However, I don't find that the datasheet specifically states that writing a 1 to ADSC during a conversion won't interfere with it; it may be the wiser course to avoid writing to ADSC when it isn't necessary.
Logged

Pages: [1]   Go Up
Jump to: