Neden her zaman DMA'yı STM32'de UART ile kesintiler lehine kullanmıyorsunuz? [kapalı]

Geçen ay UART'ın (MIDI için) STM (STM32F103C8T6) ile kesintileri kullanarak çok fazla başarı elde etmeden çok zaman harcadım.

Ancak, bu akşam DMA kullanarak oldukça hızlı çalıştı.

DMA'yı okuduğum kadarıyla daha hızlı ve CPU'yu rahatlattığından, neden her zaman DMA'yı kesintiler lehine kullanmıyorsunuz? Özellikle STM32'de oldukça bazı sorunlar var gibi görünüyor.

STM32CubeMx / HAL kullanıyorum.

DMA CPU'yu rahatlatır ve böylece aynı çekirdek üzerinde çalışan diğer kesintiye dayalı uygulamaların gecikmesini azaltabilirken, bununla ilişkili maliyetler vardır:

• Yalnızca sınırlı sayıda DMA kanalı vardır ve bu kanalların farklı çevre birimleriyle nasıl etkileşime girebileceği konusunda sınırlamalar vardır. Aynı kanaldaki başka bir çevre birimi DMA kullanımı için daha uygun olabilir.

  Örneğin, her 5 ms'de bir toplu I2C aktarımınız varsa, bu DMA için UART2'ye gelen bir hata ayıklama komutundan daha iyi bir aday gibi görünüyor.

• DMA'yı kurmak ve sürdürmek kendi başına bir maliyettir . (Normal olarak, DMA'nın ayarlanması, bellek yönetimi, daha fazla çevre birimi, DMA kullanarak kendi kendine kesintiler ve DMA dışında ilk birkaç karakteri ayrıştırma olasılığınız nedeniyle, karakter başına kesintiye dayalı aktarım ayarlamaktan daha karmaşık olarak kabul edilir. her neyse, aşağıya bakın.)

• DMA ek güç kullanabilir , çünkü saatin çekilmesi gereken çekirdeğin başka bir alanıdır. Diğer yandan, çekirdek destekliyorsa, DMA aktarımı devam ederken CPU'yu askıya alabilirsiniz.

• DMA, çalışmak için bellek arabellekleri gerektirir (çevre biriminden çevre birimine DMA yapmıyorsanız), bu nedenle onunla ilişkili bir miktar bellek maliyeti vardır.

  (Bellek maliyeti olabilir Çerezsiz kesmelerini kullanırken de orada, ancak iletiler hemen kesme içine yorumlanır eğer o da beni çok daha küçük veya hiç yok olabilir.)

• DMA bir gecikme oluşturur çünkü CPU yalnızca aktarım tamamlandığında / yarı tamamlandığında bildirim alır (diğer yanıtlara bakın).

• Bir halka arabelleğine / aralığından veri aktarımı hariç, ne kadar veri alacağınızı / göndereceğinizi önceden bilmeniz gerekir .

  • Bu, karakter başına kesmeler kullanarak bir iletinin ilk karakterlerini işlemek gerektiği anlamına gelebilir: örneğin, bir XBee ile arayüz kurarken, önce paket türünü ve boyutunu okur ve ardından tahsis edilen ara belleğe bir DMA aktarımını tetiklersiniz.

  • Diğer protokoller için, yalnızca mesaj sonu sınırlayıcıları kullanıyorlarsa, bu hiç mümkün olmayabilir: örneğin, '\n'sınırlayıcı olarak kullanılan metin tabanlı protokoller . (DMA çevre birimi bir karakterle eşleşmeyi desteklemedikçe.)

Gördüğünüz gibi, burada dikkate alınması gereken çok sayıda ödünleşim var. Bazıları donanım sınırlamalarıyla (kanal sayısı, diğer çevre birimleriyle çakışmalar, karakterlerle eşleştirme) ilgilidir, bazıları kullanılan protokole (sınırlayıcılar, bilinen uzunluk, bellek arabellekleri) dayanır.

Bazı anekdot kanıtları eklemek için, tüm bu değiş tokuşlarla çok farklı protokollere sahip birçok farklı çevre birimi kullanan bir hobi projesinde karşılaştım. Çoğunlukla "ne kadar veri aktarıyorum ve ne sıklıkta yapacağım?" Sorusuna dayanarak bazı ödünleşmeler yapıldı. Bu temelde basit kesintiye dayalı aktarımın CPU üzerindeki etkisi hakkında kabaca bir tahmin verir. Böylece, aynı DMA kanalını kullanan birkaç saniyede bir UART aktarımı üzerinden her 5 ms'de bir I2C aktarımına öncelik verdim. Diğer UART aktarımı daha sık ve daha fazla veri ile gerçekleşirken, daha nadiren gerçekleşen başka bir I2C aktarımına göre öncelik kazanmıştır. Hepsi değiş tokuş.

Tabii ki, DMA kullanmanın da avantajları var, ancak istediğiniz şey bu değil.

