Fråga:
Hur väljer jag en MCU-plattform?
ARF
2012-08-09 02:02:20 UTC
view on stackexchange narkive permalink

Det finns många MCU-plattformar och när någon väl har vant sig vid en, är de i allmänhet ovilliga att byta till en annan plattform.

Min fråga är: Om man började använda en MCU för allmänt ändamål uppgifter idag, hur skulle man kunna välja en? Vilka är de unika försäljningsställena för de olika plattformarna?

Låt oss veta vilka typer av projekt och volymer du tänker på, och det hjälper oss att besvara frågan.
Allmänt är * mycket * för brett. Det är lite meningsfullt att använda samma uC för att blinka en cykel-LED och för en RTOS med en högupplöst touch-färg-LCD.
Ja, du skulle helst ha flera marker du känner till för olika storleksproblem - och vara redo att plocka upp en ny om den är unikt lämpad för en uppgift.
@WoutervanOoijen Idén med denna fråga var som följer: det finns många uppgifter som någon av plattformarna enkelt kan hantera (dvs. allmänna uppgifter). Man står då helt fritt att välja mellan plattformar. I detta fall är de "mjuka faktorerna", t.ex. användarvänlighet, antal externa komponenter etc. blir dominerande. - Jag ville ta reda på vilka olika plattformar som fungerar bra / dåligt jämfört med andra.
R E L I G I O N
åtta svar:
Nick Alexeev
2012-08-09 03:46:55 UTC
view on stackexchange narkive permalink

Efter ett år höll jag ett föredrag om att välja mikrokontroller (det tog ungefär 1,5 timmar). Publiken var programvara och tillverkare på hög nivå. Majoriteten av publiken hade inte tidigare μC-upplevelse, resten har bara spelat med Arduino. Huvudantalet i publiken var cirka 30. Så detta var en multicast, i motsats till en en-mot-en-klinik.

Nyckelbilden i föredraget var detta:

Mått

för jämförelse av mikrokontroller. Listan är i fallande ordning.
  • Utvecklingsmiljö (verktygskedja)
    • Utvecklingsmiljö
    • Nämnde jag utvecklingsmiljö?
  • Support
    • Application notes
    • Peer support: tribal knowledge, friends, forums, teh codes [sic]
  • Funktioner
    • Minne
    • Kringutrustning
    • Beräkningsförmåga
  • Energiförbrukning
  • Kostnad

ps

Jag bör definiera det omfång som detta svar på mig är begränsat till. Jag ser denna plattforms urvalsfråga genom två typer av linser. Den första är en prototyper. Den andra är en utvecklare av professionell utrustning med gatupriser i storleksordningen $ 3 000 och kvantiteter i hundratals per år. Hobbyistlinsen är inte långt borta också. I dessa fall är den ökande kostnaden för mikrokontrollern liten, jämfört med kostnaden för utveckling, eller med kostnaden för den professionella utrustningen som mikrokontrollen går in i.

Det finns naturligtvis ett helt annat perspektiv på massproduktion. När någon väljer en mikrokontroller för en billig enhet som kommer att produceras i stora mängder (vanliga leksaker är ett bra exempel), kommer de att drivas av hårdvarukostnaden. En blygsam besparing i hårdvarukostnaden multiplicerad med en stor produktionsvolym (i hundratusentals eller mer) kan motivera smärtan med att använda en otrevlig utvecklingsmiljö och en prissatt mikrokontroller med mediochre-stöd.

