Normalt att det blir bugg om man anropar funktion i funktion

[sodjan]

> Kan jag då använda vilka AVR uC då med min arduino?

Jag är lite osäker här, men det kan ju finnas saker i Arduinos bibliotek
som bara fungerar med vissa modeller av AVR.

Eller vad menar du med "min arduino"? Menar du själva Arduino kortet?
Det stöder så klart enbart de modeller som det är konstruerat för. Det
finns ganska säkert många AVR'er som inte fungerar rent elektriskt
i den aktuella kopplingen på ett visst Arduino kort.

Enklast, om man inte vill dyka ner i alla tekniska detaljer, är att
använda en utvecklingsmiljö som är dokumenterad och testad
samt AVR mnodeller som utryckligen är supportade av miljön.

[Al_Bundy]

Jag är lite osäker här, men det kan ju finnas saker i Arduinos bibliotek
som bara fungerar med vissa modeller av AVR.

Eller vad menar du med "min arduino"? Menar du själva Arduino kortet?
Det stöder så klart enbart de modeller som det är konstruerat för. Det
finns ganska säkert många AVR'er som inte fungerar rent elektriskt
i den aktuella kopplingen på ett visst Arduino kort.

Jag menar att kan jag ta vilken ATtiny eller ATmega som helst och koppla ihop den med min programmerare och sedan programmera, om jag har ställt in så jag använder exempelvis den interna oscillatorn?

Om jag vill programmera ATmega328 8 Mhz så väljer jag just det kortet och då är det bara att programmera.

Med andra ord:
Vad krävs det för att få en AVR uC för att bli anpassad för arduinos språk, wiring?

[TomasL]

Ingenting, förutom att Arduino/Wiring måste stöda just den specifika uC du avser att använda, samt att du sätter konfigen (fuses) riktigt för just den uC du använder.

[sodjan]

> Vad krävs det för att få en AVR uC för att bli anpassad för arduinos språk, wiring?

Att Arduinos språk/miljö är anpassad till AVR'en.
AVR'en i sig kan du inte göra mycket åt.

Antingen undersöker du detta själv eller så kör du någon supportad konfiguration.

[Al_Bundy]

Okej. Tackar. Jag tror jag inte klarar av att bygga egen konfig. Så det får nog bli att jag får söka på diverse forum eller github osv.

[Al_Bundy]

Inte för att direkt gnälla men jag tycker denna kod tar alldels upp för mycket minne.

void setup()
{

}

void loop()
{

}

Detta är grundkoden för arduino. Den gör inget.
Blir ca 498 bytes. Tänk om man ska programmera en Attiny som har ca 1 kb i ROM. Det går enligt youtube, men 1 kb ROM....

[Nerre]

Nu vet jag inte direkt hur det ser ut i Arduino, men när man skriver program i C så skapas det en del kod som körs "innan" main() anropas.

Jag vill minnas att detta kallas initialisering, bland annat allokeras minne till globala variabler, en del register sätts också till "rätt" värde (av nån anledning så använder man t.ex. i C ofta ett "noll-register", d.v.s. ett register som innehåller talet noll och som används för att nollställa variabler, jag gissar att det beror på att det i de flesta fall är enklare att nollställa en minnescell direkt från ett register).

Jag antar att på en Arduino så körs det också lite kod som ställer diverse portar rätt.


Det brukar gå alldeles utmärkt att få ut en listfil som innehåller assemblerkoden, då kan man se exakt vad det är för kod man fått.


Detta gör att det för små mikrocontrollers inte är så bra att köra med C, man bör där skriva direkt i assembler.

[Al_Bundy]

Kan man säga att assembler är steget innan maskinkod?
Med andra ord: Det är så perfekt anpassat efter hårdvara?

[vfr]

Assembler är maskinkod. Bara i ett mer läsbart format än 1:or och 0:or.

[sodjan]

> Detta är grundkoden för arduino. Den gör inget.

