Svenska ElektronikForumet

Måste hålla med Marta här, har man moderata krav på vad processorn
ska göra, så är väl C (eller Basic eller Pascal) OK. Visst går det att skriva
i (främst) C på ett sätt som gör att kompilatorn kommer att generara
skapligt effektiv kod, men det kräver att man har bra känsla för
vilken kod kompilatorn spottar ur sig, och det i sin tur kräven bra kännedom
om assemblerprogrammering, så man kommer inte undan...

Men för enkla applikationer utan större krav på en skola, spelar det
kanske inte så stor roll...

Men, som sagt, om syftet är att *lära* sig PIC arkitekturen (och inte
bara så snabbt som möjligt slänga ihop något som "fungerar"), så är
nog assemebler inte fel att start med.

Jag utnyttjar min rätt att inte hålla med och envist vägra ge mig
Jag har programmerat en del ASM, tillräckligt för att veta precis vad jag går miste om . Jag ser inte hur man lär sig architekturen bättre genom att skriva alla loopar och ifsatser för hand i asm. Man lär sig förvisso hur JMP och CMP fungerar, men i övrigt är ju kraven desamma. Skall man göra en AD läsning måste man ju ställa in ADns register på rätt sätt både i C och ASM. samma gäller väl alla funktioner man vill komma åt. De enda funktionaliteter som är dolda som jag kan komma på är hur interruptvektorerna är implementerade. Där skirver man ju bara en vanlig funktion i C och deklarerar att det är en interrupthanterare. Man slipper även minnesallokering och till sist slipper man bry sig om det aritmetiska tragglet med hur man gör plus och minus, men det är väl kanske inte heller en stor förlust...

Vad det gäller effektivitet brukar C kompilatorn ofta vara bättre än man tror på att omtimera. GCC vs. en oerfaren ASM programmerare är en ganska jämn match. Dessutom är det oftast en väldigt liten del av koden som måste vara riktigt tight. Om man känner att man måste optimera en innerloop nånstans och att man är bättre på ASM än vad GCC är så kan man ju skirva den i inline ASM och göra allt icke tidskrävande i C.

OK, men C är i alla fall inte lika "kul" !

Varför ska man tala Latin med en grottmäniska

Efter att ha varit "assembler only" i nära 20 år kan jag rekomendera C.
Har god erfarenhet av mikroC (mikroe.com).
Allt dom skriver om assembler är sant men programmerar man i C kan man åstadkomma mycket mer på kort tid.
Använd assembler när det krävs t.ex. en extra snabb loop och tag C till resten.

OK, jag känner mig lite missförstådd här...

> Använd assembler när det krävs t.ex. en extra snabb loop och tag C till resten.

Visst, låter väl rimligt. Men, hur ska det gå till om man aldrig fick
lära sig assembler i början ?

Notera att det jag talar om, är inte vad man ska använda efter
5 eller 10 år, utan vad en nybörjare bör/ska *börja* med för att
snabbt komma in i hur (t.ex) en PIC fungerar. Dessutom är
det inte fel att kunna "läsa" asm-listorna från kompilatorn för att
lära sig hur den jobbar, eller för att kontrollera vad den spottar ur sig.

Det finns många faktorer att ta hänsyn till, t.ex är jag tveksam
till något annat än assembler på 10F/12F modellerna.

Det går inte att ge ett *generellt* råd för val av verktyg/miljö.

Jag vidhåller dock att man lär sig PIC arkitekturen snabbare/bättre
genom att köra assembler i början (säg från 6 mån till upp till 1 år).
Sedan får var och en göra ett personligt val, och då spelar det mindre
roll vilket val man gör, och man behöver inte så många råd längre...

Nä, problemet är att många vill ha en genväg utan att behöva lära sig
saker och ting ordentligt från grunden.

Håller med sodjan där.

När jag körde Basic för några år sedan, då fick jag sakerna att funka men jag förstod inte hur.

Nu när jag *kan* assembler så förstår jag hur processorn fungerar.
Ångrar att jag inte började med assembler istället för basic.

