Hur koda en timer i PBasic Pro?

[sodjan]

Självklart fungerar pause *rent tekniskt* oavsett antalet rader, men
det var väl inte det som avsågs, det förstår säkert du också. Även detta
har inget med språket att göra, en pause funktion fungerar exakt lika
bra (eller dåligt) helt oavsett språk.

[TotteBasicPic]

Se.
Mikroprocessor till reglersystem tråden

1 mS Timer i programmet

Thomas

Det man inte kan göra i basic är inte värt att göra.

[Glenn]

Det man inte kan göra i basic är inte värt att göra.

Öl ?

[TotteBasicPic]

Det man inte kan göra i basic är inte värt att göra.

Öl ?

Nä men stryrningen

Thomas

[sodjan]

Problemet är inte vad man kan eller inte kan göra i BASIC.
Problemet är vad de som använder BASIC kan eller inte kan göra.

Och det som gör att just BASIC ofta framstår som lite "begränsat"
är att de som ofta använder det (i alla fall de som ofta ställer frågor
om BASIC) är lite av nybörjare (vilket absolut inte utgör en värdering
i sig). Det finns alltså en tendens att just de som använder BASIC ställer
just den typ av frågor som t.ex just denna tråd startade med. Och detta tas
ibland som en "bevis" fört att BASIC i sig skulle vara på det ena eller det
andra sättet, vilket naturligstvis är fel.

Den som hade varit väl bevandrad i mikrokontrollers hade sannolikt aldrig
ställt den frågan och löst det hela "som vanligt", helt oavsett att det
råkade vara ett BASIC baserat verktyg som används.

Därmed inte sagt att frågan i sig var fel eller dum, det är att använda den
aktuella frågan som ett bevis för att BASIC är på det ena eller den andra
sättet som är fel och dumt.

[Kretskort]

Jag är grymt nöjd med PBP. Förra året gjorde jag en steglös fläktcontroller till en solfångare som blev enkel att programmera med dom färdiga kommandona för hårdvaru PWM och ADC. Dom färdiga LCD kommandona är också väldigt användbara.

Nu har jag börjat på Chalmers och där använder vi C. Det kan vara att jag inte kommit in i det ännu men det känns som att det är onödigt krångligt. Som det är nu har jag svårt att se vad som skulle bli begränsande i PBP.

[sodjan]

Oj, 2 och ett halv år !...

C är inget bra språk *i sig*. Fördelen med det är att det är spritt,
och det överväger ofta nackdelarna. Men som programmeringsspråk
har det en hel del brister.

> Som det är nu har jag svårt att se vad som skulle bli begränsande i PBP...

Portabilitet, t.ex.

[Icecap]

Ett enkelt exempel:

Ett projekt styr en enhet. Det projekt ska kunde kommunicera via en seriell port med en PC där det ska göras ett program som visar värden och tillåter att man ändrar dom osv.

Jag är ganska säker på att man inte kan göra PC-programmet i PBP!

Visst kan man göra det i ett annat programmeringsspråk, kanske VB eller liknande men fördelen med C i "båda ändar" är att jag har en enda gemensam kommunikationsdefinitionsfil som båda använder i kompileringen. Jag kan alltså enkelt ändra/lägga till/ta bort något i den fil och sedan bara kompilera om programmen och allt fungera helt utan problem. Alla ändringar i definitionerna sker ett enda ställe som är gemensamt för båda projekt.

Detta måste man göra manuellt med PBP + VB och någonstans på vägen blir det fel! Inte för att det är PBP eller VB men för att det ska göras manuellt! Visst, de första 3 ändringar är inget problem men någonstans på vägen blir det fel!

Sedan är portabiliteten ytterst trevlig! Rutinen jag utvecklade till min dåvarande Z80 hemdator använder jag fortfarande till PIC (16 & 18), Fujitsu's FFMC-16LX, Renesas M16C och AVR... utan ändringar!

Jag portade ett stort program från Intel 80C320 till FFMC-16LX i sin tid, fick skriva om hårdvaruinitieringen och ISR'arna - men sedan fungerade det som tänkt i första test.

Så standard är en bra sak! Gör om det med PBP...

Men ändå: har man ingen ambitioner om att någonsin lämna PIC-världen är det helt fint med PBP, problemet är först när man sniffar på annat, då finns inte PBP. Kanske man kan hitta en annan BASIC till det projekt men syntax kommer inte att vara lika med PBP ändå, det kommer att vara skillnader!

[Glenn]

Nu får du ju ge dej, det klart att projektet i sej skulle fungera alldeles utmärkt att göra i PBP, man börjar väl ändå med att designa ett protokoll, sen låter man båda ändarna prata detta.


Dina argument är än en gång i stil med att "Det är bäst att köpa en volvo, för volvoverkstaden kan så lite om toyota, och så få delar på deras lager passar till toyotor!"

[Icecap]

