(deftig) Beginnen met pics

Als je de code in Basic al niet begrijpt, kan ik me niet voorstellen dat het in een andere taal eenvoudiger zal zijn...
(Eerder moeilijker...)

Je kan eens mikroC proberen, die is gratis tot 2K code (een 16F628 kan je helemaal vol programmeren).

Met C heb je wel het gevaar dat je snel "ver van de hardware" zit te programmeren, en dus weinig efficiënt werkt, je moet altijd de datasheet in het achterhoofd houden.

Het probleem met die picbasic is is dat het een demo versie is en ik er niet genoeg mee kan programmeren...Voor de rest werkt die taal wel netjes en goed...

Ik denk dat bijna alle compilers een gelimiteerde basisversie hebben. Al dan niet in source code of hex output gelimiteerd.
Voor een 'full-blown' versie zul je niet met een gratis versie uitkomen...

Dat is heel wat anders dan wat in je startpost staat, kan het niet met elkaar rijmen...

Maar goed, gebruik de zoekfunctie even.

als je alle ruimte van de wereld en snelheid wilt: ASM! gratis compiler, gratis ontwikkelomgeving etc.

We steile leercurve, maar daarna kun je ook echt alles wat je maar kan bedenken. (en je bent van niemand afhankelijk)\

fripster

Tip: Niet doen!

Ga niet aan assembler beginnen. Je schrijft echt 10x sneller wat je wilt in een hogere taal als C of basic. (Als het puntje bij het paaltje komt en er is en stuk van je code die heftig tijdkritisch is, dan laat je de compiler de boel naar assembler vertalen, en bestudeer je dat. Als je dan denkt: "Dat kan ik beter!", dan doe je dat.)

Ik heb ook een tijdje met PICs geklooit. Proef versies. Beperkingen etc etc. Bij AVR heb je het voordeel dat de gcc compiler beschikbaar is, en dat is een Open Source compiler. Geheel vrij.

Ik kreeg van de week post van iemand die ook een argument heeft om voornamelijk in een hogere programmmeertaal te beginnen:
Hij heeft jaren in assembler geprogrammeerd maar is overgestapt op PIC Basic omdat hij (na er een tijdje niet mee bezig te zijn geweest) zijn eigen geschreven assemblerprogramma's niet meer snapte.
En alleen díe dingen in assembler te doen, die in de hogere programmeertaal slechter gaan (te traag voor een bepaalde functie bijvoorbeeld).

Je kunt assembler mixen met een hogere programmeertaal.
In PIC Basic gaat dat door de assemblercode te plaatsen tussen ASM en END ASM.

Hij heeft jaren in assembler geprogrammeerd maar is overgestapt op PIC Basic omdat hij (na er een tijdje niet mee bezig te zijn geweest) zijn eigen geschreven assemblerprogramma's niet meer snapte.

Slap argument mi, in elke programeertaal moet je commentaar bij je code zetten, desnoods bij elke regel. Ook of moet ik zeggen juist in "C" kun je leuke spagetti code schrijven.

http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest

zijn eigen geschreven assemblerprogramma's niet meer snapte.

Da's een kwestie van voldoende commentaar toevoegen natuurlijk. Ik snap mn ASM programmaatjes van 20 jaar geleden nog steeds alhoewel je jaren later wel iets hebt van , hm, dat had ik nu toch anders opgelost. Grootste nadeel van ASM vind ik dat je zelf moet waken voor je variabelen (hergebruik, overschrijven) en zaken als je stack en dergelijke dat je die niet opblaast.

Groeten, Bram

Op 28 mei 2008 21:27:50 schreef Videomodulator:
Met C heb je wel het gevaar dat je snel "ver van de hardware" zit te programmeren, en dus weinig efficiënt werkt, je moet altijd de datasheet in het achterhoofd houden.

Ik heb het idee dat je met C dat gevaar juist niet zo loopt. Eigenlijk ben je dicht op de hardware bezig, met het gebruik van registers e.d., met het gemak van fijne statements voor program-flow.
M.i. zit je met BASIC juist wat verder van de hardware. Ik wil niet zeggen dat dat per definitie slecht is overigens, voor veel toepassingen telt het gemak van 'even snel in BASIC' harder dan het dicht op de hardware zitten.

Het argument van TS dat hij als informaticus graag in C wil schrijven kan ik denk ik wel begrijpen. Ik programmeer voor m'n werk ook bijna dagelijks in C, en het is vervelend om dan een andere taal tussendoor te doen. AVR heeft als groot voordeel dat er een gratis GCC is, hoewel voor PIC ook wel het e.e.a. te 'krijgen' is.

