Svenska ElektronikForumet

Då skulle kanske detta passa dig?
http://www.mikroe.com/en/compilers/mikr ... /index.htm

Glenn: och när du jämför med C, hur känns det då?

Eller är ditt tyckande baserat på att du enbart känner till PBP?

Om det är så har du alltså ingen aning om vad du har gått miste om eller hur?

Mjae, men det är väl egentligen inte så intressant ? om det känns lättarbetat och jag får det jag behöver göra gjort, varför skulle jag då behöva något annat ?

Sen förstår jag inte riktigt vad som automagiskt skulle göra att en C-kompilator skulle generera bättre asm-kod än en BASIC-kompilator egentligen, Så skulle jag lära mig något annat så skulle det bli pic-asm.

lgrfbs skrev:Då skulle kanske detta passa dig?
http://www.mikroe.com/en/compilers/mikr ... /index.htm

Hmm, jag testade nån gratiskompilator först (för över ett år sen då) och tyckte den var mycket mer svårjobbad, dock så känner jag inte igen varken tillverkaren eller sidan du länkar till så det kan ju vara ytterligare en variant.

Glenn skrev:Sen förstår jag inte riktigt vad som automagiskt skulle göra att en C-kompilator skulle generera bättre asm-kod än en C-kompilator egentligen, Så skulle jag lära mig något annat så skulle det bli pic-asm.

En C-kompilator kan generera exakt lika bra asm som en C-kompilator.
När det gäller basic däremot så antar jag (aldrig sett ett kompilerat picbasicprogram) att lösningarna blir lite mer "ala standard".

Hela resonemanget mot Basic hade inget att göra med kodgenereringen utan hur källkoden är. Det är där Basic har en del svagheter. C är betydligt mera strukturerat och dessutom bättre standardiserat.

Kan ju vara ytterligare en variant

Ja, det är väl mycket sannolikt om du inte känner igen det. Det finns ju hur många språk och kompilatorer som helst, så varför det skulle varit just den du provat vet jag inte.

Det ena skulle ju ha varit "Basic-kompilatorn" då

Fast allt hänger ju på hur bra kompilatorn är, en dålig c-kompilator genererar säkerligen sämre kod än en bra basic-kompilator, om man verkligen vill kan man ju kompilera motsvarand eprogram och sen titta på asm-filen och se hur det blev, jag har roat mej med att titta lite, men jag är för kass på pic-asm för att kunna se om det är bra eller dåligt.

Jag har lite svårt att köpa argumentet om hur standardiserat det är ? ..man skriver ju för den varianten man tänker komnpilera med.

Anledningen att jag blev lite konfunderad är ju att det afaik bara finns tre olika pic-basicar, ME-labs, Proton och en till som är hyfsat fri, men jag kan ha fel.


Iaf så upplever jag att många har fördomar utan att ens ha tittat på produkten, en person jag pratade med bashade ju PBP totalt, och jag bad honnomn om argument, varvid han hasplade ur sej "Öööh, variabelhanteringen i basic suger, du kan inte sätta variabeltyp" ..jaha, hur då frågade jag, varvid han sa typ "Ja, du kan inte definera en variabel till en byte tex, varvid jag tyckte 'foo var byte'

Jag säger inte att picbasic är för alla, kan man redan C är det säkert enklare, men PBP är väldigt kompetent.

Glenn: "Jag har lite svårt att köpa argumentet om hur standardiserat det är"
Jepp, och det är nog där du misstar dig allvarligt.

På mitt förra jobb använde jag en Fujitsu-processor till allt, till mitt nuvarande jobb "tog jag med den" för att jag kände den och vi behövde resultat snabbt.

Nu har jag gått över till Renesas M16C och jag kan FORTFARANDE kompilera källkoden utan fel! javisst, det finns hårdvaruanpassningar, jag har varit tvungen att bryta upp alla hårdvarudelar till var sin fil så att Fujitsu-processorn har en hårdvarufil och Renesas'en har en egen.

Men det berör bara interrupts, timers osv.

