PIC Programmeren ASM of C

Behalve de code fetishisten zit er soms nog een voordeel aan het direkt in assembler te doen, je kunt het kompacter en sneller laten lopen, elke hogere programeertaal voegt een gedeelte overhead toe.

En of C makkelijker te lezen is: ook ik heb lijnen C code geschreven die ik na een maand niet meer wist hoe ze in elkaar zaten en waarom ze zo werkten. Een programma van minder dan 100 regels, werkte perfect, todat ik een half jaar later een kleine uitbreiding nodig had. Kon van 0 beginnen. (Les: Zet genoeg kommentaar in je code, zodat je later nog weet waarom je iets zo gedaan hebt.)

meestal gaat hem om de voorkeur van de programmer(dus de persoon) ik schrijf bijvoorbeeld graag in Basic.

het feit blijft dat asm sneller is dan een hogere taal.
elk programma waar je niet genoeg commentaar bij schrijft zul je na verloop van tijd niet je programma niet meer begrijpen.

Als je C goed schrijft, is het redelijk self-documenting.
Groot nadeel is dat je vaak niet weet wat je compiler er van bakt. Dus wat performance aangaat vaak niet het handigste. En ach... hoe spannend is assembly nou eigenlijk?

Ja ok dat klopt! de commentarisatie van je code is
zeker enorm belangrijk.. (geregeld achtergekomen)
Maar MikroC kan zelf een ASM aanmaken van mijn..
is het dan makkelijker / sneller om van de ASM een hex te maken? Of maakt dat geen verschil?
(gekke vraag misschien?)

Waarom ASM?

Mijn eerste programmeerervaring dateert van 1978.
Dat was op een discrete processor (3 kaarten ter grootte van anderhalf A4) + 32K ferrietkerngeheugenkaart + 24x40 karakter (mono)schermcontroller.
Als I/O controller was er een synchrone controller, een asynchrone RS232 en een floppy + tape controller.
Massageheugen was een 8" single side/hard sectored 160KB floppy.
De 8-bits processor draaide aan 12MHz en kende 35 instructies.
Er was geen andere programmeeromgeving voor dan een simpele assembler-editor.
Hiermee heb ik dus beroepsmatig leren ontwikkelen in ASM.

Vervolgens 8080 en 8085, weeral in ASM.
Nadien eerste contact (thuis) met Basic interpreter: Sinclair ZX-80/ZX-81.
Draaide zó traag dat ik Z80 ASM-code in een REM op lijn0 plaatste om wat prestatie te halen.

Ook nog Commodore64/Amiga500 maar daar heb ik nooit veel op geprogrammeerd.

Sinds 2001: PIC microcontrollers, puur ASM.

Moraal van dit verhaal:
Ik heb het extreem moeilijk om mij los te maken van de hardware, hogere programmeertalen zijn zo abstract voor mij dat ik er niet veel van begrijp (ik heb nochtans C geprobeerd!), dus het zal ASM blijven...

CD

het omzetten van asm naar hex kan met microchip's MPLAB net zoals het schrijven van de ASM code

maar daar staat wel tegen over dat je moet verdiepen in ASM
voor de 16F serie zijn dat maar 35 commando's dat is niet veel maar ik zie het niet als een voordeel. ik vind een taal zoals Basic wat doorzichtiger dan ASM(in zovere dat ik sneller zie wat er gebeurt in Basic dan in ASM). ik heb verder geen ervaring met C maar heb zo en zo al een hekel aan alle accolades en dergelijke waar je rekening mee moet houden.

@timmie
weet jij dan een mooie link met 'alle' gangbare ASM commandos?
opzich wel fijn als ik van beide iets weet..
Ga ik voor de lol even een progje maken in ASM om te testen!

als het goed staat er een lijst op www.microchip.com
en anders in de datasheet staan naar mijn weten ook alle commando's

tevens staat er op de site en in MPLAB(gratis) een tutorial

gevonde!
Dank u!

Mijn persoonlijke voorkeur gaat uit naar ASM, omdat je wat dichter bij de hardware staat (een vrij persoonlijk argument natuurlijk). Maar ik programmeer ook in C, ik heb wel eens projecten met veel invoer/uitvoer, extern eprom, rs232 aansluiting, toetsenbord eraan. En dan wordt het programmeeren in ASM heel complex, in C kan je dan een stuk abstracter programmeren. (je levert dan wel ietsjes in aan snelheid maar dat moet dan maar)

Op 8 november 2006 11:05:57 schreef LuckyBasterd:
@timmie
weet jij dan een mooie link met 'alle' gangbare ASM commandos?
opzich wel fijn als ik van beide iets weet..
Ga ik voor de lol even een progje maken in ASM om te testen!

Download de datasheet van de PIC van je keuze, alle ASM instructies worden er in beschreven...

CD

