Svenska ElektronikForumet

Minns inte att jag uttalade mig om något annat språk än PicBASIC, vill inte heller påstå att dom är sämre vilket jag inte skulle tro heller. Skulle inte kunna tänka mig kalla något språk för leksak, fungerar till det de ska vilket räcker för en del. Jag har programmerat i Basic och började med en Vic64 och har försökt följa med utvecklingen i Basic programmering, det är inget bra språk men det gör det de ska så jag är nöjd. Vid nästan 60 års ålder och endast en hobby (kallat lek om du vill) så finner jag inte intresse att lära mig något annat språk. Om en del vill använda ett enkelt språk så sluta hacka på dom då.
Tror alla vet att PicBASIC inte är som en ny Volvo utan mer som en röd, rostig Fiat, men vi kommer fram med den dit vi vill för det mesta.

sdujolo2>> Det är det säker många som gör men hoppas att dom inte lägger in det på forumet.

Jag skulle nog inte kalla det för en röd rostig Fiat heller då det absolut inte behöver vara något gammalt och slitet på det sättet. Jämför hellre med en Hyundai Getz eller nåt liknande. Kan vara nytt och fräscht men kanske inte det bästa.

Jag förstår Icecap. Det frågades om Basic i samband med inbyggda system och det uttryckte han sina åsikter om, även om det inte var ett svar på den direkta frågan.

Sedan har det även fortsatt med argumentation mot det som Icecap säger, som då förklarat lite hur och varför. Inget konstigt med det. Och i många fall så gäller samma saker för hemmaanvändare som proffsanvändare. Lätt att flytta kod, lätt att föstå o.s.v. Sedan att hemmanvändaren kanske inte har lika mycket pengar att lägga på det, är en sak. Variation är naturligtvis bra i sig och tycker man att det funkar bra så är det ju bara att köra på. Inga problem där. Det är när motargumenten kommer som diskussionen blossar upp.

En viktig sak tycker jag är att de erfarna försöker överföra sin kunskap till de mindre erfarna.

BASIC ser jag som en fallgrop som är lätt att köra fast i. Man kan jämföra lite med PIC/AVR vs BasicStamp. BS är bra och enkel i början, kan kopplas direkt till serieport och så vidare MEN (och detta är ett stort men) man kommer inte så långt utan att köra i väggen och detta till stor del pga BASICs brister. Kan man inte hantera interupt och sånt så duger inte den bästa PIC/avr mycket till.

Samtidigt sitter jag själv i VB för att det är så enkelt Lite paradox kom jag på

Låt den som är utan synd kasta första stenen

En viktig sak(som redan är sagd men tål att upprepas) är iaf att man hellre gör något i BASIC än inte alls.

Men försök att fasa över så snart det är möjligt till mer hårdvarunära.

Nostalgitripp det här, tror jag deltog i såna här debatter för 20 år sen...

v-g

Kan man inte hantera interupt och sånt så duger inte den bästa PIC/avr mycket till.

Hur menar du att man inte kan använda interrupt i basic?
och vad är "och sånt"

Jag har använt interrupt i picbasic, och det gick bra. bla på timer overflow och int1.

Kan någon ge ett exempel på när picbasic inte skulle klara en uppgift??

Jag tror att du har missuppfattat.

Att BASIC-Stamp inte klarar interrupt är ju en extrem nackdel men PBP kan ju fint göra det.

Det som gör BASIC till en leksak är att man inte har den struktur som finns i C/Pascal/andra.

Men programmet kan lösa alla upgifter som en programmör kan klara att göra program för och det är just stötestenen: BASIC blir mycket snabbt plottrigt.

Har man samma struktur som i ett C/Pascal/andra där man kan skicka parameter till en namngivit rutin och att rutinen svarar med resultatet är det ju de-facto inte BASIC längre, då är det ett OOP-språk med BASIC syntax.

Jag har sett sådana program, det är ett krystat sätt att försöka få det till att bli enklare, tyvärr tappar man en stor del av funktionaliteten (pointers, casting och allt gott som man i C kan göra bort sig med)

