Arduino vs. andra utvecklingsmiljöer

[TomasL]

bluint, vet du egentligen vad du pratar om?
Huruvida biblioteken är komplexa eller inte påverkar knappast exekveringshastigheten.

Man kör ju knappast några interpreterande språk på en uC.
Bootloader eller inte, spelar ingen roll.
Det är väl snarare så att språket/dialekten inte blir portabel om den är exotisk.

Biblioteken kan dock vara av hög eller låg kvalitet, vilket naturligtvis har betydelse på mängden genererade instruktioner.
Samt huruvida biblioteken klarar MISRA eller inte.

Huruvida processorn har många register eller mycket minne spelar heller inte så stor roll, då man uppenbarligen kan trycka in en webserver på 1024 byte programminne, typ.

Som alltid gäller: Rätt grejjor för rätt jobb.
SKall man bygga sig en enkanalig termostat med någon OW-givare, så kanske en "MIPS/ARM" baserad uC är lite overkill.

Skall man bygga ett komplett nätverkat reglersystem med många undernoder på flera olika nät, så är en PIC16/18 eller motsvarande Atmega garanterat inte rätt val.

[j.po]

Detta är en blinkkod.
Man ansluter en LED+ i hålet 13 på den digitala sidan och LED- i GND och är jorden, dvs minussidan.

Kod: Markera allt

int led = 13;


void setup() {                
  pinMode(led, OUTPUT);     
}


void loop() {
  digitalWrite(led, HIGH);   
  delay(1000);             
  digitalWrite(led, LOW); 
  delay(1000);              
}

Hur skulle det sett ut om man programmerade metoden med AVRstudio?

Det här är ju Arduinons fördel, skriv denna kod, anslut en Uno till datorns USB och ladda ner. Det tar max en minut innan det blinkar. Skall man använda en AtmelMega eller PIC saknas hårdvaran som passar ihop med denna kod. Då skall man initiera oscillator m.m. för att få rätt blinkfrekvens. Det är detta man slipper när man börjar med Arduino. Och vill man köra assembler var det enklare att komma igång med AVRStudio för några år sedan när det var AT90S1200 som gällde, inte alls så mycket register att ta hänsyn till för att få igång en blinkande LED.

[TomasL]

Det tar ungefär lika lång tid med ett PIC-Kit, eftersom hårdvaran redan finns.
Du behöver inte ens ansluta någon hårdvara, eftersom LEDen redan finns på kortet.

Naturligtvis, eftersom ARDUINOS kodbibliotek ÄR hårt knutna till deras hårdvara, blir det enkelt, men om du försöker göra någonting som inte stöds i deras hårdvara, då blir det totalstopp.

Naturligtvis, om du i stället använder resp tillverkares normala utvecklingsmiljöer, MPLAB för PIC eller liknande, så har du inga begränsningar, på vilka portar du kan använda, du är inte låst till att stoppa LEDen i hål 13, du kan sätta den på port RG.13 om du så vill, eller vad som helst, typ.
Det är den stora skillnaden, I Arduino är du 100% fastlåst till plattformen, i alla andra system kan du göra vad du vill.

[Borre]

Givertvis kan man ansluta LEDen till vilken pinne man vill, hur kan du påstå att det inte skulle gå?

Hårt knuten, ja det är inte några problem att ansluta en Attiny utan att ändra koden mer än pinnumret i blinkexemplet, så nej det är det inte..

[TomasL]

Har aldrig påstått så, utan det var ett exempel, när du går utanför HW-definitionen på kortet man använder, är det kört.
Problemet med arduino, som jag förstått det, är att man använder en ickestandardiserad variant av C, där mycket är gömt, vilket gör det svårt att migrera till andra plattformar.

[sodjan]

Arduino konceptet är ju byggt för att göra det enkelt i första hand.
T.ex så har pinnarna delats upp i digitala resp analoga I/O. Nu så
kan man använda en analog pinne för digitala I/O, men man får
ändå skriva i stil med digitalWrite(A0, HIGH); för att köra
Analog pinne nr 0 digitalt. Det fungerar men lite förvirrande kanske...

[Borre]

Ja det är ju vad du skriver.

Det är Atmegan (om en sådan används) som sätter begräsningarna, naturligtvis, inte Arduino IDEet i sig. Det är inga problem att sätta en lysdiod på nån av de analoga pinnarna på tex en Arduino UNO och använda den som en digital utgång.

[sodjan]

Nej tekniskt fungerar det, det är bara namnsättningen
på pinnarna som blir lite rörig...

[Borre]

Eller så använder man pinne 14-19, istället för A0-5 om det är enklare.

Här finns utomordentligt bra "pinout"-bilder på alla Arduinokort och lösa processorer, med alla pinnummer och funktioner osv utskrivna vid alla pinnar.
http://forum.arduino.cc/index.php/topic,146315.0.html

