PIC32 vs dsPIC vs ARM vs AVR, yine de C dilinde programlama yaparken mimari önemli mi? [kapalı]


10

Şu anda 32-bit PIC32 Mikrodenetleyici kullanıyoruz. İhtiyaçlarımız için iyi çalışıyor, ancak bize daha iyi hizmet edebilecek diğer mikro denetleyicileri de araştırıyoruz + MCU'yu seçtiğimiz başka projelerimiz var. Bu amaçla, ARM tabanlı SAM DA mikrodenetleyiciyi aynı 32-bit olan ancak ARM tabanlı (PIC32'den daha popüler - endüstri açısından) seçtik.

Şimdi PIC32 için MPLAB kullanıyoruz, ancak ARM cortex-M0 için Atmel Studio kullanacağız. Her iki platformda da C dili kullanacağız. Endişe duyduğum şey, iki 32 bit mikrokontoller (aynı şirketten) kullanacağız, ancak farklı mimarilere sahip olacağız. Bu, iki farklı cihazı öğrenmemizi gerektirecek ve "öğrenme eğrisi" + teslimat süresini artıracaktır. Ancak diğer taraftan, her iki durumda da C-Language kullanacağımız için, ARM için öğrenme eğrisi duyulmamış olmalı ve bu işlemciyi de keşfetmeye değer.

Benim asıl sorum, C-dilinde programlama yaparken mimarinin mikro denetleyicinin iç kısımlarının bir soyutlamasını sağladığı için ne kadar büyük bir fark yarattığıdır. Ve C-dili programlaması göz önüne alındığında MPLAP ve Atmel Studio'daki ana farklar nelerdir .


2
PIC32 ile işler çalışıyorsa, geçişin anlamı nedir? Kod tamamen bağlansa bile (olmayacak), alışmak için hala yeni takım zinciri ve IDE var. Amaç ne? Dini nedenlerle geçiş yapmak veya "ARM tabanlı" (ya da başka bir şey) olmak aptalca. Bunun iyi bir sebebi olmalı ama bize hiç göstermedin.
Olin Lathrop

Geçiş hakkında soru sormadım. Birden fazla proje üzerinde çalışırken diğer projeler için farklı bir mimari seçmekten bahsettim + mevcut tasarımımızda iyileştirme için yer var. Ana nokta, öğrenme eğrisi ve aynı anda iki farklı mimariyle çalışmanın zorlukları hakkındaydı.
mühendis

Atmel Studio'nun MPLAB youtube video
mühendisi

Yanıtlar:


20

Bu oldukça tartışmalı bir konudur. Kendim için konuşabilirim (AVR, ARM, MSP430).

Fark 1 (en anlamlı) çevre birimlerinde. MCU'ların her birinin benzer UART, SPI, zamanlayıcılar vb. Vardır - sadece kayıt adları ve bitleri farklıdır. Çoğu zaman kod cips arasında taşırken uğraşmak zorunda kaldım ana sorun oldu. Çözüm: Sürücülerinizi ortak bir API ile yazın, böylece uygulamanız taşınabilir olabilir.

Fark 2, bellek mimarisidir. Bir AVR'ye flaşları sabit olarak yerleştirmek istiyorsanız, bunları okumak için özel nitelikler ve özel işlevler kullanmanız gerekir. ARM dünyasında sadece bir işaretçi serbest bırakıldınız çünkü tek bir adres alanı var (küçük PIC'lerin ne kadar üstesinden geldiğini bilmiyorum, ancak AVR'ye daha yakın olduklarını varsayalım).