Men man har likaväl knappast någon portabilitet i det, för en amatör kan det kanske kvitta... fram till man vill testa en ny processor och det händer, att vara amatör betyder inte att man är insnöat på PIC16F84, det betyder bara att man inte tjänar pengar på det jobb man gör.

Det händer att amatörer kommer över billiga testkit (ARM/Renesas eller andra roliga saker) och plötsligt är alla BASIC-rutiner och lösningar till att kasta. Visst, man kan skriva om dom till den nya processor och kompiler, det kan mycket väl vara att sättet är OK och att rutinen bara ska skrivas i det "nya" språket.

Men faktum kvarstår: ska lampan blinka och den gör det... då är jobbet gjort!

Men BASIC är inget seriöst programmeringsspråk, det är på tok för stympat.

v-g skrev:Assembler är nästan lika "snabbt" att koda i som C eller BASIC om man gjort lite förut och har några rutiner man vet fungerar. Från början står man med två tomma händer men de får man snabbt uppfyllda.

Det där gäller ju vilket språk man än pratar om iofs, inkl BASIC.

v-g skrev: En blink a led smäller man ihop på 10 minuter storlek c:a 200 byte. Alla "grunder" finns som färdiga sk. mallar som bara är att ladda ner från microchip.

"Blink a led" är väl iofs det enklaste du kan göra också, och det tar mer i stil med 10 sekunder med PBP..

v-g skrev: Sen går ju skiten att felsöka också vilket jag tycker är den största fördelen av alla. Ska man tex skicka kod till en display och är osäker, in med en "pause" och kolla varje pinne om den är hög eller låg med en hederlig lysdiod. Lite annat än färdiga kommandon.

..Och hur gör jag när jag felsöker picbasic ? ..tar en ledig pinne och kopplar på en LED.. ..Skillnaden är ? ..Jag kan dessutom använda debugkommandot för att få ut debug på en serieport om jag nu vill.

v-g skrev: Har även projektet uppdelat i flera filer för att få överskådlighet. Nu är jag rätt lat så jag är inte så noga men det går ju att dela upp väldigt smart så man hittar det man söker direkt.

..Och skillnaden mot PBP's includefunktion är... ?

v-g skrev: Alla kommandon står ju dessutom baki bruksen, var står de för C & basic?

I manualen till PBP, och antagligen i manualen till C-kompilatorn.. var annars ?

v-g skrev: Det som gör BASIC till en leksak är att man inte har den struktur som finns i C/Pascal/andra.

Men programmet kan lösa alla upgifter som en programmör kan klara att göra program för och det är just stötestenen: BASIC blir mycket snabbt plottrigt.

struktur ? på vilket sätt ? ..och jag tycker nog asm är bland det plottrigaste isåfall, på gott och ont.

v-g skrev: Har man samma struktur som i ett C/Pascal/andra där man kan skicka parameter till en namngivit rutin och att rutinen svarar med resultatet är det ju de-facto inte BASIC längre, då är det ett OOP-språk med BASIC syntax.

Uhm, en basic som inte kan hantera subrutiner och skicka värden fram och tillbaka är inte speciellt modern på något sätt, och givetvis kan PBP göra det, annars hade det blivit rätt jobbigt att använda. Hade det saknats namngivna subrutiner hade jag nog aldrig anvbänt det alls faktiskt.

v-g skrev: Men BASIC är inget seriöst programmeringsspråk, det är på tok för stympat.

Har du ens tittat på PBP ? ..det är inte direkt Commodore BASIC V2 vi har här, utan en BASIC som har typ 25 års extra utveckling, och är specialgjord för just PIC. På det du skriver verkar du inte ens ha tittat på det.

> Men BASIC är inget seriöst programmeringsspråk,

Det beror ju helt på den aktuella implementationen !

"BASIC" kan vara allt från GW-BASIC under DOS till
t.ex HP-BASIC under VMS där du i princip inte saknar
någonting (förutom den förvirrande och svårtydda
syntaxen i C )...

