Einige Syntaxfragen / AVR GCC preprocessor

Wutz

Nobuo T schrieb:

Oder nimmt der Preprocessor dann "&Data" insgesamt als neuen Variablennamen?

Nein.

Allerdings verstehe ich nicht, worin der Sinn bestehen sollen, die ADRESSEN von Datenbereichen zu vergleichen wie du oben schriebst. Ich vergleiche eigentlich immer die Daten selbst miteinander, also statt
&DATA1 == &DATA2
lieber
DATA1 == DATA2

Ich hoffe mal, in der o.g. Lib wird das auch so getan bloß dein "Extrakt" ist etwas danebengegangen.

cirion

ein sinn liegt imho nur dann vor, wenn die präprozessorsymbole auf port-register und nicht auf konstanten verweisen. da würde dann z.b. nach "#define P0 PORTB" und "#define P1 PORTC" eine abfrage "if (P0 == P1)" (nach präprozessorlauf "if (PORTB == PORTC)") auswerten, ob die flags bei beiden ports identisch gesetzt sind, während "if (&P0 == &P1)" (nach präprozessorlauf "if (&PORTB == &PORTC)") tatsächlich auswertet, ob P0 und P1 sich auf den gleichen port beziehen.

ru,
cirion

cirion

(wie pointercrash oben schon schrieb)

editieren geht hier forum nicht, oder?

ru,
cirion

pointercrash**

cirion schrieb:

eine 8bit breite übertragung ans display aber durchaus sinn. z.b. wenn man nur ein sehr enges zeitfenster für die ausgabe hat und jeder taktzyklus zählt.

Der Chip ist sowas von lahm, der verliert ja schon die Peilung, wenn man ihn mitm AVR am Uhrenquarz befeuert. Heißt, Memory Mapping scheidet aus und man verlagert ihn in eine gemütliche Service- Routine am Besten im Polling- Teil und damit jederzeit unterbrechbar. Das busy- Handling ist ziemlich unleidlich gestaltet, soweit ich mich erinnere.

pointercrash**

cirion schrieb:

(wie pointercrash oben schon schrieb)

editieren geht hier forum nicht, oder?

ru,
cirion

Doch, bei jedem Deiner Beiträge müßte es auch einen Link zum Editieren geben.

pointercrash**

Wutz schrieb:

Nobuo T schrieb:

Oder nimmt der Preprocessor dann "&Data" insgesamt als neuen Variablennamen?

Nein.

Oh doch, schon. Belehr' mich eines Besseren, aber da der Präppi von C nix weiß, sind &DATA und DATA einfach nur zwei unterschiedliche Literale.

cirion

pointercrash() schrieb:

Der Chip ist sowas von lahm, der verliert ja schon die Peilung, wenn man ihn mitm AVR am Uhrenquarz befeuert.

nicht jeder hd44870-kompatible lcd-controller ist so lahm wie das original.

ru,
cirion

pointercrash**

cirion schrieb:

pointercrash() schrieb:

Der Chip ist sowas von lahm, der verliert ja schon die Peilung, wenn man ihn mitm AVR am Uhrenquarz befeuert.

nicht jeder hd44870-kompatible lcd-controller ist so lahm wie das original.

Na und? Du kriegst irgendwelche Chinesenscheiße, mal reagiert der Controller im ns- Bereich (500 ns sind für die meisten µC sowieso noch lahm, zu lahm für memory mapping) und bei der nächsten Lieferung irgendwas mit einem Uralt- Chip. Was anderes als der 44870 war ja nicht spezifiziert - willst Du Dich dafür vom Einkauf anpissen lassen?
Ich jedenfalls nicht.

cirion

klar. wir sind hier in der produktion, und wenn jemand hd44870-code nutzt, dann muss es zwangsweise um einen hd44870 gehen...

fakt ist, man hat nicht bei jeder anwendung beliebig zeit für das display, und in solchen fällen macht eine 8bit-anbindung sinn, wenn man die pins eh noch frei hat.

ru,
cirion

pointercrash**

cirion schrieb:

fakt ist, man hat nicht bei jeder anwendung beliebig zeit für das display, und in solchen fällen macht eine 8bit-anbindung sinn, wenn man die pins eh noch frei hat.

