Nov 24, 2020
04:28 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2020
04:28 AM
I have a special application using 24 PWM outputs. I am updating the duty on all 24 outputs every PWM cycle, and want to run at high switching frequency (30kHz+).
The problem is that writing to all 48 registers (SR0, SR1 for each TOM channel), takes a lot of time, about 7-8us when running at the TC299's max frequency of 300Mhz.
My whole task (adc/resolver read, current control loop, duty calculation, writing to registers) takes about 26us, so 25% of it is writing to the registers.
The code is as follow:
/* writing to GBL_CTRL to disable updates */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx
/* writing to TOM Shadow registers*/
GTM_TOMx_CHx_SR0.U = PeriodArray[0];
GTM_TOMx_CHx_SR1.U = PeriodArray[1];
/*above code repeated for each of the 24 TOM channels*/
/* Enable updates again */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx
My question is: is there anyway to make it faster? Is this normal to take that long?
Thanks!
The problem is that writing to all 48 registers (SR0, SR1 for each TOM channel), takes a lot of time, about 7-8us when running at the TC299's max frequency of 300Mhz.
My whole task (adc/resolver read, current control loop, duty calculation, writing to registers) takes about 26us, so 25% of it is writing to the registers.
The code is as follow:
/* writing to GBL_CTRL to disable updates */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx
/* writing to TOM Shadow registers*/
GTM_TOMx_CHx_SR0.U = PeriodArray[0];
GTM_TOMx_CHx_SR1.U = PeriodArray[1];
/*above code repeated for each of the 24 TOM channels*/
/* Enable updates again */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx
My question is: is there anyway to make it faster? Is this normal to take that long?
Thanks!
6 Replies
Nov 24, 2020
07:59 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2020
07:59 AM
The GTM is pretty slow on the SPB. Is PeriodArray in local DSPR? That will only help a tiny bit.
You could make a gigantic DMA linked list to do the transfers from PeriodArray into GTM_TOMx_CHx_SRx. That would reduce the CPU stall to just the time of kicking off DMA.
You could make a gigantic DMA linked list to do the transfers from PeriodArray into GTM_TOMx_CHx_SRx. That would reduce the CPU stall to just the time of kicking off DMA.
Nov 24, 2020
08:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2020
08:21 AM
I think this one lives in Pflash. I'm not currently using the PSPR/DSPR areas.
I can have a look into moving it there, see if that helps.
I'll also have a look at using the DMA more. I've noticed it takes quite a while to return my ADC results, I can probably speed that up using the DMA as well. I've seen there are code examples for this, I'll give it a go.
Thanks a lot for the suggestions!
I can have a look into moving it there, see if that helps.
I'll also have a look at using the DMA more. I've noticed it takes quite a while to return my ADC results, I can probably speed that up using the DMA as well. I've seen there are code examples for this, I'll give it a go.
Thanks a lot for the suggestions!
Nov 24, 2020
09:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2020
09:31 AM
Possibly important to note that using DMA isn't really faster, because there's a bit of overhead in arbitrating between DMA channels and swapping transaction sets in and out. A good general guideline is that a DMA transfer will complete within 400 ns.
Offloading those moves to DMA gives you more CPU bandwidth, so in that sense, it's faster 🙂
Offloading those moves to DMA gives you more CPU bandwidth, so in that sense, it's faster 🙂
Nov 24, 2020
12:22 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 24, 2020
12:22 PM
That's a good point. I'm not so much after pure speed, even though I'd like to run that task at >50kHz. It's more like getting the CPU to do actual calculations, not waiting register writes!
My input processing will certainly be interesting. The TOM generates an interrupt at 50% duty, which triggers the ADC sampling, which generates an interrupt at end of sampling, which will trigger the DMA transfer, which will generate an interrupt and trigger the rest of my task once the data is ready! Nothing can go wrong 😄
I'll update the post to report on my progress.
My input processing will certainly be interesting. The TOM generates an interrupt at 50% duty, which triggers the ADC sampling, which generates an interrupt at end of sampling, which will trigger the DMA transfer, which will generate an interrupt and trigger the rest of my task once the data is ready! Nothing can go wrong 😄
I'll update the post to report on my progress.
Nov 26, 2020
12:14 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 26, 2020
12:14 PM
FYI, this seems to work!
I've done a linked list to transfer the 6x ADC results, it didn't save a lot of time, but it's nice to have.
I also implemented a linked list to move the 48 TOM Shadow Registers, this ended up pretty much saving 5-6us (pretty big for a task running up to 30kHz). I'll need to time the DMA transactions, to see how long it takes to copy all the data to the GTM, but at least it frees up the CPU to do actual calculations!
Thanks again for the suggestion UC_wrangler. I'll start using the DMA more.
I've done a linked list to transfer the 6x ADC results, it didn't save a lot of time, but it's nice to have.
I also implemented a linked list to move the 48 TOM Shadow Registers, this ended up pretty much saving 5-6us (pretty big for a task running up to 30kHz). I'll need to time the DMA transactions, to see how long it takes to copy all the data to the GTM, but at least it frees up the CPU to do actual calculations!
Thanks again for the suggestion UC_wrangler. I'll start using the DMA more.
Nov 27, 2020
12:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 27, 2020
12:21 AM
Last update. It works well, but yes, the DMA transfers are taking quite some time (12us in total). I'll have to make some optimisation, because I don't think a 48 wide linked list is the best way to go, but it's a good proof of concept. Unfortunately, the TOM channels I use are not contiguous, so I cannot take advantage of the multiple moves per transaction capability (with auto source address increment).