[jesse]

Arduino skiljer väl sig inte från andra "professionella" utvecklingskort. Atmel har t.ex. själva gjort ett antal olika utvecklingskort för sina processoerer. Dessa är dock betydligt mer korkade än Arduino, då varje modell har helt olika I/O och förutsättningar, och de är i princip omöjliga att portera mellan. (Atmel Studio har numera ett tillägg som heter ASF, Atmel Software Framework, som är knutet till vissa utvecklingskort. I ASF måste man välja vilket utvecklingskort man ska använda, och I/O med mera är hårt knutet till vissa pinnar/funktioner. Helt oflexibelt, till skillnad mot Arduino.)

Atmel Software Framework
The Atmel Software Framework (ASF), integrated in Atmel Studio 6, is a collection of production-ready source code, including 1,600 ready-to-use project examples, written and optimized by experts and tested in hundreds of production designs. Use these peripheral drivers, communication stacks and application-specific libraries to quickly and easily complete your projects.

ASF är väl Atmels motsvarighet till Arduino-biblioteken, antar jag. Jag har dock aldrig testat ASF. Dels för att jag själv redan utvecklat de viktigaste biblioteken jag behöver långt innan ASF fanns, dels för att jag inte gillar att inte veta vad som sker när jag använder en funktion. (Det brukar gå fortare att programmera lågnivå I/O själv än att behöva plöja igenom 100 sidor dokument för en massa okända funktioner som sedan visar sig vara onödigt komplicerade för uppgiften).

Arduinos bibliotek verkar vara mer rakt på sak - ganska enkla funktioner (definitioner?) som sätter en bit på en utgång eller läser in data från ADC. Så dessa är betydligt lättare att sätta sig in i och använda utan att det för den delen skulle vara "sämre" än att skriva koden själv.

I Arduino är det självklart att man har en väl definierad hårdvara som alltid är samma, dvs. pin 13 sitter alltid på samma ställe, vilket underlättar enormt om man ska koppla in diverse färdiga mät- och styr utrustning avsedda för Arduino (s.k. "shields"). Detta innebär ju sällan någon begränsning. Du kan ju ansluta precis vad som helst till vilken av pinnarna du vill, eftersom (nästan?) alla pinnar är anslutna till stiftlist och kan användas som in- eller utgångar.

Jag tycker själv det är väldigt praktiskt med ett generellt utvecklingskort där man enkelt kan ansluta extern elektronik för att testa en idé eller en funktion. Annars måste man cadda ett nytt processorkort varje gång man vill mäta eller styra en sak. Med Arduino behöver du bara koppla in och köra.

Så det här blev något slags försvarstal för Arduino, trots att jag aldrig själv varit i närheten av en Arduino.

[sodjan]

Absolut, Arduinos hårda standardisering är ju också just fördelen med Arduino.
D.v.s så länge som man håller sig inom Arduino-konceptet, och de möjligheter
som detta ger räcker till, så är man ju inte "begränsad". Och, som någon annan
sa, Arduinos community och hemsida är faktiskt riktigt bra, det finns ofta
beskrivningar för nästan vad som helst...

Det som de som är lite nya inom denna teknik (helt naturligt) har lite svårt
med är att inse vilka begränsningar som Arduino-konceptet faktiskt ändå har.
Att det finns begränsningar är självklart inget unikt för Arduino...

[ronnylov]

Arduino verkar som ett trevligt koncept tycker jag. Standardiserade byggstenar är inte alls dumt utan ganska smart egentligen så länge som byggstenarna funkar att använda för det man vill.

Går det att kombinera färdigt med egenutvecklade saker? Alltså använda vissa standardbibliotek för Arduino och blanda med egna bibliotek man skapar för speciella syften? Känns som det borde gå bra att göra. Även hårdvaruässigt borde man kunna använda Arduino bootloader på en lös AVR och sedan bygga specialanpassade kretsar runt om den utifall den standardiserade hårdvaran har begränsningar som behöver fixas. Som nybörjare har man inte hunnit skapa en massa egna bibliotek med programvara så det kanske kan vara bra att använda det som finns färdigt om det visar sig fungera bra. Men man lär sig väl mera på att skapa allting själv. Fast ofta blir det väl att man ändå googlar fram andras lösningar som kanske inte alltid är så optimala. Jag är lite kluven, gillar både konceptet Arduino och att göra det själv från grunden.

Men som nybörjare idag, ska man kanske direkt gå på något kraftfullare än små AVR eller PIC? Många kanske skaffar sig raspberry pi men ofta ser man sådana projekt som lika gärna skulle kunna lösas med en Arduino. Kanske raspberry pin ändå blir billigare och mer flexibel i slutändan även om den ofta är overkill? Men jag gillar KISS-principen, alltså att inte krångla till något i onödan fast det är ibland svårt att veta i förväg vad som är minst krångligt. Men provar man på lite av varje så kanske man lär sig så småningom.

