Assembly of een hogere programmeertaal voor microcontrollers?

Gepost door Jeroen Boere op woensdag 6 april 2005 19:45
Optie Percentage Aantal
Assembly 44.3 % (548)
Hogere programmeertaal 55.7 % (688)
Totaal 1236 stemmen
Gepost door free_electron op zondag 10 april 2005 11:24
assembler !. en als't echt moet : PL/M op een 8051.
Gepost door Jeroen Boere op maandag 11 april 2005 22:07
Assembler. houd de source optimaal en je hebt meer "contact" met alle registers ipv standaard kant en klare routines te gebruiken.
je hebt sneller door hoe zo'n ding werkt en dient te denken.
Gepost door Thomas op maandag 11 april 2005 22:30
Jal. Ik ben te lui om assembler te leren / te gebruiken.
Gepost door Wouter Sijm op maandag 11 april 2005 22:43
ASM! Over het algemeen veel sneller, en veel efficiënter qua programma geheugen, mcu's zijn gewoon gemaakt voor asm ;)
Gepost door Xenobinol op dinsdag 12 april 2005 08:42
Voor Real time applicaties zou ik kiezen voor assembler.
Een PIC16 zou ik gewoon altijd in assembler doen, want die is zo eenvoudig.
C of een andere hogere taal heeft natuurlijk ook zijn voordelen (snel te coderen, leesbaar en onderhoudsvriendelijk, vind ik).
Een collega van mij die zowel DSP's als MCU programmeert gebruikt ook zowel asm als C, zelfs door elkaar als het moet :-P
Gepost door tEmPeSt op dinsdag 12 april 2005 10:24
ASM boven een hogere programmeertaal?
Met beide voeten op de grond blijven zou ik zeggen jongens.
Asm sneller en efficienter >>>>> de gemiddelde hobbyist zal hier nauwelijks wat van merken, tenzij het hier op CO vol zit van de specialisten, en als ik heel eerlijk mag zijn denk ik van niet. Als je er bepaalde posts op na leest, en men begint in detail vragen te stellen krijgt men nog rap antwoorden als RTFM en andere nodeloze reacties...(niet slecht bedoeld)
Dit wil niet zeggen dat ik asm afbreek.
Veel succes voor degene die het wenst aan te leren.........

[Reactie gewijzigd op dinsdag 12 april 2005 10:25]

Gepost door RES op dinsdag 12 april 2005 10:55
Assembleertaal, machinetaal, ASM.
Een minimum aan overhead, een maximaal rendement.
Gepost door Koen Van Vlaenderen op dinsdag 12 april 2005 12:03
Als je hogere wiskunde nodig hebt (goniometrische functies bijvoorbeeld) mag je blij zijn dat je dan even niet in assembler bezig bent ;)
Gepost door nerdo op dinsdag 12 april 2005 14:19
FORTH lekker laag :p
Gepost door Berry op dinsdag 12 april 2005 14:58
C! Veel duidelijker, makkelijker een foutje opsporen, later makkelijker uit te breiden. Wie van jullie merkt dat snelheidsverschil nou?!
Gepost door Lucky Luke op dinsdag 12 april 2005 14:59
begin dr net mee, assembler staat tenminste in die toturital hier (goed werk trouwens :D )
Gepost door robint91 op dinsdag 12 april 2005 19:11
Bascom voor avr. noppes registers!!!!!
Gepost door Marcel op dinsdag 12 april 2005 19:22
C Sneller te coden, overzichtelijk en makkelijk te onderhouden. Voor standaard functies zijn standaard libraries zodat je niet steeds het wiel opnieuw hoeft uit te vinden.

Bij een AVR geeft C ook nauwelijks overhead in vergelijking met assembler.
Gepost door Jeroen op dinsdag 12 april 2005 20:19
Kleine opmerking: de naam van de taal is assembly, het programma dat er machinecode van maakt heet een assembler. Ik heb de poll even aangepast ;).
Gepost door RES op dinsdag 12 april 2005 20:54
Kleine opmerking: de naam van de taal is assembly, het programma dat er machinecode van maakt heet een assembler. Ik heb de poll even aangepast ;).