Op 28 mei 2008 21:24:17 schreef Arco:
Als je de code in Basic al niet begrijpt, kan ik me niet voorstellen dat het in een andere taal eenvoudiger zal zijn...
(Eerder moeilijker...)

Dat is nu toch eens echt iets dat op niets slaagt hé. En de discussie is al zoveel keer meer gevoerd geweest. Programmeren is en blijft een persoonlijke keus.

Ik had voor ik wat begon wat C++ ervaring. Ik dacht ja, ik zal maar beginnen met Basic voor PICS te programmeren, ik snapte er helaas niet veel van. Verder dan de programmatjes van Frits zijn site kwam ik niet.

Ik heb het dan ook maar laten liggen en ik heb mij enkele tools van mE aangekocht voor in C te programmeren. Een Dev board en de C compiler.
En om eerlijk te zijn ging dat toch stukken beter, en alles zelf geleerd aan de hand van het mE forum, mE voorbeelden en de datasheets van de PICS.

@ Videomodulator, dat hangt allemaal af van hoe je programmeert in C, het probleem die je aankaart kan je evengoed voorhebben met Basic.

Op 28 mei 2008 21:36:38 schreef foxie:
Het probleem met die picbasic is is dat het een demo versie is en ik er niet genoeg mee kan programmeren...Voor de rest werkt die taal wel netjes en goed...

Het probleem zit hem kennelijk in de financiële drempel voor aanschaf van de commerciële versie van de compiler.
Ik heb van TS nog geen argument gezien waarom PICBasic niet zou voldoen.

Als je met PICBasic niet uit de voeten kunt, zal dat met C ook niet gaan lukken (zoals Arco al terecht opmerkt).

Overigens is er een gratis C compiler voor PIC's, maar het nadeel vind ik daarvan dat de asm een spaghetti wordt.
Het voordeel van PICBasic is dat de gegenereerde assembler code redelijk de PICBAsic statements volgt, waardoor je makkelijker kunt tweaken, tunen of andere optimalisaties doorvoeren (of soms fouten in de compiler kunt opsporen).