DMA kullanmak genellikle her karakterde bir kesinti yapmamanız, daha ziyade yalnızca bir karakter tamponu alındıktan (veya iletildikten) sonra kesinti yaptığınız anlamına gelir. Bu, bu karakterlerin işlenme gecikmesini artırır - ilk karakter, arabellekteki son karakter alınana kadar işlenmez.

Bu gecikme, özellikle MIDI gibi gecikmeye duyarlı bir uygulamada, burada birkaç msn ve canlı performanslar için ciddi oynanabilirlik sorunları ekleyebileceğiniz kötü bir şey olabilir.

DMA kesintilerin yerini tutmaz - genellikle birlikte kullanılırlar! Örneğin, bir UART üzerinden veri göndermek için DMA kullanıyorsanız, gönderme işleminin ne zaman tamamlandığını bildirmek için yine de bir kesintiye ihtiyacınız vardır.

DMA kullanımı, UART çevresel kullanımının diğer tüm düşüncelerinin ötesinde bazı ilginç sorular ve zorluklar getirir. Size birkaç örnek vereceğim: uC'nizin diğer cihazlarla bir RS485 (veya her neyse) veriyolunda oturduğunu varsayın. Otobüste birçok mesaj var, bazıları uC'niz için tasarlanmış, bazıları değil. Ek olarak, bu veri yolu komşularının hepsinin farklı bir veri protokolü konuştuğunu varsayalım, bu da mesaj uzunluklarının farklı olduğunu gösterir.

Yalnızca DMA kullanılırken ortaya çıkan bazı sorular:

• ne zaman araya gireceğim?
  • DMA'lar yalnızca önceden belirlenmiş miktarda veri aktardıklarında kesmeyi sever.
  • DMA kesintisini tetiklemek için asla yeterli veri almazsanız ne yaparsınız?
• DMA kesintiye uğradığında yalnızca kısmi bir mesaj alırsanız ne olur?
• RX tamponlarınız neye benziyor? Bunlar doğrusal mı dairesel mi?
  • DMA, yalnızca adres sınırına uyması, ancak dairesel tampon sistemindeki diğer işaretleyicileri aşmakta herhangi bir sorun yaşamaması anlamında olağandışı dairesel bir tampon katılımcı olabilir.

Her neyse, sadece düşünce için yiyecek.

Alma tarafında (hatırladığım gibi) DMA, bir karakter eşleşmesinde veya terminal sayımında sona erer. Bazı protokoller ve birçok etkileşimli uygulama bu modele kolayca uymaz ve her şeyi karakter karakter ele almanız gerekir. DMA teknikleri, iletişim bağlantısının güvenilir olmadığı durumlarda da kırılgan olabilir, akışta tek bir karakteri kaybetmek DMA durum makinenizi kolayca bozabilir.

Şu anda birkaç projede STM32CubeMx / HAL kullandım ve ürettiği UART taşıma yazılımının alma tarafında kesin eksiklikler olduğunu gördüm.

İletimde normalde bir veri bloğu veya metin satırı göndermek istersiniz. Bu durumda, veri aktarımının ne kadar sürdüğünü önceden biliyorsunuz ve bu nedenle DMA'yı kullanmak bariz bir çözümdür. Aktarım tamamlandıktan sonra bir kesinti elde edersiniz ve ana kodunuza iletimin tamamlandığını belirtmek için UART TX tam geri arama işlevini kullanabilir ve başka bir veri bloğu gönderebilirsiniz.

Veri alımı söz konusu olduğunda, ST tarafından sağlanan işlevlerin tümü, gönderen cihazın göndermeye başlamadan önce size kaç karakter vereceğini bildiğinizi varsayar. Normalde bu bilinmemektedir. Kesme işlevi, alınan verileri arabelleğe yerleştirir ve yalnızca önceden tanımlanmış sayıda karakter alındığında kullanılabilir veriler olduğunu gösterir. Sıralı tek karakter aktarımlarını ayarlayarak veri almak için DMA veya kesinti işlevini kullanmaya çalışırsanız, bunların her birinin kurulum süresi, en yavaş veri hızlarından (yapacağınız baud hızı) başka bir şeyde karakterleri kaybedeceğiniz anlamına gelir. Verileri kaybetmeye başlamak işlemcinizin saat hızına bağlı olacaktır) ve işlemciyi aşırı yükleyecek ve diğer işlemler için talimat döngüsü bırakmayacaktır.

Bunu elde etmek için, verileri küçük bir yerel dairesel tamponda saklayan ve alınan verilerin hazır olduğunu belirtmek için ana kod (RTOS sayma semaforu) tarafından okunan bir sayıyı ayarlayan kendi kesme işleyici fonksiyonumu yazdım. Ana kod daha sonra boş zamanlarında bu arabellekten veri toplayabilir, veri toplanmadan önce yerel ara belleğin taşmaması koşuluyla verilerin toplanmasında bir miktar gecikme olup olmadığı önemli değildir.