Assembleertaal dus.
Gepost door ocmer op dinsdag 12 april 2005 20:45
Ben niet echt met uc's bezig, dus als ik het al zou doen zal ik het wel met assembler doen.
Gepost door RES op dinsdag 12 april 2005 20:50
Wat ook wel voorkomt is een project geprogrammeerd in een hogere taal die net de geheugenlimiet overschreidt (bijv. 2k1 en maar 2k flash beschikbaar) van een al bestaande print of systeem (of dat er een bepaalde microcontroller moet worden toegepast vanwege kostendekking), dan kan men alleen nog terugvallen op de moedertaal (ASM)

[Reactie gewijzigd op dinsdag 12 april 2005 20:51]

Gepost door zweetvoetje op dinsdag 12 april 2005 21:41
PIC's AVR's, en de rest: op de brandstapel ermee.
Analoog: Dat is voor mensen die wel snappen wat electronica is
Gepost door Berry op woensdag 13 april 2005 15:52
PIC's AVR's, en de rest: op de brandstapel ermee.
Analoog: Dat is voor mensen die wel snappen wat electronica is

hmm, niet altijd. Voor sommige toepassingen is een uC veel praktiser, of de enigste mogelijkheid. Soms is een oplossing met een uC ingewikkelder dan gewoon met een ic, maar je hebt wel meer eigen keuzemogelijkheid.
Gepost door nerdo op donderdag 14 april 2005 21:08
PIC's AVR's, en de rest: op de brandstapel ermee.
Analoog: Dat is voor mensen die wel snappen wat electronica is

Geen slecht woord over AVR!
Gepost door elmowww op dinsdag 12 april 2005 23:49
Doe mij maar hogere talen ;)
Ik ga geen user menus in assembler proggen voor een apparaat dat toch hooguit 30x gebouwd wordt. Ik heb uitgerekend dat een basic stamp nog goedkoper is qua uren :P
Gepost door Wouter van Ooijen op woensdag 13 april 2005 12:49
Als het dan toch in assembler moet schrijf ik wel een compiler.
Gepost door Jeroen Boere op woensdag 13 april 2005 20:35
Als het dan toch in assembler moet schrijf ik wel een compiler.
okee, dan add ik de volgende vergelijkbare poll een nieuwe optie:
C. Ik bak m'n eigen compiler wel :D
Gepost door Martijn Berntsen op donderdag 14 april 2005 21:56
bascom is leuk en snel, maar toch niet altijd optimale ondersteuning (bijv attiny26)
dan is assembler makkelijkste mogelijkheid, het dicht bij de hardware zitten trekt mij wel, makkelijk ivm debug.
c moet ik nog es proberen, zijn veel mensen wel over te spreken.
Gepost door Simpy op vrijdag 15 april 2005 19:49
Assembler voor de 8052
C voor de PIC's
Gepost door Andy op zaterdag 16 april 2005 13:33
C voor 8051 en assembler als het niet anders kan.
C en assembler voor AVR
Gepost door sille op zaterdag 16 april 2005 15:02
ASM :s goed voor de kleinere projecten. Tot je een prog van 40k moet schrijven :s geef mij maar C dan !!!
Gepost door RES op zaterdag 16 april 2005 19:15
ASM :s goed voor de kleinere projecten. Tot je een prog van 40k moet schrijven :s geef mij maar C dan !!!

Das dus het mooie van ASM, het blijft een minimum en doet het maximum. :)
Nadeel is dat het schrijven langer in beslag neemt als C bij complexe programma's.
Voor een bedrijf is C handiger, de klanten hoeven niet weken te wachten. :)
Progje voor de Space Shuttle is puur ASM las ik eens, zo'n 2 miljoen regels code. :) (mag dan ook niet fout gaan)

[Reactie gewijzigd op zaterdag 16 april 2005 19:17]

Gepost door free_electron op maandag 18 april 2005 11:39
[...]

Progje voor de Space Shuttle is puur ASM las ik eens, zo'n 2 miljoen regels code. :)