> det är på tok för stympat.

Jag är inte helt säker på vad du menar med "stympat".
Det jag tycker att en del BASIC implementationer för
(t.ex) PIC saknar, är finliret, de jobbar på en lite för
hög nivå för att man ska känna att man har kontroll
över vad som igentligen händer. Så i de fallet är C att
föredra, det var ju faktiskt ursprungligen konstruerat
för en 16 bitars maskin med (med dagens mått) ganska
begränsade resurser (som t.ex max 4 MB minne o.s.v).

Däremot fungerar andra språk (som t.ex COBOL) bättre
i riktigt stora administrativa system där säkerhet och
(speciellt) *förutsägbarhet* är viktigast. D.v.s att om koden
går igenom kompileringen så kommer den även att fungera
som programeraren avsåg.

> ..Och skillnaden mot PBP's includefunktion är... ?

Nu är ju "include" inte någon bra/snygg lösning i *något* språk.
Ska det vara någon mening med det så ska det vara
separatkompilering (eller assemblering) så att man
har separata name-space o.s.v...

> är det ju de-facto inte BASIC längre, då är det ett OOP-språk med BASIC syntax.

So what ???

FORTRAN-77 har funktioner som FORTRAN-IV saknar.
Betyder det att FORTRAN-77 inte längre är FORTRAN ?
Eller för den delen FORTRAN-90, -95, -2002 eller 2008 ?

COBOL-2002 har saker som COBOL-85 (eller -74, eller -68 eller -60)
saknade, är det alltså inte COBOL ??

Skillanden kan vara att det (så vitt jag vet) inte finns motsvarande
ANSI eller ISO standards för BASIC...

Om det nu är ”PBP PicBasic Professional” det handlar om så undrar jag:

Vad betyder ”stympat”, är det att man kan ”prata” med en USB anslutning på två korta programrader eller att ”prata” i serie (232) på en kort rad? Eller I2C, eller kanske läsa av en 18S20 med en kort rad kod?
Isåfall förstår jag vad som menas med ”stympat”!

Jag har programmerat Basic sedan Vic20 var modern. Fortsatte sedan med olika Basic-dialekter för Amiga och DOS/Windows. Har även programmerat i Pascal, diverse C-varianter, E (påminner om C), cobol, fortran, assembler och en hög andra språk.

Oavsett vilket språk man programmerar i så måste man lära sig att programmera strukturerat. Basic är inte det lättaste att göra strukturerad kod i, men ca 20 års kodande gav en hel den erfarenheter om hur man undviker fallgropar och får väldigt snåriga program att fungera. När jag började med PIC-kretsar så valde jag därför MikroBasic. Men eftersom jag ville "komma innanför skalet" och lära mig mer så undvek jag färdiga rutiner som t.ex LCD8_init() för att initiera en HD44780-display. Därför var det inte alls svårt att gå över till att börja knappa assembler för PIC-kretsarna. Det är *stor* skillnad om man bara använder färdiga rutiner!

Så varför hoppade jag då över till assembler?
Mjo.. jag höll på med ett projekt i MikroBasic där jag tvingades göra ganska mycket fusklösningar. Projektet var dessutom väldigt stort (med Basic-mått mätt). Ju mer funktioner jag lade till desto mer udda fenomen dök upp. Jag gjorde några trådar om det och det blev aldrig någon riktigt lösning på problemet. Den genererade assemblerkoden såg väldigt ..dålig ut. Väldigt många saker som skulle kunna ha gjort betydligt snyggare om man hade gjort det i assembler från början. Så där insåg jag helt enkelt varför Icecap flera gånger skrivit att Basic inte var så bra (milt sagt).

Så trots att jag alltid har mött Basic-kritik med ett stort "nja......" så fick det projektet mig att inse vad de menar.


