Att skriva i ASM är faktiskt både kul och enkelt.
Jag föredrar ASM före C i vissa tillfällen och C över ASM i vissa.
Men jag tycker inte om basic till annat än Visual Basic för att skriva gui:n till ens projekt som snackar till datorn.
Det jag ser som dåligt med både basic och C emot ASM är att det blir väldigt mycket mindre kod när man skriver i asm för man har koll på allt.
Det är kontroll man saknar i både basic och c.
Och det bästa med asm emot c är att det bara finns några få kommandon.
Och man har 100% kontroll. Och man slipper kompilerings tiden!
Men C är bra när man ska göra mer avancerade saker och har mycket minne.
Som när man ska snacka med glcd tex.
Och basic är ologiskt när man kodar.
Man använder inte subrutiner på samma sätt som i c och det känns mer normalt att använda () och {} och sådant.
Sedan så är det inte lika lätt att lägga till rutiner som andra har skrivit.
Jag började också koda i basic i basic stamp och i qbasic.
Jag använder iof fortfarande qbasic till vissa saker.
Men för att sammanfatta allt, alla språk är bra på någon sak men vissa språk är bättre och på fler saker än andra.
Great Cow BASIC
-
victor_passe
- Inlägg: 2436
- Blev medlem: 28 januari 2007, 18:45:40
- Ort: Kungsbacka
Tripp:
Grejen är att man kan göra "allt" oberoende på programmeringsspråk!
En µC blir inte annorlunda av att kompilern får källkod i form av BASIC eller C eller Pascal eller...
Skillnaden är strukturen i programmet och sättet att behandla variabler på.
Ett exempel:
Har ett antal projekt med olika parameter som styr en massa saker. Dessa variabler är av olika storleker (bytes/words/long osv.) och de sparas i EEPROM. Man kan ändra dessa variabler på olika sätt men senaste inställningen ska sparas för varje ändring.
Så långt är allt ganska normalt.
I C deklarerar jag:
Detta deklarerar en variabel-typ (som heter "T_CONFIG") som består av samlingen av alla dessa variabler. detta är ett ganska begränsat exempel, jag har projekt som har avsevärd större och mer komplicerat.
För att faktisk deklarera ett kopia i minnet gör jag:
T_CONFIG Config;
Nu har jag reserverat plats i minnet till Config, för att "komma åt" dessa variabler skriver jag t.ex. X = Config.Rampspeed_Carrier_Offset.
OK, detta är bara ett avancerat att göra det samma som man kan i BASIC...
Men jag ska ju läsa från EEPROM när jag slår på skiten:
// EEPROM I/F
#define EE_SCK p6_4
#define EE_SCK_DD pd6_4
#define EE_SI p6_5
#define EE_SI_DD pd6_5
#define EE_SO p3_0
#define EE_SO_DD pd3_0
#define EE_NCS p3_1
#define EE_NCS_DD pd3_1
#include "\SofTune\Works\25lc160.h" // That's it, now it's possible to use the EEPROM
Sådär, nu har jag tagit min gamla EEPROM-rutin från Fujitsuprocessorn in i mitt Renesas M16C-projekt HELT UTAN ÄNDRING! (portabilitet!)
Men det gör knappast så mycket, jag ska ju fortfarande hämta data från EEPROM till Config-blocket eller hur? OK, jag har tagit en genväg:
#define Save_Config() (Write_EE_Buffer(Config_Start , (BYTE*)&Config , sizeof(T_CONFIG)))
#define Read_Config() (Read_EE_Buffer (Config_Start , (BYTE*)&Config , sizeof(T_CONFIG)))
När jag alltså skriver "Read_Config();" läsas de data som finns i EEPROM in i Config-blocket, ändrar jag ett värde och vill spara det är det bara att lägga in kommandot: "Save_Config();" på lämpligt ställe i programmet.
Men låt oss dissikrera det lite, själva funktionen utförs av den kommando jag har gjort i den fil som inkluderas:
Write_EE_Buffer(Config_Start, (BYTE*)&Config, sizeof(T_CONFIG));
Lite förklaring:
Config_Start har ett värde som anger på vilken startadress i EEPROM'en dessa värden har lagrats på, i detta fall 0h.
(BYTE*)&Config... den är lite tuffare men det är ett sätt att berätta att jag vill ha Config's adress i RAM men att jag vill använda den som en pekare till bytes. Det är så för att den rutin jag har gjort förväntar sig en adress som pekar på byte(s).
Sedan är det "sizeof(T_CONFIG)" som ger ett värde som anger hur många bytes en T_CONFIG-variabel tar i minnet.
Ändrar jag Config vid att ändra storleker på variabler (8 -> 16 bits t.ex.) kommer detta värde att "följa med" då kompilern "tillverkar" det när det kompileras.
Ett annat exempel:
Seriell överföring, protokoll. En datablock har tagits emot men VAD ska den göra? Jo, det finns en byte som anger detta! Här kallar vi den "Rx.Command" (jepp, du har gissat rätt, det är en 'struct')
Förklaring:
enum ger del tags som står i klammorna fortlöpande värden, första värde får 0, nästa får 1 osv. Man kan dock ange det värde som tag'en ska ha och sedan kör den vidare därifrån om man vill. Man kan alltså få 0, 1, 5, 7, 100, 101, 102, 103 osv om man vill.
Sedan switch.... kan bäst jämföras vid:
if(Rx.Command = Command_Ping)
// Gör vad som ska göras här
else if(Rx.Command = Command_Set_Speed)
// Gör vad som ska göras här
else if(Rx.Command = Command_Read_Speed)
// Gör vad som ska göras här
else
// Allt som inte passar in på några av de andra
endif
Visst, i BASIC har man "on X goto" (ibland) men vad om man bara vill använda kanske 3 av 100 värden? Då ska man i BASIC skriva upp alla 100 fast bara 3 av dom pekar på en egentlig rutin, resten pekar på "stega vidare".
Om jag då skulle få för mig att ändra enum:
enum {Command_Ping = 'A', Command_Set_Speed, Command_Read_Speed};
Vad händer då?
Ingenting, allt fungerar precis likadan efter kompilering fastän värden är ändrade!
Självklart definierar man kommunikationsvariabler i en egen fil, denna inkluderar man sedan i sitt PC-program (C++) och därmed kan kommunikationen inte gå fel om man lägger till eller ändrar värden, det är bara att kompilera igen i "båda ändar" och saken är biff och tro mig, jag har testat detta MYCKET.
Grejen är att man kan göra "allt" oberoende på programmeringsspråk!
En µC blir inte annorlunda av att kompilern får källkod i form av BASIC eller C eller Pascal eller...
Skillnaden är strukturen i programmet och sättet att behandla variabler på.
Ett exempel:
Har ett antal projekt med olika parameter som styr en massa saker. Dessa variabler är av olika storleker (bytes/words/long osv.) och de sparas i EEPROM. Man kan ändra dessa variabler på olika sätt men senaste inställningen ska sparas för varje ändring.
Så långt är allt ganska normalt.
I C deklarerar jag:
Kod: Markera allt
typedef struct
{
WORD Club_Number;
BYTE Grinds_Max;
BYTE Carrier_Target;
BYTE Grinder_Target;
BYTE Rampspeed_Carrier_Offset;
BYTE Rampspeed_Carrier_Step;
BYTE Rampspeed_Grinder_Offset;
BYTE Rampspeed_Grinder_Step;
} T_CONFIG;
För att faktisk deklarera ett kopia i minnet gör jag:
T_CONFIG Config;
Nu har jag reserverat plats i minnet till Config, för att "komma åt" dessa variabler skriver jag t.ex. X = Config.Rampspeed_Carrier_Offset.
OK, detta är bara ett avancerat att göra det samma som man kan i BASIC...
Men jag ska ju läsa från EEPROM när jag slår på skiten:
// EEPROM I/F
#define EE_SCK p6_4
#define EE_SCK_DD pd6_4
#define EE_SI p6_5
#define EE_SI_DD pd6_5
#define EE_SO p3_0
#define EE_SO_DD pd3_0
#define EE_NCS p3_1
#define EE_NCS_DD pd3_1
#include "\SofTune\Works\25lc160.h" // That's it, now it's possible to use the EEPROM
Sådär, nu har jag tagit min gamla EEPROM-rutin från Fujitsuprocessorn in i mitt Renesas M16C-projekt HELT UTAN ÄNDRING! (portabilitet!)
Men det gör knappast så mycket, jag ska ju fortfarande hämta data från EEPROM till Config-blocket eller hur? OK, jag har tagit en genväg:
#define Save_Config() (Write_EE_Buffer(Config_Start , (BYTE*)&Config , sizeof(T_CONFIG)))
#define Read_Config() (Read_EE_Buffer (Config_Start , (BYTE*)&Config , sizeof(T_CONFIG)))
När jag alltså skriver "Read_Config();" läsas de data som finns i EEPROM in i Config-blocket, ändrar jag ett värde och vill spara det är det bara att lägga in kommandot: "Save_Config();" på lämpligt ställe i programmet.
Men låt oss dissikrera det lite, själva funktionen utförs av den kommando jag har gjort i den fil som inkluderas:
Write_EE_Buffer(Config_Start, (BYTE*)&Config, sizeof(T_CONFIG));
Lite förklaring:
Config_Start har ett värde som anger på vilken startadress i EEPROM'en dessa värden har lagrats på, i detta fall 0h.
(BYTE*)&Config... den är lite tuffare men det är ett sätt att berätta att jag vill ha Config's adress i RAM men att jag vill använda den som en pekare till bytes. Det är så för att den rutin jag har gjort förväntar sig en adress som pekar på byte(s).
Sedan är det "sizeof(T_CONFIG)" som ger ett värde som anger hur många bytes en T_CONFIG-variabel tar i minnet.
Ändrar jag Config vid att ändra storleker på variabler (8 -> 16 bits t.ex.) kommer detta värde att "följa med" då kompilern "tillverkar" det när det kompileras.
Ett annat exempel:
Seriell överföring, protokoll. En datablock har tagits emot men VAD ska den göra? Jo, det finns en byte som anger detta! Här kallar vi den "Rx.Command" (jepp, du har gissat rätt, det är en 'struct')
Kod: Markera allt
enum {Command_Ping, Command_Set_Speed, Command_Read_Speed};
switch(Rx.Command)
{
case Command_Ping:
// Gör vad som ska göras här
break;
case Command_Set_Speed:
// Gör vad som ska göras här
break;
case Command_Read_Speed:
// Gör vad som ska göras här
break;
default: // Behöver inte vara med!
// Allt som inte passar in på några av de andra
}
enum ger del tags som står i klammorna fortlöpande värden, första värde får 0, nästa får 1 osv. Man kan dock ange det värde som tag'en ska ha och sedan kör den vidare därifrån om man vill. Man kan alltså få 0, 1, 5, 7, 100, 101, 102, 103 osv om man vill.
Sedan switch.... kan bäst jämföras vid:
if(Rx.Command = Command_Ping)
// Gör vad som ska göras här
else if(Rx.Command = Command_Set_Speed)
// Gör vad som ska göras här
else if(Rx.Command = Command_Read_Speed)
// Gör vad som ska göras här
else
// Allt som inte passar in på några av de andra
endif
Visst, i BASIC har man "on X goto" (ibland) men vad om man bara vill använda kanske 3 av 100 värden? Då ska man i BASIC skriva upp alla 100 fast bara 3 av dom pekar på en egentlig rutin, resten pekar på "stega vidare".
Om jag då skulle få för mig att ändra enum:
enum {Command_Ping = 'A', Command_Set_Speed, Command_Read_Speed};
Vad händer då?
Ingenting, allt fungerar precis likadan efter kompilering fastän värden är ändrade!
Självklart definierar man kommunikationsvariabler i en egen fil, denna inkluderar man sedan i sitt PC-program (C++) och därmed kan kommunikationen inte gå fel om man lägger till eller ändrar värden, det är bara att kompilera igen i "båda ändar" och saken är biff och tro mig, jag har testat detta MYCKET.
Jag har inte rört assembler sedan jag övergick till Basic på min VIC20 för många år sedan. Det betyder förmodligen att Basic har utvecklats mer än assembler under samma tid. Har Icecap kanske jobbat med de senare versionerna av Swordfish eller PICBasic PRO så att en utan förutfattade meningar och helt opartisk jämförelse kan göras??
Det var kanske ett tag sen du kollade vad som händer på andra sidan planket?
Ursäkta min okunnighet men vem fan är Edsger W.Dijkstra? Det är uppenbarligen en enkelspårig och trångsynt typ.
PerE > Det var en mycket bra beskrivning av stämningen här och jämförelsen med CNC.
AndersG Ställer du en konkret programmeringsfråga om BASIC är chansen ganska stor att du får ett svar. Det är nog så att en del känner sig nedrackade så fort Basic nämns och vågar sedan inte öppna käften igen i ämnet! Basic borde kanske ha en egen avdelning där assemblerister är portade!
Tripp> Ge dig, du får ändå inga vettiga exempel!
stekern> Det är mest hobbyister här i forumet och jag tror inte att portabiliteten har en avgörande betydelse.
Självklart kan man använda makros i Basic, skriv vilka rutiner du vill i t ex assembler och använd som makros.
Det var kanske ett tag sen du kollade vad som händer på andra sidan planket?
Ursäkta min okunnighet men vem fan är Edsger W.Dijkstra? Det är uppenbarligen en enkelspårig och trångsynt typ.
PerE > Det var en mycket bra beskrivning av stämningen här och jämförelsen med CNC.
AndersG Ställer du en konkret programmeringsfråga om BASIC är chansen ganska stor att du får ett svar. Det är nog så att en del känner sig nedrackade så fort Basic nämns och vågar sedan inte öppna käften igen i ämnet! Basic borde kanske ha en egen avdelning där assemblerister är portade!
Tripp> Ge dig, du får ändå inga vettiga exempel!
stekern> Det är mest hobbyister här i forumet och jag tror inte att portabiliteten har en avgörande betydelse.
Självklart kan man använda makros i Basic, skriv vilka rutiner du vill i t ex assembler och använd som makros.
Icecap> Skillnaden är strukturen i programmet och sättet att behandla variabler på.
Visst, syntaxen är olika, men det betyder inte att man inte kan göra i princip samma sak.
Icecap> I C deklarerar jag: [följt av ett exempel på en "struct" i C-syntax).
I mikroBasic blir samma struct :Ingen avgörande skillnad, bara lite olika syntax.
Icecap> För att faktisk deklarera ett kopia i minnet gör jag:
Icecap> T_CONFIG Config
Eller i MikroBASIC (fortfarande bara skillnad i syntax) :Icecap> för att "komma åt" dessa variabler skriver jag t.ex:
Icecap> X = Config.Rampspeed_Carrier_Offset.
I MikroBASIC :
X = Config.Rampspeed_Carrier_Offset.
Ser *någon* någon skillnad ???
Ditt switch exempel i C skulle bli ungefär :Även här primärt syntax skillnader.
ON x GOTO är riktigt stenåldern och blir bara löjligt att ta med i en
sådan här jämförelse. Problemet är att sin trovärdighet kan få en törn om
man inte riktigt kollar upp saker och ting innan man jämför.
BASIC idag är knappast vad det var när man körde ABC80....
Andy> Ursäkta min okunnighet men vem fan är Edsger W.Dijkstra?
En av de största programmerings teoretikerna genom tiderna.
"Pappa" till det som vi i dag kallar "strukturerad programmering".
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra
Andy> Det är uppenbarligen en enkelspårig och trångsynt typ.
Det är inte speciellt många som skulle hålla med om det. Läs på lite
så tror jag att du är beredd att ta tillbaka det omdömet...
Visst, syntaxen är olika, men det betyder inte att man inte kan göra i princip samma sak.
Icecap> I C deklarerar jag: [följt av ett exempel på en "struct" i C-syntax).
I mikroBasic blir samma struct :
Kod: Markera allt
structure T_CONFIG
Club_Number as WORD
Grinds_Max as BYTE
Carrier_Target as BYTE
Grinder_Target as BYTE
Rampspeed_Carrier_Offset as BYTE
Rampspeed_Carrier_Step as BYTE
Rampspeed_Grinder_Offset as BYTE
Rampspeed_Grinder_Step as BYTE
end structureIcecap> För att faktisk deklarera ett kopia i minnet gör jag:
Icecap> T_CONFIG Config
Eller i MikroBASIC (fortfarande bara skillnad i syntax) :
Kod: Markera allt
dim Config as T_CONFIGIcecap> X = Config.Rampspeed_Carrier_Offset.
I MikroBASIC :
X = Config.Rampspeed_Carrier_Offset.
Ser *någon* någon skillnad ???
Ditt switch exempel i C skulle bli ungefär :
Kod: Markera allt
select case Rx.Command
case Command_Ping
// Gör vad som ska göras här
case Command_Set_Speed
// Gör vad som ska göras här
case Command_Read_Speed:
// Gör vad som ska göras här
case else // Behöver inte vara med!
// Allt som inte passar in på några av de andra
end selectON x GOTO är riktigt stenåldern och blir bara löjligt att ta med i en
sådan här jämförelse. Problemet är att sin trovärdighet kan få en törn om
man inte riktigt kollar upp saker och ting innan man jämför.
BASIC idag är knappast vad det var när man körde ABC80....
Andy> Ursäkta min okunnighet men vem fan är Edsger W.Dijkstra?
En av de största programmerings teoretikerna genom tiderna.
"Pappa" till det som vi i dag kallar "strukturerad programmering".
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra
Andy> Det är uppenbarligen en enkelspårig och trångsynt typ.
Det är inte speciellt många som skulle hålla med om det. Läs på lite
så tror jag att du är beredd att ta tillbaka det omdömet...
BASIC har såklart utvecklats och det är möjligt att "BASIC-motståndare" har förutfattade meningar om vad dagens BASIC kan och inte kan göra.
MEN, rätta mig nu om jag har fel, till skillnad från C så är inte detta standardiserat på samma sätt (jo det finns en ANSI standard från 1987, men är detta något som nutidens BASIC följer?)
Det du pekar på sodjan känns som ganska C influerad BASIC.
Jag, kan ju återigen ha fel, men är det inte så att Structure inte finns i t.ex. PicBASIC (eller Great Cow Basic, som den här tråden handlar om)?
Om man nu skall skriva C med BASIC syntax, varför inte gå steget fullt ut och skriva C istället?
Och måla in sig i ett hörn tycker jag man gör hursomhelst, C-kompilatorer finns det till "alla" mikroprocessorer, BASIC finns inte.
Och är man nybörjare så ska man först sätta sig in i hur en mikroprocessorer fungerar och detta görs bäst med assembler (jag har aldrig hört talas om någon kurs på högskola/universitet där de använder BASIC när det undervisas om mikroprocessorer etc. Vi fick i alla fall öva på 6800-assembler där jag studerade)
MEN, rätta mig nu om jag har fel, till skillnad från C så är inte detta standardiserat på samma sätt (jo det finns en ANSI standard från 1987, men är detta något som nutidens BASIC följer?)
Det du pekar på sodjan känns som ganska C influerad BASIC.
Jag, kan ju återigen ha fel, men är det inte så att Structure inte finns i t.ex. PicBASIC (eller Great Cow Basic, som den här tråden handlar om)?
Om man nu skall skriva C med BASIC syntax, varför inte gå steget fullt ut och skriva C istället?
Och måla in sig i ett hörn tycker jag man gör hursomhelst, C-kompilatorer finns det till "alla" mikroprocessorer, BASIC finns inte.
Och är man nybörjare så ska man först sätta sig in i hur en mikroprocessorer fungerar och detta görs bäst med assembler (jag har aldrig hört talas om någon kurs på högskola/universitet där de använder BASIC när det undervisas om mikroprocessorer etc. Vi fick i alla fall öva på 6800-assembler där jag studerade)
Det fina i C är väl just att structen går att läsas och skrivas med hjälp av en pekare, vilket Icecap visade:
I BASIC vet jag inget sätt att spara/läsa Config utan att skriva varje element för sig, Går det att göra motsvarande C-sättet?
Kod: Markera allt
#define Save_Config() (Write_EE_Buffer(Config_Start , (BYTE*)&Config , sizeof(T_CONFIG)))
#define Read_Config() (Read_EE_Buffer (Config_Start , (BYTE*)&Config , sizeof(T_CONFIG))) 
Tack alla! 
Mycket mer info än vad jag räknat med! Min tanke var att få veta lite om det fria GC BASIC jämfört med de kommersiella utgåvorna, från olika företag! Desto bättre har jag fått veta mycket mer... Ett plus att tunga auktoriteter, här på forumet, har uttalat sig. Tillika proffs inom området, om jag förstått saken rätt.
Har noga läst igenom inläggen, har väl inte hunnit smälta allt ännu. Men tror mig hittat den röda tråden, den allmänna uppfattningen!
Jag var nog lite optimistisk, när jag trodde att BASIC skulle vara något som fungerade idag! Vi lekte lite med BASIC på våra hemdatorer för 25 år sedan!
Det var PIC-ar jag ville programera, till att göra lite roliga saker! Har nu förstått att det krävs mångåriga studier i assembler programmering, om man vill göra något annat än blinka med en lysdiod!
Som tur är har jag, än så länge, bara investerat i ett exprimentkort med programmerare samt en PIC! Får ta det som läropengar! Jag är nog till min natur en obotlig optimist!
Om jag i framtiden skulle behöva en mcu, hur dyrt är det att få den programmerad? Vilka firmor går sådant? Jag menar även utveckling av programvaran! /M
Mycket mer info än vad jag räknat med! Min tanke var att få veta lite om det fria GC BASIC jämfört med de kommersiella utgåvorna, från olika företag! Desto bättre har jag fått veta mycket mer... Ett plus att tunga auktoriteter, här på forumet, har uttalat sig. Tillika proffs inom området, om jag förstått saken rätt. Har noga läst igenom inläggen, har väl inte hunnit smälta allt ännu. Men tror mig hittat den röda tråden, den allmänna uppfattningen!
Jag var nog lite optimistisk, när jag trodde att BASIC skulle vara något som fungerade idag! Vi lekte lite med BASIC på våra hemdatorer för 25 år sedan!
Det var PIC-ar jag ville programera, till att göra lite roliga saker! Har nu förstått att det krävs mångåriga studier i assembler programmering, om man vill göra något annat än blinka med en lysdiod!
Som tur är har jag, än så länge, bara investerat i ett exprimentkort med programmerare samt en PIC! Får ta det som läropengar! Jag är nog till min natur en obotlig optimist!
Om jag i framtiden skulle behöva en mcu, hur dyrt är det att få den programmerad? Vilka firmor går sådant? Jag menar även utveckling av programvaran!
/M
Du är uppenbarligen som du säger okunnig, eller väldigt ungUrsäkta min okunnighet men vem fan är Edsger W.Dijkstra? Det är uppenbarligen en enkelspårig och trångsynt typ.
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra
Om man pysslar med programmering är det svårt att låta bli att höra talas om honom samt farbröder som Niklaus Wirth, Donald Knuth etc. För att inte tala om tanter som Grace E Hopper.
Medan operativsystem och språk kommer och går så består algoritmer och datastrukturer.
Men visst fungerar BASIC. Ingen har väl (utom Icecap)Jag var nog lite optimistisk, när jag trodde att BASIC skulle vara något som fungerade idag! Vi lekte lite med BASIC på våra hemdatorer för 25 år sedan!
påstått något annat. Det är bara det att det kanske inte alltid är rätt verktyg.
För att förstå BASIC, måste man veta historien bakom det.
BASIC var det första högnivåspråket, skapat för studenter som inte studerade datorer, mattematik, elektronik etc.
På den tiden fanns enbart FORTRAN och COBOL som standardiserade språk, vilka var rätt komplicerade att använda, dvs stansa hålkort, kompilera och läsa in.
BASIC är ett interpreterande språk, även VBA fortfarande vill jag minnas.
Detta hade fördelen, för nybörjare att se felen direkt, man behövde inte kompilera för att köra programmen.
I dag, med snabba datorer, C, JAVA, FORTH, PASCAL etc så är behovet mycket litet. Däremot är det mycket bra som scriptspråk, tex VBA och andra liknande.
Började själv en gång, mitten 70-talet med BASIC, då hette den Swapping-BASIC, och snurrade på en NakedMINI. Denna BASIC dialekt var mer en kombination av OS och Interpretator, då den hanterade all I/O i maskinen, samt att det var ett fleranvändarsystem (vi hade väl ett 20-tal användare uppkopplade mot datorn).
Därefter blev det Uppsala-BASIC eller METRIC-BASIC som den också kallades för, med samma OS funktioner som Swapping-BASIC (fleranvändare etc), samt en hel del MC6800 asm.
Sedan kom ju ABC80, hmm.
Nåväl, Kontentan är, BASIC är i dag ett något utdaterat och gammalt sätt att programmera, och det slår snabbt stopp. Duger säkert till att få en PIC/AVR/etc att blinka en lampa eller så, men sen är det väl i princip stopp.
Vill man bli "seriös" så går man över till MNEONICS, dvs ASM (ASM är fortfarande inte ett språk), eller C (beroende på processor).
BASIC var det första högnivåspråket, skapat för studenter som inte studerade datorer, mattematik, elektronik etc.
På den tiden fanns enbart FORTRAN och COBOL som standardiserade språk, vilka var rätt komplicerade att använda, dvs stansa hålkort, kompilera och läsa in.
BASIC är ett interpreterande språk, även VBA fortfarande vill jag minnas.
Detta hade fördelen, för nybörjare att se felen direkt, man behövde inte kompilera för att köra programmen.
I dag, med snabba datorer, C, JAVA, FORTH, PASCAL etc så är behovet mycket litet. Däremot är det mycket bra som scriptspråk, tex VBA och andra liknande.
Började själv en gång, mitten 70-talet med BASIC, då hette den Swapping-BASIC, och snurrade på en NakedMINI. Denna BASIC dialekt var mer en kombination av OS och Interpretator, då den hanterade all I/O i maskinen, samt att det var ett fleranvändarsystem (vi hade väl ett 20-tal användare uppkopplade mot datorn).
Därefter blev det Uppsala-BASIC eller METRIC-BASIC som den också kallades för, med samma OS funktioner som Swapping-BASIC (fleranvändare etc), samt en hel del MC6800 asm.
Sedan kom ju ABC80, hmm.
Nåväl, Kontentan är, BASIC är i dag ett något utdaterat och gammalt sätt att programmera, och det slår snabbt stopp. Duger säkert till att få en PIC/AVR/etc att blinka en lampa eller så, men sen är det väl i princip stopp.
Vill man bli "seriös" så går man över till MNEONICS, dvs ASM (ASM är fortfarande inte ett språk), eller C (beroende på processor).
Då min storebror studerade ekonomi på 70-talet skrev de program, på hålkort och lämnade in för kompilering. Resultatet fick de en vecka senare.På den tiden fanns enbart FORTRAN och COBOL som standardiserade språk, vilka var rätt komplicerade att använda, dvs stansa hålkort, kompilera och läsa in.
Flytande gräns, samma gäller Javascript, PHP etc.BASIC är ett interpreterande språk, även VBA fortfarande vill jag minnas.
Men för att återföra denna diskussion så menar jag fortfarande att Assembler är rätt verktyg om man vill förstå maskinnära programmering och PIC är i högsta grad maskinnära.
Såklart BASIC fungerar idag!
Ett exempel är mitt motorstyrsystem
http://www.elektronikforumet.com/forum/ ... highlight=
Eller om man vill använda en Nokia 6610 LCD, allt skrivet i BASIC.
http://www.elektronikforumet.com/forum/ ... highlight=
Eller om man vill bygga en: Bredbands lambdamätar display.
http://www.elektronikforumet.com/forum/ ... highlight=
Jag tycker man kommer långt med PIC-BASIC.
Men det finns ju olika PIC-BASIC, den versionen som jag använder tycker jag funkar riktigt bra.
http://www.picbasic.org/proton_development_suite.php
Det finns en test (gratis) version.
http://www.picbasic.org/proton_lite.php
sodjan:
Jag kan ge liknande kod exempel, men sodjan har redan gjort det.
Jag är inte övertygad att:
Icecap
I min första länk i denna post, är om mitt motorstyrsystem
ECUn styr både tändning och bränsle.
Mäter vattentemp, lufttemp, TPS, MAP, EGT, Batterisänning, RPM mm.
Hanterar 60-2 trigger samt hall trigger.
Har datalogg funktion.
Styr tomgång med både PID regulator och timing regulator.
Accsuprikning.
mm mm.
Liknar du detta med att blinka en LAMPA???
Ett exempel är mitt motorstyrsystem
http://www.elektronikforumet.com/forum/ ... highlight=
Eller om man vill använda en Nokia 6610 LCD, allt skrivet i BASIC.
http://www.elektronikforumet.com/forum/ ... highlight=
Eller om man vill bygga en: Bredbands lambdamätar display.
http://www.elektronikforumet.com/forum/ ... highlight=
Jag tycker man kommer långt med PIC-BASIC.
Men det finns ju olika PIC-BASIC, den versionen som jag använder tycker jag funkar riktigt bra.
http://www.picbasic.org/proton_development_suite.php
Det finns en test (gratis) version.
http://www.picbasic.org/proton_lite.php
sodjan:
ON x GOTO är riktigt stenåldern och blir bara löjligt att ta med i en
sådan här jämförelse. Problemet är att sin trovärdighet kan få en törn om
man inte riktigt kollar upp saker och ting innan man jämför.
BASIC idag är knappast vad det var när man körde ABC80....
Jag kan ge liknande kod exempel, men sodjan har redan gjort det.
Jag är inte övertygad att:
Icecap
TomasLBASIC är skit!
Va menar du?Nåväl, Kontentan är, BASIC är i dag ett något utdaterat och gammalt sätt att programmera, och det slår snabbt stopp. Duger säkert till att få en PIC/AVR/etc att blinka en lampa eller så, men sen är det väl i princip stopp.
I min första länk i denna post, är om mitt motorstyrsystem
ECUn styr både tändning och bränsle.
Mäter vattentemp, lufttemp, TPS, MAP, EGT, Batterisänning, RPM mm.
Hanterar 60-2 trigger samt hall trigger.
Har datalogg funktion.
Styr tomgång med både PID regulator och timing regulator.
Accsuprikning.
mm mm.
Liknar du detta med att blinka en LAMPA???
Jag hade bestämt mig för att inte lägga mig i den här tråden men nu kan jag inte låta bli. Jag har ingen erfarenhet av C och inte mycket av ASM för PIC heller, men jag tror att den som säger att BASIC (för PIC) inte duger till mycket mer än att blinka en lampa kan knappast tittat på, läst om, provat på eller använt t.ex PBP från MELABS.Duger säkert till att få en PIC/AVR/etc att blinka en lampa eller så, men sen är det väl i princip stopp.
Det var ett tag sedan jag använde PBP nu men det här är ett av dom senaste projekten, en protoyp av ett litet DC-servo:
En 18F2431 räknar encoder pulser med sin inbyggda QEI-modul och driver en LMD18200 H-brygga med en PWM utgång. En timer-interrupt triggar en PID-loop med 1220Hz och USART'en är kopplad till en RS485 krets så att flera enheter kan kopplas på en multi-drop RS485-bus. Via bussen kan man sätta P, I och D-parameterar hos den enhet man adresserar, man kan begära önskad hastighet av motorn och fråga om aktuell position etc.
PID-loopen körs via TMR2 och high priority interrupt medans serie-kommunikation tas om hand via low priority interrupt och "signalerar" huvud programmet när ett "komplett" kommando finns i bufferten för vidare behandling.
Kanske leksaker, kanske oseriöst enligt vissa, kanske hur lätt som helst att göra i C eller ASM - vad vet jag. Men nog f-n är det mer än att blinka en lampa.
EDIT: Såg att fler än jag "triggade" på blink-a-led uttalandet
Naturligtvis kan man göra i princip samma saker i BASIC som iC, men, som andra påpekat, en mycket distinkt skillnad:Tripp skrev:Såklart BASIC fungerar idag!
TomasLVa menar du?Nåväl, Kontentan är, BASIC är i dag ett något utdaterat och gammalt sätt att programmera, och det slår snabbt stopp. Duger säkert till att få en PIC/AVR/etc att blinka en lampa eller så, men sen är det väl i princip stopp.
I min första länk i denna post, är om mitt motorstyrsystem
ECUn styr både tändning och bränsle.
Mäter vattentemp, lufttemp, TPS, MAP, EGT, Batterisänning, RPM mm.
Hanterar 60-2 trigger samt hall trigger.
Har datalogg funktion.
Styr tomgång med både PID regulator och timing regulator.
Accsuprikning.
mm mm.
Liknar du detta med att blinka en LAMPA???
ASM -> Byt processor = Skriv om programmet.
BASIC ->Byt processor = Skriv om programmet.
C -> Byt Processor = Kompilera om programmet.
Ett inte helt ovanligt scenario, när man behöver lägga till funktioner.
Samma gäller naturligtvis om målprocessorn slutar tillverkas, vilket sker med jämna mellanrum.
Vill minnas att EEDesigner var skrivet i Basic, en gång i tiden, så visst allt går om man bara vill.
