68k var väl top-of-the-line i sin tid vad jag minns. Det var tydligen den man skulle ha om man behövde lite prestanda och jag har hör några som berömde hur lätt den var att koda osv.
Men det tillverkas ju fortfarande 8031/8051-baserat system än i dag och den kärna är ju ålderdomlig så det känns. Javisst har det kommit uppgraderade versioner men i grunden är den gammal och död, det finns dock så mycket program och verktyg till den att den lever på än.
Repaterion: du behöver inte be om ursäkta (jo, jag fattar att du försöker vara spydig), du behöver däremot ta till dig den information du får! Alla svarar att det inte är mikroprocessorn som definierar projektet men tvärtom, ändå kör du hårt i det spår. Om du har ett specifikt projekt och behöver hjälp med att hitta lämplig µC kan du lägga fram det men även där vill svaret bli med stor spridning, alltså många olika möjligheter.
Och är det ett projekt som du känner kan expandera eftersom kan det vara lönt att faktisk välja efter det största man kan tänka sig, då kan man expandera eftersom.
Ett exempel: du vill testa att styra en stegmotor. Det kan göras mycket enkelt med en minimal µC men vad nu om du drömmar om att bygga en 3D skrivare? Då ville det vara bättre att med en gång ta en µC som klarar hela jobbet direkt, speciellt om det ska tillverkas kretskort osv. När grundsystemet är klart kan du då börja leka med att styra stegmotorn, när det fungerar kan du leka med att styra två och sedan stadigt expandera systemet till du har det kompletta system klart.
PIC | AVR | ARM | o. motsv.
-
Repaterion
- Inlägg: 597
- Blev medlem: 4 februari 2011, 00:57:32
- Ort: Gustavsfors (Lite till vänster om världens utkant)
Re: PIC | AVR | ARM | o. motsv.
Jag tar åt mig information när den kommer, men om någon säger att projektet styr så säger inte det speciellt mycket igentligen.
För det måste vara skillnader iom att en pic kan vara ett bättre val i vissa fall än en avr och vice versa, och så vitt jag har läst har det inte kommit ett enda exempel som gett en finger visning åt vilket håll som är bättre eller sämre av vad som kan då kan vara ett bättre val.
Om man gämnför det med ett bil köp, vilken bil skall man ha?
Vill man maxa på Autobahn inte fasen skaffar man sig en Opel Corsa -84
Är man en familj så vill man antagligen ha en mellanklass bil, i vart fall om man bor på landsbygden.
Bor man i en stad och inte kör så ofta så är väll en småbil antagligen ett bra val.
Men det tyder på att det inte är någon idé att tjafsa vidare för det ser inte ut som att det blir någon enkel utväg i detta ämne.
För det måste vara skillnader iom att en pic kan vara ett bättre val i vissa fall än en avr och vice versa, och så vitt jag har läst har det inte kommit ett enda exempel som gett en finger visning åt vilket håll som är bättre eller sämre av vad som kan då kan vara ett bättre val.
Om man gämnför det med ett bil köp, vilken bil skall man ha?
Vill man maxa på Autobahn inte fasen skaffar man sig en Opel Corsa -84
Är man en familj så vill man antagligen ha en mellanklass bil, i vart fall om man bor på landsbygden.
Bor man i en stad och inte kör så ofta så är väll en småbil antagligen ett bra val.
Men det tyder på att det inte är någon idé att tjafsa vidare för det ser inte ut som att det blir någon enkel utväg i detta ämne.
Re: PIC | AVR | ARM | o. motsv.
> men om någon säger att projektet styr så säger inte det speciellt mycket igentligen.
Det säger om inte allt så i alla fall väldigt mycket om hur det är "out there", i det som kallas "verkligheten".
> För det måste vara skillnader iom att en pic kan vara ett bättre val i vissa fall än en avr och vice versa,
Självklart är det skillnader ! (Och det heter PIC och AVR.)
> ...åt vilket håll som är bättre eller sämre av vad som kan då kan vara ett bättre val.
Skillnader i sig är inte mycket mer än just det, skillnader. Det ligger ingen värdering i det.
"Bättre" eller "sämre" kan det bara bli när dessa skillnader ställs i rellation till ett faktiskt behov
eller projekt. Det verkar vara just det som du inte fattar.
> Vill man maxa på Autobahn...
Där har du ett konkret krav ! Och *det* gör olika bilar "bättre" eller "sämre" *i just det konkreta fallet*.
Men det gör ju inte en Corsa (varför just -84 ??) till en sämre bil rent generellt.
> för det ser inte ut som att det blir någon enkel utväg i detta ämne.
Nej, för den finns helt enkelt inte !
Din frågeställning visar bara på okunnighet i ämnet. Varför inte lyssna och lära ?
Det säger om inte allt så i alla fall väldigt mycket om hur det är "out there", i det som kallas "verkligheten".
> För det måste vara skillnader iom att en pic kan vara ett bättre val i vissa fall än en avr och vice versa,
Självklart är det skillnader ! (Och det heter PIC och AVR.)
> ...åt vilket håll som är bättre eller sämre av vad som kan då kan vara ett bättre val.
Skillnader i sig är inte mycket mer än just det, skillnader. Det ligger ingen värdering i det.
"Bättre" eller "sämre" kan det bara bli när dessa skillnader ställs i rellation till ett faktiskt behov
eller projekt. Det verkar vara just det som du inte fattar.
> Vill man maxa på Autobahn...
Där har du ett konkret krav ! Och *det* gör olika bilar "bättre" eller "sämre" *i just det konkreta fallet*.
Men det gör ju inte en Corsa (varför just -84 ??) till en sämre bil rent generellt.
> för det ser inte ut som att det blir någon enkel utväg i detta ämne.
Nej, för den finns helt enkelt inte !
Din frågeställning visar bara på okunnighet i ämnet. Varför inte lyssna och lära ?
-
Repaterion
- Inlägg: 597
- Blev medlem: 4 februari 2011, 00:57:32
- Ort: Gustavsfors (Lite till vänster om världens utkant)
Re: PIC | AVR | ARM | o. motsv.
Hade en tanke om att svara men jag tror jag skiter i det.
Tröttnat på att kallas det ena och det andra när man försöker få svar i ämnen man nyss börjat kolla på,
det ger ju inget vidare lyft med den attityden mot sig så jag får helt enkelt gå min egen väg...
Kan någon lika gärna låsa tråden innan total pajkastning utbryter...
Tröttnat på att kallas det ena och det andra när man försöker få svar i ämnen man nyss börjat kolla på,
det ger ju inget vidare lyft med den attityden mot sig så jag får helt enkelt gå min egen väg...
Kan någon lika gärna låsa tråden innan total pajkastning utbryter...
Re: PIC | AVR | ARM | o. motsv.
OK.
Vi får hoppas att du tar med dig svaren och att du har
nytta av dom i framtiden. För du har fått i princip korrekta svar.
Och *jag* har i alla fall inte kallat dig någonting speciellt.
Att påstå du saknar en del erfaranhet i ämnet du frågar om,
kan ju knappast tolkas som att "kallas det ena och det andra".
Om du hade kunnat detta så hade du ju aldrig frågat som du gjorde.
Dessutom är det ju lite löjligt att först säga att du "just har börjat kolla på det",
men när du får svar så är svaren avgjort felaktiga och du vet bättre ?
Nej, den ursprungliga frågeställningen är nog lätt att fomulera, och det kan vara lätt
att tro att den har ett enkelt svar. Men det är lika omöjligt som den klassiska frågan
om "Expressen eller Aftonbladet". Det "beror på", helt enkelt.
Att begära låsning av denna tråd verkar lite onödigt.
Vi får hoppas att du tar med dig svaren och att du har
nytta av dom i framtiden. För du har fått i princip korrekta svar.
Och *jag* har i alla fall inte kallat dig någonting speciellt.
Att påstå du saknar en del erfaranhet i ämnet du frågar om,
kan ju knappast tolkas som att "kallas det ena och det andra".
Om du hade kunnat detta så hade du ju aldrig frågat som du gjorde.
Dessutom är det ju lite löjligt att först säga att du "just har börjat kolla på det",
men när du får svar så är svaren avgjort felaktiga och du vet bättre ?
Nej, den ursprungliga frågeställningen är nog lätt att fomulera, och det kan vara lätt
att tro att den har ett enkelt svar. Men det är lika omöjligt som den klassiska frågan
om "Expressen eller Aftonbladet". Det "beror på", helt enkelt.
Att begära låsning av denna tråd verkar lite onödigt.
Re: PIC | AVR | ARM | o. motsv.
Jag ska försöka ge dig ett svar som alla andra kommer såga
Nu när jag jämför så tittar jag på enchipslösningar som i stort sätt enbart kräver ev en kristall och strömförsörjning samt några passiva komponenter för att kunna köra.
Pris:
Här är det en enda djungel tycker jag. Det finns 8-32 bitars MCUer som ligger i ung samma prisklass runt 3-4$ i vissa fall kan en gammal 8bitars PIC vara dyrare än den än en ny variant av t.ex arm7.
Kapselstorlek:
PIC har tydligen en kapsel på 8 pinnas om är extremt liten. Generellt är det lättare att löda 8-16 bitars varianterna av PIC-AVR eftersom de har SOIC kapsel (eller hålmonterade ) som har lite större avstånd mellan benen. Är man bra på att löda finns det QFN etc som är lite lurigare att handlöda på kortet.
Perferienheter:
Oftast brukar det vara så att en större kapsel ger fler möjligheter till perferienheter. De flesta har ung samma förutom om man behöver något speciellt som USB, CAN, TCP/IP, DA där man tidigare fått välja antingen det ena eller det andra.
Programminne:
Kapslar mer fler antal ben brukar ha större flash-minne. Det finns vissa varianter av t.ex PIC som har lågbudget flash som bara kan programmeras om ett visst antal gånger.
Strömförbrukning:
8-16 bitars varianterna har tidigare varit väldigt strömsnåla och är det även nu. Men det finns även väldigt strömsnåla varianter av t.ex ARM7 och MIPS som drar något mer i ström. Har man ingen batteridriven applikation där strömförbrukningen är extremt viktig spelar detta ofstast mindre roll. större roll spelar isf valet av t.ex dcdc omvandlare, layout av kretskort med pullups/pulldown, kodarkitektur etc.
Uppstartssträcka:
Ofast är det något lättare att sätta sig in i och förstå en liten kapsel jämför med en större. Men i de flesta fall utgår man från ett färdigt programexempel och modifierar detta efter sina egna önskemål. Därför ser jag inte någon direkt skillnad mellan att starta med en 8-bitars jämfört med en 32bitas. En timer, SPI, I2C, ADC etc har ung samma typer av inställningar oavsätt arkitektur. Interrupthanteringen kan ske på lite olika sätt och de större arkitekturerna kan hitta på mer "magi" i bakgrunden så att man faktiskt kan göra saker paralellt. denna magi kräver lite extra inställningar och förståelse.
Modulerbrahet:
När jag pysslat med mina 8-16 bitars MCUer så kommer det ofa nya varianter i nya kapslar där man ändrat lite på registerna. Mycket är sig likt men det tar ändå tid att hitta och porta om koden så att man kommer runt skillnaden. Därför gillar jag att hålla mig till en typ av arkitektur som jag kan bättre än att hoppa fram o tillbaka mellan kapslar som är "nästan" likadana. Det jag menar med nästan är t.ex de äldre varianterna av PIC-16 serien där t.ex timer-register var samma medan inställningar för oscillator och strömförbrukning skilde sig åt.
Eftersom jag kunde pic sedan tidigare lärde jag mig dspic och 24 serien där mycket är lika och i stort sätt bara kapseln skiljer. De problem jag stötte på var att när man försöker sig på lite mer avancerade grejjer, t.ex att man vill ha flera processer igång samtidigt eller styra en display, TCP/IP el liknande så hade dessa kapslar för lite kraft.
Därför försöker jag nuförtiden lära mig en MCU som man kan få i olika kapselstorlekar beroende på om man har mycket eller lite plats på kretskortet (STM32)
jag har säkert glömt några aspekter, ni får gärna kompletera.
Sammafattnignsvis ser jag i dagsläget inga större skillnader mellan 8-16 bitars processorer jämfört med de större arkitekturerna. Den största skillnaden är att gamla rävar ofta rekomenderar gamla små processorer som ska programmeras med ASM eftersom det är just detta som de är experter på.
Om man ser framåt ser jag ingen framtid för 8-16 bitas kapslar när priset , strömförbrukningen och storleken sjunker på de mer avancerade kapslarna.
Nu när jag jämför så tittar jag på enchipslösningar som i stort sätt enbart kräver ev en kristall och strömförsörjning samt några passiva komponenter för att kunna köra.
Pris:
Här är det en enda djungel tycker jag. Det finns 8-32 bitars MCUer som ligger i ung samma prisklass runt 3-4$ i vissa fall kan en gammal 8bitars PIC vara dyrare än den än en ny variant av t.ex arm7.
Kapselstorlek:
PIC har tydligen en kapsel på 8 pinnas om är extremt liten. Generellt är det lättare att löda 8-16 bitars varianterna av PIC-AVR eftersom de har SOIC kapsel (eller hålmonterade ) som har lite större avstånd mellan benen. Är man bra på att löda finns det QFN etc som är lite lurigare att handlöda på kortet.
Perferienheter:
Oftast brukar det vara så att en större kapsel ger fler möjligheter till perferienheter. De flesta har ung samma förutom om man behöver något speciellt som USB, CAN, TCP/IP, DA där man tidigare fått välja antingen det ena eller det andra.
Programminne:
Kapslar mer fler antal ben brukar ha större flash-minne. Det finns vissa varianter av t.ex PIC som har lågbudget flash som bara kan programmeras om ett visst antal gånger.
Strömförbrukning:
8-16 bitars varianterna har tidigare varit väldigt strömsnåla och är det även nu. Men det finns även väldigt strömsnåla varianter av t.ex ARM7 och MIPS som drar något mer i ström. Har man ingen batteridriven applikation där strömförbrukningen är extremt viktig spelar detta ofstast mindre roll. större roll spelar isf valet av t.ex dcdc omvandlare, layout av kretskort med pullups/pulldown, kodarkitektur etc.
Uppstartssträcka:
Ofast är det något lättare att sätta sig in i och förstå en liten kapsel jämför med en större. Men i de flesta fall utgår man från ett färdigt programexempel och modifierar detta efter sina egna önskemål. Därför ser jag inte någon direkt skillnad mellan att starta med en 8-bitars jämfört med en 32bitas. En timer, SPI, I2C, ADC etc har ung samma typer av inställningar oavsätt arkitektur. Interrupthanteringen kan ske på lite olika sätt och de större arkitekturerna kan hitta på mer "magi" i bakgrunden så att man faktiskt kan göra saker paralellt. denna magi kräver lite extra inställningar och förståelse.
Modulerbrahet:
När jag pysslat med mina 8-16 bitars MCUer så kommer det ofa nya varianter i nya kapslar där man ändrat lite på registerna. Mycket är sig likt men det tar ändå tid att hitta och porta om koden så att man kommer runt skillnaden. Därför gillar jag att hålla mig till en typ av arkitektur som jag kan bättre än att hoppa fram o tillbaka mellan kapslar som är "nästan" likadana. Det jag menar med nästan är t.ex de äldre varianterna av PIC-16 serien där t.ex timer-register var samma medan inställningar för oscillator och strömförbrukning skilde sig åt.
Eftersom jag kunde pic sedan tidigare lärde jag mig dspic och 24 serien där mycket är lika och i stort sätt bara kapseln skiljer. De problem jag stötte på var att när man försöker sig på lite mer avancerade grejjer, t.ex att man vill ha flera processer igång samtidigt eller styra en display, TCP/IP el liknande så hade dessa kapslar för lite kraft.
Därför försöker jag nuförtiden lära mig en MCU som man kan få i olika kapselstorlekar beroende på om man har mycket eller lite plats på kretskortet (STM32)
jag har säkert glömt några aspekter, ni får gärna kompletera.
Sammafattnignsvis ser jag i dagsläget inga större skillnader mellan 8-16 bitars processorer jämfört med de större arkitekturerna. Den största skillnaden är att gamla rävar ofta rekomenderar gamla små processorer som ska programmeras med ASM eftersom det är just detta som de är experter på.
Om man ser framåt ser jag ingen framtid för 8-16 bitas kapslar när priset , strömförbrukningen och storleken sjunker på de mer avancerade kapslarna.
Re: PIC | AVR | ARM | o. motsv.
>PIC har tydligen en kapsel på 8 pinnas om är extremt liten.
PIC finns från 6 till flera hundra pinnar.
PIC finns från 6 till flera hundra pinnar.
Re: PIC | AVR | ARM | o. motsv.
Finns väl ingen anledning att såga det där, men det är ju inte
heller något svar på frågan "vilken är bäst?"...
> Om man ser framåt ser jag ingen framtid för 8-16 bitas kapslar när priset,
> strömförbrukningen och storleken sjunker på de mer avancerade kapslarna.
Ja.
Haken är just det där lilla order "när".
Det är inte så idag. Och ingen vet när "när" inträffar.
heller något svar på frågan "vilken är bäst?"...
> Om man ser framåt ser jag ingen framtid för 8-16 bitas kapslar när priset,
> strömförbrukningen och storleken sjunker på de mer avancerade kapslarna.
Ja.
Haken är just det där lilla order "när".
Det är inte så idag. Och ingen vet när "när" inträffar.
Re: PIC | AVR | ARM | o. motsv.
Det e klart att man inte vet "när" det blir. Men enligt min uppfatting så är det väldigt små skillnader i dagsläget. Därför ser jag ingen anledning att lära sig en arkitektur på är påväg bort (även om alla arkiteturer är påväg bort). Om man ska jämföra det med bilar så ser jag en pic/avr 8-16 6 bitars som en volvo 240. Den fungerar, kör stabilt och man vet hur man lagar den. Men den börjar bli väldigt omodern och man kommer troligtvis lägga mycket tid på att reparera o fixa samt att man skulle vilja ha något mer t.ex AC, antisladd eller andra funktioner som är bekväma.
[edit] fasen, nu kom jag nog ner i pajkastningsträsket. går det att ta bort inlägg i efterhand?
[edit] fasen, nu kom jag nog ner i pajkastningsträsket. går det att ta bort inlägg i efterhand?
Re: PIC | AVR | ARM | o. motsv.
Ja, om det är det sista/senaste inlägget i tråden,
men det är det ju inte längre...
men det är det ju inte längre...
-
Swech
- EF Sponsor
- Inlägg: 4750
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: PIC | AVR | ARM | o. motsv.
Det är väl svårt att säga att någon arkitektur är på väg bort.
PIC(16) och AVR bygger på samma teknik som för över 10 år sedan.
Nyare modeller kan vara nyskapande men de gamla volvo 240 modellerna lever vidare.
8086 dör väl tyvärr aldrig
68000 som nämnts är dock ganska död
Det som Repaterion verkar vilja göra är inte det mest avancerade vilket innebär att
i princip alla processorer klarar av jobbet.
Eftersom alla klarar det så blir det mer känslor involverade om man skall rekommendera någon.
Hade kravet varit 4GHZ och 10GFlops så skulle det vara enklare att välja..
Swech
PIC(16) och AVR bygger på samma teknik som för över 10 år sedan.
Nyare modeller kan vara nyskapande men de gamla volvo 240 modellerna lever vidare.
8086 dör väl tyvärr aldrig
68000 som nämnts är dock ganska död
Det som Repaterion verkar vilja göra är inte det mest avancerade vilket innebär att
i princip alla processorer klarar av jobbet.
Eftersom alla klarar det så blir det mer känslor involverade om man skall rekommendera någon.
Hade kravet varit 4GHZ och 10GFlops så skulle det vara enklare att välja..
Swech
Re: PIC | AVR | ARM | o. motsv.
Har haft en dator som har haft Hz men inte HZ 
8086.. tänk om den kunde hamna på den historiska skrothögen
8086.. tänk om den kunde hamna på den historiska skrothögen
Re: PIC | AVR | ARM | o. motsv.
När ni säger 8086 tänker ni på hela x86 arkitekturen då eller specifikt på just den processorn?
För inte är väl 8086 att betrakta som fullt levande fortfarande?
För inte är väl 8086 att betrakta som fullt levande fortfarande?
Re: PIC | AVR | ARM | o. motsv.
"8086" används till största delen av de som gärna ser att man fokuserar
just på den historiska bakgrunden till dagens Intel standard processorer.
D.v.s ur ett negativt sett att se på det. Det är så klart väldigt stor
skillnad på en modern Intel processor av samma grundarkitektur jämfört
med en av de gamla modellerna, t.ex 8086. Men samtidigt så hade en
processor med samma utvecklingsresurser bakom sig sannolikt varit
bättre på många sett utan denna historiska "ryggsäck" att bära på.
just på den historiska bakgrunden till dagens Intel standard processorer.
D.v.s ur ett negativt sett att se på det. Det är så klart väldigt stor
skillnad på en modern Intel processor av samma grundarkitektur jämfört
med en av de gamla modellerna, t.ex 8086. Men samtidigt så hade en
processor med samma utvecklingsresurser bakom sig sannolikt varit
bättre på många sett utan denna historiska "ryggsäck" att bära på.
Re: PIC | AVR | ARM | o. motsv.
Detta tycker jag:
PIC = Datablad som är lätta att förstå för nybörjare.
AVR = Datablad som förklara på en djupare nivå än microhip hur faktisk de interna mekanismerna fungerar.
PIC = Generellt många välbeskrivna ERRATA
AVR = Färre beskrivna ERRATA
PIC = Lånsam debugger, men billig debbugger hårvara.
AVR = Snabb debugger, men dyr debbugger hårvara (Syftar på MKII och jtag)
Lite råd:
Oavsett vilken arkitektur du väljer lär dig hur hårdvaran fungerar inuti. Om du tänkt att koda i C lär dig först att koda alla grundläggande saker i ASM. På så sätt kan du förstå hur C kompilatorn översätter din kod och då bli bättre på att skriva effektiv C kod för processorn.
Jag är av den åsikt att under utveckling skall alltid debugger finnas tillgänglig. Jag själv har sparat otroligt mycket tid på detta. Som nybörjare ger det mycket hjälp att kunna stoppa programmet och kontrollera hur register, variabler, portar har förändrats. Till exempel är det möjligt att slippa programmera om sin krets massa gånger i onödan. Detta genom att tvinga sig förbi felaktiga delar av koden med debuggern och då kan all kod testas i ett svep. Alla fel som hittas kan sedan rättas i ett svep i stället för att springa på dem en och en.
PIC = Datablad som är lätta att förstå för nybörjare.
AVR = Datablad som förklara på en djupare nivå än microhip hur faktisk de interna mekanismerna fungerar.
PIC = Generellt många välbeskrivna ERRATA
AVR = Färre beskrivna ERRATA
PIC = Lånsam debugger, men billig debbugger hårvara.
AVR = Snabb debugger, men dyr debbugger hårvara (Syftar på MKII och jtag)
Lite råd:
Oavsett vilken arkitektur du väljer lär dig hur hårdvaran fungerar inuti. Om du tänkt att koda i C lär dig först att koda alla grundläggande saker i ASM. På så sätt kan du förstå hur C kompilatorn översätter din kod och då bli bättre på att skriva effektiv C kod för processorn.
Jag är av den åsikt att under utveckling skall alltid debugger finnas tillgänglig. Jag själv har sparat otroligt mycket tid på detta. Som nybörjare ger det mycket hjälp att kunna stoppa programmet och kontrollera hur register, variabler, portar har förändrats. Till exempel är det möjligt att slippa programmera om sin krets massa gånger i onödan. Detta genom att tvinga sig förbi felaktiga delar av koden med debuggern och då kan all kod testas i ett svep. Alla fel som hittas kan sedan rättas i ett svep i stället för att springa på dem en och en.