Personligen tycker jag fortfarande att Basic inte är helt fel om man sedan tidigare är van vid Basic och vill börja med t.ex PIC-kretsar, *om* man läser databladet och undviker de färdiga rutinerna i t.ex MikroBasic eller vad man nu använder. Ska man göra väldigt små grejjer, t.ex läsa av en USART och peta ut innehållet på en display så fungerar det helt klart med de inbyggda rutinerna. Det går väldigt fort att fixa och det fungerar. Men annars hamnar man förr eller senare i en återvändsgränd och då måste man ändå lära sig hur man t.ex upprättar kommunikation med en USART.

Sedan det här med assembler. Man har galet mycket nytta av att kunna det. Det är faktiskt inte så svårt att lära sig det som man kan tro. Dessutom står faktiskt alla instruktioner i databladet, ofta med små kodexempel.


Har man programmerat Basic eller assembler i t.ex en PC så *har* man nytta av det när man börjar programmera för PIC-kretsar. Det finns naturligtvis inte t.ex TRIS och PORT i x86-assembler, men kan man syntaxen (while, for, movf, osv) från "datorprogrammering" så känner man igen sig när man börjar med PIC-kretsar. Man måste strukturera koden lite annorlunda eftersom man inte direkt kan slösa med CPU-kraften, men det är iallafall inget främmande om man har t.ex Basic, C eller assembler i bakfickan när man börjar med PIC-kretsar.




Vilket man än väljer så måste man ändå lära sig att programmera strukturerat. Det finns inget språk som gör det åt en. Däremot kan man säga att om man programmerar i assembler så tvingas man nästan att koda vettigt och programmerar man i Basic så är det lätt att det blir rörigt och fusklösningar. Assembler är som att ta på sig skorna och knyta dem. Basic är som att låta skorna vara knutna och sätta i fötterna ändå. Det går fortare att lära sig och att få resultat i Basic, men i det långa loppet har man nytta av att lära sig knyta skorna.
Men vad man än väljer så får man på sig skorna och det är väl ändå huvudsaken när det kommer till kritan.

> Basic är inte det lättaste att göra strukturerad kod i,

Samma sak här också, det beror helt på hur den aktuella
implementeringen ser ut. En del BASIC's är dåliga på det,
andra BASIC's har bra stöd för det. De kan båda vara "BASIC"
men ändå vara väldigt olika att programmera i.

> Har även programmerat i Pascal, diverse C-varianter, E (påminner om C), cobol, fortran, assembler och en hög andra språk.

Det är bara att gratulera ! Det är erfarenheter som man har oerhört
mycket hjälp av...

Sen ska man ju inte förakta faktumet att det är extremt lätt att lägga in asm-rutiner i PBP heller, tittar man på "proffsen" som hänger på PBP-forumet gör dom ofta enormt snygga program med små asm-subrutiner där det behövs, det är ganskla uppenbart att många kan pic-asm ganska bra men föredrar att använda PBP ändå för det mesta.

Det är bara dåliga hantverkare som skyller på sina verktyg...

Felsökningen jag pratade om menar jag såhär. Nu när jag skulle kommunicera med ds1820 (onewire temperaturkrets) så kunde jag stoppa sändningen BIT FÖR BIT när det (såklart ) inte fungerade med en gång. Samma med displayen när den trilskades.

Supersimpelt att bara lägga in en extern trigg för att kunna kontrollera med oscilloskop vad som egentligen skiten skickar

Har man då färdigt paket och det inte fungerar är det som att stå med hyrbil på långparkeringen på arlanda efter två veckor med innerbelysningen på, man blir torsk helt enkelt. Med assembler felsöker man ner till minsta beståndsdel och det behövs kan jag lova.

Senast idag kämpade jag med kod för one wire och lade in kod för att se i stort sett hela pulståget från resetpulse till datat mottaget på oscilloscopet.

När man är på såpass låg nivå KRÄVS det att man vet exakt var i koden man är och att inte en massa läggs till bara för ett kommando.

sodjan:Precis, sen är det ju svårt som fasen även med dremmeln att ändra inne i en krets då den inte fungerar