Håller nog med Sodjan också. Tycker dock att du skall testa C först, även om du "lär sig PIC arkitekturen snabbare/bättre genom att köra assembler".
PIC arkitekturen är inte den enda arkitekturen, även om jag och många använder PIC. (def finns ju AVR, HC11, HC12 osv)
Vad jag vill säga är att lär du dig C kan du programmera ALLA processorer, och inte bara PIC.

Sodjan har rätt i mycket och likaså C-förespråkarna, skillnaden är just var på inlärningskurvan man befinner sig.

Har man gott om "choklad på skjortan" och vet hur man ska pilla på registre, hur minnet fungerar osv är livet snabbare med C och faktisk ASM i vissa lägen då man iblant kan "trolla" fram en funktion som kan vara knepig i C men enkel i ASM (fast det är inte så ofta).

Men är man alldeles ny på µC och ska börja med att blinka en LED osv vill jag definitivt rekommendera ASM och det är så jag läsar sodjans inställning.

Alltså: start med ASM, när man "kan skiten" kan man kliva på C-tåget för då vet man ju hur processorn fungerar, precis som med utbildning: nu har man lärt en viss sak och då tar man ett steg vidare.

Men utan en noga förståelse för hur en µC fungerar kommer man inte att kunna använda den "rätt" (fullt o helt), man kommer istället att vara tvungen att använda standartlösningar osv.

> Vad jag vill säga är att lär du dig C kan du programmera ALLA processorer, och inte bara PIC.

Kanske för väldigt enkla saker, men annars tror jag inte det stämmer riktigt.
Visst finns det C-kompilatorer till alla (?) processorer, men det betyder inte
att samma källkod fungerar på alla. Inte ens samma "programming style"...

Kan man programmera assembler på en så kan man på de flesta. Visst skiljer instruktionsseten, men grunderna i hur man angriper ett problem är alltid desamma. För övrigt är det oftast inte kodningen utan programlogiken som tar tid att komma fram till. Sätter man sig vid datorn och börjar knappa direkt så blir resultatet oftast inget bra. Istället skall man börja med papper, blyertspenna och ett stort radergummi.

Flödesschema säger jag.... Där lärde jag mig ialafall att göra "smartare" kod och tappar inte bort sig lika enkelt i koden heller.

Och för att göra bilden komplett, så är det ofta det som finns *utanför*
processorn som ställer till det mesta problemen...

Sodjan: På amatörnivå duger dina tankar bra men i lite större sammanhang så vill man att en mjukvara ska överleva ett byte av mikrokontroller, man vill göra så självständiga moduler man kan för att kunna återanvända kod och man vill att någon annan person ska kunna förstå koden och kunna göra ändringar i den.

För att få en mjukvara som är oberoende av vilken hårdvara man kör på måste man göra ett snitt där man separerar den funktionella koden från den hårdvaruberoende. Väljer man assembler så är automatiskt all kod hårdvaruberoende.
För att modularisera mjukvaran så mycket som möjligt krävs det någon metod för att partionera systemet. Objektorientering är en utmärkt metod för att nå dit.
För att göra sin mjukvara så begriplig som möjligt så bör man välja ett språk som alla förstår och det finns det ju.

Sen allt snack om prestanda och att kompilatorer lägger ut mängder med kod för att göra en viss sak är jag skeptisk till. Man kan anta att en C-kompilator lägger ut den mest effektiva koden för en generell for-loop, för en tilldelning, för att hantera pekare och referenser osv. Jag vill påstå att en normal assemblerprogrammerare ofta inte gör en optimal implementation av även de enklaste loopar och algoritmer dessutom är risken stor att implementationen inte blir samma från gång till gång.

"För att få en mjukvara som är oberoende av vilken hårdvara man kör på måste man göra ett snitt där man separerar den funktionella koden från den hårdvaruberoende. Väljer man assembler så är automatiskt all kod hårdvaruberoende."

Ser ingen skillnad där, bara göra en equ-lista, sedan behöver du bara ändra i den istället för 500ställen i koden.