Great Cow BASIC

[Swech]

kanske tråden skall byta namn till
Great Saw BASIC

[H.O]

Håll er till programering grabbar, det heter gersåg eller geringssåg

[AndersG]

ngen bra liknelse heller tycker jag, för en hobbysnickare kan den billiga gersågen funka precis lika bra, den kanske inte håller för daglig användande men dom tre gångerna den ska användas så funkar den nog lika bra som den i proffskvalitet.

Nej, det gör den inte. En DeWalt är förvisso stabilare byggd, men framförallt så har den en repeterbarhet som de billiga sågarna inte har och girar du dörrfoder så vill du gärna ha samma vinkel varje gång. Det går så mycket latexfog annars...

Det skrämmande med programmering dock är att i Windows så finns latexfogen inbyggt. Det går att hacka ihop vilken skit som helst och det set hyfsat bra ut..

[Icecap]

Och jag som trodde att Windows var gjort på tuggummi... men det är alltså latexfog....

Men i essens är det rätt: en del svär till ett visst programmeringsspråk och det man egentligen skulle var att välja rätt språk till det jobb som ska utföras.

Och enl. mitt tycke är BASIC inte med i några av dessa övervägande.

Jag anser att med PIC (& liknande) är det hårdvarunära programmering det ska räknas som, alltså väljer man språk efter det, ASM eller C eller Pascal.

Och är projektet "för att lära sig" är ASM ett bra ställe att börja då man tvingas att inse att det som verkar enkelt kan vara mycket jobb bakom, man tvingas att förstå hur ett interrupt fungerar och varför man inte kan reservera mängder av minne bara för att "det blev så", något som inte alls är ovanligt vid programmering av PC.

[AndersG]

Men i essens är det rätt: en del svär till ett visst programmeringsspråk och det man egentligen skulle var att välja rätt språk till det jobb som ska utföras.

Precis, rätt verktyg till rätt uppgift. Sluta banka in spik med vattpasset...

Och enl. mitt tycke är BASIC inte med i några av dessa övervägande.

Inte i mitt heller.

Jag anser att med PIC (& liknande) är det hårdvarunära programmering det ska räknas som, alltså väljer man språk efter det, ASM eller C eller Pascal.

Precis

Jag girade foder till 4-5 dörrar med C-O billigaste girsåg med bättre
resultat än de dörrar och fönster som snickarna girade med deras proffs prylar.
Men det berodde mest på att jag var noggrannare.

Sodjan tar givetvis upp en annan bra poäng: Inga verktyg i världen kan kompensera om man saknar kunskap eller slarvar.

[v-g]

Min billiga biltemagersåg fungerade utmärkt sålänge jag var noggrann däremot blev den lite sliten sen man sågat några hundra kap

Hur man än vrider och vänder på det blir BASIC en återvändsgränd tycker jag. ASSEMBLER kan aldrig orsaka detta förutsatt att hårdvaran räcker till. Dokumentationen till ASM är ju på topp även om vissa delar såsom den delen av dokumentationen som handlar om tex relocatable mode är _icke_förklarande. Men kikar man lite runt tex på sodjans sida så går det upp ljus även för mig. Man behöver heller inte kunna allt detta för att koda även om det kan vara avgörande när man börjar fylla upp sin PIC något som snarare sker förr än senare med BASIC.

Jag gissar också på att tex min elmätare blivit svår att göra i BASIC i assembler var det en piece of cake timingen är av yttersta vikt när man räknar sånt. Det duger inte med mikrosekunder fel redan från början, sen kan ju kristallen bjuda på sitt också men det är ju inget jag kan påverka utan större mätningar(eller jo det är ju enkelt bara att lägga en trigger och mäta tiden med oscilloskop hmm ). Men som det var nu så simulerar man bara tiden i MPSIM och vips vet man hur ofta det hela räknar och kan enkelt påverka det hela ner på minsta tidsdel.

Förstår heller inte vad som är så svårt med ASM jämfört med BASIC. När registrena väl är inställda så är tex seriell komunikation überenkelt. MOVWF TXREG vips så skickas datat automagiskt Vill man ha mer kontroll så kollar man flaggor eller kör interupt. Förstår liksom inte omaket som folk påstår ligger i assembler. Visst man kan inte skicka ett värde direkt till en variabel utan måste skriva två rader men just det kan man ju benyttja till sin fördel ibland också.

[Glenn]

Hur man än vrider och vänder på det blir BASIC en återvändsgränd tycker jag. ASSEMBLER kan aldrig orsaka detta förutsatt att hårdvaran räcker till. Dokumentationen till ASM är ju på topp även om vissa delar såsom den delen av dokumentationen som handlar om tex relocatable mode är _icke_förklarande. Men kikar man lite runt tex på sodjans sida så går det upp ljus även för mig. Man behöver heller inte kunna allt detta för att koda även om det kan vara avgörande när man börjar fylla upp sin PIC något som snarare sker förr än senare med BASIC.