zelf programmeer ik in ASM en C, al heeft ASM nog steeds mijn voorkeur.
C is wel lekker makkelijk met bepaalde dingen, maar toch vind ik ASM voor mij veel meer voordelen hebben.
rekenfuncties in ASM zijn net wat ingewikkelder maar als je dat eenmaal werkend heb snap je alles.

[Bericht gewijzigd door NICKB op woensdag 8 november 2006 21:39:06 ]

Op 8 november 2006 09:53:10 schreef LuckyBasterd:
Waarom programmeren de meeste in de 'standaard' ASM taal
en niet in de C taal?

Weet je zeker dat dat zo is? In mijn assembler vakken verel ik altijd dat je als programmeur het beste voor de 'hoogste mogelijke' taal kunt kiezen, dus alleen voor assembler als daar een dwingende reden voor is.

Op 8 november 2006 21:52:54 schreef Wouter van Ooijen:
[...]

Weet je zeker dat dat zo is? In mijn assembler vakken vertel ik altijd dat je als programmeur het beste voor de 'hoogste mogelijke' taal kunt kiezen, dus alleen voor assembler als daar een dwingende reden voor is.

...en daar sluit ik mij geheel bij aan.

slechte leraar ;P

Ik zou eerder zeggen dat je kijkt naar je target voor de taal.

Alhoewel er voor uC prima C compilers zijn, doe ik die dingen toch het liefste in assembly. Terwijl er voor x86 prima assemblers zijn, maar assembly daar doorgaans niet zo heel zinnig meer is...

Op 8 november 2006 22:14:34 schreef Marco69:
Alhoewel er voor uC prima C compilers zijn, doe ik die dingen toch het liefste in assembly. Terwijl er voor x86 prima assemblers zijn, maar assembly daar doorgaans niet zo heel zinnig meer is...

En waarom? Ik wil niet zeggen dat je nooit assembly moet gebruiken. In een hobby situatie ben je natuurlijk helemaal vrij om te kiezen. In een professionele situatie kijk je doorgaans naar de totale kosten. Je weegt gewoon de meerprijs van de grotere/snellere uC die je (misschien) nodig hebt bij programmeren in C (of iets anders, misschine Java of Haskell) af tegen de extra ontwikkelijd (=geld) die je nodig hebt bij programmeren in assembler. Voeg evt extra kosten toe voor omscholing of tools, en neem nog hergebruik van oude en naar nieuwe projecten mee. Gewoon een rationele, kwantitatieve afweging.

Je kan het ook zo zggen: voor een gegeven product is er aantal te produceren eenheden N waarboven assembler bestlist de betere keuze is, en een M waar beneden een hogere taal beslist beter is. De botte stelling dat een van de twee altijd beter is is dus onzin, of ten minste aan verschuiving onderhevig doordat chips goedkoper worden en mensen duurder.

Op 8 november 2006 22:04:59 schreef NICKB:
slechte leraar ;P

Strikt genomen is dat onzin, want ik beslis niet over het curriculum, ik geef alleen een paar vakken. Maar ondertussen heb ik natuurlijk wel enige invloed, en ik ben het wel eens met de keuzes die gemaakt zijn: nadruk ligt op C en wat assembler bij electrotechniek, op Java en C++ (en wat C en assembler) bij technische informatica (wat bij ons vooral PC werk is, minder uC).

Op 8 november 2006 23:21:47 schreef Wouter van Ooijen:
[...]

En waarom? Ik wil niet zeggen dat je nooit assembly moet gebruiken. In een hobby situatie ben je natuurlijk helemaal vrij om te kiezen. In een professionele situatie kijk je doorgaans naar de totale kosten. Je weegt gewoon de meerprijs van de grotere/snellere uC die je (misschien) nodig hebt bij programmeren in C (of iets anders, misschine Java of Haskell) af tegen de extra ontwikkelijd (=geld) die je nodig hebt bij programmeren in assembler. Voeg evt extra kosten toe voor omscholing of tools, en neem nog hergebruik van oude en naar nieuwe projecten mee. Gewoon een rationele, kwantitatieve afweging. [...]

Vandaar dus vaak assembly. Dat is veel beter evalueerbaar dan C, omdat je dan ook de compiler mee moet gaan nemen. Die paar extra uurtjes programmeren wegen ruimschoots op tegen het compleet evalueren van een compiler. En eh... als het wat complexer wordt: in C schrijven, de assembly die daar uit komt (ndien niet al te spooky) op de hand leesbaar maken. Ook klaar.

Het is een ander geval als je wat voor een kantoorautomatisering of zo maakt. Dat mag zo nu en dan omvallen (volgens M$...).

En dan zwijgen we nog maar over de voodoo die C++ compilers uithalen. Dat ga je niet eens proberen te evalueren.