Glenn: Jag förstår att dina erfarenheter med detta är begränsade men jag har projekt som har hållit på att expanderas och ändras under 10 år. Och då processorn har utgått ur produktion måste jag byta och i detta fall blir det till ett helt annat fabrikat, enbart för att projektet fortfarande säljs och kommer att göra det ett antal år fram i tiden.

Så din argumentation visar bara att du inte vet hur det är i verkliga livet...

Jag är fortfarande i kontakt med dom jag jobbade för 1998-2005, där programmerar jag fortfarande på de gamla projekt och det har blivit "en och annan" ändring under tiden och även där är det inblandat olika processorer men då det är C som programmeringsspråk har porteringen gått enkelt.

Och sedan ser jag inte vad bilmärken har med saken att göra, ska du hålla dig till fordon-analogi är det mer "använd en Otto-motor, den har visat sig fungera i många olika fordon" som jag förordar! Men den kanske är för avancerat för dig?

Men jag vill gärna veta: vilka argument har du för att PBP är det enda vettiga?

Jag påstår inte att C är enkelt! Då jag skulle börja med Pascal gick det ett par månader där jag klurade som en tok på hur fan skiten var skruvat ihop men då jag väl insett syntaxen och hur man kunde bygga variabler och använda på det sätt jag ville blev jag mycket nöjd, det fungerade så smidigt som jag ville ha det.

Sedan blev jag introducerat till C, det liknade Pascal så pass att jag enkelt kunde byta och jag lärde mycket snabbt att uppskatta vissa skillnader som jag kände är en stor fördel med C - men grunden i programmeringssättet är ju lika. Vad jag förstår är PBP mycket pascal-liknande fast med BASIC-"ord" istället, alltså subtila skillnader så det är inte strukturen i C/Pascal du inte klarar av, alltså måste det vara något annat som gör att allt annat suger. Men vad?

sodjan: C är ett kraftfullt språk och precis som du skriver kan man göra bort sig helt enormt! Det är en styrka och svaghet samtidig att det är så okontrollerat. C++ ska ju vara mer strukturerat men i grunden är det mest "kom inte ihåg"-saker som är fixat, man kan fortfarande göra bort sig enormt. C# skulle ta hand om det och jag har lekt med det men jag anser inte att det fungerar bra för mig.

[sodjan]

> visar bara att du inte vet hur det är i verkliga livet...

Nu så skiljer sig kanske ditt "verkliga liv" ganska mycket från
den "verkliga liv" en hobbyist och hemmapulare upplever...

> Men jag vill gärna veta: vilka argument har du för att PBP är det enda vettiga?

Lägg av. Det är det ingen som har sagt !

> alltså måste det vara något annat som gör att allt annat suger.

Det är det väl inte heller någon som har påstått !?
Du överdriver ganska mycket...

[Glenn]

Glenn: Jag förstår att dina erfarenheter med detta är begränsade men jag har projekt som har hållit på att expanderas och ändras under 10 år. Och då processorn har utgått ur produktion måste jag byta och i detta fall blir det till ett helt annat fabrikat, enbart för att projektet fortfarande säljs och kommer att göra det ett antal år fram i tiden.

Det är ju dock något som är fullkomligt irrlevant för typ 99% här inne, dessutom ser jag inte riktigt hur det skulle hjälpa att använda C i det fallet.

Så din argumentation visar bara att du inte vet hur det är i verkliga livet...

Du tycker inte att du själv applicerar DIN situation på alla andra och tar den som norm ? definitionen av "verkliga livet" skiljer sej ganska mycket beroende på vad man tänker göra och vilka förutsättningar man har. Är man i sverige är svenska ett användbart språk, men befinner man sej i sydamerika funkar spanska bättre, har man en kompis som äger en volvoverkstad är det förstås fördelaktigt att köra volvo.

JAG skriver inte PIC-kod för att sälja eller livnära mej på, JAG skriver det för att jag vill lösa ett problem, för min del är det oftast så att jag vill bygga något och då funderar jag på hur jag enklast löser det med vad jag har tillgängligt, min nixieklocka jag har tänkt bygga i sådär 15 år eller nåt designade jag först (på papper) enbart med logikkretsar och en 1Hz-klockning på det, efterssom det var enklast med dom förutsättningarna jag hade, den senaste reinkarnationen är baserad på en PIC, efterssom jag nu kände att det var enklaste vägen.

I MITT verkliga liv är PIC-programmering bara en hobby. ..Och det gäller nog de flesta här.

Och sedan ser jag inte vad bilmärken har med saken att göra, ska du hålla dig till fordon-analogi är det mer "använd en Otto-motor, den har visat sig fungera i många olika fordon" som jag förordar! Men den kanske är för avancerat för dig?

Min poäng med liknelsen var att du applicerade din smala bild av verkligheten på alla som läste det.

Kan man redan C är det ju säkert jättebra att börja med det, ska man bygga nåt som måste vara superoptimerat så är det troligen bättre att köra asm eller ännu hellre hyra in nån som kan det redan.

