Great Cow BASIC

[TotteBasicPic]

Hej har programerat i Basic sen 80-Talets mitt med upphåll också.
Jag säga att det fungerar i alla läggen ut märkt.
kör i dag VB6 .VB
Använder i dag PICBASIC Pro från Melabs för jag använder mycket serial Komunkation till Picarna där jag Använder från 12f675 till 18F252
Så jag tyckar du skall prova med en fri version först och om det passar så skaffa en Compilator med många färdiga Kommandon.

H.
Thomas

[v-g]

Mythbusters borde knäcka denna myt: Assembler är svårt att lära sig.

Kommandona står hur de fungerar bak i databladet. Huvudstrukturen för ett program finns på microchip. Alla kommandon kan torrjuckas rakt i MPASM så man ser hur registren påverkas.

Frågor utöver detta finns EF att få svar på.

Generella program i all ära men är detta något en glad amatör behöver ens lägga en tanke på? Ska vara om man funderar på att använda det i "tjänsten" men då räknar jag inte det som amatör.

Jag personligen valde PIC för att dels var det en ganska stor familj med många möjligheter och som jag ser det klarar jag mig på deras utbud för privat bruk sen har de BRA datablad. Om inte microchip konkar så ser jag ingen anledning att ens fundera på att byta.

Assembler då? Jo kodexemplen i databladet är i ASM, för att utveckla behöver man inte "testa" några verktyg för att se om det "fungerar"(MPASM). Gratis vill man ju ha, då kostnaderna ska vara helst noll. C kostar, BASIC kostar medans ASM är 100% gratis.

BASIC testade jag på BS2 och så fort jag körde skallen i väggen med den processorn vill jag inte ens tänka på. Samtidigt insåg jag BASICs begränsningar. Dvs bäst att lära rätt från början och hiva BS2.

Jag har alltid försökt skriva strukturerat och kommentera så gott det går (om det inte är självklart vad som händer) och på så sätt blir även långa haranger av kod lättlästa. Man kan även dela upp programmen i olika filer tex för att slippa se returntables/delaykod/osv i "huvudprogrammet". På något sätt blir det hela "C-Orienterat" även om man inte kan skicka parametrar lika lätt mellan programmets olika rutiner Å andra sidan kan man ju återanvända variablerna enklare då.

Lika lätt som jag skriver ett (hyffsat) strukturerat inlägg skriver jag dito assemblerprogram. Avdelare/indenteringar/STORA/små bokstäver allt gör de sitt till. Nämnde jag att jag kör Case sensitivity på i MPASM

ASM är dessutom så inbjudande till små fiffiga lösningar, tex kanske man använder de 4 låga BITsen på en byte till något. Då är det dyngenkelt att använda de 4 höga BITsen till annat utan att påverka de lägre. På så sätt spar man enkelt många variabler och därmed minne. I de flesta fallen onödigt men när de obankade minnesplatserna tryter så är det ett smidigt sätt då man kanske bara behöver indikera 1 eller 0.

Fördel också är att man väldigt enkelt kan felsöka assemblerkod, helt enkelt eftersom man kan avbryta den varsomhelst eller slänga in en trigger till oscilloskop/display eller dylikt.

Trots BASICs enkelhet krävs det att man måste kunna läsa databladet om man ska använda några roliga saker i processorn som I2C/ A/D /timers/interupt osv. Kan man inte dessa så är det ju rätt fetkört att komma längre än blinka en led i olika mönster.

I assembler kan man aldrig köra in i väggen så länge man ligger innanför vad µcns begränsningar tillåter.

[AndersG]

Under tiden har jag hittat en sida, som på ett bra sätt förklarar, varför BASIC är "överlägset" Assembler! /M

Skriven av någon som naturligtvis är helt opartisk och inte alls vill sälja sin kompilator

Länken är annars ett lika bra argument varför BASIC är direkt olämpligt om man skall lära sig en PIC, nämligen att man döljer mycket av hårdvaran.

Poängen med att börja med Assembler som man skall lära sig en PIC är att då har man en större chans att förstå vad som händer.

Som sodjan säger, vi vet eg inte vad du är ute efter? Att bara lära sig PIC? Att bygga ihop ett specifikt projekt där det spelar mindre roll om du förstår vad som händer?

Jag säga att det fungerar i alla läggen ut märkt.
kör i dag VB6 .VB

Och du kan flytta din VB kod till PIC?

[sodjan]

> BASIC testade jag på BS2...

