Ce v-ati dori de la un limbaj de programare pentru PIC?

[sifor]

Da intereseaza pe cineva detalii tehnice despre PBP 2.43 ?

 

Don Mario

 

bogdanm: topic split

[bogdanm]

Am mutat aici mesajul lui Don Mario (raspunsul meu: da, pe mine ma intereseaza cate ceva), pe care il voi completa cu o rugaminte personala: ar fi interesant ca fiecare sa spuna cam cum i-ar placea sa arate un limbaj de programare pentru PIC (sau orice alt microcontroller, nu trebuie limitat la PIC) si/sau ce-i place/ce nu-i place la limbajul favorit. Ca sa nu generalizam prea mult, sa luam exemplul unui limbaj tip BASIC. Si o mare rugaminte: nu comparam limbajele, nu e nevoie sa transformam topic-ul intr-un "language war" O sa incep eu:

 

- ar fi frumos sa am posibilitatea sa scriu datele (intregi, siruri samd) unde vreau eu (lcd, seriala samd). Ceva de genul

 

print a, b, c, "test" to lcd

print a, "1", 2 to uart

 

- sa am niste periferice predefinite cu care sa pot lucra foarte usor. Exemple:

 

receive a from spi

send a to uart

 

Mai departe, va astept

[Vizitator cristianpaius]

Dupa parerea mea, cred ca pot sa afirm ca PIC BASIC PRO e cel mai potrivit pentru microcontrollere. si sincer cand aud de combinata C si PICmi se pare cam exagerat putin.. sa lasam C-ul pentru PC-uri !!!!In basic se pot face lucruri dragutze mult mai rapid si mai simplu fara sa imi storc creierul cu headere peste headere.....In vacanta asta de iarna am scris un program de yala electromagnetica pe baza de smartcard cu rtc, evidenta a intrarilor in eeprom, etc in totalitate in pbp. Desi am intampinat mici surprize de genul Fatal error OP=47.. si compilatorul implicit a inceput sa dea out of memory, fiind constrans sa merg pe MPASM, TOTUSI NU IMI SCHIMB PAREREA DESPRE PIC BASIC PRO. E grozav.... chiar si de la 1000 linii de cod incolo. NU DEGEABA "E PE BANI!" (Cineva ieri a sarit ca ars cand a auzit de PBP243 si mi-a sters o parte din mesajul postat de mine...,mai usor baieti ca nu e chiar asa... mai usor...)PS: Va salut Don Mario...Ne-am intalnit la seminarul microchip din 2 martie anul trecut si am mai discutat putin pe mail.. imi pare bine sa va reintalnesc pe acest forum..

[bogdanm]

Eu am "sarit ca ars". Intelegerea mea a fost ca vrei sa ceri PB 2.43 varianta full pe forum. Daca am gresit, imi cer scuze. Daca nu, imi mentin decizia si nu o voi lasa deloc "mai usor". Dar asta e alt subiect. Haideti sa continuam sa vorbim despre limbajele de programare.

[Cristiano]

Cred ca intrebarea e pusa un pic gresit. Nu limbajele in sine ofera suport pentru diversele periferice, ci bibliotecile care vin cu un compilator sau altul. Personal, prefer compilatoarele produse de HiTech (biblioteci + exemple cuprinzatoare, suport tehnic excelent, au versiune free pt. PIC16 + demo-uri pentru aproape toate celelalte tipuri de microcontrollere suportate, compatibilitate ANSI, flexibilitate si, nu in ultimul rand, experienta mea cu lucrul in C).cristianpaius: daca te referi la C++ si programare orientata obiect, atunci ai dreptate. Daca ai in vedere doar C, atunci cred ca te inseli.

[bogdanm]

Cred ca intrebarea e pusa un pic gresit. Nu limbajele in sine ofera suport pentru diversele periferice, ci bibliotecile care vin cu un compilator sau altul.

Fara indoiala ai dreptate, si in asta sta de fapt toata intrebarea. Daca intr-un limbaj high-level mai apropiat de masina (gen C) utilizatorul e constient de existenta librariilor de care vorbesti, in BASIC (de exemplu) acest lucru e transparent. Desi functiile sunt tot in librarii, limbajul BASIC ofera de obicei suport chiar la nivel sintactic pentru folosirea lor. "Sintactic sugar", daca vrei, dar asta poate face diferenta intre un limbaj usor de folosit si unul greoi.

