Falls man auf einen Winzling wie AT90S1200 Sprachen wie C loslassen will, muss man natürlcih bedenken, daß die Einschränkungen der Hardware immer auch adäquate Problemlösungen auf Hochsprachen-Ebene nach sich ziehen müssen. Handarbeit ist da auf jeden Fall notwendig. Ob es ein Gewinn ist, C anstatt Assembler zu nehmen, kann nur die Praxis zeigen. Dabei ist auch von Bedeutung, welchen Assembler man einsetzt!
Zitat von
rungo
Es ist darum ziemlich wichtig, daß möglichst viele Elektroniker Assembler lernen!
...oder eine auf µC inzwischen wohl dominierende Sprache C.
Gleichzeitig ist bei Software-Entwicklern und Informatikern zu beobachten, daß diese überhaupt keine Vorstellung mehr davon haben, wie ein µC arbeitet oder was bei dessen Programmierung für Besonderheiten zu beachten sind. An den Hochschulen wird vielleicht Java gelehrt, aber einen C-Programm für µC zu schreiben schaffen die gar nicht mehr, ohne die Resourcen zu vergeuden oder daß das Ding komplett instabil wird -- wenn überhaupt was läuft.
Oftmals kommt der Code gar nicht mehr aus "erster Hand" von Programmierern, sondern wird von irgendwelchen Codegeneratoren ausgespuckt. Was in einem harmlosen Falle dann etwa so aussieht:
Code:
if( (B_norkat) || (((dvksAusBtskpp3 & ((uint8_t)1u << 1)) != (uint8_t)0u) && !((kvdsLkbtsKoop3 & ((uint8_t)1u << 3)) != (uint8_t)0u)) ||(((kvdsStatBtskpp3 & ((uint8_t)1u << 1)) != (uint8_t)0u) && ((((kvdsscAusBtskpp1 & ((uint8_t)1u << 4)) != (uint8_t)0u) && (B_erkat)) || !((kvdsscAusBtskpp1 & ((uint8_t)1u << 4)) != (uint8_t)0u))
))
{
((((kvdsStatBtskpp3 & ((uint8_t)1u << 2)) != (uint8_t)0u) || (B_nofrao)) ? ((KVDSlkbts |= (uint8_t)1u << 2)) : ((KVDSlkbts &= (uint8_t)(((uint8_t) (uint8_t)0xFFu) - ((uint8_t)1u << 2)))));
}
Zitat von
rungo
Die Erkenntnis, die (nicht nur) dieses
Buch vermittelt, ist, daß auch ein C-Programmierer in Sachen Mikrocontroller auf gute Assemblerkenntnisse angewiesen ist. Gleichzeitig erkennt man auch, daß bei den relativ vielen 'Extrawürsten', die C für die AVRs 'braten' muß, die (leichte) Portierbarkeit des Codes doch sehr in Frage gestellt wird.
Jepp, es ist ein häufigen Missverständnis, daß geglaubt wird, wenn man einen µC in C programmiert, sei man komplett losgelöst von der Hardware (siehe oben), und wundert sich, daß einem die Ressources ausgehen oder einem alles um die Ohren fliegt, weil man zu faul war, das Datenblatt zu lesen.
Was du mit "Extrawürsten" meinst versteh ich jetzt nicht. Du kannst deinen AVR in Standard ANSI-C programmieren. C hat freilich keine Vorstellung davon, was eine ISR ist und spezifiziert weder Syntax noch Semantik dafür -- das obliegt dem jeweiligen Compilerbauer.
Ansonsten sehe ich nicht, was an AVR-C über den Standard hinausgeht, oder wo Extrawürste sind. Die Makros, die etwa die IO-Register beschreiben, lösen nach ANSI-C auf. Und du brauchst sie nicht zu benutzen, du kannst ebenso hinschreiben
Code:
*((unsigned char volatile *) 0x3f) = 0x40;
Aber portierbar auf eine andere Architektur ist das eh nicht.
Wenn du das willst, dann ist nicht der Compiler oder die Sprache unzureichend, sondern dein Design: Du musst erst von der Hardware abstrahieren, und greifst in deiner architekturunabhängigen Applikation nur über die Interfaces dieses abstraction layers auf die Maschine zu.
ZitierenRAM war dabei eigentlich noch nie ein Problem.
Lesezeichen