..Sen ser det inte speciellt snyggt ut att flika in förolämpningar i argumentationen, det gör dessutom att det är svårare att ta dina faktiska argument på allvar.

Men jag vill gärna veta: vilka argument har du för att PBP är det enda vettiga?

Var har jag påstått det ? ..Det har jag inte gjort, inte i denna tråden eller i någon annan tråd.

Jag har tvärt om flertalet gånger sagt att jag snarare delar upp det hela i asm och högnivåspråk, och dessa har sina för och nackdelar,
högnivåspråken (framförallt C och olika BASIC-varianter) är enklare att koda i, men man har mindre detaljkontroll på hårdvaran.

Just PBP har en stor nackdel, dess kostnad (eller, gratisversionens begränsningar om man nu ser det så), denna kostnaden har däremot
även funnits för C på PIC tills ganska nyligen (och även till viss del idag tror jag.) Dess stora fördel är hur snabbt det går att komma igång
och faktiskt få något fungerande.

Sedan blev jag introducerat till C, det liknade Pascal så pass att jag enkelt kunde byta och jag lärde mycket snabbt att uppskatta vissa skillnader som jag kände är en stor fördel med C - men grunden i programmeringssättet är ju lika. Vad jag förstår är PBP mycket pascal-liknande fast med BASIC-"ord" istället, alltså subtila skillnader så det är inte strukturen i C/Pascal du inte klarar av, alltså måste det vara något annat som gör att allt annat suger. Men vad?

Var påstod jag att allt annat suger ? lägg inte ord i min mun.

PBP är väl snarare en modern BASIC, jag har inte kodat speciellt mycket BASIC annat än på 8-bitarstiden, ingen pascal och väldigt lite C, så jag är inte rätt person att avgöra det, däremot har jag postat lite PBP-kod i diverse trådar (och i mitt tävlingsprojekt) som man kan titta på om man vill avgöra det. (Eller så googlar man fram andra personers kod och tittar på den.)

Det var ju ett tag sen BASIC var synonymt med radnummer, även om folk som ogillar språket gärna vill se det så fortfarande

Anledningen att jag PERSONLIGEN föredrar PBP är framförallt att jag tycker det är en väldigt lätt syntax och ett logiskt språk, och framförallt ser jag inte en enda fördel med att försöka lära mej C som också är ett högnivåspråk och alltså inte ger de fördelarna ett byte till asm skulle ge mej.

[vfr]

Det Icecap säger, kanske inte är applicerbart till 100% på alla dom hobbyprojekt som finns här, eller ens i närheten. Men han har ändå en poäng i all den grundläggande argumentationen. Även här i hobbyprojekten skulle man ha bra nytta av att kunna använda t.ex samma inkluderingsfiler i både PC-ändan och uC-ändan av en kommunikationslänk. Och som han skriver så blir det mycket mindre risk för fel när man kan använda samma definitioner. Även i hobbysammanhang. Alla vill väl komma framåt med sina projekt och lära sig verkligt nya saker, istället för att lägga tid på att felsöka idiotfel som t.ex beror på att konstanter är definierade olika i olika delar av ett projekt.

Jag har gjort flera hobbyprojekt med nytta av det här. Jag tror inte att dom varit där dom är idag, om jag inte kunnat ta filer och lyfta rakt över och VETA att innehållet är riktigt.

Som sagt, kanske lite överdrivet, men korrekt enligt min mening!

[TomasL]

Det spelar egentligen ingen roll vilka verktyg man väljer, må vara C, Basic, Pascal, Forth eller till och med Assembler, men man skall vara medveten om verktygens begränsningar.

När det gäller uControllervärlden finns det bara ett val om man vill ha porterbarhet och kunna växa, och det är just C, inga av de andra valen erbjuder just detta.
Sedan är det upp till varje individ att bedöma huruvida man vill låsa in sig i ett hörn, eller kunna växa utan att behöva uppfinna hjulet gång på gång.
Visst, är man nöjd med exempelvis Basic, och inte för allt "smör i småland" kan tänka sig att byta hårdvara, då är det ok, samma gäller naturligtvis också för Assembler, Forth, Pascal mfl verktyg.
Problemet uppkommer ju naturligtvis när man vill/måste byta hårdvara/Arkitektur, då är allt jobb man lade ned på sina Basic/Assemblerprogram osv till ingen nytta, och man får oftast börja om på ny kula.

Sedan tror jag definitivt inte att C är svårare att lära sig än till exempel Basic.

[sodjan]

> Men han har ändå en poäng i all den grundläggande argumentationen.

Ja men visst !

Det var mer "i verkliga livet", "...PBP är det enda vettiga", "...som gör att allt annat suger"
o.s.v som var det som i alla fall jag reagerade lite på.

> ...då är allt jobb man lade ned på sina Basic/Assemblerprogram osv till ingen nytta,

Det är klart att man kanske inte har någon nytta av själva *koden*, men jobbet man
lade ner kan mycket väl vara till stor nytta. Det man lärde sig om programmering
rent generellt (oavset språket) kan alltid vara till nytta.