TomasL skrev:
Och nej jag generaliserar inte utifrån mina proffesionella behov, utan vad som är enklast att komma igång med för en hobbyist eller nybörjare, då är garanterat en PIC18/32 betydligt enklare, med C, än en PIC16 med ASM
Om man inte sätter likhetstecken mellan "8-bit" och "PIC" så ser vi att (minst) en annan 8-bit arkitektur lämpar sig väl för programmering med C och gissningsvis är just C dominerande för den arkitekturen (som jag har i tanken) och hobbyister.
Vad jag har förstått är arduino också ganska lätt att komma igång med som nybörjare och det är ju i princip en AVR med en speciell bootloader.
Själv resonerar jag att det är tiden är den viktiga faktorn både inom hobbyprojekt och proffesionellt. När jag tittar på 8bitars kontrollers finns det många olika varianter med för/nackdelar, få av dessa har allt. Vill man t.ex köra med USB behöver man oftast köpa en ny kontroller bygga elektronik för denna och därefter ladda ner exempelkod för att komma igång. Hur många PIC 8bit har t.ex USB och CAN på samma chip? Börjar man utveckla på en kontroller kommer man på fler och fler saker som man vill göra tills man slår i taket. Då får man börja om och porta om sin befintliga kod till den nya kärnan man valt. t.ex att man vill ha en display att visa data på.
När det gäller 32bitars arkitekturen finns det mycket mer funktionallitet och tar längre tid innan man slår i taket. Detta har betytt för mig att man kan lära sig en 32bitars akritektur ganska bra och använda kunskapen mellan olika projekt på ett bättre sätt. Risken att slå i taket är mindre vilket gör att man håller sig till sitt chip. Mycket av utvecklingsmiljön är gratis (iaf för ARM) där det inte finns begränsningar i form av optimering. Oftast vill man göra saker "snabbt" vilket gör att t.ex microchips begränsning att ta bort optimeringen är för mig väldigt irriterande.
valet att koda i C /C++ ger även andra fördelar som att man slipper till större del (jämfört med 8 bitar) trixa med pragman och blanda lågnivå- med högnivå-lager. Detta medför att man kan skriva testdrivet, kompilera sin kod för t.ex windows-miljö och köra enhetstester mm. Just detta har sparat mig MASSOR av tid istället för att debugga på hårdvara.
Själva lödningen med t.ex 0.5 i pitch går aldeles utmärkt att köra för hand. det krävs lite övning men det vanligaste generalfelet är att man glömmer använda FLUSS. har man ingnget fluss går det heltenkelt inte att lösa dessa komponenter för hand.
Vem behöver USB och CAN för att blinka med en lysdiod? Jag tror att de flesta som pysslar med uC på det här forumet idag ligger på en betydligt högre nivå än den genomsnittliga uC-hobbyisten (som antagligen inte kommer att göra mer än ett uC-projekt varannat år).
Tittar man på de typer av grejer där uC brukar rekommenderas som lösning (här på forumet) så handlar det oftast om olika typer av signalomvandling (ex. resistans till PWM). För såna grejer finns det ju inget behov av USB eller CAN.
vem behöver en uC för att blinka med en lysdiod eller omvandla resistans till PWM? går bra med lite OP förstärkare och några passiva komponenter så slipper man lära sig utvecklingsverktyg, programmera, debugga, mm. Enligt min mening börjar man oftast med en uC med ett väldigt enkelt projekt för att komma in i det hela. Men hur kul är det att titta på sin blinkande lysdiod? oftast vill man göra nått "mer" t.ex styra nått eller liknande. I annat fall "fastnar" man i sin lilla uC eftersom man inte orkar läsa ytterligare manualer och installera miljöer mm för att få till den där extra grejjen som hade varit kul att ha.
Frågan är väl snarast om man slår i nubb med slägga eller om man föredrar pennhammare.
Olika tillämpningar har olika processorer som "optimala".
Sen är inte ASM ett dugg svårt, för tex då PIC står alla kommandon i databladet debuggingen görs på instruktionsnivå osv osv tar man sig tiden så går det för det mesta att klura ut vad som är fel iom man har total kontroll. Fast det är klart jag kanske inte skulle koda en iPhone mha .ASM
Säg att man har en processor med extra allt, är då extra allt påslaget per default eller måste det ställas in eller kanske (som i PIC) stängas av? Komplexiteten ökar ju även chansen för fel, även enkla 8-bitars processorer har ju fel (kiselfel) och då borde rent logiskt en mer komplex sak har fler fel.
Jag har arbetat med en microcontroller med 32-bit PowerPC-kärna. Allt i den är kraftfullt och flexibelt, men också svårt och komplicerat. Det krävs veckor av läsande i manualen för att få igång periferienheter som bara tar några timmar på en liten 8bit.
blueint, Tämligen ointressant faktiskt, eftersom koden alltid är applikationsspecifik, sas.
Valet mellan 8/16/24/32/64 bitars beror naturligtvis på applikationen inget annat, dock eftersom detta är ett hobbyforum, vill jag påstå att en 32-bitars processor är bättre att jobba med.
Gissar 2 veckor eller så, typ.
Å andra sidan kostar ett coograkort strax under tusenlappen, om man nöjjer sig med 2 lager.
0,4mm pitch är förvisso i princip omöjligt att göra själv.
