Je kunt ook een tussenweg kiezen. Het hoofdprogramma in c en eventueel code die snel uitgevoerd moet worden als inline assembly invoegen.
Ikzelf heb liever c. Ik kom vanuit de software kant met het spul in aanraking en heb veel meer met talen zoals Delphi, C, Java, Visual Basic, Ada e.d gewerkt. Assembly heb ik op school wel gehad op een 68hc11, maar goed. Als je genoeg geheugen op zo'n ding hebt maakt het mij niet uit. Als het erg krap wordt, dan moet je zeker overwegen het wel te doen.
Ben zelf 'gespecialiseerd' in asm, simpelweg omdat ik zo begonnen ben met PICs. Ik denk dat het verdomde goed is om asm te kennen, zo snap je (denk ik) de interne hardware van je controller beter.
Daarnaast lijkt me dat exacte timing (op klokniveau dus) gemakkelijker te realiseren is dan in C. (correct me if i'm wrong).
Op praktisch gebied is asm niet altijd even welkom. Als je bijvoorbeeld een 32bit deling moet doen, ben je in asm wel even zoet..in bijvoorbeeld C ligt zoiets een stuk simpeler.
Ik heb natuurlijk ondertussen wel libraries aangemaakt met routines die dit soort zaken regelen (in asm), maar toch, er kan altijd weer iets voorbij komen, waardoor ik mijn bestaande routines weer aan moet passen. En dat kan soms best wel eens wat tijd kosten.
Daarom heb ik bovenaan mijn to-do-lijstje nog steeds het leren van C staan. Het komt er helaas niet van, maar ik denk dat het zeker een goede stap zou zijn.
Dus ja..asm of C? Ik zou zeggen C, al kan ik het zelf niet 
.
Op 9 november 2006 12:02:09 schreef DIY:
1. Ik denk dat het verdomde goed is om asm te kennen, zo snap je (denk ik) de interne hardware van je controller beter.2. Daarnaast lijkt me dat exacte timing (op klokniveau dus) gemakkelijker te realiseren is dan in C. (correct me if i'm wrong).
1. Dat is een (volgens mij goed) argument voor het *leren* van assembler, niet voor het *gebruiken*.
2. Dat is een van de (weinige?) 'dwingende" redenen om asm te gebruiken.
Je kunt ook een tussenweg kiezen. Het hoofdprogramma in c en eventueel code die snel uitgevoerd moet worden als inline assembly invoegen.
Dat is dan weer een verzachting van punt 2: ook als je voor een deel van je code (bv IRDA zenden) echt asm nodig hebt, dan is het niet direct noodzakelijk je hele applicatie in asm te schrijven. En als je C en asm mixt heb je (vaak) de keuze om het asm deel in MPASM te schrijven, of in 'inline' asm in je C file.
nog maar eventjes inhaken: mijn projectje moet een uart hebben, en een I2C-interface, en ook nog SPI. (een beetje een grabbelton dus. De routines die nodig zijn om deze fucnties in een 16F676 te bitbangen heb ik dus al voor 90% in m'n hoofd zitten, omdat ik op andere PIC-varianten al eens een I2C, een uart en een SPI dmv. bitbangen geprogd heb. Het enige wat er nog bij moet is A/D uitlezen, en een kleine regelkring maken die via SPI een D/A aanstuurt. (heb geen zin om ook nog eens een PWM te gaan bitbangen indat ding)
Zou een van onze softwaremensen dezelfde functionaliteit in C moeten maken (op een grotere PIC) is-ie daar zeker weten langer mee bezig.
Special Member
Op 10 november 2006 17:57:16 schreef DC2PCC:
Zou een van onze softwaremensen dezelfde functionaliteit in C moeten maken (op een grotere PIC) is-ie daar zeker weten langer mee bezig.
Amateurs zeker, bij een fatsoenlijke compiler zit er een runtime library bij voor je I2C, je SPI en UART. En zullen we van de regellus een PID regeling maken? Wat denk je dat sneller is C of ASM ?
Vele jaren code geklopt, 95% was C en 5% was ASM en dan was ik nog een van de weinigen die er af en toe assembly door heen gooide (omdat ik vaak op driver level zat). Vanaf het windows-era werd alles C++ en 0% assembly.
Zoals Wouter vertelde: het break-even punt ligt bij zeer grote aantallen (afgezien van een zeer incidentele uitzondering) voordat assemby economisch rendabel wordt. Wat mij er overigens niet van weerhoud om in de hobby sfeer bijna alles in assembly te klooien (tot fp rekenwerk aan toe)
Op 10 november 2006 17:57:16 schreef DC2PCC:
Zou een van onze softwaremensen dezelfde functionaliteit in C moeten maken (op een grotere PIC) is-ie daar zeker weten langer mee bezig.
Is dat een eerlijke vergelijking? Ik denk dat als ik dat in C zou schrijven ik dat sneller zou doen dan jij in asm, aangenomen dat we het allebei in de zelfde mate 'al in ons hoofd hebben'. Ik hoef me iig niet druk te maken over pages en banks ...
Op 10 november 2006 19:06:53 schreef JoWi:
[...]Amateurs zeker, bij een fatsoenlijke compiler zit er een runtime library bij voor je I2C, je SPI en UART. En zullen we van de regellus een PID regeling maken? Wat denk je dat sneller is C of ASM ?
D'r loopt hier momenteel een projectje met een PIC24, 't had al lang klaar kunnen zijn, maar het duurt en duurt en duurt...
Vele jaren code geklopt, 95% was C en 5% was ASM en dan was ik nog een van de weinigen die er af en toe assembly door heen gooide (omdat ik vaak op driver level zat). Vanaf het windows-era werd alles C++ en 0% assembly.
op een PC geef ik je onder windhoos 100% gelijk, maar op een kleine controller kun je met C veel fout doen, als je geen idee hebt waar je mee bezig bent (variabelen als long float, omdat de getallen niet in een 'int' passen.
Zoals Wouter vertelde: het break-even punt ligt bij zeer grote aantallen (afgezien van een zeer incidentele uitzondering) voordat assemby economisch rendabel wordt. Wat mij er overigens niet van weerhoud om in de hobby sfeer bijna alles in assembly te klooien (tot fp rekenwerk aan toe)
Precies, doe ik net zo, daarom heb ik al 90% van de code bijeen, heb al RS232 gebitbanged, al I2C gebitbanged(volledig multimaster compatibel overigens) SPI gebitbanged en met de ADC gespeeld, 't is voor mij niets meer als 'copy-paste' uit bestaande programma's. Regelalgoritme als PID-regelaar hoeft niet eens, 't is een compensatie voor een amplitudegang, twee tabelletjes uitlezen en de boel is voor elkaar.
@wouter: Pages en bank zijn voor mij inmiddels geen hindernis meer, ik 'denk' helemaal in pages en banks als ik een pic programmeer, ik zet bepaalde stukken code bewust op een bepaalde page neer, of bepaalde variabelen bewust op een bepaalde registerbank.
in het begin wel even moeite mee gehad, maar inmiddels niet meer.
en wat de eerlijke vergelijking betreft, voordat ik onze C-programmeur zover heb dat hij het in dezelfde mate 'in het hoofd' heeft zijn er al 2 dagen verstreken. 't Is geen hardware-minded persoon.
Op 13 november 2006 08:36:19 schreef DC2PCC:
en wat de eerlijke vergelijking betreft, voordat ik onze C-programmeur zover heb dat hij het in dezelfde mate 'in het hoofd' heeft zijn er al 2 dagen verstreken. 't Is geen hardware-minded persoon.
Dus geen eerlijke vergelijking. als je het die C programmeur is asm laat doen kost het hem meer tijd, is dat een valide C-is-beter-dan-asm argument?
Op 13 november 2006 08:57:22 schreef Wouter van Ooijen:
Dus geen eerlijke vergelijking. als je het die C programmeur is asm laat doen kost het hem meer tijd, is dat een valide C-is-beter-dan-asm argument?
Hij mag het in C doen vwat mij betreft ! maar voordat hij doorheeft wat ik wil zijn 2dagen verstreken.
en ja, in DIT geval is het een ASM-is-beter-dan-C argument.
maar voor elk ander geval kan dat anders zijn.
Ik merk wel dat de keuse bij vele bij ASM ligt.
Maar dat is ieders eigen mening.
Ik merk dat mensen die ervaring hebben met C toch ook hier gebruik van maken en ook (soms) in C programmeren.
Het is maar net waar je mee bent opgegroeid 
Special Member
Ik hoef me iig niet druk te maken over pages en banks ...
Als je de juiste macro's download hoef je je daar in ASM ook geen zorgen om te maken. Ik programmeer PIC's ook meestal in ASM omdat ik gewoon veel tijdkritische processen heb, en ook de ruimte in kleine PIC's beperkt is...
Op 13 november 2006 09:05:45 schreef DC2PCC:
en ja, in DIT geval is het een ASM-is-beter-dan-C argument.
nee, een jij-bent-hiervoor-beter-dan-hij argument. heeft niets met c-versus-asm te maken.