Jag tycker mest du säger emot dej själv

..Och en kass programmerare lär fylla minnet på pic'en snabbare än killen som kodar basic, för kör du asm hänger ju all optimering på dej själv, kör du ett högnivåspråk så hänger en stor del av optimeringen på kompilatorn.

F.ö verkar många av nån konstig anledning tro att picbasic-varianterna körs interpreterade ? så är det ju SJÄLVKLART inte, man skriver basic och kör det genom kompilatorn och får dels en asm-fil och en hexfil man lägger i pic'en, sen körs den precis som vanligt. asm-filen man får kan man ju om man vill titta på, ändra i och sedan använda.. den kan även användasa för att se hur kompilatorn jobbar, det finns även en switch att ställa in så den försöker överföra kommentarer från basicen till asm-filen, men det går förstås inte alltid så bra av naturliga skäl. (Precis som om man kör C)

Jag gissar också på att tex min elmätare blivit svår att göra i BASIC i assembler var det en piece of cake timingen är av yttersta vikt när man räknar sånt. Det duger inte med mikrosekunder fel redan från början, sen kan ju kristallen bjuda på sitt också men det är ju inget jag kan påverka utan större mätningar(eller jo det är ju enkelt bara att lägga en trigger och mäta tiden med oscilloskop hmm ). Men som det var nu så simulerar man bara tiden i MPSIM och vips vet man hur ofta det hela räknar och kan enkelt påverka det hela ner på minsta tidsdel.

Jag tror att ett så simpelt bygge hade varit *väldigt* enkelt att göra i picbasic, iaf i PBP. Jag har faktiskt funderat på att bygga en liknande sak själv ända sen fortum var här och skruvade upp min nya mätare med blinkdiod.

Har du över huvud taget tittat på produkten ? eller manualen ens ? (den finns att beskåda gratis i HTML-format)

*DET ÄR INTE INTERPRETERAD BASIC V2 MED RADNUMMER FRÅN 1982 SOM KÖRS RAKT AV HÄR"

Är det så svårt att förstå ? (Gäller inte bara dej utan många andra..)

Har du inte läst en tidigare tråd där en forummedlem har byggt en fullt fungerande ECU till en bil kodad i en pic-basic-variant ? inser du hur beroende av timeing en sådan applikation är ?

Förstår heller inte vad som är så svårt med ASM jämfört med BASIC. När registrena väl är inställda så är tex seriell komunikation überenkelt. MOVWF TXREG vips så skickas datat automagiskt Vill man ha mer kontroll så kollar man flaggor eller kör interupt. Förstår liksom inte omaket som folk påstår ligger i assembler. Visst man kan inte skicka ett värde direkt till en variabel utan måste skriva två rader men just det kan man ju benyttja till sin fördel ibland också.

..Jag upprepar mej.. har du över huvud taget tittat på PBP ? nån annan picbasic ?

Har du tittat på de kodexempel jag skrivit förut ?

Jag drar ett till (skrivet av mej själv)

Kod: Markera allt

resist0 var byte
main:
	pot portb.1,145,resist0
	HPWM 1,resist0,245
	pause 100
	GoTo main

Det lilla programmet läser av en potentiometer på 20K som sitter på RB1 (tillsammans med en konding = rc-brygga) 10ggr per sekund, och skickar ut en PWM på CCP1-porten där du lämpligen sätter en MOSFET och då kan styra en last.

Hur lång tid och hur måmnga rader kod behöver du för att göra det i asm ? vill du att jag ska lägga till funktionalitet för att
få ut värdet på LCD också ? tar tar en rad till, två om man måste använda en PIC som har PWM på samma pinne som RB3. (som 16F628)


..Börjar du förstå enkelheten nu ?

[AndersG]

..Börjar du förstå enkelheten nu ?

Men samma prylar finns i C18 och om jag måste välja, så väljer jag alla gånger att strukturerat, standardiserat språk, före BASIC. Men det är som sagt var min personliga preferens, baserat på ganska många års erfarenhet och ganska många programmeringsspråk.

Ser man sedan på den pedagogiska aspekten, så illustrerar ditt lilla program mycket tydligt varför man inte skall börja med BASIC, eller ens C/Pascal om man vill lära sig hur en PIC fungerar.