Fark 3, kesinti bildirimi ve kullanımdır. avr-gccvardır ISR()makro. ARM'nin sadece bir işlev adı vardır (someUART_Handler () gibi - CMSIS üstbilgileri ve başlangıç ​​kodu kullanıyorsanız). ARM kesinti vektörleri herhangi bir yere yerleştirilebilir (RAM dahil) ve çalışma zamanında değiştirilebilir (örneğin değiştirilebilir iki farklı UART protokolünüz varsa çok kullanışlıdır). AVR yalnızca "ana flaş" veya "bootloader bölümünde" vektörleri kullanma seçeneğine sahiptir (bu yüzden kesintileri farklı işlemek istiyorsanız bir ififade kullanmanız gerekir ).

Fark 4 - uyku modları ve güç kontrolü. En düşük güç tüketimine ihtiyacınız varsa, MCU'nun tüm özelliklerinden yararlanmanız gerekir. Bu MCU arasında çok farklı olabilir - bazılarında daha kaba güç tasarrufu modları vardır, bazıları ayrı çevre birimlerini etkinleştirebilir / devre dışı bırakabilir. Bazı MCU'larda ayarlanabilir regülatörler vardır, böylece bunları daha düşük hızda daha düşük voltajla çalıştırabilirsiniz vb. bireysel çevresel saat kontrolü.

Taşınabilirlikle ilgilenirken en önemli şey, kodunuzu donanıma bağımlı (sürücüler) ve donanıma bağımlı olmayan (uygulama) parçalara ayırmaktır. İkincisini normal bir bilgisayarda sahte bir sürücüyle (örneğin, UART yerine konsol) geliştirebilir ve test edebilirsiniz. Prototip donanımı yeniden akış fırınından çıkmadan önce uygulama kodunun% 90'ı tamamlandığından bu beni birçok kez kurtardı :)

Bence ARM ile ilgili iyi olan şey "monokültür" dür - birçok derleyicinin (gcc, Keil, IAR ... birkaçını), birçok ücretsiz ve resmi olarak desteklenen IDE'ler (en azından NXP, STM32, Silikon Laboratuvarları, Nordic), birçok hata ayıklama aracı (SEGGER - özellikle Ozon, ULINK, OpenOCD ...) ve birçok çip satıcısı (onları adlandırmaya bile başlamayacağım). PIC32 çoğunlukla Microchip ile sınırlıdır (ancak yalnızca araçlarını beğenmediğinizde önemlidir.

C kodu söz konusu olduğunda. % 99 aynı, bir ififade aynı, bir döngü aynı şekilde çalışıyor. Ancak, yerel kelime boyutunu önemsemelisiniz. Örneğin , sayaç için forkullanırsanız AVR'deki bir döngü en hızlı uint8_t, ARM'de uint32_tise en hızlı tiptir (veya int32_t). Daha küçük bir tip kullandıysanız, ARM her seferinde 8 bitlik taşmayı kontrol etmelidir.

Bir MCU ve / veya satıcı seçilmesi genel olarak (: - Kullanım MSP430 veya Vorago yüksek sıcaklık örneğin çok net mühendislik kısıtlamaları, yoksa) çoğunlukla siyaset ve lojistik ile ilgili. Uygulama herhangi bir şey üzerinde çalışabilse ve kodun (sürücülerin) sadece% 5'inin ürün ömrü boyunca geliştirilmesi ve desteklenmesi gerekse bile, şirket için hala ekstra bir maliyettir. Çalıştığım tüm yerler bir favori satıcı ve MCU hattına sahipti ("farklı bir şey seçmek için çok iyi bir sebep olmadığı sürece istediğiniz herhangi bir Kinetis'i seçin" gibi). Yardım istemek için başka insanlarınız varsa da yardımcı olur, bu yüzden bir yönetici olarak herkesin tamamen farklı bir çip kullandığı 5 kişilik geliştirme departmanına sahip olmaktan kaçınırım.


3
“Sayaç için uint8_t kullanırsanız AVR en hızlı olurken ARM'de uint32_t en hızlı türdür (veya int32_t). Daha küçük bir tip kullandıysanız ARM'nin her seferinde 8 bit taşmasını kontrol etmesi gerekir. ” sadece en az 8 bite ihtiyacınız varsa uint_fast8_t kullanabilirsiniz.
Michael