progje voor spaceshuttle is niet echt in assembler geschreven. Er wordt gebruik gemaakt van een interpreter en de programmeertal HAL/S (High-Order assembly Language for SpaceShuttle).
HAL is trouwens ook gebruikt voor GPS satellieten , het ISS ( spacestation) en nog een aantal andere ruimte projecten.
Die is geporteerd naar 3 verschillende processoren. De shuttle heeft ene majority vote tussen 3 computers. bij faling van de vote wordt eerst een herberekening gedaan. bij opnieuw falen wordt een sensor kruising gedaan (iedere sensor is 3 keer aanwezig. elke cpu heeft zijn eigen sensoren) . als de
vote opnieuw faalt was een van de computers stuk of software corrupt. dan wordt een cpu swap gedaan ( er zijn 2 reserves ). indien de vote failure verkruipt hebben we te maken met een defecte sensor.

wanneer 2 cpu's (van de 5 : 3 actieve + 2 spares )uitvallen volgt een mission abort ,wordt het re-entry programma automatisch gestart en komt de shuttle naar dee eerst beschikbare landingsplaats.

de reden voor een interpreter ( HAL/S gebruikt zelfs nog regelnummers ! )
is dat indien murphy catastrofaal toeslaat men desnoods via VHF radio kan dicteren wat er moet ingetikt worden. Er wordt ook nog gebruik gemaakt van ferrietcore geheugen voor de RAM van die cpu's. Da's het enige wat niet kan aangetast worden door alfa deeltjes.
het programma kan ook gestopt ( pause) worden zonder dat variabelen verloren gaan , aangepast worden , en verder gerund worden vanwaar het al gekomen was .

Nog een paar leuke anecdotes over de shuttle.
als de moteren gestart worden dan zie je de 3 hoofdstraalpijpen een 'dansje' doen. Dit zijn geen vibraties maar een gestuurde beweging ( door hydraulische motoren ). De reden is om de geluiddruk naar beneden te halen. Anders knallen alle ruiten in een straal van 30 kilometer . De drie stuwstralen worden zo gericht dat er slechts 1 schokgolf verticaal naar beneden gaat. en niet rondgestrooid.

die grote witte wolk die ontstaat tijdens de start komt niet van de shuttle zelf zoals veel mensen denken. er staat een grote watertoren ( ben vergeten hoeveel miljard liter er in zit ) op het moment dat de moteren naar vol vermogen gaan en de SRB's gestart worden ( de 2 vaste brandstof raketten langs de shuttle ) dumpen ze die watertoren. Binnen de 6 seconden issie leeg. kwestie van het lanceerplatform niet te laten smelten / barsten. door de dump leidingen kan je met 2 vrachtwagens boven elkaar rijden .

Toen ik in de US werkte was er een collega die van NASA kwam en daar meegewerkt heeft aan de motorsturing van de shuttle. vandaar. Die had daar heel coole foto's van.
Gepost door The Force op woensdag 20 april 2005 19:35
[...] Zeer uitgebreid en interessant verhaal [...]

Sodeju man!! Is er iets in de electronica wereld waar jij GEEN verstand / kennis van hebt?!
Gepost door Fox2 op donderdag 21 april 2005 19:18
Assembler!
Ik heb met C/C++ heel slechte ervaringen (o.a. op een 16-bits mixed-signal DSP van Analog Devices). Een paar voorbeelden:

* De C-runtime environment gaan compleet over de rooie wanneer je de stackpointer aanpast (we moeten toch context-switchen...). Met een boel truukjes werkt het uiteindelijk wel. Maar na een update van de ontwikkelsoftware crasht de compiler met een 'internal compiler error'(!). Na veel puzzelen blijkt dat je nou helemaal niet meer aan die stackpointer mag zitten... Dan maar weer downgraden.

* Een array van 32 bools neemt in C 64 byte aan RAM in!!! Al assemblerend passen die natuurlijk gewoon in 4 bytes...