Sedan det där med tajming, jag har aldrig sagt att BASIC är interpreterande på en PIC. Det kompileras till källkod och sedan länkas biblioteksrutiner in. Vad som slutligen hamnar i din HEX-fil har du bara begränsad kontroll över. Samma om du använder C eller Pascal. Med Assembler har du 100% koll, förutsatt att du vet vad du gör.

[Icecap]

Jag får nog hålla med AndersG: den programsnudd är ett mycket bra exempel på varför man INTE ska använda PBP.

I MikroC/MikroBasic/MikroPascal finns det dessa "smarta" rutiner som kan en massa, styra LCD och skit och det är väl bra för dom som vet hur det kan fungera, jag har dock sett (i detta forum) exempel på att en UART-rutin blev inlagt och man kunde välja TX och RX pinne helt själv...

Alltså rör det sig om en soft-UART och den riktiga hårdvara-UART var alldeles ledig...

Att det i PBP finns ett kommando som heter POT är INTE en anledning att välja det språk, snarare tvärtom, dessa funktioner (i lite varierande grad och form) finns dock i de flesta språk så det är inte diskvalificerande i sig men definitivt inget att välja språket för heller!

Och hur lång tid det tar att göra samma sak i ASM? Tja, kortare tid än det tar DIG att skriva den funktion UTAN att någon har gjort ditt arbete för dig! Likaså med LCD-delen, vill du verkligen ha samma villkor gör någon annan jobbet åt dig, POT är INTE en del av BASIC, det är en extra rutin som någon har skrivit åt användaren, precis som någon har skrivit t.ex. olika utskriftbibliotek till C eller matterutiner till vilket-språk-som-helst.

[Glenn]

..Börjar du förstå enkelheten nu ?

Men samma prylar finns i C18 och om jag måste välja, så väljer jag alla gånger att strukturerat, standardiserat språk, före BASIC. Men det är som sagt var min personliga preferens, baserat på ganska många års erfarenhet och ganska många programmeringsspråk.

Javisst, jag säger inte att PBP är universallösningen på allt, men jag tycker folk har lite för lätt att av färda det som oanvändbart, det är väldigt lätt att snabbt få fungerande saker i det.

Ser man sedan på den pedagogiska aspekten, så illustrerar ditt lilla program mycket tydligt varför man inte skall börja med BASIC, eller ens C/Pascal om man vill lära sig hur en PIC fungerar.

Nej, men det gäller ju som sagt allt utom asm isåfall.

Det jag har störst problem med är folk som argumenterar för andra språk som kompileras ner ändå, att man för vissa grejer vill använda asm har jag full
förståelse för, det är baradet att tröskeln blir ganska hög om man börjar från noll och ska ha ut en fungerande lösning om man börjar med asm.

[ristomemo]

Glenn: man ska inte kasta sten i glashus.
Tror denna diskussion kommer att hålla på länge. Den har varit off topic bra länge nu. Grundfrågan var ju inte om basic i allmänhet är bra eller dåligt, utan om hur den fria versionen "Great Cow Basic" står sig mot kommersiella allternativ. För vissa fungerar BASIC ypperligt, för andra inte. Beror ju vad man vill åstakomma.
Vill man få hjälp med basic för pic utan att riskera att tråden ska bli en övertalningskampanj att byta kan nog någon av dessa forum vara bättre http://www.picbasic.co.uk/forum/ eller http://www.sonsivri.com/forum/index.php

[Andy]

Jag får nog hålla med AndersG: den programsnudd är ett mycket bra exempel på varför man INTE ska använda PBP.

I MikroC/MikroBasic/MikroPascal finns det dessa "smarta" rutiner som kan en massa, styra LCD och skit och det är väl bra för dom som vet hur det kan fungera, jag har docksett (i detta forum) exempel på att en UART-rutin blev inlagt och man kunde välja TX och RX pinne helt själv...

Alltså rör det sig om en soft-UART och den riktiga hårdvara-UART var alldeles ledig...

Att det i PBP finns ett kommando som heter POT är INTE en anledning att välja det språk, snarare tvärtom, dessa funktioner )i lite varierande grad och form) finns dock i de flesta språk så det är inte diskvalificerande i sig men definitivt inget att välja språket för heller!

Och hur lång tid det tar att göra samma sak i ASM? Tja, kortare tid än det tar DIG att skriva den funktion UTAN att någon har gjort ditt arbete för dig! Likaså med LCD-delen, vill du verkligen ha samma villkor gör någon annan jobbet åt dig, POT är INTE en del av BASIC, det är en extra rutin som någon har skrivit åt användaren, precis som någon har skrivit t.ex. olika utskriftbibliotek till C eller matterutiner till vilket-språk-som-helst.