@Michael - _fast türlerini kullanabileceğinizden emin olun, ancak taşma davranışına güvenemezsiniz. Benim gcc's stdint.h "temelde bir uint32_t :)" tipedef unsigned int uint_fast8_t "var
filo

Farklı platformların farklı yetenekleri olduğu düşünüldüğünde verimli, evrensel ve eksiksiz bir API yazmaya çalışmak zordur. CPU muhtemelen çevre birimlerinden ve onlarla verilen tasarım kararlarından daha az önemlidir. Örneğin, bazı aygıtlar çeşitli çevre birimlerinin herhangi bir zamanda en fazla birkaç mikrosaniye içinde yeniden yapılandırılmasına izin verirken, diğerleri yüzlerce mikrosaniye ve hatta milisaniye boyunca yayılmış birden fazla adım gerektirebilir. Önceki model için tasarlanan bir API işlevi, 10.000Hz'de çalışan bir kesme hizmeti rutini içinde kullanılabilir, ancak ...
supercat

... operasyonların yüzlerce mikrosaniyeden fazla yayılmasını gerektiren platformlarda böyle bir kullanımı destekleyemedi. Donanım tasarımcılarının neden "herhangi bir zamanda hızlı işlem" API semantiğini desteklemek için çok uğraşmadıklarını bilmiyorum, ancak birçoğu durum yerine bireysel işlemleri senkronize eden bir model kullanıyor, böylece örneğin bir istek verilmişse bir cihazı açtığınızda kodun açık olması gerekmediğini fark eder; kod, isteğin kapatılmasını sağlayabilmesi için cihazın açılmasını beklemelidir. Bunu bir API'de sorunsuz bir şekilde ele almak büyük komplikasyonlar ekler.
supercat

11

Dört farklı üreticiden birkaç MCU kullandım. Her seferinde ana çalışma çevre birimlerini tanımaktır.

Örneğin bir UART'ın kendisi çok karmaşık değil ve sürücülerimin bağlantı noktasını kolayca buluyorum. Ama saatler, G / Ç pimleri kesinti, etkinleştirme vb. Almak için son günüm neredeyse bir gün sürdü.

GPIO çok karmaşık olabilir. Bit seti, bit temizleme, bit değiştirme, Özel işlevler etkinleştirme / devre dışı bırakma, üç durumlu. Daha sonra kesintiler alırsınız: herhangi bir kenar, yükselme, düşme, seviye-düşük, seviye-yüksek, kendi kendini temizleme veya değil.

Daha sonra I2C, SPI, PWM, Zamanlayıcılar ve her biri kendi saatine sahip iki düzine çevre birimi daha var ve her yeni kayıtta kayıtlar farklı. Tüm bunlar için, veri sayfasını okumak hangi koşullar altında hangi bitin nasıl ayarlanacağını okumak saatlerce sürer.

Son üretici, kullanılamaz bulduğum birçok kod örneğine sahipti. Her şey soyutlanmıştı. Ama izini sürdüğümde, kod altı geçti! GPIO biti ayarlamak için fonksiyon çağrısı seviyeleri. 3GHz işlemciniz varsa ancak 48MHz MCU'da değilse güzel. Sonunda benim kodum tek bir satır oldu:

GPIO->set_output = bit.

Daha genel sürücüler kullanmaya çalıştım ama vazgeçtim. Bir MCU'da her zaman uzay ve saat döngüleri ile mücadele ediyorsunuz. 10KHz olarak adlandırılan bir kesme rutininde belirli bir dalga formu oluşturursanız, soyutlama katmanının pencereden ilk çıkan olduğunu buldum.

Şimdi her şeyim var ve çok, çok iyi bir sebep olmadığı sürece tekrar geçiş yapmamayı planlıyorum.