cristianpaius: daca te referi la C++ si programare orientata obiect, atunci ai dreptate. Daca ai in vedere doar C, atunci cred ca te inseli.

Sunt absolut de acord cu tine, cu doua observatii:- depinde de PIC Pentru un F84, de exemplu, si mie C-ul mi se pare overkill. La versiunile ceva mai mari n-am nici o problema cu el.- chiar si acum, dupa enspe ani de experienta in C si dupa ce am programat pe o gramada de platforme, mai am nevoie de ceva timp initial pentru a-mi construi un fel de "basic project" de la care sa pornesc (sursa simpla + makefile). Un BASIC bun nu te obliga sa pierzi acest timp initial.

[Cristiano]

Pana la urma, e o chestie de preferinte. Dupa mine, adaugarea unui " #include" nu reprezinta un efort prea mare.Chiar si pentru PIC-urile "mici" prefer C-ul. Nu e mult de scris, si nici codul generat nu difera foarte mult fata de ce as scrie direct in assembler:

#include <pic.h>__CONFIG(HS_OSC & WDT & .....)void interrupt ISR() {         // .... }void main() {         // .... }

Insa, dupa parerea mea, un aspect important (mai important decat functiile "transparente" sau alte detalii) il reprezinta calitatea codului generat: corectitudine, eficienta (dimensiune) si stabilitatea compilatorului:

Desi am intampinat mici surprize de genul Fatal error OP=47.. si compilatorul implicit a inceput sa dea out of memory, fiind constrans sa merg pe MPASM, [...]. E grozav.... chiar si de la 1000 linii de cod incolo.

Asa ceva mi se pare o deficienta grava. Rezumand, cele mai importante lucruri pe care le astept de la un compilator sunt:1. corectitudine si eficienta a codului generat.2. posibilitatea de a folosi usor diferite tipuri de variabile (1 bit, 8 biti, 16 biti, 32 biti, cu si fara semn, tablouri, etc) si operatiile uzuale.3. compilatorul sa preia sarcina comutarii bank-urilor de RAM si a paginilor de memorie program (adesea generatoare de erori) - valabil pt. PIC4. suport tehnic bun, biblioteci cuprinzatoare

[bogdanm]

Pana la urma, e o chestie de preferinte. Dupa mine, adaugarea unui " #include" nu reprezinta un efort prea mare.

Ok, compara un BASIC ipotetic in care scrii asa:

s = "Test"print s to lcd

cu asta:

#include <lcd.h> // in cazul fericit in care driver-ul exista dejachar *s = "Test";void main( void ){  lcd_init();  lcd_putstr( s );}

(la asta mai adauga timpul necesar pentru a crea un Makefile daca nu folosesti un mediu integrat).

Ghici ce ar alege un incepator? Si chiar un programator "mai serios", pe care il pui pe o platforma noua si are nevoie sa invete cat mai rapid cum sa genereze cod pentru ea.

Insa, dupa parerea mea, un aspect important (mai important decat functiile "transparente" sau alte detalii) il reprezinta calitatea codului generat: corectitudine, eficienta (dimensiune) si stabilitatea compilatorului:

Oho ... te-ai ingrozi daca ai afla cam cate bug-uri sunt intr-un compilator. Crede-ma, lucrez in domeniu, si e incredibil cate mici erori are un compilator in care iti pui baza. Un compilator de C simplu (fara optimizari) poate fi considerat de incredere fara prea mari rezerve; cand apar optimizarile (absolut necesare pentru o platforma cu resurse atat de limitate ca PIC-ul) lucrurile devin extrem de complexe, iar stabilitatea compilatorului o loterie, mai mult sau mai putin. Probabil ti se pare ca exagerez. I wish.

Asa ceva mi se pare o deficienta grava.

Da, dar e problema de compilator, nu de limbaj. Nu are rost sa incepem sa discutam calitatea diverselor compilatoare aici (apropo de calitate, e evident ca un compilator de BASIC ar trebui sa fie mai usor de scris decat unul de C), hai sa ne referim doar la limbaj.

[sifor]

bogdanm ! te rog pune subiectul pe numele tau,ca tu l-ai initiat,nu eu !Don Mario

[bogdanm]

bogdanm ! te rog pune subiectul pe numele tau,ca tu l-ai initiat,nu eu !

 

Don Mario

Don Mario, a fost un topic split. O sa adaug comentariul de rigoare. Eu l-am inceput, dar tu mi-ai dat ideea

[bogdan_]

