Programmering för riktigt tröga idioter?

[ochkl0620]

Hehe
Jo jag har insett hur begränsad man är om man inte kan programmera något :/
Vill till exempel kunna bygga en svepande uv box och kulla ställa in expo tid och storlek på kort osv... o en massa annat.
Vad rekommenderar ni? Jag har en Arduino som jag som mest kan modda lite kod men mer är det inte. Finns det någon bra guide för att lära sig? Helst på svenska då jag har svårt att hänga med i en förklaring på engelska :/

[Klas-Kenny]

Något som är ganska basic för enklare saker är just BASIC.

Jag har kört det lite på PIC i skolan och det var nästan löjligt enkelt. Men också tämligen begränsande om man vill göra något lite avancerat eller effektivt.

[ochkl0620]

Hehe ungefär samma svar fick jag i PM precis
Kommer läsa lite om det o testa Tack!
Men förresten, vad behöver jag skaffa för hårdvara för det?

[XCore]

Mjukvaran ser ut som så att du har compilator ( som gör om din basic kod till HEX), sedan ett program som pratar med din programmerings utrustning.
Värt att läsa mer om är pro basic, alla koder fungerar i stort sett rakt av emot basic stamp processorerna.
Där kan du se en jäkla massa guider och kodexempel också.
För mer avancerade saker som ultraljuds sensorer och prata serielt med saker osv.

Hårdvaran blir väl något utvecklings verktyg.
Tex pickit2 för microchip, eller stk500 för avr.

Pickit2 :
http://www.electrokit.com/pickit-2-pic- ... -kit.44204
stk500 :
http://www.electrokit.com/atstk500-atme ... -kit.44199

[Glenn]

Något som är ganska basic för enklare saker är just BASIC.

Jag har kört det lite på PIC i skolan och det var nästan löjligt enkelt. Men också tämligen begränsande om man vill göra något lite avancerat eller effektivt.

Vad tycker du är begränsande ? ..Det är väl egentligen bara extremt tidskritiska saker som blir problem, eller ja, inline asm kan man ju köra.


..Nu finns det ju iofs minst fem olika BASIC-varianter för PIC, och ett antal för AVR också så det beror ju på vilken man kör.

Själv kör jag PBP, den kostar dock en slant tyvärr. (demoversionen är gratis men ganska begränsad)

[Icecap]

Problem 1: "helst på svenska"
- Tyvärr, det är engelska som gäller i datablad osv. Eller rättare: de flesta datablad finns på japanska också om det nu är någon hjälp... Och att förklara engelska uttryck på svenska är att förlora hälften. Lösningen är att tugga sig egenom det engelska!

Problem 2: skit totalt i BASIC!
- Det ger inget som ett standardiserat programmeringsspråk inte ger - förutom begränsningar och omöjlighet att portera koden. Sedan kan PBP-fantasterna komma o yla om att det minsann är helt OK språk att använda, bara synd att det enbart fungerar till PIC...!

Lär ett standardiserat språk, t.ex. C. Det kan användas till så många processortyper som det finns kompiler till. Problemet är inte vilket programmeringsspråk man ska använda, det är istället en fråga om att man förstår hur man löser uppgiften!

Tänk det som ett talspråk: när du vet exakt vad du vill säga kan du ta fram ordboken. I början är det en hel..... Massa uppslag i boken och grammatiken är ...intressant... men efter ett tag blir talet mindre besvärligt och grammatiken mindre förkert.

Till slut kan du göra dig förstådd utan problem och då börjar det bli riktigt kul.

Detta gäller oavsett vilket språk du väljer och då är det lika bra att välja ett språk som fungerar world-wide som engelska eller C.

[sodjan]

Det är inte helt tydligt vad det är som du vill lära dig.
Du skriver om t.ex Arduino, men av resten av texten låter det som
att det är "programmering" i största allmänhet som är "problemet".

Och det kan jag förstå, det finns vissa grunder inom programmering som
återkommer helt oavsett vad man ska programmera eller i vilket språk.
D.v.s att bryta ner ett problem i logiska delar, skapa sig en inre bild
av hör flödet genom applikationen ser ut o.s.v. Jag vill påstå att det
inte är något som man bara öppnar en bok och "lär sig". Om man har
rätt förutsättningar som kommer det av sig självt med tiden. Det är
på sätt och vis ett hantverk och som med alla andra hantverk så
tar det år innan man blir bra och man slutar aldrig att lära sig.

Har du programmerat någonting alls tidigare ?
Det är inte säkert att du lär dig programmeringsgrunder bäst genom att
starta med microcontrollers, du kanske ska börja lite i en mer "normal"
miljö som en PC eller liknande. Men som sagt, har du aldrig programmerat
någonting alls tidigare, så blir frågan om BASIC eller något annat ointressant.

> Helst på svenska då jag har svårt att hänga med i en förklaring på engelska :/