Wow, Deine Ahnungslosigkeit ist beeindruckend.
Vor jedem Schreibzugriff muß man das Busy checken und das toggelt mit 60 Hz oder so, weil der Chip gerade die Backplane invertiert. Was interessiert es mich da, ob ich ihm in der Zeit 100 oder 1000 Zeichen reinblasen kann, der Controller kann nur etwa 100 Zeichen anzeigen. Der Geschwindigkeitsvorteil von 4 zu 8 Bit ist damit völlig unerheblich, alles Andere, als das unterbrechbar zu gestalten ist krasses Fehldesign. :p

cirion

pointercrash() schrieb:

Wow, Deine Ahnungslosigkeit ist beeindruckend.

nein, eher die deinige. ausser beim clearen des ganzen displays ist das busy-flag herzlich irrelevant, wenn man das timing vernünftig hinbekommt. schon mal ohne probiert? mach mal. und reiss danach erst wieder die klappe auf, bitte.

ru,
cirion

pointercrash**

cirion schrieb:

ausser beim clearen des ganzen displays ist das busy-flag herzlich irrelevant, wenn man das timing vernünftig hinbekommt. schon mal ohne probiert? mach mal. und reiss danach erst wieder die klappe auf, bitte.

Ja, schon mal probiert, je nach Nachbau mit unterschiedlichen Ergebnissen, genau darauf kommt's an. FM- Technik (funktioniert manchmal) ist was für Bastler, aber nix, was ein paar Tausend mal ins Feld muß.
Der 4-Bit- Betrieb spielt jedenfalls keine Rolle, der 8-Bit- Betrieb verschafft keine Geschwindigkeitsräusche.
Außerhalb der Spec soll man die Dinger auch nicht betreiben, weil sie sonst gelegentlich abstürzen. Alles schon probiert.

cirion

rofl... und jetzt wälz nochmal das hd44780-datasheet (das originale, nicht die ganzen china-kürzungen) und stell fest, dass das busy-flag gar nicht periodisch gesetzt wird, sondern absolut berechenbar ist...

von geschwindigkeitsrausch war eh nie die rede. aber du nutzt ja sowieso sachen wie polling...

ru,
cirion

abc.w

cirion schrieb:

rofl... und jetzt wälz nochmal das hd44780-datasheet (das originale, nicht die ganzen china-kürzungen) und stell fest, dass das busy-flag gar nicht periodisch gesetzt wird, sondern absolut berechenbar ist...

Toll. Dann ist das Busy-Flag einfach nur da, um da zu sein

cirion

nö. wenn man eben kein timing garantieren kann, oder nicht will, ist's ganz hilfreich. mehr aber auch nicht.

ru,
cirion

abc.w

cirion schrieb:

nö. wenn man eben kein timing garantieren kann, oder nicht will, ist's ganz hilfreich. mehr aber auch nicht.

Was steht denn in deinem originalen Datenblatt zum Busy-Flag? Würde mich mal interessieren...

cirion

zum beispiel dass das busy-flag nur nach gesendeter instruktion für die dauer der internen bearbeitung der instruktion gesetzt ist, inklusive einer liste, wie lange jede instruktion zur bearbeitung maximal braucht. kannst du aber auch selbst nachlesen. hitachi-datenblätter sind dem netz nicht fremd.

ru,
cirion

abc.w

In diesem Datenblatt www.sparkfun.com/datasheets/LCD/HD44780.pdf steht z.B. (Seite 9):

When the busy flag is 1, the HD44780U is in the internal operation mode, and the next instruction will not be accepted ... The next instruction must be written after ensuring that the busy flag is 0.

cirion

lies mal das ganze datenblatt.

the busy flag (BF) indicating that the system is now internally operating on a previously received instruction. If BF is 1, the internal operation is in progress.

und wie lange die internal operations maximal dauern, sagt dir table 6. fertig.

der umstand, dass es in der praxis (ohne fehlerquote) auch funktioniert (selbst bei china-clones), spricht eh für sich.

ru,
cirion

abc.w

cirion schrieb:

und wie lange die internal operations maximal dauern, sagt dir table 6. fertig.

Die Timings in Table 6 sind für f_osc = 270 kHz angegeben. Die f_osc kann im Bereich [190, 350] kHz liegen. Auf der Seite 55 sieht man, wovon diese Frequenz abhängt: Von einem simpen ohmschen Widerstand! D.h. die Timings in Table 6 sind nur rein informativ und einfach "nur" Pi mal Daumen...