Yukarıdakilerin tümü, kaç ürün sattığınız ve ne kaydettiğiniz konusunda itfa edilmelidir. Bir milyon satmak: Farklı bir türe geçmek için 0,10 tasarruf, yazılım çalışma saatlerine 100.000 harcayabileceğiniz anlamına gelir. 1000 satarak sadece 100 harcayacaksınız.


1
Şahsen bu yüzden montajcıya bağlı kalıyorum. Güzel ikili, soyutlama yok.
Ian Bland

C'nin ön işlemcisi, özellikle __builtin_constant intrinsics ile birleştirildiğinde, işlerle oldukça iyi yapabilir. Her bir I / O için bir tanımlar sabit bir şekilde (port numarası * 32 + bit numarası) bit, bu bir makro yazmak mümkün OUTPUT_HI(n)kod eşdeğer elde edecek için GPIOD->bssr |= 0x400;ise n0x6A gibi bir sabittir, ama eğer basit bir alt yordam çağrı nIS sabit değil. Bununla birlikte, gördüğüm çoğu satıcı API'ları vasat ve korkunç arasında değişiyor.
supercat

8

Bu bir cevaptan çok bir görüş / yorumdur.

C programında istemiyorsunuz ve programlamamalısınız. C ++, doğru şekilde kullanıldığında çok daha üstündür. (Tamam, itiraf etmeliyim ki, yanlış bir şekilde kullanıldığında C'den çok daha kötüdür.) Bu, (modern) bir C ++ derleyicisine sahip olan ve AVR ( bazı sınırlamalar, filo tekdüze olmayan bir adres alanının sorunlarından bahseder), ancak neredeyse tüm PIC'leri (PIC32 desteklenebilir, ancak henüz iyi bir bağlantı noktası görmedim) hariç.

C / C ++ 'da algoritmaları programlarken, bahsettiğiniz seçenekler arasındaki fark küçüktür (16, 32 veya daha fazla bit aritmetiği yaptığınızda 8 veya 16 bit çip ciddi bir dezavantaj olacaktır). Performansın son onsuna ihtiyacınız olduğunda, muhtemelen montajcı kullanmanız gerekir (kendi kodunuz veya satıcı tarafından sağlanan kod veya üçüncü bir taraf). Bu durumda, seçtiğiniz çipi yeniden değerlendirmek isteyebilirsiniz.

Donanımı kodlarken bazı soyutlama katmanlarını (genellikle üretici tarafından sağlanır) kullanabilir veya kendiniz yazabilirsiniz (veri sayfasına ve / veya örnek koda dayalı olarak). IME mevcut C soyutlamaları (mbed, cmsis, ...) genellikle işlevseldir (neredeyse) doğrudur, ancak performansta korkunç bir şekilde başarısız olurlar (oldfarts'ın bir pim seti işlemi için yaklaşık 6 dolaylı dolaylama katmanı olduğunu kontrol edin), kullanılabilirlik ve taşınabilirlik. Belirli bir çipin tüm işlevlerini size açıklamak istiyorlar , neredeyse her durumda umursamayacağınız ve umursamayacağınız ve kodunuzu söz konusu satıcıya (ve muhtemelen o çipe) kilitler.

Bu C ++ çok daha iyi yapabilirdi: düzgün yapıldığında, bir pin seti 6 veya daha fazla soyutlama katmanından geçebilir (çünkü daha iyi (taşınabilir!) Bir arayüz ve daha kısa kod mümkün kılar), ancak hedeften bağımsız bir arayüz sağlayın basit durumlar için ve yine de montajcıda yazdığınızla aynı makine koduyla sonuçlanır .

Kullandığım kodlama stilinin bir parçası, ya sizi heyecanlandırabilir ya da dehşete kapabilir:

// GPIO part of a HAL for atsam3xa
enum class _port { a = 0x400E0E00U, . . . };

template< _port P, uint32_t pin >
struct _pin_in_out_base : _pin_in_out_root {

   static void direction_set_direct( pin_direction d ){
      ( ( d == pin_direction::input )
         ? ((Pio*)P)->PIO_ODR : ((Pio*)P)->PIO_OER )  = ( 0x1U << pin );
   }

   static void set_direct( bool v ){
      ( v ? ((Pio*)P)->PIO_SODR : ((Pio*)P)->PIO_CODR )  = ( 0x1U << pin );    
   }
};

// a general GPIO needs some boilerplate functionality
template< _port P, uint32_t pin >
using _pin_in_out = _box_creator< _pin_in_out_base< P, pin > >;

// an Arduino Due has an on-board led, and (suppose) it is active low
using _led = _pin_in_out< _port::b, 27 >;
using led  = invert< pin_out< _led > >;

Gerçekte daha soyutlama katmanları vardır. Ancak ledin son kullanımı, diyelim ki onu açmak için, hedefin karmaşıklığını veya ayrıntılarını göstermiyor (bir arduin uno veya ST32 mavi hapı için kod aynı olacaktır).

target::led::init();
target::led::set( 1 );

Derleyici tüm bu katmanlar tarafından korkutulmaz ve ilgili sanal işlevler olmadığından, iyileştirici her şeyi görür (çevre saatini etkinleştirmek gibi bazı ayrıntılar atlanmıştır):

 mov.w  r2, #134217728  ; 0x8000000
 ldr    r3, [pc, #24]   
 str    r2, [r3, #16]
 str    r2, [r3, #48]   

Bu şekilde montajcıda yazardım - PIO kayıtlarının ortak bir bazdan ofsetlerle kullanılabileceğini fark etseydim. Bu durumda muhtemelen yapardım, ancak derleyici böylesi şeyleri optimize etmede çok daha iyi.

Cevabım olduğu sürece, donanımınız için bir soyutlama katmanı yazın, ancak modern C ++ (kavramlar, şablonlar) ile yapın, böylece performansınıza zarar vermez. Bu ile kolayca başka bir çipe geçebilirsiniz. Hatta etrafında yerleştirdiğiniz, familiair olan, iyi hata ayıklama araçlarına sahip olan vb.Geliştirmeye başlayabilirsiniz ve son seçimi daha sonraya kadar erteleyin (gerekli bellek, CPU hızı vb. Hakkında daha fazla bilgi sahibi olduğunuzda).

IMO Gömülü gelişimin kusurlarından biri önce çipi seçmektir (bu forumda sıklıkla sorulan bir soru: hangi çip için seçmeliyim .... En iyi cevap genellikle: önemli değil.)

(edit - "Performans açısından, C veya C ++ aynı düzeyde mi?"

Aynı yapılar için C ve C ++ aynıdır. C ++, herhangi bir araç gibi, iyi veya kötü için kullanılabilen soyutlama için çok daha fazla yapıya sahiptir (sadece birkaç: sınıflar, şablonlar, constexpr). Tartışmaları daha ilginç hale getirmek için: herkes neyin iyi neyin kötü olduğunu kabul etmez ...


Peki performans açısından, C veya C ++ aynı seviyede mi? C ++ daha fazla aşırı yük olacak düşünüyorum. Kesinlikle beni doğru yöne doğrulttun, C ++ C'ye gitme yoludur
mühendis

C ++ şablonları, kod her bir belirli kullanım senaryosu için derlendiğinden, performans açısından sıfır (hatta negatif) maliyet olabilen derleme zamanı polimorfizmini zorlar. Ancak bu, hedefleme hızına (GCC için O3) en iyi şekilde uyum sağlama eğilimindedir. Çalışma zamanı polimorfizmi, sanal işlevler gibi, bakımı daha kolay ve bazı durumlarda yeterince iyi olmasına rağmen, çok daha fazla ceza alabilir.
Hans

1
C ++ 'nın daha iyi olduğunu iddia edersiniz, ancak daha sonra C tarzı dökümler kullanırsınız. Utanç.
JAB

@JAB Yeni tarz oyuncular için hiç bu kadar hissetmedim, ama onları deneyeceğim. Ama şu anki önceliğim bu kütüphanenin diğer kısımlarında. Asıl sorun, elbette, işaretçileri şablon parametreleri olarak geçiremediğimdir.
Wouter van Ooijen

@Cto (Time Objects Derleme) stilim oldukça dar bir kullanım senaryosuna sahiptir (donanıma yakın, derleme zamanı bilinen durum), sanal tabanlı OO'nun tranditional kullanımlarının yerine bir C katilidir. Yararlı bir bycatch, dolaylı yokluğun yığın boyutunun hesaplanmasını mümkün kılmasıdır.
Wouter van Ooijen

4

Doğru anlarsam, C dil ortamınızda platformun hangi mimariye özgü özelliklerinin "açıldığını" bilmek istersiniz, bu da her iki platformda da bakımı kolay, taşınabilir kod yazmayı daha zor hale getirir.

C zaten bir "portatif montajcı" olduğu için oldukça esnektir. Seçtiğiniz tüm platformlar, C89 ve C99 dil standartlarını destekleyen GCC / ticari derleyicilere sahiptir, yani tüm platformlarda benzer kodu çalıştırabilirsiniz.

Birkaç husus vardır:

  • Bazı mimariler Von Neumann (ARM, MIPS), diğerleri ise Harvard. Temel sınırlamalar, C programınızın ROM'dan veri okuması gerektiğinde ortaya çıkar, örneğin yazdırma dizeleri gibi, "const" veya benzeri olarak tanımlanan verilere sahipse.

Bazı platformlar / derleyiciler bu "sınırlamayı" diğerlerinden daha iyi gizleyebilir. AVR'de ROM verilerini okumak için belirli makrolar kullanmanız gerekir. PIC24 / dsPIC'de ayrıca özel tblrd talimatları da mevcuttur. Bununla birlikte, bazı parçalarda FLASH'ın bir sayfasının RAM'e eşlenmesine olanak tanıyan "veri alanı görünürlüğü" (PSVPAG) özelliği de mevcuttur. Derleyici bunu oldukça etkili bir şekilde yapabilir.

ARM ve MIPS Von Neumann'dır, bu nedenle ROM, RAM ve çevre birimleri için 1 veriyoluna paketlenmiş hafıza bölgeleri vardır. RAM veya "ROM" dan veri okumak arasında herhangi bir fark görmezsiniz.

  • C'nin altına dalarsanız ve belirli işlemler için oluşturulan talimatlara bakarsanız, G / Ç etrafında bazı büyük farklılıklar bulacaksınız. ARM ve MIPS, RISC yük deposu kayıt mimarisidir . Bu, bellek veriyolundaki veri erişiminin MOV talimatlarından geçmesi gerektiği anlamına gelir. Bu aynı zamanda, çevresel değerde yapılacak herhangi bir değişikliğin bir okuma-değiştirme-yazma (RMW) işlemine yol açacağı anlamına gelir. G / Ç çevre alanında set / clr-bit kayıtlarını eşleyen Bit-Bantlamayı destekleyen bazı ARM parçaları vardır. Ancak bu erişimi kendiniz kodlamanız gerekir.

Öte yandan bir PIC24, ALU işlemlerinin dolaylı adresleme yoluyla (işaretçi değişikliklerinde bile) doğrudan veri okumasına ve yazmasına izin verir. Bunun CISC benzeri bir mimariden bazı özellikleri vardır, bu nedenle 1 talimat daha fazla iş yapabilir. Bu tasarım daha karmaşık CPU çekirdeklerine, daha düşük saatlere, daha yüksek güç tüketimine vb. Yol açabilir. Neyse ki sizin için parça zaten tasarlanmıştır. ;-)

Bu farklılıklar, PIC24'ün benzer şekilde saatlendirilmiş bir ARM veya MIPS çipinden daha "gçlü" g / Ç işlemleri olabileceği anlamına gelebilir. Ancak, aynı fiyat / paket / tasarım kısıtlamaları için çok daha yüksek bir saatli ARM / MIPS parçası alabilirsiniz. Sanırım pratik terimler için, bence bir çok "platformu öğrenmek" mimarinin neler yapabileceğini ve yapamayacağını, birkaç işlem setinin ne kadar hızlı olacağını vs.

  • Çevre birimleri, saat yönetimi vb. Parça ailesine göre farklılık gösterir. Kesin olarak, NVIC ve SysTick gibi birkaç Cortex m bağlı çevre birimi dışında, satıcılar arasındaki ARM eko sisteminde de değişecektir.

Bu farklılıklar aygıt sürücüleri tarafından bir şekilde kapsüllenebilir, ancak sonunda gömülü bellenim donanım ile yüksek düzeyde bir bağlantıya sahiptir, bu nedenle özel çalışma bazen önlenemez.

Ayrıca, Microchip / eski Atmel ekosistemlerinden ayrılıyorsanız, ARM parçalarının onları çalıştırmak için daha fazla kurulum gerektirdiğini görebilirsiniz. Yani; çevre birimlerine saatler etkinleştirmek, daha sonra çevre birimlerini yapılandırmak ve "etkinleştirmek", NVIC'yi ayrı ayrı ayarlamak vb. Bu, öğrenme eğrisinin sadece bir parçasıdır. Tüm bunları doğru bir şekilde yapmayı hatırladığınızda, tüm bu mikrodenetleyiciler için aygıt sürücüleri yazmak bir noktada oldukça benzer hissedecektir.

  • Ayrıca, henüz yapmadıysanız stdint.h, stdbool.h vb. Gibi kütüphaneleri kullanmaya çalışın. Bu tamsayı türleri genişlikleri açık hale getirir, bu da kod davranışını platformlar arasında en öngörülebilir hale getirir. Bu, 8 bitlik bir AVR'de 32 bitlik tamsayıların kullanılması anlamına gelebilir; ama kodunuzun ihtiyacı varsa öyle olsun.

3

Evet ve hayır. Bir programcı bakış açısından, ideal olarak komut kümesinin ayrıntılarını gizlersiniz. Ancak bu, bir dereceye kadar, programın yazılmasının tüm noktası olan çevre birimlerinin, ilgili talimat setinin bir parçası olmadığı ile ilgilidir. Şimdi aynı zamanda 4096Byte flaş parçalarını bu komut setlerinde karşılaştıramazsınız, özellikle C kullanıyorsanız, flaş / belleğin tüketim miktarı talimat seti ve derleyici tarafından büyük ölçüde belirlenir, bazıları asla bir derleyici görmemelidir (öksürük PIC öksürük) derleyerek bu kaynakların ne kadar israfı tüketildiğinden dolayı. Diğerleri flaş tüketimi daha küçük bir ek yüktür. Performans, MCU uygulamalarında üst düzey bir dil ve performans konuları kullanırken de bir sorundur, bu nedenle mcu için kart başına 3 $ veya 1 $ harcamak arasında bir fark yaratabilir.

Programlamayı kolaylaştırmakla ilgili ise (ürünün toplam maliyetiyle), talimat seti mimarisinin hiç görmediğiniz bir şey olacak şekilde mcu için bir geliştirici paketi indirebilirsiniz. bir endişe değil. Hala bu kütüphaneleri kullanmak için ürünün maliyeti kadar para maliyeti, ancak, pazara sunma süresi daha kısa olabilir , kütüphanelerin kullanmak için daha fazla zaman / iş / doğrudan çevre birimleri ile konuşmak buldum.

Alt satırda talimat setleri endişelerinizin en azıdır, gerçek sorunlara geçin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.