de curand au lanasat si cei de la MikroElektronika un compilator de C http://www.mikroelektronika.co.yu/engli ... pilers.htm pe laga celelalte de pascal si basic.

eu nu folosesc C. nu stiu sa programez in C desi vreau de mult sa invat.

am folosit compilatorul de Pascal. A mers foarte bine, nici o eroare pana acum(recunosc ca n-am facut prea multe programe).

compilatorul are proceduri facute pentru LCD, Manchester pt radio, CF, debouncing de buton etc....

lucreaza cu multe tipuri de variabile(inclusiv tablouri), face singur schimbu de bank si alocarea de memorie.

desigur, e varianta DEMO, functioneaza complet, dar cu limite de 2K pe asm. adica se pot programa picuri cu 2K complet.

 

s-a mai jucat careva pe compilatoarele astea?

[Cristiano]

Ok, compara un BASIC ipotetic in care scrii asa:

s = "Test"print s to lcd

cu asta:

#include <lcd.h> // in cazul fericit in care driver-ul exista dejachar *s = "Test";void main( void ){  lcd_init();  lcd_putstr( s );}

Exagerezi un pic, si in Basic ar trebui initializat LCD-ul si adaugat START ... END. Ramane in plus doar "#include" si declaratia tipului de variabila, nu e chiar asa mare lucru.

 

(la asta mai adauga timpul necesar pentru a crea un Makefile daca nu folosesti un mediu integrat).

Argument invalid, deoarece acest lucru e valabil pentru orice compilator/limbaj, nu numai pt. C. Si daca tot ai adus in discutie lucrul asta, consider ca integrarea compilatorului intr-un IDE este foarte importanta (pentru interfatarea cu uneltele de dezvoltare caracteristice platformei pt. care se scrie soft-ul: debugger-e, emulatoare, etc).

Ghici ce ar alege un incepator? Si chiar un programator "mai serios", pe care il pui pe o platforma noua si are nevoie sa invete cat mai rapid cum sa genereze cod pentru ea.

Cred ca factorii cei mai importanti sunt experienta anterioara cu un limbaj sau altul de programare, precum si existenta unui suport bun (manuale, exemple, integrarea in IDE, etc). Sintaxa e mai putin importanta.

Oho ... te-ai ingrozi daca ai afla cam cate bug-uri sunt intr-un compilator. [...] e incredibil cate mici erori are un compilator in care iti pui baza. Un compilator de C simplu (fara optimizari) poate fi considerat de incredere fara prea mari rezerve; cand apar optimizarile (absolut necesare pentru o platforma cu resurse atat de limitate ca PIC-ul) lucrurile devin extrem de complexe, iar stabilitatea compilatorului o loterie, mai mult sau mai putin. Probabil ti se pare ca exagerez. I wish.

Mda, atunci n-ar mai folosi lumea astfel de compilatoare. Bug-uri exista in aproape orice aplicatie, hard sau soft. Important e ca efortul dezvoltarii unei aplicatii functionale folosind un compilator sa fie mai mic decat efortul dezvoltarii aceleiasi aplicatii in assembler. Cat despre loterie, inseamna ca am fost foarte norocos, deoarece n-am intalnit probleme majore la nici unul din compilatoarele cu care am lucrat (HiTech C pt. PIC16, PIC18 si dsPIC, Microchip C18 pt. PIC18 - inlocuit cu HiTech ulterior -, Holtek C compiler pt. microcontrollere Holtek, Franklin IDE + C compiler pt. 8051 - Analog Devices AdUCxxx -, Keil IDE + C compiler pt. 8051 - pt. NVLSI nRF24E1 -).

Asa ceva mi se pare o deficienta grava.

Da, dar e problema de compilator, nu de limbaj. Nu are rost sa incepem sa discutam calitatea diverselor compilatoare aici [...], hai sa ne referim doar la limbaj.

Daca e sa ne referim doar la limbaj, raman punctele 2, 3 si 4 din postul meu anterior.

[Cristiano]

de curand au lanasat si cei de la MikroElektronika un compilator de C http://www.mikroelektronika.co.yu/engli ... pilers.htm pe laga celelalte de pascal si basic.[...] s-a mai jucat careva pe compilatoarele astea?

Daca a lucrat cineva cu toate cele 3 compilatoare de la MikroElektronika (presupunand ca ofera cam aceleasi facilitati, diferind doar limbajul de programare), poate ne spune si noua parerea lui despre avantajele/dezavantajele fiecarui dintre cele 3 limbaje.