Du fokuserar på utvecklingsmiljön. Låter rimligt. Vad var dina slutsatser?
@ArikRaffaelFunke Tja, dessa kulor i mitt inlägg ovan är slutsatserna. Inte avgörande nog? Mitt mål för samtalet var att: (1) Ge en minsta lista över de frågor som måste ställas under urvalsprocessen. (2) Visa var och hur man letar efter svar. Jag har specifikt undvikit att göra hårda slutsatser i linje: familjen X är bra om ..., familj Y är bra om ...
För små volymer och typiska krav, ja. Men ibland måste du välja den bästa tekniken. Eller om volymen är enorm kan ganska betydande huvudvärk under utveckling motiveras om det sparar några cent per widget - inklusive att testa lösningar baserade på konkurrerande delar och redo att hoppa till.
@ChrisStratton Strömförbrukning är en annan sak [förutom höga produktionsvolymeffekter], vilket ibland kan motivera viss huvudvärk. Lite kan göra om han vill ha mycket låg effekt, och uC (som han valde) kan inte stödja det.
Fokus på utvecklingsmiljö är helt rätt. Du kan ha det bästa chipet i världen men om du inte kan programmera och felsöka den jävla saken kan det lika gärna vara en tegelsten. Jag har hört bra saker om NXP, men ingen direkt upplevelse. Jag trodde Freescale var dålig, men sedan försökte jag TI (MSP och sedan DM36x) och nu är Freescale en lysande fyr av glans i mina ögon. Bästa råd med NÅGON utvecklingsmiljö: Bygg / installera den i en virtuell maskin och förvara en säkerhetskopia av den i fullt fungerande tillstånd så att den inte går sönder när du flyttar datorer / uppgraderar OS osv ...
En annan något annan lista över kriterier finns i [den här tråden] (http://electronics.stackexchange.com/a/28984/7036).
relaterat: [mikrokontrollerlandskap 2017, inklusive diskussion om utvecklingsmiljöer] (https://jaycarlson.net/microcontrollers/).
ARF
2012-08-12 00:42:00 UTC
view on stackexchange narkive permalink

Eftersom denna fråga inte riktigt har lett till den plattformsjämförelse jag hoppats på har jag försökt skapa en själv genom att studera litteraturen liksom de andra svaren. Kanske kan det hjälpa någon annan i framtiden.

Meddela mig om det finns några misstag eller om det finns information jag kan lägga till.


Jämförelse av plattform

Anmärkningar angående jämförelsen:

  • IDE: kommentarer gäller gratisversionen

PIC:

  • överlägset de billigaste nybörjarchipsen
  • många har interna spänningsregulatorer
  • till ett givet pris, har vanligtvis fler och bättre kringutrustning
  • kvasi industristandard: mycket bra bibliotek och support för utvecklare
  • IDE: NetBeans-baserade, enastående, inklusive fullständig offline-simulering och felsökning
  • tredjepartsfelsökare: cirka $ 25
  • mycket brett utbud av paket
  • unika försäljningsställen: 1. XLP = tillgängliga enheter med extra låg effekt; 2. många moderna marker har den kapacitiva avkänningsmodulen för beröringsknappar etc.

AVR:

  • AVR ligger vanligtvis efter omplacera kringutrustning och är något dyrare. På det hela taget liknar AVR dock mycket PIC i funktionalitet och pris.
  • 8bit AVR-chips är snabbare än 8bit PIC-chips
  • tredjepartsemulatorer: cirka $ 20
  • mycket brett utbud av paket

Arm Cortex-M:

  • modern processorarkitektur: ingen minnesbank, bra multitasking
  • överlägset de billigaste 32-bitarsenheterna
  • ganska lätt att flytta mellan olika chips och olika tillverkare
  • enheter kräver i allmänhet mer externa komponenter än PIC
  • mycket billiga USB-enheter med ROM-bootloader: NXP LPC1342 / LPC1343
  • rimligt biblioteksstöd
  • IDE: rimligt, ingen offline-simulering
  • SWD-gränssnitt tillåter programmering, felsökning och spårning i systemet med lätt att bygga hårdvara (
  • billiga NXP-marker finns bara i små eller mindre kortpaket
  • försäljningsställen: 1. billigaste 32-bitars plattformen; 2. billigaste plattformen med USB ROM bootloader

PSoc: (från Rocketmagnets svar)

  • king när det gäller analoga kringutrustning : ett givet chip kan konfigureras internt för att ge olika analoga och digitala kringutrustningar
  • betydligt dyrare än PIC: er
  • IDE: utmärkt
  • $ 88 programmerare (gör det tillåter felsökning?)
  • endast SMD-paket

Propeller: (från Rocketmagnets svar)

  • flerkärniga MCU: olika kärnor kan fungera simulerat på olika uppgifter kärnorna, ger otrolig flexibilitet
  • svag när det gäller analoga kringutrustning
  • IDE: utmärkt
  • DIP-paket tillgängligt

Jämförelse efter applikation

USB:

"Legend" för listan nedan:

  • bootloader = förprogrammerad USB-boo tloader
  • spänningsregulator = kan drivas från buss utan extern regulator
  • pullups = inget behov av extern pullup
  • impedansmatchning = inget behov av externa matchningsmotstånd
  • precisionsoscillator = inget behov av extern kristall

Egenskaper för den billigaste anordningen: (på ca. prisordning)

  • PIC: 8bit, låg- och fullhastighet, spänningsregulator, pullups, impedansmatchning, ESD-skydd
  • NXP: 32bit, bootloader, full- endast hastighet, ESD-skydd
  • Freescale: 8bit, endast låg hastighet, spänningsregulator, impedansmatchning, ESD-skydd
  • Atmel: 8bit, bootloader, endast full hastighet, spänningsregulator, pullup, ESD-skydd
  • STM: 32bit, bootloader, endast full hastighet, pullup, impedansmatchning, ESD-skydd
  • Silicon Laboratories: 8bit, låg- och fullhastighet, spänningsregulator, pullups, impedansmatchning, precisionsoscillator
  • TI: 32bit, bootloader, låg- och fullhastighet, andra egenskaper okända
  • PSoc: konfigurerbar som modul, andra egenskaper okända
  • Propeller: 32 bitar, endast bitbanging

Ethernet:

  • PIC: billigaste enhet med integrerad PHY
Få anteckningar här: Propeller har inte avbrott alls och det finns inget stöd för felsökning i den officiella IDE. Istället verkar den föredragna felsökningsmekanismen vara att ansluta saken till en TV och använda ett tillhandahållet bibliotek som visar variabler på skärmen. Dessutom finns det ingen kodavslutning, ingen simulator, ingen integration med kodhanteringssystem, ovanlig implementering av inkluderar ... Det finns inga kringutrustning för hårdvara utom de två räknarna per kärna, såvitt jag vet.
Har du också en källa för $ 20 AVR-emulatorn? Det är det vanliga priset för programmerare, enligt vad jag har sett.
@AndrejaKo Jag tänkte på [Olimex AVR-USB-JTAG] (https://www.olimex.com/dev/avr-usb-jtag.html). Tack för anteckningarna på Propellern. Jag kommer att inkludera dem i min nästa redigering.
Intressant enhet. Det verkar för mig att Atmel dödar av JTAG-aktiverade enheter till förmån för felsökningsenheter och det verkar nästan inte finnas några kloner av JTAGICE MK2.
Anmärkning om propellern - Den har INGEN avbrott. **Alls**. Om du behöver något som liknar en traditionell avbrott snurrar du upp ytterligare en CPU-kärna och får den snurra-vänta.
Efter att ha arbetat med propellern ganska omfattande skulle jag inte hålla med om ditt betyg på IDE. Personligen tycker jag att det är typ av en turd, det är i bästa fall medioker (Du kan inte använda flikar! Det har inget alternativ att stänga av tab-space-omvandling).
Hur skulle något liknande processorn xmos jämföras med dessa när det gäller enkelhet, flexibilitet och kapacitet? Jag förstår att xmos inte är en mikrokontroller som resten men det ser ut som en mycket attraktiv plattform med den inversa filosofin jämfört med propellrarna (en riktigt kraftfull kärna delas upp istället för många kärnor kombinerat).
@ArikRaffaelFunke Dina kommentarer till PIC verkar bara anta 8-bitars enheter. Du säger, "Arm Cortex-M har överlägset de billigaste 32-bitars enheterna". Att kontrollera Digi-Key, den billigaste PIC32 med 16K Flash och 4K RAM är $ 2,90. Den billigaste Arm Cortex-M med samma blixt och RAM är $ 2,65. Men PIC32 är faktiskt något billigare i 100 kvantiteter. I alla fall tycker jag att påståendet "överlägset billigast" för ARM inte är särskilt exakt. Och många versioner av PIC32 finns i ett DIP-paket, ovanligt för 32-bitars processorer.
En sådan lista är nästan oundvikligen meningslös och inaktuell. Alla tillverkare tävlar med varandra hela tiden och de flesta försöker erbjuda något i varje kategori - du gör en undersökning när du har behov, väljer en lösning och och om det fungerar kör du med den tills du har behov för vilken det finns en bättre lösning.
För vad det är värt kan du inkludera MSP430-linjen här också för sin extremt låga energiförbrukning
@ChrisStratton: En sådan lista på papper eller i ett 5-årigt blogginlägg skulle vara inaktuell. Listan kan dock redigeras så att den alltid har den senaste informationen.
["Inbäddade system / särskilda mikroprocessorer"] (http://en.wikibooks.org/wiki/Embedded_Systems/Particular_Microprocessors) har liknande information om hur man väljer en processor, som på samma sätt kan redigeras för att (förhoppningsvis) hålla den uppdaterad -datum och relativt neutralt.
@ConnorWolf det måste vara anledningen till att de kallar det en propeller - det måste ständigt snurra för att gå någonstans?: P
Rocketmagnet
2012-08-09 04:13:16 UTC
view on stackexchange narkive permalink

Ditt val av MCU beror mycket på vilken typ av projekt du ska arbeta med. Gör du högvolym, super billiga och enkla enheter som blinkande cykelljus? Utvecklar du komplexa prototyprobotar som har att göra med många bisarra IO-enheter och sensorer?

Jag arbetar mest med den senare. Det största problemet för mig är att försöka hitta mikrokontroller som har den kringutrustning jag vill ha. Detta är mycket svårt eftersom våra krav inte verkar vara vanliga. Vi vill ha saker som 5 PWM-kanaler, 5 kvadraturavkodare, 2 icke-standardiserade SPI-portar och en UART med negerad IO.

De enda MCU: erna jag har sett som enkelt kan hantera sådana krav är PSoC och Propellern.

Propeller chips

Propellen är i grunden åtta 32-bitars MCU i ett enda chip. Om du vill ha någon typ av kringutrustning programmerar du helt enkelt en av MCU: erna för att utföra det jobbet. Så du kan få vad du vill.

PSoC

PSoC: erna har två smaker, 3 och 5. 3 är en 8051-kärna och 5 är en ARM-cortex M3. På chipet ingår också omkonfigurerbara digitala och analoga block som kan göras till ett stort antal kringutrustning: ADC, filter, op-amp, DAC, SPI, UART, kvadraturavkodare, CRC-generator etc.

Utvecklingsmiljön är fantastisk. Du har den vanliga källkodsredigeringen av en typisk IDE, men du har också en schematisk redigerare. Du kan bokstavligen ansluta vilken digital krets du vill, ansluta kringutrustning med grindar, flipflops etc. Behöver du 5 PWM? Enkelt, lägg bara in dem i schemat, koppla ihop dem och så går du iväg. Du kan till och med skriva dina egna kringutrustning i Verilog om du vill ha något som inte tillhandahålls. En stor del av din applikation kan enkelt implementeras i denna typ av hårdvara.

Den verkliga fördelen är att du kan hålla fast med ett chip och veta att det kan hantera många av de projekt du vill göra i framtiden. Vad jag tyckte var irriterande med PIC: er trålade ständigt genom dussintals enheter som letade efter den som hade den specifika kringutrustning jag behövde. Nu har jag inte det problemet.

Propellern är ett märkligt koncept. Jag måste tänka lite på den. När det gäller PSoC: Jag har övervägt dem tidigare på grund av den otroliga flexibiliteten men behovet av en $ 250-programmerare gjorde det ganska mycket som en icke-start för mig.
@ArikRaffaelFunke - Programmeraren är bara [$ 88] (http://www.digikey.com/product-search/en/programmers-development-systems/in-circuit-programmers-emulators-and-debuggers/2621880?k=miniprog3) , mindre än hälften av priset för [ICD3] (http://www.digikey.com/product-search/en/programmers-development-systems/in-circuit-programmers-emulators-and-debuggers/2621880?k= icd3).
@ArikRaffaelFunke - en annan faktor är förpackning. Om du planerar att bygga dina egna prototyper är det mycket lättare att arbeta med DIP-paket. De flesta PIC: er och ATmel AVR: er finns i DIP, liksom Propeller. PSoC 3 och 5 gör det inte.
@tcrosley - Ja, det är en annan bra poäng. Det är något som många har bett Cypress om.
schmartboard har en enkel att använda smt to dip-lösning: http: //www.youtube.com/watch? v = -32orELxkpE
+1. Jag använde PSOC 1 (M8C-kärna), i DIP-paket, den dagen då PSOC 3 och PSOC 5 bara var rykten. Jag ser att "PSoC 4" nyligen har blivit tillgänglig. Nu 4 smaker?
hmm, detta publicerades 2012 men jag kommer att fråga hur som helst.Eftersom du har ett perifera krav som inte är mainstream, tänkte du någonsin att flytta över till mjukvaror (Alteras Nios II och Xilinxs picoblaze och microblaze)?Med en mjukporr på en FPGA finns det oändliga möjligheter för vad som kan sättas ihop på en enda FPGA.
@quantum231: Jag ansåg det men: 1) FPGA: er verkade generellt sett vara större och dyrare än mikrokontroller (och robotar har ofta desperat korta utrymme).Och 2) Jag har inte mycket erfarenhet av FPGA: er, och det är alltid ett besvär att behöva lära sig en helt annan verktygssats och sätt att tänka bara för någon mindre applikation.
Jag skulle inte rekommendera dessa för professionellt bruk, eftersom de har rekord för att göra sina produkter slut / föråldrade med kort varsel.
jippie
2012-08-09 02:30:03 UTC
view on stackexchange narkive permalink

För mig var det viktigaste kravet om enheten / IDE stöds väl på min icke-Windows-dator (Linux). Visade sig att för mig hade Atmel AVR bättre (öppen källkod) support än PIC.

Visual Micro
2012-08-21 22:04:19 UTC
view on stackexchange narkive permalink

Att använda mer än en plattform är okej. Välja den bästa för varje jobb och även tillgänglighet av kod och exempel relaterade till jobbet.

De flesta av dem har bra utvecklingsverktyg, arduino har visual studio, pic har ett fantastiskt verktyg och det gör andra också. Så för mig är det hur snabbt och enkelt kan jag få jobbet gjort bra, + hur många personer med öppen källkod som arbetar med samma sak?

Men hur hittar man sådan information utan att bli vilseledd av marknadsförstånd.Jag menar, vi måste hitta människor som har använt hårdvaran och verktygskedjan för att få all den informationen.Hur hittar du sådana samhällen i ditt jobb?Eller är det att du litar på vad applikationsingenjören säger till dig?
Du kan ställa frågor på olika forum som detta.Förklara din ansökan och be om hjälp
boz
2012-08-13 12:08:23 UTC
view on stackexchange narkive permalink

Mikrokontroller är en värld som förändras snabbt, det finns många fördelar med att lära sig om de aktuella "in" -chipsen och mest populära IDE: s mest anmärkningsvärda är att få hjälp från samhället. Som PIC-person skulle jag säga att Aduino förmodligen har de bästa IDE- och utvecklingskorten för nybörjare just nu och du kan lägga till mycket på ett grundläggande aduino-kort utan att röra vid ett lödkolv.

Den som använder en aduino för verkliga saker kanske snart vill gå vidare men vid den tiden har du lärt dig en hel del grundläggande digital elektronik och en bra delmängd av C för att enkelt använda något mer lämpligt.

Som någon har nämnt du väljer chipet för ditt projekt, jag har sett några projekt som använder ARM-chips som enkla temperatursensorer eller AD-omvandlare, på samma sätt som jag har sett aduinos och PIC 16's drivit till sin gräns för att generera ett space invaders-spel, FPGA är galso reat och det är bra att förstå HDL om du seriöst går in i elektronikdesign .. men tyvärr finns det inte många projekt där ute i den verkliga världen där du kommer att behöva använda ett flertal jobb är låg volym, snabb design och prisbegränsade och det är här 8 bitars uC regerar högsta

Jag förstår, vilka begränsningar har Arduino för att en person skulle få en person att röra sig bortom dem?Har ARM mer processorkraft än PIC och Arduino, har den kringutrustning som inte finns i PIC och Arduino, eller är dess verktygskedja överlägsen vad som finns för PIC och Arduino?Varför så mycket buller om ARM-baserade marker.Jag vet att de har mycket låg strömförbrukning men varför skulle ARM annars väljas för "allvarliga" projekt?
Lundin
2019-01-10 20:55:14 UTC
view on stackexchange narkive permalink

Eftersom många av de upplagda svaren fokuserar på hobbyanvändning kommer här olika rekommendationer riktade till professionella utvecklare.

Bär minsta krav
Om MCU inte uppfyller alla dessa bör den inte användas.

  • Har varit i produktion i minst ett år.
  • Silicon errata är tillgängligt och har reviderats minst en gång.
  • Intern vakthund.
  • Intern lågspännings- / avbrottdetektering.
  • Flash-minne på chip.
  • ESD-skydd.
  • JTAG / SWD eller något felsökningsgränssnitt med en tråd.
  • Kärnan använder 8 bitars byte och 2 komplement signatur.
  • Prover och utvärderingstavlor är lätt tillgängliga.
  • Har responsiv teknisk support direkt från tillverkaren.

Wvarningsskyltar - MCU-hårdvara
Det här är saker du inte bör slösa med tid under år 2019.

  • Oklara adresseringslägen som måste hanteras av programmeraren. Inklusive användning av obskyra, icke-standardiserade nyckelord för att få åtkomst till ROM-data.
  • Allvarliga stackminne eller stackdjupbegränsningar.
  • 16-bitars int , som i sin tur kommer med alla dolda faror med C-språkens heltalskampanjer.
  • Kan inte utföra 16 eller 32 bitars aritmetik utan att börja koka.
  • Fångar inte om du kör kod i datasektioner.
  • Ingen instruktionsspårningsbuffert.
  • Levereras med exotiska hårdvaruutrustning som du inte har någon användning för.

WVarningsskyltar - verktygskedja

  • Förlitar sig på mjukvarusimulatorer på PC eller på något sätt av bootloader, istället för att blinka hela MCU och använda exekvering / felsökning på chip.
  • Levereras inte med färdiga drivrutiner / exempel / bibliotek skrivna av proffs. Förlitar sig på att utvecklare återuppfinner hjulet eller internetforum / öppen källkod.
  • CRT för C-kompilatorn uppfyller inte kraven här.
  • C-kompilatorn levereras med en lång lista med standard C-funktioner som inte stöds.
  • C-kompilatorn stöder fortfarande inte C11 (oavsett om du tänker använda den eller inte).
  • IDE spionerar flera konstiga länkarfel åt dig första gången du försöker ett "Hello World" -program.
  • Att stöta på många IDE- eller kompileringsfel under de första veckorna av användning.
Detta är alltför dogmatiskt.Du har helt utelämnat kostnad, förpackningsalternativ, (öppen källkod! = Oprofessionellt), kvalitet på kringutrustning osv.betyder att du måste känna till avvägningen som i första hand ledde till dessa begränsningar.
@awjlogan Kostnads- och förpackningsalternativ är väldigt projektspecifika, så det är inte meningsfullt att ta upp här.Jag sa inte att öppen källkod är oprofessionellt, men ett företag som lägger ut sin verktygskedja till öppen källkod och deras stöd till webbplatser som SO är inte professionellt.Även om open source-projekt med för få bidragsgivare inte är professionella heller, vilket vi kan se med kompileringsportar med öppen källkod till olika exotiska MCU: er.Det borde inte finnas några skäl att välja en MCU med begränsad stack år 2019.
Visst, de är projektspecifika men du har genast ökat din baslinjekostnad genom att ange 16/32 bit * endast * i din lista (snabb genomsökning av Digikey) och jag har inte sett en 6-stifts M0 nyligen.Om du inte behöver något (inklusive tid), spendera inte extra pengar på det, det är de beslut du bör fatta som professionell.Men ja, bra verktyg är så viktigt, kan inte hålla med mer.
@awjlogan LPC81X har funnits i över 5 år.Jag fick nyligen veta om Cypress PSoC4 som ser intressant ut.Och så vidare.Antalet stift är inte ofta ett argument, bara paketstorlek och typ.Om du tål QFN eller BGA kan du få mycket små marker.
var överens om att dina val begränsas i liten storlek (samma för alla arkitekturer men).Min övergripande poäng är att även om alla saker på din lista är önskvärda, bör du också vara tillräckligt ledig för att veta när du ska bryta dem.
@awjlogan Huvudargumentet här är att inte välja lite icky 8-bitter bara för att man har bott under en sten de senaste 20 åren, utan att fatta ett välgrundat beslut baserat på hur marknaden ser ut nu, inte baserat på hur den såg ut iår 1995.
absolut, jag håller helt med, men ett "informerat beslut" borde vara rationellt och inte dogmatiskt.
@awjlogan Du kommer att ha svårt att hitta någon som är mer dogmatisk än 8-bitars lobbyn.De fick slut på giltiga argument för 10 år sedan och ändå fortsätter de.
Återigen håller jag helt med!:)
ganesh737
2014-07-03 08:42:37 UTC
view on stackexchange narkive permalink

Om du går till allmänna uppgifter som kan ha analog och digital bearbetning skulle jag ha föredragit PSoC för dess IDE, Debugger och det stora antalet saker du kan göra med dessa.

Jag har använde PSoC3 på college för mina projekt och det är ganska enkelt att bemästra. Det enda är att om du behöver prestationschips måste du fortfarande få dem separat. Den har tillräckligt bra portar. Så om du letar efter några prestandamarker tillsammans med utvecklingssatsen, bör du bättre välja separata komponenter.

Det kan vara värt att lägga till lite mer information om PSoC för att göra detta mer användbart, ett par andra svar täcker det redan.
@PeterJ: Jag ville ge detta som en kommentar till Rocketmagnets svar men jag har inget rykte att ge en kommentar.
Finns det en anledning till att du inte gick för mjukporrbaserad design som att använda Nios II på Altera FPGA eller microblaze / picoblaze på en Xilinx FPGA?De kan användas för att få samma effekt som PSoC och jag skulle påstå att det på många sätt är ett överlägset val.
@quantum231: Jag accepterar det, men den största begränsningen för mig vid den tiden var budgeten och den var tillgänglig gratis i vår elektronikavdelning.


Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...