* De interrupt latency is gigantisch (zo'n 10 us op een 160 MHz processorcore), omdat daar zo nodig een 'C runtime interrupt dispatcher' tussen moet zitten. In assembler zit je na minder dan 10 kloktikken al in je interrupt service routine.

Kortom: tenzij je bakken vol geheugen hebt en niets in hard-real-time hoeft te doen, geef mij maar assembler.
Gepost door Aaargh! op donderdag 21 april 2005 21:40
Assembler!
Ik heb met C/C++ heel slechte ervaringen
(...)
* Een array van 32 bools neemt in C 64 byte aan RAM in!!! Al assemblerend passen die natuurlijk gewoon in 4 bytes...

Het kan natuurlijk ook gewoon zo zijn dat je C skills niet zo geweldig zijn.

Ten eerste: C ken geen bool, die moet je zelf definieren, als je er dan 16 bits voor reserveert, tja... Iemand die wel C kan krijgt ook gewoon 32 bools in 32 bits gefrot.

Wat betreft die runtime, daar ben je natuurlijk zelf bij, jij kiest een bepaalde runtime, misschien had je een handigere keuze kunnen maken, mijn interrupt routines op een 16 Mhz atmel uCtje doen het in C in heel wat minder uSecs/kloktikken dan jouw 160 Mhz DSP...

[Reactie gewijzigd op donderdag 21 april 2005 21:42]

Gepost door DAC op vrijdag 22 april 2005 15:50
Omdat niet iedereen met dezelfde elektronica werkt en iemand die al 30 jaar met assembly en de 8052 werkt misschien moeilijk te overtuigen is is daar niet een echt antwoord op maar volgens mij met microcontrollers van microchip werken sommige dingen beter in assembly en daarom is het wel handig om het in ieder geval te kennen en dan inline assembly te gebruiken en voor de rest gebruik ik toch liever een goede ‘C’ compiler omdat het sneller en overzichtelijker werkt.
Voor veel bedrijven is het vaak belangrijker om iets snel af te hebben dus word de beslissing vaak gemaakt door mensen die zelf geen verstand hebben van elektronica.
Gepost door FrostByte op maandag 25 april 2005 14:27
Tja de Poll had iets specifieker moeten zijn,

Ik klop C en asm voor de Pic´s, beide zijn goed.
Tijdspecifieke dingen gaan perfect in asm zoals bv. bitbang rs232.
Menu structuurtjes met keyafhandeling perfect in C.

En C is nou ook niet zo´n ´hoge´ programeer taal.
Moet zeggen dat ik niet zo heb op die Basic achtige oplossingen.
Gepost door ism op dinsdag 3 mei 2005 20:17
Ik heb geen tijd om assembler te leren
Gepost door free_electron op donderdag 12 mei 2005 13:43
het grote probleem van ALLE hoger programeertalen is hun runtime library. Je hebt veelal geen idee hoe het in elkaar steekt , noch hoe de compiler er mee aan de slag gaat. om dan assembler te mixen met de hogere taal is een nachtmerrie. compiler fabrikanten geven veelal de source van de runtime library niet prijs.

er zijn ook veel slechte compilers op de markt. die dingen mappen een vrituele instructieset ( die zit in de runtime library ) op de set van de processor. de code wordt dan vertaald naar calls in de runtime library. een echte compiler generreert machine code zonder of met een heel minimale runtiome library ( mathematics en een paar memeory managing functies). die dingen zijn echter heel duur. ik heb ooit code gezien die door 2 verschillende compilers getrokken was. 200k assembler tegen 400k output. de 400k was snelst. geen runtime lib , geen overbodige calls. de 200k was een runtime lib van 80k met 120k calls en subroutines. de 200k code had ook 100k ram nodig voor system management, stack, argument passing en weet ik veel . de 400k code deed het met minder dan 1 page ( 32k )

tis wikken en wegen
Gepost door JohnR op vrijdag 13 mei 2005 23:30
Hogere programmeertalen voor microcontrollers zijn voor mensen die het niet snappen. Geef mij maar assembler, zeker bij het schrijven van timing-routines.
Gepost door CARENTAN op zaterdag 14 mei 2005 12:59
assembler.

Maar wanneer staat er eigelik een ander topic op want 'k vind het leuk om er op te reageren.!

Groeten

Koen
Gepost door Squant op dinsdag 17 mei 2005 14:03
Over het algemeen in C, is gemakkelijk qua uren gezien.

Een snelle lus, ISR, bibliotheek routine die veel tijd eist doe ik meestal in assembleertaal.

Als je ingelogd bent kun je een reactie plaatsen.