På tal om ”smarta rutiner”, några ASM’are som jag känner jobbar ju på precis det sättet! Dom plockar ASM snuttar från ett samlat bibliotek och bygger på så sätt upp sina ASM program. Jag vet inte (trots att detta gäller flera bekanta) om det är ett normalt/vanligt sätt att använda ASM på men vad är det som säger att t ex PBP’s ”smarta rutiner” inte är uppbyggda på ett minst lika korrekt sätt som polarnas ”biblioteks rutiner”??
Är individerna som gjort PBP rutinerna/kommandona på något sätt dummare än mina ASM polare?

[Glenn]

Jag får nog hålla med AndersG: den programsnudd är ett mycket bra exempel på varför man INTE ska använda PBP.

I MikroC/MikroBasic/MikroPascal finns det dessa "smarta" rutiner som kan en massa, styra LCD och skit och det är väl bra för dom som vet hur det kan fungera, jag har docksett (i detta forum) exempel på att en UART-rutin blev inlagt och man kunde välja TX och RX pinne helt själv...

Alltså rör det sig om en soft-UART och den riktiga hårdvara-UART var alldeles ledig...

Jag förstår inte riktigt problemet här ? ..om den som programmerar gör fel så spelar det ingen roll vilket språk han eller hon har valt.

I min lilla rutin så använder jag tex hårdvaru-PWM'n, om jag hade valt en annan pinne än en CCPx så hade jag troligen helt enkelt fått ett kompileringsfel, hade jag använt kommandot pwm istället för hpwm däremot hade jag kunnat använda en annan io-pinne, men då hade allt skett i mjukvara.

Att det i PBP finns ett kommando som heter POT är INTE en anledning att välja det språk, snarare tvärtom, dessa funktioner )i lite varierande grad och form) finns dock i de flesta språk så det är inte diskvalificerande i sig men definitivt inget att välja språket för heller!

Det gör oavsett språk att det är oändligt mycket lättare att få saker att fungera, och i ärlighetens namn, just pot-exempelet är väl ganska dumt valt, det är ju en typisk grej man antagligen inte har så mycket användning för att göra på annat sätt.. interuptrutiner däremot, där ser man ofta folk lägga in lite asm-snuttar i sin kod.

Och hur lång tid det tar att göra samma sak i ASM? Tja, kortare tid än det tar DIG att skriva den funktion UTAN att någon har gjort ditt arbete för dig!

Otroligt dåligt argument, isåfall vill jag att du gör PIC'en också, och skriver all mjukvaran du utvecklar på.. hur långt vill du dra det ?

Jag använder inte några externa bibliotek och länkar till i detta fallet, det är enbart saker som är inbyggda/medföljande till kompilatorn. Jag skriver min mjukvara
i en textfil, kör kompilatorn med textfilen och aktuell picvariant som argument och får tillbaka en asm och en hexfil.

Jag sitter inte och bygger min lödkolv heller, eller blandar eget flussmedel, det finns redan färdiga varianter som gör det jag vill.

Likaså med LCD-delen, vill du verkligen ha samma villkor gör någon annan jobbet åt dig, POT är INTE en del av BASIC, det är en extra rutin som någon har skrivit åt användaren, precis som någon har skrivit t.ex. olika utskriftbibliotek till C eller matterutiner till vilket-språk-som-helst.

BEEP, både pot och lcdout *ÄR EN DEL AV PICBASIC PRO* ..jag använder externa includes också ibland, men det jag använde i exemplet ovan är ENBART sådant som finns inbyggt från början, saker som är dokumenterade i den officiella manualen, som vem som helst kan gå in och läsa online.

[Nerre]

Jag tycker det är fascinerande i den här tråden att se hur Basic-förespråkarna blir påhoppade från två håll:-)

Dels blir de påhoppade från ASM-dyrkarna, som anser att Basic döljer för mycket för programmeraren.

Dels blir de påhoppade från C-fanatikerna, som tror att Basic är interprerat och inte går att använda för strukturerad programmering.

Så när Basic-förespråkarna argumenterar mot C-fanatikernas argument så kommer ASM-dyrkarna och sågar dem (med argument som även sågar C), och när Basic-förespråkarna argumenterar mot ASM-dyrkarnas argument så kommer C-fanatikerna och sågar dem (med argument som även sågar ASM).


Ett tips till er som argumenterar: Ta era senaste inlägg. Byt ordet "Basic" mot "C" eller "Assembler" (eller vice versa) och kolla hur det blir. Det är lätt att bli hemmablind.


Det var nåt program på TV för nåt år sen som handlade om invandrare som vägrade anpassa sig. De bodde i områden där det mest bodde folk från deras land, de vägrade lära sig språket, hade egna resturanger och butiker.

Det handlade om svenskar i spanien...

[speakman]

Sammanfattar: "Samma skit. Olika semantik."