Svenska ElektronikForumet

Nu blir man ju lite nyfiken på vad som döljer sig i "Ow_Write()" ..

Varför denna tävling om att skriva så lite kod som möjligt?

För att ju mindre kod du skriver ju mindre fel kan du göra.
Men det gäller ju att någon annan har skrivit rätt tidigare, och skulle det vara fel i denna kod kan det bli intressant. Då måste man in och grotta i kod någon annan skrivit, vilket kan vara en utmaning även för den mest rutinerade programmeraren..

Särskilt om den är i binär form utan källkod..

Och varför vill man grotta ned sig i binärkod?

blueint skrev:Nu blir man ju lite nyfiken på vad som döljer sig i "Ow_Write()" ..

Det är anrop till microCPro biblioteksrutin one_wire. Vill man jämföra kod så får det väl bli lite på lika villkor.

Jag har pillat lite med att programmera AVR direkt med C för att jag tycker det är roligt men har inte testat använda Arduino. Jag gillar att lära mig och för att kunna jämföra måste jag väl prova alternativen. Som jag förstått det ligger Arduino på en högre nivå programmeringsmässigt, alltså att det finns färdiga bibliotek som anropas istället för att man skriver egna funktioner. Även hårdvarumässigt är nivån högre då man gärna använder färdiga byggmoduler. Detta kan säkerligen vara smidigt om det funkar problemfritt. Jag gillar att utnyttja öppen källkod och slippa uppfinna hjulet på nytt så ser inget fel i detta. Men jag börjar gärna från grunden och går sedan uppåt för att lära mig. Så när det gäller programmering av vanliga datorprogram har jag först börjat med C innan jag senare ska ge mig på Python och bash-script. Kanske "fel" väg att gå men jag gillar den vägen. Egentligen borde jag väl ha börjat med assembler istället kanske...

Möjligen kan man optimera koden bättre om man själv utvecklar något från grunden specialanpassat till den egna applikationen. Kan alltså göra funktionen snabbare och resurssnålare än att anropa diverse subrutiner som även innehåller extrafunktioner som man inte behöver. Å andra sidan kan det gå snabbare att utveckla något om man har större färdiga beprövade byggstenar att bygga med. Det är väl som att välja högnivåspråk eller lågnivåspråk när man programmerar och att bygga med färdiga moduler istället för lösa komponenter när man bygger hårdvaran. För att snabbt testa ett koncept så väljer man antagligen högnivåmetoden och sedan för att strömlinjeforma och specialanpassa kör man lågnivåmetoden.

Har jag förstått det hela ungefär rätt?

I så fall finns det för- och nackdelar med olika miljöer och det finns ingen större anledning att påstå att det ena är bättre eller sämre än det andra. Det beror helt på behoven och sammanhangen när det ena är bättre än det andra. Nu för tiden är hårdvaran så pass kraftfull så man kanske inte alltid måste optimera allt i minsta detalj, man kanske skaffar kraftigare hårdvara istället. Men ibland kan det ändå vara bra att köra minimalistiskt, kanske om det är krav på låg strömförbrukning samtidigt som bra prestanda eller att det ska bli billigt att massproducera. Produktion i stora volymer kan göra det befogat att lägga mer tid på optimering men ska man bara göra någon prototyp för att testa ett koncept vill man kanske inte fastna i detaljer. Som hemmapulare är det väl ofta kanske något enstaka exemplar man bygger men sedan kan ju motiven vara olika, om man gör det för att lära sig saker eller för att få fram sin pryl så enkelt som möjligt. Men man lär sig oavsett vilken nivå man jobbar med.

Intressant att Arduino även börjar komma med ARM och intel x86 (se min tråd om intel galileo). Så man verkar inte ha låst fast sig med AVR trots allt även om man använder Arduino-konceptet. Funderar själv på om jag ska gå vidare med ARM. Kör i och för sig en raspberry Pi med Linux på men tänkte mer lågnivå istället. Vi får se. Samtidigt känner jag att det man inte löser med en AVR kan man kanske lika gärna köra på en raspberry Pi med Linux istället? Då hamnar man plötsligt på en nivå över Arduino. Nästa steg är att köra det på en PC. Själv vill jag koppla ihop allting så att småprylarna kanske snackar med en raspberry pi som i sin tur snackar med min stora servermaskin. Då behöver man lära sig på alla nivåer.

> Har jag förstått det hela ungefär rätt?

Jag skulle säga "ja", både på det innan och det efter din fråga.

Förrutom en liten punkt:

> Intressant att Arduino även börjar komma med ARM och intel x86...

Som jag har förstått det så är det inte "Arduino" som gör det, utan *andra*
tillverkare/leverantörer som tagit fram "Arduino-kloner" som inte kör just AVR.
En detalj kanske...

Nej. Arduino Due, "It is the first Arduino board based on a 32-bit ARM core microcontroller."
http://arduino.cc/en/Main/ArduinoBoardDue

Aha! Där ser man!
Ja då finns det "original Arduino" med annat än AVR...

Och när man har en saftigare processor så behöver man inte längre de förenklande (döljande) Arduino biblioteken

Dock är det standardiserade fysiska gränssnittet användbart.

Hur menar du nu blueint, är det enklare att programmera en saftigare processor? På ett sätt kan det vara det om man kör ett operativsystem i bakgrunden (som på raspberry pi som kör Linux). var det så du menade?

Jag fattar inte heller. Om man har mer "kraft under huven" så bör
inte de "förenklade" biblioteken vara en lika stor "bromskloss"...

Jag tycker många borde ta lärdom av Arduinos site, den är ren, snygg och man hittar alla grunderna på 1 eller 2 steg från huvudsidan. Jämför tex med AVRFreaks.com som trots att de har funnits 10+ år fortfarande bara är en röra eller Atmels site där man blir översköljd av mer information än man kan hantera och tvingas sedan läsa deras hemska datablad som hela tiden refererar detaljer 21 sidor bakåt, 53 framåt, 3 åt sidan, 46 bakåt osv...

Professionellt däremot tycker jag AVRStudio med standard libc är en bättre miljö och vad det gäller styr & regler allmänt är utvecklingsmiljöerna för PLC och hårdvaran ett ljusår framför Arduino, tror man att spridningen kommer att bli mycket större än hobbysamhället så beror det på att nattmössan framför ögonen har hindrat en från att se vad som redan finns där ute.

Om man har snabbare CPU med lite saftiga register och ordenligt med minne så kan man slösa lite på operativsystem och bibliotek. Då bortfaller också behovet av väldigt specifika och begränsade bibliotek som i stort sett är lobotomerade för att uppfylla ett snävt syfte.

I extremfallet kan man slänga ihop ett Perl-skript som fixar uppgiften. Inget som fungerar på en ATmega direkt..
Dessutom kan man logga in och fixa fjärrstyrt sådant till skillnad från exotiska kompilatorer-uppladdning-bootning osv.

Nackdelen är mer effektåtgång, pris, storlek, latenstid och inte minst komplexitet med hackade maskiner mm.