[Icecap]

Problemet är mest att steget är relativt stort att gå från ett färdigt "LEGO"-miljö som BASIC-STAMP, Arduino eller liknande till egetdesignade system.

Orsaken är ganska ofta att kunnandet om grundstenen i µC-bygget är lika okänd för de flesta som har använd dessa byggklossar.

Det finns ett antal som kommer till detta forum med lusten att börja med µC och attityden "jag kan programmera Java, hur svårt kan det vara med µC då?"
Och alla problem man kan läsa om visar att det är riktigt svårt för en hel del.

Grundproblemet är att alla dessa "enkla" system som bygger på färdiga funktioner och byggklossar medger att man kan skapa funktioner som kan lösas med de befintliga byggblock - men ska man gå utanför dessa blir det mesta svårt.

Och det är ju hela ändamålet med BASIC-STAMP, Arduino osv: att inte blanda in alla "besvärliga" hårdvaraval eller liknande.

Och jag gör det på sätt o vis också när jag startar ett projekt. Om jag har en pinne som driver en LED kommer jag att ge den LED ett namn som visar mig dess funktion, det kan t.ex. vara LED_Blue. Då skriver jag:

Kod: Markera allt

// LED 0 on PA1, output (D4, Blue)
#define LED_Blue_0         PORTA.PODR.BIT.B1
#define LED_Blue_0_D       PORTA.PDR.BIT.B1

Då kan jag initiera portpinnen som utgång vid att skriva:
LED_Blue_D = 1; // Set to output

Och sedan kan jag styra LED'n i programmet:
LED_Blue = true; // Turn on the LED
LED_Blue = false; // Turn off the LED

Men jag måste ta tag i hårdvarumanualen, kolla vilka pinnar jag ansluter - och i mitt fall: hur jag har ritat schemat och mönsterkortet - till vad, leta upp deras namn i kompilern och definiera dom.

Men när jag har gjort det sparar jag dessa definitioner i en egen fil ("xxxxx_hardware.h") som jag inkluderar i projekten och därmed kan jag skapa fler program till samma "bas-kretskort". Jag har alltså - precis som Arduino har pin-nummer - namn åt pinnarna. Vilket man sedan tycker är mest logisk beror nog ganska mycket på vad man är van vid.

Och ja, med en 100+-pinars krets är detta ett ganska omfattande grundarbete att göra - men det ska bara göras en gång och sedan fungerar det, med en 20-pinnars krets är jobbet självklart avsevärd mer enkelt.

Med "egna" system har man sedan tillgång till "hela systemet", det kan vara underbart - men även hemsk jobbigt om man inte har koll på hur hårdvaran verkligen fungerar.

Så för mig är Arduino (och liknande) lite som barnmat på burk/glas: det går att använda, det är smaklöst och tråkigt, smalt urval, redan färdigtuggad - men man kan överleva på det och har man aldrig smakat annat är det helt OK.

Men är man van vid riktig mat (t.ex. mammas köttbullar eller Kanin i kål) är det väldigt smaklöst och jag tycker synd om dom som äter sånt och tycker att det är gott. Men det är ju för att mina referensramar innehåller mer vidd trots att jag rent faktisk har hållit på väldigt mycket med Z80 också.

Och ja, jag började också med "byggklossar": TRS80

Till den fanns det mycket extra byggklossar att köpa, mängder med beskrivningar på hur man byggde saker, färdiga scheman o allt.

Den jag hade blev ombyggd ganska allvarligt: allt dynamisk minne ut och 32kB statisk RAM i, sedan blev det ett byte av EPROM från 8kB + 4kB till en enkel krets (27C256). Det tillkom en RTC med supercap som backup, LCD (20x2) som jag kunde skriva i med PRINT-kommando och som sista grej lade jag in 128kB statisk RAM med batteri-backup och skyddskrets, detta som en sorts hårddisk.

Sedan startade jag med mujkvaran, jag disassemblerade den, fixade de special/"signatur"-grejer som fanns och kunde sedan kompilera det hela till fungerande BASIC.

Efter det ändrade jag en del kommandon, dels för att kunde använda TIME$, dels för att kunde spara och ladda in program i extraminnet med SAVE och LOAD osv.

[AndersG]

Jag kollade som hastigast på Arduino och det är ett kul koncept. Skulle tex kunna tänka mig att använda det i (enklare) undervisning, någon som minns språket Logo?

Men för mig personligen är det ointressant av orsaker som sammanfattas bra av Icecap här ovan.

[ensten]

@Icecap: Ett bra inlägg - balanserat!