mikrocontroller.net

Forum: Compiler & IDEs Umsetzung von Hardware-ungekoppeltem Code; Zeiger in C?


Autor: Christian Wolf (clupus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

ich hab schon oft gehört, dass es sinnvoll sei, im Code keine direkten
Port-Bezeicher & Co. einzuarbeiten. Ist logisch.
Nun hab ich aber das Problem, dass ich für eine Uhr so 17 LEDs und 2
Schlter (hört sich wenig an) an einen Mega8 rankriegen muss. Ich will
aber, da ich noch nicht weiß, an welchen Ports welche LED rankommt
(kann sein, dass sich da noch das ein oder andere ändert), das so
programmieren, dass ich in der hardware.h-Datei (so heißt das Ding halt
bei mir) alles eingeben kann.

So nun zu meinem Problem:
Ich hab es einmal geschrieben und gesen, dass es sehr viel Aufwand ist,
wenn ich mir das alles als Makros definiere. Da muss ich dann Unmengen
an #define-Anweisungen setzen und auch das Ansprechen ist nicht so ohne
(Ich muss ja für jede LED einzeln prüfen, ob sie leuchten soll, und dann
im jeweiligen IO-Register ein-/ausschalten.) Das ist im auskommentieren
Code ja teilweise zu sehen!

Daher dachte ich mir es ginge einfacher, wenn ich Arrays verwende. In
die Arrays kommen die Zeiger auf verschiedene Register (DDR, Port, PIN,
...). Damit kann ich einzelne LEDs ihrer Priorität nach mit LED_SEC[0]
bis LED_SEC[5] (z.B.) ansprechen. Ich hab also die Zeiger mithilfe der
&-Operator in die Arrays eingegeben. (Vgl. Anhang; die erste Reihe an
Arrays haben in Nachhinein einen * verpasst bekommen, dazu später)

Nun zum ersten Problem, bei dem ich C nicht verstehe:
wenn ich eine Funktion definiere mit
test_func(int * param) {...}
und mit test_func(a) aufrufe, "sieht" die Funktion:
*param = <Wert von a>
param = <Adresse von a>
=> *param = a könnte man sagen

rufe ich aber nun test_func(&a) auf, ist das nicht mehr das selbe; die
Funktion sieht (in Klammer: solle analog sehen):
*param = <Wert von a> (<Adresse von a>)
param = <Adresse von a>
**param = >Mist< (<Wert von a>)
=> Auch hier könnte man *param = a sagen, obwohl eigentlich *param = &a
logisch wäre, oder?

Ziel sind die Funktionen LED_xxx_OFF und LED_xxx_ON. Hier wird die
Adresse aus den Zeigern ausgewertet. Zuerst hatte ich hier die
Parameter ohne die * angegeben. Dann bekam ich vom gcc eine
Fehlermeldung. Nur interessehalber: Was hab ich da "falsch" gemacht?
(Damit mir das nicht noch mal passiert?

2. Problem (viel wichtiger, da ungelöst!!!!!):
Weiter unten (Z. 274ff) versuche ich auf die Werte der oben
eingesetzten Zeiger zugreifen, um die jeweiligen LEDs
ein-/auszuschalten. Da bekomme ich nur folgende Meldung vom gcc:

hardware.h: In function 'Init_HW':
hardware.h:274: error: assignment of read-only location

Hier hab ich dann oben die * eingefügt, bei den Arrays, hat aber nix
außer der zusätzlichen Meldungen des GCC gebracht:

hardware.h:30: warning: initialization discards qualifiers from pointer
target type

Das wird dann für jedes Element wiederholt.

Was kann ich da machen? Oder gibt es eine bessere Möglichkeit das mit
dem HW-unabhängigen Code zu machen, so dass es auch
Programmiertechnisch im Rahmen bleibt und möglichst übersichtlich
bleibt (die Kommentare mit dem alten Code kommen klar noch raus, aber
jetzt sind sie zu Debug-Zwecken noch drinnen)?

MfG
Christian

PS: Mir wäre v.a. mit der 2. Antwort geholfen. Und noch eine
Kleinigket: Ich habe hier kein C-Buch. Also so Kommentare wie "Schalg
mal dein C-Buch auf und ließ!" ziehen nicht. Ich hab das bisschen C-
das ich kann zum einen Lerning-By-Doing und zum anderen aus dem Netz
gelernt. Und meine Quellen geben zu dem Thema nix her.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht aus, als willst Du ne Binäruhr bauen.

Ich programmiere ja schon viele Jahre, aber so auf die schnelle binär
dekodieren zu müssen, wäre mir zu mühsam.
Ich würde eine Ziffern- oder Zeigerdarstellung nehmen.


Etwas grundsätzliches zu Feldern, sie beginnen immer bei 0 und gehen
bis n-1.
D.h. bei einer Feldgröße von 6 sind nur die Indizes 0..5 gültig.


Was Du mit dem vielen Geschreibsel erreichen willst, ist mir nicht
klar. Zumindest ist es sehr schwer zu verstehen.

Ich würde den Portpins per define Namen zuweisen und sie dann im
Programm direkt über ihren Namen ansprechen.

Bevorzugt würde ich zusammengehörende Pins im gleichen Port
unterbringen, muß aber nicht sein. Der Codeaufwand ist dann aber
geringer.


Peter

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau darum geht's. Weil ich noch nicht weiß, ob die Pins so bleiben,
will ich die Adresse zu jedem Pin (DDR-, PORT-Register, Pin-Nummer) in
einer Definition am Anfang eingeben. Wenn ich das via #define mache,
sind da ziemlich viele defines notwendig und v.a. ist das Problemchen,
dass ich für jede LED einzeln mit if oder ?: prüfen muss, ob sie
leuchten soll oder nicht. Das ist nicht wenig Tipparbeit. Da ist eine
for-Schleife, die das ganze durchläuft deutlich praktischer. Das geht
aber nicht mit #define-Anweisungen.
zum Thema Anzeige: Das das Ding binär anzeigt, ist gewollt. Es ist eine
Eigenkonstruktion, weil eine gute Freundin so ein Ding haben wollte. Ich
allerdings sehe darin eine gute Übung und auch ggf. die Mgl das Ding auf
Armabduhr-Format zu bringen. Dehalb der modulare Aufbau.

Einen Teil der Probleme hab ich übrigens gelöst: Ich muss folgendes
machen:

Oben definieren:
const uint8_t DDR_LED_SEC[6] = {&DDRC,&DDRC,&DDRC,&DDRC,&DDRC,&DDRC};

Weiter unten dann entweder verwenden:

*(uint8_t *)DDR_LED_SEC[...] = abc;

oder eben mit Unterfunktion:
LED_OFF_ll(uint8_t LED,uint8_t * PORT){ *PORT |= _BV(LED); }
aufzurufen mit LED_OFF_ll(2,&PORT_LED_SEC[...]);

Es bleibt also die Frage, wie ich die Arrays in den Programmspeicher
bekomme und ob es irgendwie besser geht.

MfG
Christian

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
» Etwas grundsätzliches zu Feldern, sie beginnen immer bei 0 und gehen
bis n-1.
» D.h. bei einer Feldgröße von 6 sind nur die Indizes 0..5 gültig.

Was meinst du damit? Habe ich das irgendwo verletzt? Ich meine nämlich,
mich immer an die Regel gehalten zu haben.

MfG
Christian

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Hier noch ein Gedanke um die defines zu vereinfachen:

#define LED_MIN_PORT  PORTB
#define LED_HOUR_PORT PORTD
#define SWITCH_PORT   PORTC
#define LED_MIN_1_pin     1
#define LED_MIN_2_pin     2
#define SW_1_pin          5

#define PIN(x) (*(&x - 2)) //address of input register port x
#define DDR(x) (*(&x - 1)) //address of data direction register port x

...

DDR(LED_MIN_PORT) |= _BV(LED_MIN1_pin);  //MIN1 LED is output
DDR(SWITCH_PORT)  &= ~_BV(SW_1_pin);     //SW_1 is input

....

LED_MIN_PORT |= _BV(LED_MIN_1);     //LED 1 on
if (PIN(SWITCH_PORT) & SW_1) ......

Reiner

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian

"Was meinst du damit? Habe ich das irgendwo verletzt?"


Ja, so kann man die Leute verarschen.

Du solltest lesbar schreiben, also nicht reservierte Syntaxelemente
zweckentfremden.

Jeder, der xx[1] sieht, denkt natürlich, das ist ein Feldelement und
kein define.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du die LEDs binär ordnen würdest, könnte man mittels
Schiebeoperatoren ausgeben.


Für die wahlfreie Zuordnung, muß man aber jede LED per Abfrage separat
schalten, das könnte z.B. so aussehen:
#include <io.h>

#define LED_MIN0        A, 0
#define LED_MIN1        B, 6
#define LED_MIN2        C, 5
#define LED_MIN3        D, 0
#define LED_MIN4        B, 7
#define LED_MIN5        A, 1


#define OUT_HIGH(x) _SH(x)
#define OUT_LOW(x) _SL(x)
#define OUT_DIR(x) _SD(x)

#define _SH(x,y) (PORT##x |= (1<<y))
#define _SL(x,y) (PORT##x &= ~(1<<y))
#define _SD(x,y) (DDR##x |= (1<<y))


void out_minute( unsigned char val )
{
  OUT_DIR( LED_MIN0 );
  OUT_DIR( LED_MIN1 );
  OUT_DIR( LED_MIN2 );
  OUT_DIR( LED_MIN3 );
  OUT_DIR( LED_MIN4 );
  OUT_DIR( LED_MIN5 );

  val &  1 ? OUT_LOW( LED_MIN0 ) : OUT_HIGH( LED_MIN0 );
  val &  2 ? OUT_LOW( LED_MIN1 ) : OUT_HIGH( LED_MIN1 );
  val &  4 ? OUT_LOW( LED_MIN2 ) : OUT_HIGH( LED_MIN2 );
  val &  8 ? OUT_LOW( LED_MIN3 ) : OUT_HIGH( LED_MIN3 );
  val & 16 ? OUT_LOW( LED_MIN4 ) : OUT_HIGH( LED_MIN4 );
  val & 32 ? OUT_LOW( LED_MIN5 ) : OUT_HIGH( LED_MIN5 );
}

Die doppelten Macros sind dazu da, um den Präprozessor zu überlisten,
der macht die Argumentenüberprüfung nur bei der ersten Macroexpansion.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

Überlisten ist nicht ganz richtig, sondern man nutzt aus, daß der
Präprozessor mehrere Durchläufe macht:

Im ersten Durchlauf stellt er fest, daß ein Macro mit einem Parameter
auch einen Parameter bekommt und ist glücklich. Dann expandiert er die
erste Instanz an Macros.

Im nächsten Durchlauf findet er wieder ein Macro, aber diesmal mit 2
Parametern, das nun auch 2 Parameter bekommt und ist wieder glücklich.


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.