[bogdanm]

Exagerezi un pic, si in Basic ar trebui initializat LCD-ul si adaugat START ... END. Ramane in plus doar "#include" si declaratia tipului de variabila, nu e chiar asa mare lucru.

In BASIC initializarea se face in general automat/mai simplu. In plus, exemplul a fost simplificat, pentru ca stiu ca lumea nu tine neaparat sa citeasca pagini intregi de cod. Daca vrei, gasesc unul in care diferenta de complexitate sa fie mai clara.

Argument invalid, deoarece acest lucru e valabil pentru orice compilator/limbaj, nu numai pt. C.

Pentru BASIC? Nu prea cred. Repet, nu discut ceea ce se intampla in spatele scenei, ci cat are utilizatorul efectiv de lucru. Un compilator bun de BASIC ar trebui sa stie sa includa automat toate librariile de care are nevoie, si poate face asta tocmai pentru ca e mai putin complex si le poate determina mai usor.

Si daca tot ai adus in discutie lucrul asta, consider ca integrarea compilatorului intr-un IDE este foarte importanta (pentru interfatarea cu uneltele de dezvoltare caracteristice platformei pt. care se scrie soft-ul: debugger-e, emulatoare, etc).

Da, pentru BASIC, din nou, asta e foarte important. Pentru C ... de cand ma stiu am preferat makefile+un editor. Nici macar VS.NET nu-mi place ca mediu integrat Dar asta e cu totul alta discutie, si in plus e o problema care tine in principal de preferinte, deci automat toata lumea are dreptate

Cred ca factorii cei mai importanti sunt experienta anterioara cu un limbaj sau altul de programare, precum si existenta unui suport bun (manuale, exemple, integrarea in IDE, etc). Sintaxa e mai putin importanta.

Just. Dar complexitatea unui limbaj e determinata in mod direct de sintaxa sa (care se leaga in mod logic de semantica, samd).

Mda, atunci n-ar mai folosi lumea astfel de compilatoare. Bug-uri exista in aproape orice aplicatie, hard sau soft. Important e ca efortul dezvoltarii unei aplicatii functionale folosind un compilator sa fie mai mic decat efortul dezvoltarii aceleiasi aplicatii in assembler.

Aparent ti-ai dat singurul raspunsul la intrebare. Lumea foloseste compilatoare pentru limbaje de nivel inalt, chiar daca au bug-uri, tocmai pentru ca timpul necesar pentru dezvoltarea in assembler ar fi mult mai mare. Ma bucur daca ai avut noroc cu compilatoarele pana acum, si iti doresc sa te tina cat mai mult norocul cu pricina.

[Cristiano]

In BASIC initializarea se face in general automat/mai simplu. In plus, exemplul a fost simplificat, pentru ca stiu ca lumea nu tine neaparat sa citeasca pagini intregi de cod.

Ai simplificat doar pt. BASIC, ceea ce ar putea duce pe unii in eroare.

Daca vrei, gasesc unul in care diferenta de complexitate sa fie mai clara.

Ok, arata-mi unul unde diferenta de complexitate este in favoarea BASIC si se datoreaza exclusiv limbajului. Eventual pe privat, ca sa nu plictisim lumea.

Un compilator bun de BASIC ar trebui sa stie sa includa automat toate librariile de care are nevoie, si poate face asta tocmai pentru ca e mai putin complex si le poate determina mai usor.

Intr-un post anterior zici sa nu ne gandim la implementarea compilatoarelor (care pot sau nu sa stie singure ce librarii sa includa), acum zici ca de fapt diferenta e facuta de compilator ... in fine, uite si un exemplu de compilator de C care are multe functii incluse (seriala, I2C, SPI, etc): http://www.ccsinfo.com/specific.shtml

 

Cat despre makefile + editor vs. IDE .... tine de preferinte, intr-adevar, dar si de necesitatea de a folosi uneltele de dezvoltare (debugger, emulator, etc). Nu vad cum as putea folosi emulatorul daca as compila in linie de comanda (sau cu makefile) codul.

Aparent ti-ai dat singurul raspunsul la intrebare [...]

Nu am pus o intrebare, ci mi-am afirmat parerea.

 

P.S.: Raman la parerea ca diferenta nu o face limbajul, ci implementarea compilatorului.

P.S.2: As fi curios sa aflam si de la altii asteptarile lor de la un limbaj/compilator pt. microcontrollere.