@Mathieuke: wat je terecht aangeeft is dat het tijd, energie (en wat pleuro's) kost om iets goed in de vingers te krijgen. Het maakt niet uit of dat C, PICBasic of welke andere taal dan ook is.
Ik schat zo in dat als je dezelfde energie (tijd, geld en moeite) in PICBasic had gestoken, je dat ook wel had kunnen leren , maar jij was in zekere zin bevooroordeeld omdat je vanuit de C++ hoek kwam.

@Mathieuke: ik moet me toch wel bij Arco aansluiten hoor. Programmeertalen zoals Pascal, C of Basic (ik heb het dus even niet over Malbolge e.d.) kun je natuurlijk best een eigen voorkeur in hebben, maar als je er één niet snapt, snap je de ander waarschijnlijk ook niet. TENZIJ (en ik denk dat dat bij jou het geval is) je je in de ene taal meer gaat verdiepen als in de andere.

kijk voor C eens naar de b knudsen data compiler
CC5X voor de 16f pics en
CC8X voor de 18f pics
voor dspic is het in aanmaak dacht ik

gratis versie is te gebruiken met een pâar limitatie maar dat valt nog best mee.

Op 29 mei 2008 11:39:18 schreef Mathieuke:
Ik had voor ik wat begon wat C++ ervaring. Ik dacht ja, ik zal maar beginnen met Basic voor PICS te programmeren, ik snapte er helaas niet veel van. Verder dan de programmatjes van Frits zijn site kwam ik niet.

Onbegrijpelijk...

Op 29 mei 2008 11:35:40 schreef Jochem_S:
AVR heeft als groot voordeel dat er een gratis GCC is, hoewel voor PIC ook wel het e.e.a. te 'krijgen' is.

Zoals twee gratis C compilers bij MPlab! HI-TECH PICC Lite C Compiler en CCS PCB C Compiler.

De argumenten van de TS vind ik nog nergens op slaan, het wel de financieele punt wel zijn, zeg het dan...

Geen probleem als je een 18F type gebruikt (en die zijn completer dan de 16F's) en Swordfish downloadt. Gratis met 2 beperkingen:

Swordfish Special Edition (SE) Limitations

The Special Edition (SE) version of Swordfish will work in exactly the same way as the full version, with the following exceptions:

* The Special Edition version will only allow you to use 256 Bytes of microcontroller RAM.

* No bank switching code is generated for SFRs that fall outside of access RAM. For almost all devices this won't be a problem, but it may be a problem for some. For example, devices with an onboard Ethernet controller. You should refer to your device datasheet to determine if any SFRs are outside of access RAM.

Op 29 mei 2008 17:57:32 schreef Henry S.:

Op 29 mei 2008 11:35:40 schreef Jochem_S:

Ehm, Henry... je legt me woorden in de mond die ik nooit gebruikt heb...
Beetje te creatief aan het quoten geweest denk ik?

Het eerste quoteblokje moet zijn:

Op 29 mei 2008 11:39:18 schreef Mathieuke:

[Bericht gewijzigd door Jochem op donderdag 29 mei 2008 18:04:55 (27%)]

Zullen we dat even wijzigen Sorry Jochem!

No prob..
Zo is't beter, nou kan ik met een gerust hart gaan eten

Hogere programmeertalen zijn vooral een kwestie van smaak.
Zo ben ik een Pascal-fanaat (delphi) en heb ik een spuughekel aan C. Basic no problem, als het maar gestructureerd Basic is (wat tegenwoordig toch meestal het geval is).
Maar mijn PICjes programmeer ik bij voorkeur in Assembler. Overigens heb ik voor een aantal redelijk standaard gevallen een soort van macro-processor gebouwd (jaja, in Delphi) die die irritante zaken als CPFxxx en BTFSx (die ik altijd vergeet) voor mij expandeert en met copy/paste in de assembler code plakt.
De uitspraak 'als je de ene taal niet snapt dan zal je de andere ook niet snappen' is niet waar, Pascal, Basic en C zijn zeer verschillend en het is ook een zaak van ervaring.
De ene taal is niet 'beter' dan de andere, het is gewoon dat de mate van beheersing van de taal bepaalt of je er mee werkt.
En, wat anderen ook zeggen, DOCUMENTEREN. & dat geldt voor elke taal, niet alleen Assembler. Daar wil ik nog aan toeveogen: betekenisvolle namen van routines en variabelen.
Dus niet i en j, maar iRij en iKolom.

Het hangt er ook maar helemaal vanaf hoeveel je van je PIC's vraagt. Als je echt het onderste uit de kan wil hebben qua performance, dan kom je met assembler waarschijnlijk verder. Als het niet zo kritisch is en je wil gewoon snel iets in elkaar flansen dan zijn hogere talen veel sneller en simpeler, en dan maakt het verder niet wezenlijk uit welke taal je kiest mijns inziens.

zijn eigen geschreven assemblerprogramma's niet meer snapte

Dat ligt dan vooral aan hemzelf en zijn programmeerstijl / documenteren ervan

Op 30 mei 2008 00:56:23 schreef hadv:
De uitspraak 'als je de ene taal niet snapt dan zal je de andere ook niet snappen' is niet waar, Pascal, Basic en C zijn zeer verschillend en het is ook een zaak van ervaring.

Jawel hoor, dat gaat voor deze talen prima op.
Als je programmeerconcepten niet snapt, is het eender welke taal je kiest. Het muntje zal nooit vallen.
Alledrie zijn procedurele talen die op zeer vergelijkbare manier werken.
Alleen PICBasic kent geen functies en heel beperkt gebruik van procedures (gosub/return).

Overigens, Delphi? Yeah!

Op 30 mei 2008 00:56:23 schreef hadv:
Zo ben ik een Pascal-fanaat (delphi) en heb ik een spuughekel aan C.

Delphi is cool. C is vaak wat krachtiger en leent zich beter voor uC's e.d. Waar ik Delphi altijd voor het betere in-elkaar-flans werk gebruikte (kleine windows-appjes enzo) gebruik ik nu C#. Scheelt mij het ongemak van verschillende syntaxes door elkaar.

De uitspraak 'als je de ene taal niet snapt dan zal je de andere ook niet snappen' is niet waar, Pascal, Basic en C zijn zeer verschillend en het is ook een zaak van ervaring.

Zolang je niet hele taal-specifieke constructies met pointers of overloading ofzo toe gaat passen is er niks aan het handje en kun jij gewoon C begrijpen als je Delphi begrijpt. Dat je een voorkeur voor een andere taal hebt is dus een ander verhaal.

Op 29 mei 2008 17:57:32 schreef Henry S.:
Onbegrijpelijk...

Voor u is dat misschien onbegrijpelijk maar ik vind dat er in basic geen structuur zit terwijl ik mijn C++ achtergrond wel de structuur in C terug vond.