search

far-far-away-science / hab-v2

High Altitude v2
GNU General Public License v3.0
4 stars 3 forks source link

Migrate UART to use DMA and UART IDLE interrupt #38

Closed usaguerrilla closed 8 years ago

usaguerrilla commented 8 years ago

AFSK modulator on release build loads CPU for 86%. I don't want UART to interrupt AFSK message generation nor I want GPS coordinates to be lost from UART.

Proposed solution:

this will remove code from interrupts and CPU will be free to handle AFSK modulation.

Scorillo47 commented 8 years ago

86% CPU for a modulator? We should just use a faster CPU

Sent from my Windows Phone

De la: Pavel Krupetsmailto:notifications@github.com Trimis: ‎02.‎06.‎2016 9:47 Către: far-far-away-science/hab-v2mailto:hab-v2@noreply.github.com Subiect: [far-far-away-science/hab-v2] Migrate UART to use DMA and UART IDLE interrupt (#38)

AFSK modulator on release build loads CPU for 86%. I don't want UART to interrupt AFSK message generation nor I want GPS coordinates to be lost from UART.

Proposed solution:

this will remove code from interrupts and CPU will be free to handle AFSK modulation.

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/far-far-away-science/hab-v2/issues/38

usaguerrilla commented 8 years ago

I want this to work on a slowest CPU possible so code can be ported to circumnavigating balloon.

I did this test: do ((a * b + c) / d) and write to RAM on 16MHz at 96kHz and it loaded CPU 30%. Adding read from program memory increased it to 50% so I don't think I can optimize much. Division might be slowest operation.

usaguerrilla commented 8 years ago

By 86% I mean CPU was running at full speed and consumed 86% of available time to fill DMA buffer.

usaguerrilla commented 8 years ago

Also DMA for UART will save us from getting to many interrupts which is good as well. I wasn't sure how to detect when UART finished transmitting but DMA buffer isn't full.

After reading specs it seems UART IDLE interrupt will be fired in this case and I can copy memory from DMA buffer to ring buffer for later processing.

So instead of handling interrupt for each symbol I will have 2 interrupts: UART IDLE, DMA BUFFER FULL

Scorillo47 commented 8 years ago

I see. How long is the duty cycle for this computation? Maybe it's not a problem if it's very small. BTW, I don't think this particular CPU implements hardware division - this could be an issue making the computation much longer. Is the "d" constant, BTW? We can use tricks to divide faster by certain type of constants (bit shifts, addition, etc) Also, the a*b + c type of expressions can be optimized to be much faster by using DSP instructions from ARM Cortex-M4 (I presume we are talking about integer operations, not floating point)

Adi

Date: Thu, 2 Jun 2016 10:10:53 -0700 From: notifications@github.com To: hab-v2@noreply.github.com CC: adi_oltean@hotmail.com; comment@noreply.github.com Subject: Re: [far-far-away-science/hab-v2] Migrate UART to use DMA and UART IDLE interrupt (#38)

I want this to work on a slowest CPU possible so code can be ported to circumnavigating balloon.

I did this test:

do (a * b + c / d) and write to RAM on 16MHz at 96kHz and it loaded CPU 30%. Adding read from program memory increased it to 50% so I don't think I can optimize much. Division might be slowest operation.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

usaguerrilla commented 8 years ago

We aren't using M4. AFSK modulation works so I don't see a problem. Changing to use DMA for UART also isn't a big deal.

usaguerrilla commented 8 years ago

optimizations for shifts and * will be done at the end when we know signal generation frequency, CPU frequency, etc. For now it's enough that it works on target CPU.

stcarlso commented 8 years ago

The division is the killer here. Can you make it a shift? Shifts are usually free.

usaguerrilla commented 8 years ago

Yeh. After I make sure precision for each operation is optimized I will replace divisions by shifts / muls.

n / 1'000'000 for instance will be replaced (if it stays) with ((n >> 6) * 67) >> 20).

This improves duty cycle from 86% to 40%.

I am still able to receive message from short distance with this change but need to test longer distances though.

usaguerrilla commented 8 years ago

Main thing is that even without this speedup code works so we can make PCB for final testing, as testing long distance with breadboard is not very clever.

usaguerrilla commented 8 years ago

we don't have enough DMA channels for this. Will have to live with interrupt.