När timern ger en interrupt kalla båda hårdvaror SAMMA ISR rutine, likaså med AD-interrupt, seriella interrupt osv.

Mjukvarustyrd SPI till EEPROM: det är den gamla från år 2000 jag använder vid att inkludera den lika gamla EEPROM-rutinen från filen som heter "25LC160.h"

Jag har alltså runt 25.000 rader kod i projektet i "gemensamma" filer och sedan väljer kompilern vilken hårdvarudel som ska med i kompileringen.

Då jag i sin tid bytte från 8031 till Fujitsu-processorn fick jag göra om hårdvaru-delen av projektet men resten av källkoden kompilerades oförändrat... och fungerade!

Gör det i PBP...

Kan hålla med om att PBP BASIC inte är till de större projekten , men helt OK för små saker. Har gjort ett par larmsändare där det bara är en ingång som skall triggas för att sedan generera ett telefonnummer till en mobiltelefon på en serieport. Helt OK .

Men nu till min fråga , Genererar C smartare kod ?
Med smartare kod menar jag en som inte stoppar upp programkörningen vid exempelvis någon form av pause! Eller är det en fråga om hur man bär sig åt ?
I asm kan man ju räkna sig till en pause med hjälp av känd looptid och på så sätt vänta en tid och ändå göra andra saker under tiden.

I PICBASIC om man gör PAUSE 1 SEK gör processorn inget annat än vänta 1 sekund
Blir det per automatik bättre med C , eller skapar en PAUSE också programstopp i C
Eller ett bättre exempel kan ju vara att sända något seriellt i tex2400B. I BASIC blir processor fullt upptagen med detta ,hur blir det i C

Kan inget om C kanske skall tilläggas
Har jag formulerat mig så ni förstår min fråga

Visst fasiken finns det ett stort motstånd mot basic på forumet, det är det knappast någon tvekan om.

Jag ser det som så att olika verktyg kan vara bra för olika projekt och olika personer.

En jämförelse med gitarrspelande: När jag började spela gitarr så lärde jag mig genom att läsa ackord (text med ackorden skriva över) och tabbar (tabulaturer). De "kunniga" hävdar bestämt att det är värdelöst, att man måste läsa noter för att det ska vara nåt värt. "Men vadå, jag är inte intresserad av att bli en ny Santana, jag vill bara plinka lite". Med tabbar kan man lära sig att spela hyffsat, lär man sig läsa och spela efter noter kan man spela exakt som det är skrivet.

Lite lika är det med basic vs C vs asm. Basic är ackorden, C är tabbarna, och asm är noter

Själv programmerar jag i C och ASM, jag har dock kört PBasic lite när jag lekte med en Basic Stamp.

En "pause" (vad det nu heter i olika verktyg) ger samma effekt
i alla verktyg, inkl BASIC, C, Pascal och assembler. Programmet "pausar"...

> I asm kan man ju räkna sig till en pause med hjälp av känd looptid

Kass lösning (helt oavsett vilket "språk" man använder).
Dessutom är det per definition inte en "pause"...

När man gör något "på riktigt" så används naturligtsvis timers, och det är
i princip ingen skillnad mellan BASIC, C, assembler eller något annat "språk".

I ett fall finns det en skillnad och det är för mycket korta delays, där
det handlar om att räkna säg 10-20 instruktions-cykler eller så. Där finns
det igentligen ingen annan löning än att göra det i assembler, helt
oavsett vilket språk man för övrigt jobbar i.

> Eller ett bättre exempel kan ju vara att sända något seriellt i tex2400B...

Ja, det är ett bra exempel på att det inte heller här är någon som helst
skillnad mellan BASIC, C, assembler eller vilket annat "språk" som helst.
En viktig skillnad är att det är vanligare att de som kör BASIC kanske inte
*förstår* att de använder en programvaru USART, men det är ju inte
språkets/verktygets fel.