Op 9 november 2006 06:54:32 schreef Marco69:
[...]Vandaar dus vaak assembly. Dat is veel beter evalueerbaar dan C, omdat je dan ook de compiler mee moet gaan nemen. Die paar extra uurtjes programmeren wegen ruimschoots op tegen het compleet evalueren van een compiler.

Die afweging kans best correct zijn voor een klein hobby projectje, maar voor een wat groter professioneel project valt het toch snel de andere kant op. Even wat aannames: 4k asm code, productiviteit 10 regels/uur, tarief E 100/uur, asm = 1 regel/instructie, C = 4 regels / instructie, C efficientie = 75%, 4k chip kost E 2, 8k chip kost E 3, productie = 10.000 units.

kosten bij 10k units: asm: 10.000 * E 2 + ( 4k / 10 ) * 100 = 20k + 40k = 60k. kosten bij C: 10.000 * E 3 + ( 4k / 4 * 10 * 0.75 ) * 100 = 30k + 13k = 53k.

Je kan best de aannames aanvechten, maar in een bedrijf zal je dan met andere aannames moeten komen, en aanvoern waar die dan op gebaseerd zijn.

Ok... begin het door te krijgen.
Als je een echte programmeur bent of je zit in een bedrijf
dan snap ik dat je kiest voor de beste efficientie
Ik merk ook dat het puur persoonlijk is wat je kiest!
En wat je wilt natuurlijk.. Snelheid, overzichtelijkheid.
En het is wat je gewend bent of wat ze je met de paplepel hebben in gegoten.
Het is dus persoonsgebonden wat je kiest en wordt het zakelijk dan is het overwegen en berekenen waard wat je wilt en hoe je het wilt!

De keuze voor C of assembler kan ook nog een heel andere grondslag hebben, nl. de code-leesbaarheid. Schrijf ik iets in assembler, dan is het voor een 'buitenstaander' vaak niet leesbaar (of die moet toevallig het assemblerdialect van de gebruikte processor kennen)
Schrijf ik iets in C, dan kan elke boerenl*l die wat van C weet begrijpen waar ik mee bezig ben.

Het nadeel van C vind ik dat je moet 'boekhouden', je moet exact bijhouden waar je accolades geopend en gesloten hebt, omdat je anders foutmeldingen krijgt die 'verschoven' zijn. (de krompiler meldt een syntaxfout op regel X, omdat je op regel Y een '}' of '{' vergeten bent.)

Ook die eeuwige puntkomma stoort me.

Maar ja, ik ben dan ook een spaghettiprogrammeur (GW-basic 3.22 rules) en assembler-freak (68HC11, 8086, PIC)

en heb me bij mijn jobkeuze bewust voor een job gekozen waar de hoeveelheid programmeerwerk minimaal is.
(en als ik dan al iets moet programmeren, dan moet men maar slikken dat ik niet in C werk.)

Over de efficientie van het programmeerwerk laat ik me niet uit, ik heb binnenkort een projectje met een pic16F676 d'r in, en heb de assembly al 90% in m'n hoofd zitten, dat rolt er dan wel uit als de print voor m'n neus ligt. Voor C zou ik minstens 3x zo lang nodig hebben omdat ik daar niet 'vaardig' in ben (moet steeds bepaalde dingen nazoeken in K&R of een ander handboek)
Zou een van onze software-ontwikkelaars hier code moeten schrijven, moet ik hem eerst 2 dagen uitleggen wat ik nou exact wil, is-ie vervolgens 2 weken bezig code te kloppen, en zijn wij samen vervolgens nog 3 dagen bezig de code te debuggen en de schakeling in gebruik te nemen. In assembly kan ik het klusje waarschijnlijk zelf in 2-3 dagen klaren.

Moet ik erbij vermelden dat dit geen serieprodukt wordt, maar een meethulp, die misschien 5x gemaakt wordt.

Op 9 november 2006 09:01:39 schreef LuckyBasterd:
Ok... begin het door te krijgen.

Natuurlijk: als persoonlijke motieven de doorslag geven is alles mogelijk, als je voor het geld werkt is (meestal) het een zakelijke berekening (met alle onzekerheden in de uitgangspunten!) het belangrijkste. Maar die berekening kan ook over meerdere projecten gaan, omscholing enzo meenemen, en dan kan de keuze toch op iets anders terecht komen dan wat voor dat ene project de voorkeur zou hebben. Bedrijfspolitiek. Soms legt de klant iets op: je *zal* in asm, C, C++, Java, Ada, etc programmeren.

Op 9 november 2006 09:35:27 schreef DC2PCC:
ik heb binnenkort een projectje met een pic16F676 d'r in, en heb de assembly al 90% in m'n hoofd zitten

Jij maakt ook een 'zakelijke' keuze, alleen weegt bij jouw het aspect 'benodigde omscholing' nogal zwaar in het voordeel van asm.