>also rein von der programmierung her sind glob. variablen böse ;-)
das mag für PC-Programmierung richtig sein bei µCs sehe ich das
anders.
nehmen wir zb. den framebuffer. dieser wird von vielen funktionen der
lcd-library genutzt. um diesen funktionen jeweils die adresse des
framebuffer bekannt zu machen bräuchte es eine zusätzliche funktion
getFramebufferAddr() die den pointer zurück gibt. diese vorgenweise ist
zwar elegant, aber auf einem µC zeit und resourcenverschwendung.
oder eine msCounter der systemweit benötigt wird getSystime() -> zeit
und resourcenverschwendung...
>ich weiß aber nicht, warum du sie so umständlich deklarierst! würde
es
>nicht reichen einfach eine struktur oder arrays "irgendwo, wo es
>passt" in das ram wenns dynamisch sein soll zu schreiben, oder wenn
>diese daten statisch sind sogar ins flash?
umständlich ist das keineswegs, mit RESERVE_RAM[x] wird angegeben
wieviel speicher reserviert werden soll und der variable *framebuffer
wird mit der entsprechenden speicherstelle initialisiert fertig.
der vorteil liegt darin, das dieser speicherbereich auf keinen fall vom
stack überschrieben wird (und umgekehrt), was das debuggen letzendlich
erleichtert.
was das anlegen "irgendwo, wo es passt" betrifft, dies erhöt die
fragmentierung des speicher.
unveränderliche daten wwerden eh als const declariert, so dass diese
automatisch im flash landen.