Nu är inte BASIC Stamp någon speciellt bra referens för BASIC i allmänhet.
Stamparna är interpreterande och därför (rellativt) långsamma. Det kan
nog inte jämföras med en "vanlig" modern BASIC kompilator.

För övrigt håller jag med, assembler är roligare, intressantare, mer
spännande och ger mer oj-vad-jag-är-bra känsla när det väl fungerar...

[vfr]

Bra formulerat v-g!!

[AndersG]

För övrigt håller jag med, assembler är roligare, intressantare, mer
spännande och ger mer oj-vad-jag-är-bra känsla när det väl fungerar...

Håller med, till 100%. Därmed inte sagt att Assembler är det optimala för alla uppgifter.

[TomasL]

Nu vet jag naturligtvis inte hur man får en LED att blinka i BASIC, men i både C och ASM är det ju enkelt:
I C

Kod: Markera allt

while (1)
{
 #asmline btg PORTA,0
}

eller

Kod: Markera allt

while (1)
{
bRA0=~bRA0;
}

I ASM

Kod: Markera allt

:label
        btg PORTA,0
        bra label

lite olika beroende på kompilator resp assemblator (och processor, när det gäller ASM)

Om jag förstått saken rätt, så gör man så här i GCBASIC

Kod: Markera allt

Main:
Set PortA.0 On
Set PortA.0 Off
goto Main

Det intressanta är hur mycket verklig kod som genereras.
I C har man oerhörda möjligheter att skriva kompakt kod, naturligtvis ännu större i ASM.
Gissar att man har små möjligheter att påverka detta i BASIC

[TotteBasicPic]

Kan bara hålla med sodjan Basic stamp är inget bra exempel på Basic fungerar men långsam.
Har bara använt denna i ett Project slog i Taket så räckte.

Kan bara säga att jag har fått fram mer av hårdvaran
när man använder Basic man Behöver inte lägga så mycket tid på hårdvaran efter som det mesta är klart.

Mapsm har jag ingen erfarenhet av efter som jag körde maskinkod innan jag började med basic. Det fönstret ser jag bara i ett par sekunder innan kompileringen är klar.

Basic går fint att Dima från bit.1 till byte , words och long i 18f serien.

Tyvärr är Basic brett språk med många dialekter.
VB6 en .Vb en annan Microbasic en och Melbs en och så vidare.

vad kul det skull var att kolla ur stor hex filen blir.

Själv skull jag vilja se den blinka.

Dim led as porta.0

main:
high led
pause 500
low led
pause 500
goto main

H. Thomas

[sodjan]

Jag tror inte skillnaden är så speciellt stor mellan C och BASIC, så
länge som man undviker "burkade" rutiner och bara manipulerar
register och enkla (byte) variabler. Problemet är att den som tycker
att det finns fördelar med BASIC's (till viss del skenbara) fördelar, också
sannolikt till större del använder färdiga rutiner och alltså sannolikt
genererar mer kod för att lösa samma problem, men det är inte så
mycket verktygens "fel" som man kanske kan tro.

Som jag har sagt tidigare, skillnaden mellan BASIC, C och andra verktyg
ligger främst i vilken bakgrund den som använder verktygen har. D.v.s att
det beror mer på den som använder verktygen än på verktygen i sig hur
resultatet blir.

Det finns naturligstvis ingenting inbyggt i BASIC som skulle göra att t.ex
"Set PortA.0 On" skulle generera mer kod än motsvarande i C eller ASM.

En nybörjare kommer att skriva skit-kod helt oavsett vilket verktyg som används...

[Kaggen]

Det har för många blivit en konstform att optimera kod! Trots att det, i många tillämpningar, inte behövs med dagens snabba och minnesstarka prossesorer! /M

Aargh! Detta uttalande är värre än att använda BASIC. Jag har tyvärr sett allt förmånga program (även professionella) som går som stelnad siiiirrraaap på de modernaste 3GHz burkar. Man skulle kunna tro att det var ett skämt. Skulle kunna tro att en BASIC tolk tolkar en BASIC tolk som tolkar en BASIC tolk... ja.. ni förstår.

Jag tror inte ens vissa "professionella" leverantörer vet hur man refaktorerar och använder index i databaser. En uppsjö med buggar och löjliga workarounds så att man nästan skäms att visa dom stackare som skall använda skräpet.