OK. Men gör något åt *det* då ! Vad är problemet ?
Tyvärr blir det svårt utan att använda engelsk literatur inom sitt område.

[Glenn]

Problem 2: skit totalt i BASIC!
- Det ger inget som ett standardiserat programmeringsspråk inte ger - förutom begränsningar och omöjlighet att portera koden. Sedan kan PBP-fantasterna komma o yla om att det minsann är helt OK språk att använda, bara synd att det enbart fungerar till PIC...!

Lär ett standardiserat språk, t.ex. C. Det kan användas till så många processortyper som det finns kompiler till. Problemet är inte vilket programmeringsspråk man ska använda, det är istället en fråga om att man förstår hur man löser uppgiften!

Nu får du ju ta och kamma dej.

Du vet lika väl som jag att man inte kan ta en C-källkod från en arkitektur och kompilator och den bara magiskt fungerar när du försöker använda den på nåt annat, så standardisering, pyttsan.

Jag har själv "portat" kod från bascom (AVR) till PBP, gick hyfsat smidigt, tror du på fullt allvar att det hade gått utan att behöva peta i koden om det hade varit C på båda sidorna ? ..För att inte tala om att försöka få C-kod som inte är avsedd för en MCU att köra på en sådan.. det är inte bara svårt, detär även en dum ide rent allmänt.

Sen är BASIC ett standardiserat språk, men precis som att C ser olika ut på olika kompilatorer/plattformar gör även BASIC det, huvuddelen är dock samma.

[Icecap]

Jag är skallig...

Men ja, min erfarenhet(!) är att jag, utan ändring, har porterat kod mellan PIC, Fujitsu FFMC-16LX och Renesas M16C!

Faktisk är styrningen till ett kommerciellt projekt gjort i två versioner rent hårdvarumässigt med Fujitst hhv. Renesas och källkoden är den samma fil! Att det sedan finns var sin fil att ta hand om hårdvaran är knappast konstigt.

Så jo, det fungerar utmärkt att ta med sig ANSI C!!! Och då utan ändring!!!

Att du har skrivit om kod så att den kunde köra i en annan kompiler är knappast imponerande heller, det kan vilken i.... som helst.

[zealotry]

Sluta bråka grabbar, det hjälper knappast trådskaparen.

Vilket språk du väljer först är inte så viktigt, bäst är om du har en kompis eller så som kan programmera och då väljer du ett språk som din vän behärskar och kan hjälpa till med. Om det är forumet här som är din närmsta kontakt till programmeringskunniga så tycker jag du ska välja att fortsätta med Arduionon iom att du då slipper köpa något nytt. Om du sen i framtiden nån gång behöver byta miljö och språk så är det bara nyttigt, det lär man sig massor på!

[stekern]

Sen är BASIC ett standardiserat språk, men precis som att C ser olika ut på olika kompilatorer/plattformar gör även BASIC det, huvuddelen är dock samma.

Standardiserat språk, kanske det ja, men är det några BASIC kompilatorer som faktiskt följer standarden?
Och nej, C ser inte olika ut på olika kompilatorer/plattformar för kod som följer standarden.

[Icecap]

Det viktiga i programmeringen är oftast inte språket men, som sodjan skriver, att kunde bryta ner problemet till mindre enheter som löser var sin del och som man sedan använder i rätt ordning.

Ska man bli riktigt bra på att programmera måste man ha det "tänk", vilket språk man sedan löser uppgiften i har mindre betydelse. Många som börjar programmera tror att när man väl kan språket kan man lösa uppgiften sedan men det är faktisk tvärtemot!

Jag började också i sin tid med att titta förtvivlat på exempelkod och undra hur i all sin dar det hängde ihop. Tog fram manualen och pillade och gjorde katastrof efter katastrof - men efter ett tag blev katastroferna färre och antalet önskade resultat började öka i omfattning.

Sedan har det blivit mycket programmering och på den vägen är det. Rent faktisk är jag knappast en lysande programskrivare men jag är en jäkel på att bena upp problemen i mindre block som jag sedan kan lösa, steg för steg. Det har hänt mig många gångar att jag har löst varje funktion för sig och sedan anropat dessa lösningar till större funktionsblock - och plötsligt var programmet klart och allt fungerade...

Och ja, jag har varit häpen ett flertal gångar! "Men... var det allt? Öhhh - ja, det ser ju ut till att allt är med... var det så enkelt?" Att det sedan har tagit många timmar är något jag lätt glömmer

[sodjan]

Now we are talking...
Icecap och jag har i stort samma grundsyn på det hela.

Det är lite av ett problem i dag att det finns en uppfattning att om
man bara läser en "tutorial" som någon amatör har kastat ihop så är
man plötsligt en topp programmerare (eller vad det hela nu handlar om).