Det är den kod som du lägger till själv. Arduino miljön lägger
sedan till en del eget för att göra livet enklare för dig.
Acceptera det eller kör något annat.

> Kan man säga att assembler är steget innan maskinkod?

Ja, ungefär.

> Assembler är maskinkod.

Det är det inte alls! En normal assembler innehåller pre-processor, direktiv,
vilkorsstyrd assemblering, assembly-time variabler/beräkningar o.s.v o.s.v.
Assembler kan även innehålla programkommenterar och annan dokumentation
direkt i källkoden/filen, vilket maskinkod inte kan. En HEX fil är däremot
maskinkod, vilket är betydligt jobbigare att läsa...

[TomasL]

Assembler ÄR maskinkod, att sedan assemblatorn, dvs programvaran som sätter samman hexfilen har en massa extrafunktioner osv är fullständigt ointressant.

[SeniorLemuren]

Ser man det på det viset så kan man ju i så fall påstå att även C, Pascal m.fl. är maskinkod.

"att sedan kompilatorn, dvs programvaran som sätter samman hexfilen har en massa extrafunktioner osv är fullständigt ointressant."

Normalt genererar en kompilator maskinkod, för senare körning på en specifik datortyp, men även andra varianter förekommer.

[Nerre]

I assembler har du (i de vanliga instruktionerna) ett 1:1-förhållande mellan assemblerkod och maskinkod.

Maskinkod går rakt av att översätta tillbaka till motsvarande assemblerkod (dock utan korrekta "symbolnamn"), det går däremot inte att översätta från maskinkod till C med samma tillförlitlighet (du kan skriva C-kod på flera olika sätt som ger samma maskinkod).

I många C-kompilatorer så skapar kompilatorn assemblerkod.


Hade du på den sida du länkar till klickat dig vidare till artikeln för maskinkod hade du kunnat läsa

För att underlätta manuell maskinspråksprogrammering använder man en "symbolisk maskinkod", assembler

[TomasL]

En gång i tiden, när jag fick lära mig detta med mikrokontrollers osv handassemblerade vi koden.

Dvs, vi skrev programmet i fråga i form av assembler mneonics på ett papper, hex-koden bredvid, och matade in detta i processorn, via ett hex-tangentbord.
Assembler och maskinkod är exakt samma sak, bara ett sätt att skriva maskinkoden på ett läsligt och begripligt sätt.

[sodjan]

> Maskinkod går rakt av att översätta tillbaka till motsvarande assemblerkod

Fullständigt skitsnack!
Det går *aldrig* att återskapa makron, assembly-time variabler,
villkorsstyrd assemblering, symboliska registernamn, pseudo instruktioner
(som skapar flera maskininstruktioner), alla kommenterar i källkoden o.s.v.
D.v.s allt det som skiljer assemblerkoden från den rena maskinkoden.

Det var väl en väldigt märkligt diskussion det här...
Helt otroligt att detta ska behöva påpekas över huvudtaget
i ett forum där detta borde vara självklart hos alla.

> har en massa extrafunktioner osv är fullständigt ointressant.

Varför skulle det vara ointressant? Det är ju den miljö man har att jobba med.
Och det är de funktionerna som gör att assembler programmering är enklare
än att koda i maskinkod direkt. Varför är det "ointressant"?

> En gång i tiden, ... handassemblerade vi koden.

Ja, det har vi nog alla gjort, vi som har varit med ett tag. Idag finns det
ofta fria och bra verktyg för att skriva koden mer lättläst, med bättre
funktioner för att förenkla programmeringen o.s.v.

> Assembler och maskinkod är exakt samma sak...

Du kan ta en rad C-kod och en bit maskinkod och hävda att det också "är exakt samma sak".

Många Cobol programmerare kan i huvudet översätta en rad Cobol till motsvarande
maskinkod, gör det att Cobol är samma sak som maskinkod? Självklart inte...