De fördomar jag har mot de som använder BASIC (jag erkänner iaf att jag har fördomar) är att de är för lata att lära sig hur saker fungerar, försöker hitta det minsta motståndets väg (vilket iofs är smart). Sedan hoppas man på att alla eventuella problem ska lösa sig med någon simpel innbyggd BASIC funktion och slippa läsa datablad. Andra fördomar mot de samma är dåligt strukturerad och optimerad kod. Jag kan ju iofs ha fel iaf i 1-2% av fallen.

Allvarligt talat så är kanske inte BASIC i sig det största problemet (jag började trots allt där jag med) utan dålig programmering. Många tänker inte heller på följderna av sin programmering (hur saker fungerar med andra program, säkerhet, felhantering, användarvänlighet), utan när deras applikation funkar hyffsat på deras egen nyinstallerade 4GHz Windows 5000 burk med senaste drivisarna och VB dotNet 9.0 så tror dom det funkar på alla datorer i världen.

OBS! ovanstående skall inte tas på förstort allvar (förutom det om dåligt optimerade program). En jag vet har gjort mer vettigt i Bascom-avr än jag nånsin vågat ge mig in på.

[AndersG]

yinstallerade 4GHz Windows 5000 burk med senaste drivisarna och VB dotNet 9.0 så tror dom det funkar på alla datorer i världen

För att inte tala om att programmet aldrig testas tillsammans med andra program.... För visst är det så att varje användare har en dator för varje program...

[TotteBasicPic]

Ja ack vad mycket skit kod man skrivit och hur många timmar men läst data blad för att få en timer eller en interrupt att fungera eller den lilla AD att fungera.

Som man kom på flera år senare varför gjorde jag inte så här.

Som tur är finns det snabbar och större Picar för var Dag.

H.Thomas

[v-g]

Givet att BS2 BASIC är crap, hela processorn är ju en återvändsgränd som bara väntar på att bli varse vid första bästa glitch. Kontentan var dock att jag insåg att BASIC _ÄR INTE_ en bra väg att lära sig saker.

TomasL:Ditt exempel för ASM kommer inte fungera Fördröjningen mellan tänd/släckt är inte ens en mikrosekund

Vanligt fel i ASM (det går för fort )

ASM är kanske inte det bästa alla gånger men för hårdvarunära programmering som µc är "all about" är det väldigt optimalt. Däremot ÄR det ganska svårt att göra lite mer avancerade mattefunktioner i ASM. Allt finns dock löst om man ids leta en par minuter med google.

Det går ju heller inte att bara skriva a>b utan man måste mixtra lite med addition/subtraktion för att få till det hela. Men allt detta är så förbaskade enkelt när man väl kan det så det är inget problem egentligen. Däremot kan man direkt se hur många rader som krävs/genreras just för detta.

Mycket handlar också om att förstå BIT & byte och hur dessa fungerar något som är ovärdeligt när man ska kommunicera med andra saker såsom en display eller liknande.

För ros skull kan jag dra en liknelse jag kom på:
Om vi tänker oss en myskväll med en trevlig date. Skulle du hellre sitta i en blästerbur och bara kunna "manipulera" din date med tjocka gummihandskar med tre fingrar.

Alternativt sitta utanför och dels kunna äta chips & dipp samt verkligen vara hands on?

Visst det är lite jobb att ta fram chipsen och blanda dippen men när det väl är gjort så slipper du ju göra det igen.

Det senare är ASSEMBLER och daten är åtråvärd dvs det är inget ras man bara vill bli av med, då rekommenderar jag faktist buren.

Sen en sanning som alltid gäller:


Många sk. moderna program är så värdelöst kodade att de som gjort dessa borde få en spark i arslet rent ut sagt. Lathet är bara förnamnet. Alla har inte superdatorer hemma/på jobbet.

[TomasL]

TomasL: Ditt exempel för ASM kommer inte fungera Wink Fördröjningen mellan tänd/släckt är inte ens en mikrosekund Very Happy

Jovisst gör den det, men fort går det.
ASM-rutinen och den första C-rutinen gör åt 2 cykler, dvs dioden blinkar med runt 5 MHz om PICen körs med 40 MHz (om jag inte minnet sviker mig helt.
Den andra C-rutinen, o-optimerad med min kompilator genererar 9 ord, vilket bör ge en blinkfrekvens runt 1 MHz.
Men som sagt, storleken på den andra C-rutinen är oerhört kompilatorberoende.

[AndersG]

Men om en LED blinkar och ingen ser den... Blinkar den då?