Det handlar om tid, intresse, svett och ennu mer tid. Samt en del "anlag".
Det har väldigt lite med teknik, val av spårk o.s.v att göra. Jag programmerar
i dag i princip ingenting i de språk där jag började programmera (Fortran och
Pascal). Det jag programmerar i mest idag (COBOL) har jag bara använt under
de senaste 4-5 åren (av ca 30). Ändå så är det i grunden samma "tänk" som
återkommer. Det största och viktigaste jobbet görs när man sitter runt ett
konf-bord tillsammans med kunden och diskuterar en ny lösning. Resten är
mest rutin.

Och jag har under 30 är enbert gjort mindre justeringar i befintliga C program,
aldrig något större, så jag är inte "miljöskadad" åt det hållet heller...
C är förvisso populärt men i grunden ett skit-språk (vilket inte har hindrat
det att bli populärt, men det är en helt annan historia... ).

Så frågan kvarstår väl, är det "programmering" i grunden som är problemet?
Eller är det att hantera någon viss teknik ?

[Icecap]

En bra lösningsmodell är att man skriver ner vad man vill uppnå.

Och då menar jag att man ska kunde ge detta papper man har skrivit det på till någon och de ska förstå vad man vill utan ytterligare förklaringar. Kan man inte förklara det för andra kan man inte förstå det själv

När det fungerar kan man dela upp det hela i funktionsblock som man sedan beskriver funktionen på på samma sätt.

Ett exempel från verkliga livet: (första kommersiella projekt jag var inblandat i)
Funktion:
- Styra 3 elektriska laboratorieugnar på en klinkersfabrik.

Styrmodell:
- Styra temperaturen i varje ugn oberoende av de andra.
- Styra temperaturerna efter kurvor från minnet (/"biblioteket").
- Kunde starta och stoppa varje ugn oberoende av de andra.
- Ska kunde köra varje ugn på fritt vald kurva, helt oberoende av de andra.
- Ska kunde matas in kurvor under eller utanför drift.

Delfunktioner:
- Kurvinmatning.
* Kräver t-bord, display, NV-minne.
* Kräver kontroll av att inmatade värden är inom arbetsområde.
- Kurvföljning.
* Kräver tidmätning, temperaturmätning, uträkning av önskat temperatur.
- Statusvisning.
* Kräver display.

Då jag började plita ner som en galning blev min chef blek, han trodde att jag började med top-down programmering. Han lugnade dock sig väldigt mycket då jag visade och förklarade att jag bara skrev ner vilka funktioner jag såg behövdes samt skrev i deras funktioner i text för vidare arbete sedan. Vi blev klara i god tid, fick testat och verifierat det hela och monterade allt en onsdag eftermiddag.

Torsdag gick chefen dit för att förklara hur det hela fungerade (vi hade inte hunnit skriva manual) - men då hade de redan startat upp det hela 3 timmar tidigare och alla ugnar körde för fullt! Vi använde runt 70% av programmeringstiden på att prata om hur man skulle skriva så att inmatningen inte kunde missuppfattas samt hur man skulle visa kurvorna osv.

Bara 30% var "riktig" programmering av funktioner.

Fabriken fick aldrig någon manual och systemet körde prickfritt utan fel fram till fabriken stängdes 12 år senare pga. bristande lönsamhet. Såg i övrigt en plottning av temperaturen i ugnarna, de rampar som styrdes var spikraka! Vi testade att ta en 1m stållinjal och alla kurvsegment var helt och totalt raka - sp fabriken var ytterst nöjd med systemet! Innan dess hade de 3-skift med gubbar som räknade ut vilken temperatur kurvorna skulle ställas på för varje kvart dygnet om och sedan ställde dom termostaten på varje ugn varje kvart dygnet om!

Med detta system kunde de ställa in proven, välja rätt kurvform, trycka start och bara vänta till allt var klart. En bränning kunde lätt ta 18 - 25 timmar.

Men utan att ha benat upp alla funktioner som behövdes och lösa var och en för sig hade det blivit totalt skit av det hela.

Så det viktigaste är just att kunde definiera vilka funktioner som ska finnas och hur uppgiften ska lösas, resten kommer automatisk då. Men om man inte vill ha engelska med i det hela blir det ganska besvärligt! I mitt tycke kan man lära sig engelska - eller leka med andra saker.

[Nisse]

Håller med fullständigt när det gäller att "programmeringstänkandet" är något man måste lära sig oavsett vilken plattform eller språk man väljer.

Men du behöver ju inte skaffa någon ny hårdvara. Kör med den Arduino du har och tycker du engelskan är krånglig kan du till en början leta information på svenska. Här finns en del exempelvis: http://www.lawicel.se/blog/?page_id=359

Böcker om programmering finns det också massor på Svenska. Men förr eller senare blir det oundvikligt att titta i databladen och då är det engelska.

Hälsningar
Nisse