En sak som skiljer, är att de som föredrar BASIC oftare har sämre "känsla"
för hur "jobbigt" det är för processorn beroende på hur man löser
problemet. Men det har mer med att de som kör BASIC oftare har
sämre kunskap om vad som händer "under the hood" så att säga, vilket
delvis kan tillskrivas BASIC's abstraktionsnivå, det är så att säga syftet
med BASIC att man inte ska (behöva) förstå helt vad som händer...

> Men nu till min fråga , Genererar C smartare kod ?

Inte generellt. Men de som föredrar C har oftare den kunskap som behövs
för att skriva bättre (C) kod som i sin tur genererar effektivare assemblerkod.
Det är vanligare att de som föredrar BASIC saknar den kunskapen.
Om det är rätt eller fel, bra eller dåligt, tja det beror ju på...
Men det finns i princip inget som hindrar att man skriver lika bra BASIC
kod med en *bra* BASIC kompilator.

En av de mer avancerade BASIC produkterna är för övrigt XCSB:
http://www.xcprod.com/titan/XCSB/index.html

> Visst fasiken finns det ett stort motstånd mot basic...

BASIC, heter det. Dock skrivs vissa produktnamn med gemener som
i "Visual Basic" eller "mikroBasic" (med litet "m") o.s.v. Men det är en
annan sak och deras val. Språket i sig heter BASIC och inget annat.

Att det heter BASIC är väl i sammanhanget en petitess? Jag tror inte att det finns någon här inne som inte förstod vilket språk jag menade

Jag kör själv med PBP eftersom en vän till mig gav mig kompilatorn och lärde mig grunderna. Det har fungerat bra i alla mina projekt hittills men jag har märkt att det inte är så snabbt alla gånger.

Jag tycker personligen det är roligare att få klart ett projekt än att sitta och programmera hur länge som helst, men jag har funderat på att lära mig ASM men ser inget riktigt behov för det just nu. Kanske att jag börjar kolla på det mer när jag verkligen behöver ha riktigt elegant och snabb kod. Men nu spelar det ingen roll för min del, resultatet blir ändå detsamma när jag inte gör så avancerade saker.

För mig känns det oviktigt med den statusen som vissa verkar tycka att asm programmering medför. Visst, hade jag lärt mig asm från början så hade jag ju såklart kört med det men det känns onödigt att lära sig det nu när jag kan göra samma funktioner som jag behöver i ett språk som jag redan kan.

Men jag vill påpeka att om jag inte fått kompilatorn gratis hade jag nog aldrig använt den, men därmed heller aldrig kanske börjat med pic...

Icecap skrev:Glenn: "Jag har lite svårt att köpa argumentet om hur standardiserat det är"
Jepp, och det är nog där du misstar dig allvarligt

Nej, för jag ser inte mitt pic-lekande som annat än ett nöje, jag jobbar inte med programmering, och kommer antagligen aldrig att göra det heller då jag inte är så intresserad.

Det enda som driver mej är resultatet, hur jag kommer dit är inte lika intressant, även om det förstås alltid är kul att övervinna problem, såväl rent elektriskt som programmeringstekniskt.


F.ö så kan man nu ladda hem den senaste PBP-manualen från MElabs sida, om man som jag kör på en äldre version för att man inte vill betala för den senaste och därmed också har en gammal manual så är den nya en stor förbättring, exempelvis så får man små tips på optimering, typ (i sin enklaste form) att istället för:

high porta.1

..för att sätta a1 hög, så tjänar man cykler på att använda

porta.1 = 1

..om man vet att pinne a1 är en utgång redan, efterssom 'high' först kommer att sätta den till utgång, och sedan sätta den hög. ..Fullkomligt logiskt ja, men ganska bra att veta i många fall.

Nu har jag inte haft behov av att montera t.ex. EEPROM på en PIC men jag kan de-facto ta samma rutin jag redan har som en .H-fil och använda direkt.

Och visst, sitter man med bara PIC är det lugnt, man behöver knappast bygga upp ett bibliotek med användbara rutiner som fungerar "överallt" men om man någon gång skulle använda någon annan processor är halva jobbet redan gjort.