Hur många här använder PICBasic Compiler?
..Jag vet att det bara var ett exempel men..Icecap skrev: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.
http://www.melabs.com/resources/pbpmanu ... 21.htm#518
http://www.melabs.com/resources/pbpmanu ... 62.htm#556
Så där har man det redan löst
Jag förstår dock din poäng, men jag ser inte riktigt var jag någonsin skulle behöva kunskapen, och skulle jag det, ja då får jag väl lösa det då, istället ägnar jag två sekunder åt att lösa problemet i PBP nu.
..Fast nu är det ju så att med PBP så har ju någon annan redan uppfunnit hjulet, så man använder det ju bara istället för att uppfinna det själv.vfr skrev:Håller med Icecap! Det har man definitivt nytta av även som hobbyist! Ju mindre tid man behöver lägga på att göra samma sak igen, desto fler hobbyprojekt hinner man med! Och kan syssla med nya roligare saker istället för att uppfinna hjulet igen.
Visst, en del saker är ju lösta, men långt ifrån alla. Dessutom kan det ibland vara svårt att veta hur dessa lösningar egentligen fungerar i alla avseenden. Men helt korrekt så har det egentligen inte med språket i sig att göra. Det kan man få även i C t.ex. Eller genom att använda ett externt bibliotek i asm. Argumenten mot BASIC i tråden var huvudsakligen mot språket som sådant och dess icke-standard.
PBP genererar inte större eller sämre kod än andra kompilatorer, det är bara sant om Basicen är använd på ett tokigt sätt.
Det går fint att "stoppa in" asm kod i Basicen om man tycker att det finns ett bättre sätt att lösa en speciell uppgift i ett program.
Hittills har jag endast ogillat DIV32 i PBP, det är lite omständigt fast jämfört med asm är det OK. Jag är mycket nöjd med PBP till de applikationer som jag hittills kört.
Jag tittade på Swordfish kompilatorn som hastigast, den ser väldigt intressant ut även vad gäller struktuering. Finns gratisvariant utan begränsningar utom för antalet variabler (om jag uppfattade det rätt). Swordfish är dock bara för 18 serien men vad gör det?
http://www.sfcompiler.co.uk/swordfish/
Det går fint att "stoppa in" asm kod i Basicen om man tycker att det finns ett bättre sätt att lösa en speciell uppgift i ett program.
Hittills har jag endast ogillat DIV32 i PBP, det är lite omständigt fast jämfört med asm är det OK. Jag är mycket nöjd med PBP till de applikationer som jag hittills kört.
Jag tittade på Swordfish kompilatorn som hastigast, den ser väldigt intressant ut även vad gäller struktuering. Finns gratisvariant utan begränsningar utom för antalet variabler (om jag uppfattade det rätt). Swordfish är dock bara för 18 serien men vad gör det?
http://www.sfcompiler.co.uk/swordfish/
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.
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.
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.
Finns också många fallgropar MEN de flesta står faktist i manualen om man ids läsa och manualen (till PIC) är avsedd för ASM.
Det finns ju såklart också en del nackdelar också bla matte kan ju vara knivigt, Alla problem FINNS dock lösta (om än inte alltid fungerande
) på piclist. Sen VET man ju inte om en rad i c eller v genererar hundra i ASM.
BASIC är som att bygga taket innan grunden. C kan vara samma sak om man inte har koll på grunderna.
I MPLAB finns många smarta funktioner som gör att man slipper hårdkoda adresser osv. I mitt displayprogram tex finns inga fasta hållpunkter förrutom startsektorn. Allt annat cirkulerar runt om man kollar i programminnet. Dvs inga problem att lägga till eller ta bort värden,sektioner osv.
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.
Alla kommandon står ju dessutom baki bruksen, var står de för C & basic?
Sen VET man att kodar man rätt så gör den exakt det den blir tillsagd att göra och inte massa annat.
ASSEMBLER åt folket!
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.
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.
Finns också många fallgropar MEN de flesta står faktist i manualen om man ids läsa och manualen (till PIC) är avsedd för ASM.
Det finns ju såklart också en del nackdelar också bla matte kan ju vara knivigt, Alla problem FINNS dock lösta (om än inte alltid fungerande
) på piclist. Sen VET man ju inte om en rad i c eller v genererar hundra i ASM.BASIC är som att bygga taket innan grunden. C kan vara samma sak om man inte har koll på grunderna.
I MPLAB finns många smarta funktioner som gör att man slipper hårdkoda adresser osv. I mitt displayprogram tex finns inga fasta hållpunkter förrutom startsektorn. Allt annat cirkulerar runt om man kollar i programminnet. Dvs inga problem att lägga till eller ta bort värden,sektioner osv.
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.
Alla kommandon står ju dessutom baki bruksen, var står de för C & basic?
Sen VET man att kodar man rätt så gör den exakt det den blir tillsagd att göra och inte massa annat.ASSEMBLER åt folket!
Tips på en E-bay aktion
ebay PIC-Basic-Swordfish-Compiler-w-2-USB-Dongles
Edit:
Ändrade en lång url till en länk //lgrfbs
ebay PIC-Basic-Swordfish-Compiler-w-2-USB-Dongles
Edit:
Ändrade en lång url till en länk //lgrfbs
C åt folket, assembler är överskattat.
Jag har jobbat med hårdvarunära programering i typ 10 år nu, Jag förstår teorierna bakom assembler och skulle säkert med databladet och en asm referensi högsta hugg kunna skriva ihop fungerande applikationer.
Senaste veckorna har jag växlat mellan 4 olika µC av olika fabrikat, är det då meningen att jag ska sätta mig in i assemblern för varje? Istället för att koncentrera mig på att lösa problemen?
Men vist kan det vara bra att trycka in lite assembler i halsen på nybörjarna, det ger förhoppningsvis en förstålese för hur det hela funkar... och mindre "windowsprogrammerade" *1 inbyggda system för mig att reda upp...
*1 Med windowsprogrammerade system menar jag att det skiljer sig ganska radikalt i tankesätt att skriva en applikation till en vanlig PC snurrandes windows med gigabyte av minne och en liten µC. Detta verkar få förstå...
Jag har jobbat med hårdvarunära programering i typ 10 år nu, Jag förstår teorierna bakom assembler och skulle säkert med databladet och en asm referensi högsta hugg kunna skriva ihop fungerande applikationer.
Senaste veckorna har jag växlat mellan 4 olika µC av olika fabrikat, är det då meningen att jag ska sätta mig in i assemblern för varje? Istället för att koncentrera mig på att lösa problemen?
Men vist kan det vara bra att trycka in lite assembler i halsen på nybörjarna, det ger förhoppningsvis en förstålese för hur det hela funkar... och mindre "windowsprogrammerade" *1 inbyggda system för mig att reda upp...
*1 Med windowsprogrammerade system menar jag att det skiljer sig ganska radikalt i tankesätt att skriva en applikation till en vanlig PC snurrandes windows med gigabyte av minne och en liten µC. Detta verkar få förstå...
Assembler i all ära, jag har gjort mycket stora arbeten i assembler men det är mycket skrivande.
Jag "kan" ju µC från grunden och upp, jag har använd "ofattbart" med tid på Z80, CP/M-2.2 & TRS80, jag har byggt om min trogna TRS80 väldigt mycket, de-assemblerat hela ROM'en, "snyggat till" den, lagt in nya kommandon i dess BASIC och fibblat väldig mycket.
Så jag använder C, det medger att man kan göra rutiner man kan "återvinna", jag håller mig helst till ANSI-C, då finns det ingen "fallgropar" som gör att jag måste göra om en (eller fler) rutin(er) för att de förliter sig på kompilerspecifika kommandon.
Visst kan jag göra rutiner som multiplicerar olika storleker variabler med varandra osv i assembler men det är helt enkelt inte lönt.
Med C har jag tillgång till hårdvaran samtidig som jag kan göra avancerade funktioner och hålla en syntax som kan läsas utan kilometervis med kommentarer.
Jag minns med skräck ett projekt jag fick överta, det var baserat på 8052's BASIC med assembler för att ta hand om interrupt. Sedan skulle de 2 språk kommunicera och komplexiteten slog alla rekord... och det fungerade inte i närheten av vad det skulle.
Min första åtgärd var att kolla igenom BASIC-delen och sammanhålla alla PEEK & POKE adresser med vad de var i ASM-delen, jag hittade många fel med inte blev det speciellt bättre för det.
Jag meddelade då chefen att det helt enkelt inte gick att få rätsida på det på det vis, vi behövde köpa en C-kompiler! Det blev en Keil, jag benade ut vad alla delar av originalprogrammet skulle göra och skrev det som C-funktioner och när jag var klar sydde jag ihop huvudflödet.
Det fungerade avsevärd bättre än det förra system... i första försök. Alla de problem som fanns med i det gamla program försvann och vi kunde utvidga funktionaliteten utan att det strulade.
Kort efter kunde jag även minska antal komponenter på styrkortet avsevärd då jag kunde spola en extern UART eftersom det fanns 2 st UART i den krets vi använde (I80C320), med BASIC'en borta hade JAG tillgång till hela elektroniken och plötsligt var resten enkelt.
Visst, det var inte BASIC'en i sig som ställde till det enbart, det var blandningen och interruptproblemer som var en stor bov men att det var BASIC med i bilden var ingen hjälp alls.
Sedan bytte jag processor till en Fujitsu, det var av rent kostnadsmässiga orsaker, på köpet fick jag även en hårdvara som klarade av en hel del mer, mer minne samt ICSP.
Visst skiljde hårdvaran sig kraftigt mellan de 2 processorer men efter att ha flyttat ut hårdvaruinitieringen kunde jag kompilera SAMMA källkod i endera kompiler och få fungerande kod, jag kunde alltså uppdatera en funktion i min C-källkod, kompilera med båda Keil och Fujitsus', ladda in programmen i vardera µC och få samma funktioner.
Jag har nu gjort samma trick mellan Fujitsu och Renesas utan problem.
Där har man styrkan vid C.
Jag "kan" ju µC från grunden och upp, jag har använd "ofattbart" med tid på Z80, CP/M-2.2 & TRS80, jag har byggt om min trogna TRS80 väldigt mycket, de-assemblerat hela ROM'en, "snyggat till" den, lagt in nya kommandon i dess BASIC och fibblat väldig mycket.
Så jag använder C, det medger att man kan göra rutiner man kan "återvinna", jag håller mig helst till ANSI-C, då finns det ingen "fallgropar" som gör att jag måste göra om en (eller fler) rutin(er) för att de förliter sig på kompilerspecifika kommandon.
Visst kan jag göra rutiner som multiplicerar olika storleker variabler med varandra osv i assembler men det är helt enkelt inte lönt.
Med C har jag tillgång till hårdvaran samtidig som jag kan göra avancerade funktioner och hålla en syntax som kan läsas utan kilometervis med kommentarer.
Jag minns med skräck ett projekt jag fick överta, det var baserat på 8052's BASIC med assembler för att ta hand om interrupt. Sedan skulle de 2 språk kommunicera och komplexiteten slog alla rekord... och det fungerade inte i närheten av vad det skulle.
Min första åtgärd var att kolla igenom BASIC-delen och sammanhålla alla PEEK & POKE adresser med vad de var i ASM-delen, jag hittade många fel med inte blev det speciellt bättre för det.
Jag meddelade då chefen att det helt enkelt inte gick att få rätsida på det på det vis, vi behövde köpa en C-kompiler! Det blev en Keil, jag benade ut vad alla delar av originalprogrammet skulle göra och skrev det som C-funktioner och när jag var klar sydde jag ihop huvudflödet.
Det fungerade avsevärd bättre än det förra system... i första försök. Alla de problem som fanns med i det gamla program försvann och vi kunde utvidga funktionaliteten utan att det strulade.
Kort efter kunde jag även minska antal komponenter på styrkortet avsevärd då jag kunde spola en extern UART eftersom det fanns 2 st UART i den krets vi använde (I80C320), med BASIC'en borta hade JAG tillgång till hela elektroniken och plötsligt var resten enkelt.
Visst, det var inte BASIC'en i sig som ställde till det enbart, det var blandningen och interruptproblemer som var en stor bov men att det var BASIC med i bilden var ingen hjälp alls.
Sedan bytte jag processor till en Fujitsu, det var av rent kostnadsmässiga orsaker, på köpet fick jag även en hårdvara som klarade av en hel del mer, mer minne samt ICSP.
Visst skiljde hårdvaran sig kraftigt mellan de 2 processorer men efter att ha flyttat ut hårdvaruinitieringen kunde jag kompilera SAMMA källkod i endera kompiler och få fungerande kod, jag kunde alltså uppdatera en funktion i min C-källkod, kompilera med båda Keil och Fujitsus', ladda in programmen i vardera µC och få samma funktioner.
Jag har nu gjort samma trick mellan Fujitsu och Renesas utan problem.
Där har man styrkan vid C.
Ni får inte berätta att även jag programmerar i PicBASIC, i 99% så har det räckt till även om det blivig flera sidor text. Det är lite skämmigt och inte riktigt fint här på forumet, men söker man på nätet så finns det massor att lära sig om PicBASIC (google= 376 000 träffar) så man är inte ensam.
Ställer man en fråga här på forumet om programmet så är det nästan samma personer som hackar på en för att man använder PicBASIC, troligtvis för att visa sig duktiga.
Om jag vill lära mig köra bil så lär jag mig det som är Basic för bilkörning vilket oftast räcker. Vill jag bli duktigare kan man bli polis och då får man bestämma över andra som bara lärt sig det som är Basic
Ställer man en fråga här på forumet om programmet så är det nästan samma personer som hackar på en för att man använder PicBASIC, troligtvis för att visa sig duktiga.
Om jag vill lära mig köra bil så lär jag mig det som är Basic för bilkörning vilket oftast räcker. Vill jag bli duktigare kan man bli polis och då får man bestämma över andra som bara lärt sig det som är Basic
Intressant... hur mycket C har du programmerat?
Jag har ett antal år med BASIC, Assembler, Pascal, C, C++, CiCode (ganska Pascal-liknande) & olika PLC-språk (mest SioX).
Jag har alltså en "viss erfarenhet" bakom mig och det är baserat på den som jag fasthåller att BASIC är en leksak.
Kalla det polis om du vill, har du bara lekt med BASIC kan du knappast uttala dig om fördelar och nackdelar vid de olika språk eller hur?
Och ytterligare en anledning till mitt motstånd mod BASIC:
"Tänket" är en del olika om man jämför BASIC och C/Pascal. Det är svårt att lära sig att programmera och ger man sig in på BASIC befäster man ett programmeringssätt som är svårt att ta sig ur, detta betyder att "alla andra" språk är mycket mer besvärliga att komma in i.
Jag har själv varit där och det var en kamp att gå över till Pascal... men steget från Pascal till C var bara ett mindre skutt, de var så lika.
Google-träffer på "c school": drygt 71.000.000
Jag har ett antal år med BASIC, Assembler, Pascal, C, C++, CiCode (ganska Pascal-liknande) & olika PLC-språk (mest SioX).
Jag har alltså en "viss erfarenhet" bakom mig och det är baserat på den som jag fasthåller att BASIC är en leksak.
Kalla det polis om du vill, har du bara lekt med BASIC kan du knappast uttala dig om fördelar och nackdelar vid de olika språk eller hur?
Och ytterligare en anledning till mitt motstånd mod BASIC:
"Tänket" är en del olika om man jämför BASIC och C/Pascal. Det är svårt att lära sig att programmera och ger man sig in på BASIC befäster man ett programmeringssätt som är svårt att ta sig ur, detta betyder att "alla andra" språk är mycket mer besvärliga att komma in i.
Jag har själv varit där och det var en kamp att gå över till Pascal... men steget från Pascal till C var bara ett mindre skutt, de var så lika.
Google-träffer på "c school": drygt 71.000.000
Vad annat kan man göra än att instämma med Icecap? Dels har han löst problem sen många av oss låg i vaggan sen har han det faktist som jobb medans det för mig och de flesta andra här mest är en hobby.
Men han _KAN_ assembler och därför kan kontrollera varför saker och ting inte fungerar som det är tänkt för det antar jag att det gör någon gång då och då
Fast jag ser också stor skillnad på hobby och proffesionellt arbete.
Kan tex dra en parallell från mitt gamla jobb där vi skulle göra ett fastighetssystem. Vi hade ett typ av "mallsystem" som man ärvde in i varje panel/popup osv. Detta för att få ett enhetligt system och att om utseendet var fel så ändrar man bara på en plats och kompilerar om hela rasket. Samma kan man göra med funktioner.
MEN ovanstående är inget jag skulle lägga tid på om jag inte hade haft det som jobb.
Istället kör jag på att problemet när det väl kommer löser jag där och då utan att krångla till det mer än nödvändigt. Smarta kodsnuttar spar jag i en textfil i en katalog som heter "bra kod" med passande namn. Sen har man ju alla de gamla testerna som bara är att titta i så ser man hur man löste problemet då.
C är utan tvekan bra inget snack om den saken och nya PIC är ju tom avsedda för C programmering i mycket större grad. Sen är det ju mycket mer överskådligt och med arv och rena strukturfördelar klår det ju assembler när det gäller större projekt.
Därmed inte sagt att det inte skulle fungera i assembler. Kodar man rätt och använder relocatable code så ändrar man processor lika kvickt i assembler som i C. I "önskedrömmen" är det bara vilken processor man väljer i "include I verkligheten troligen lite mer
Men han _KAN_ assembler och därför kan kontrollera varför saker och ting inte fungerar som det är tänkt för det antar jag att det gör någon gång då och då
Fast jag ser också stor skillnad på hobby och proffesionellt arbete.
Kan tex dra en parallell från mitt gamla jobb där vi skulle göra ett fastighetssystem. Vi hade ett typ av "mallsystem" som man ärvde in i varje panel/popup osv. Detta för att få ett enhetligt system och att om utseendet var fel så ändrar man bara på en plats och kompilerar om hela rasket. Samma kan man göra med funktioner.
MEN ovanstående är inget jag skulle lägga tid på om jag inte hade haft det som jobb.
Istället kör jag på att problemet när det väl kommer löser jag där och då utan att krångla till det mer än nödvändigt. Smarta kodsnuttar spar jag i en textfil i en katalog som heter "bra kod" med passande namn. Sen har man ju alla de gamla testerna som bara är att titta i så ser man hur man löste problemet då.
C är utan tvekan bra inget snack om den saken och nya PIC är ju tom avsedda för C programmering i mycket större grad. Sen är det ju mycket mer överskådligt och med arv och rena strukturfördelar klår det ju assembler när det gäller större projekt.
Därmed inte sagt att det inte skulle fungera i assembler. Kodar man rätt och använder relocatable code så ändrar man processor lika kvickt i assembler som i C. I "önskedrömmen" är det bara vilken processor man väljer i "include
I verkligheten troligen lite mer 
