Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
zondag 10 april 2005 11:24:58
assembler !. en als't echt moet : PL/M op een 8051.
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.
Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand
dinsdag 12 april 2005 08:42:04
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
Fighting the World every single day. Fighting the World for the right to play. Heavy Metal in my brain. I'm fightin for Metal cause it's here to stay.
dinsdag 12 april 2005 10:24:26
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:47]
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.
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:07]
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.
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
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.
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:27]
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
maandag 18 april 2005 11:39:12
[...]
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.
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.
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:51]
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.
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.
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
donderdag 12 mei 2005 13:43:07
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 )
Hogere programmeertalen voor microcontrollers zijn voor mensen die het niet snappen. Geef mij maar assembler, zeker bij het schrijven van timing-routines.
A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" Byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off."
dinsdag 17 mei 2005 14:03:15
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.
Reacties (39)