Markusiii
13.05.2006, 20:49
Hallo alle Interessierten !
Ich habe mich jetzt lange zurück gehalten mit meinem Anliegen.
Kurz zu den Gegebenheiten.
Seit mehreren Monaten, bzw. mindestens einem halben Jahr,
habe ich dieses Development-Board von Atmel.
Also nicht von Phillips (LPCxxxx), sondern Atmel, mit dem AT91SAM7S64 drauf.
Erste Versuche mit den vier Tasten und den vier LED’s, den acht A/D Wandlern und der seriellen Schnittstelle sind erfolgreich gewesen.
Beispiele der Versuche sind (relativ gut zeitlich geordnet, aufsteigend):
· Veränderungen des mitgelieferten Beispielprogramms ‚Led-Lauflicht’;
· serielle Schnittstelle, Ein- und Ausgaben;
· A/D Wandler ansprechen und Werte auf serielle Schnittstelle ausgeben;
· Adaption an KFZ, Werte der Drosselklappenstellung und des Unterdrucksensors
bei einer 17-minütigen Probefahrt auf den Laptop übertragen;
· Versuch der Drehzahlerfassung, blieb beim Versuch;
· Programmierung einer Schrittmotorsteuerung mit Anfahrts- und Abstiegskurve, Schrittdaten und Richtung über serieller Schnittstelle übertragbar;
Das alles ist natürlich nach sehr langwierigem Suchen und Ausprobieren mit der Programmiersprache C und den in den mitgelieferten Libraries entstanden.
Und so recht viel ist das nicht, wenn man bedenkt, wieviele sehr nützliche Funktionen
der Prozessor beinhaltet.
Jetzt sieht es so aus, dass ich mir mein eigenes Prozessor Board aufbauen möchte,
bzw. muss.
Deshalb habe ich jetzt seit Langem (aus Frust) wieder dieses IAR Embedded Workbench geöffnet und wollte ein Test-Program in C schreiben.
Ich bin leider nur soweit gekommen, dass ich schonmal auf andere Ausgangspins,
als die vom Board für die vier LED’s verwendeten, schreiben konnte.
Eine kleine datailliertere Erklärung dazu folgt hier:
Die Datei Board.h sieht, unter anderem, original (Beispielprogramm) so aus :
#define LED1 (1<<0) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED2 (1<<1) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED3 (1<<2) /* PA2 & PWM2 SCK0 44 */
#define LED4 (1<<3) /* PA3 & TWD NPCS3 43 */
#define LED_MASK (LED1|LED2|LED3|LED4)
Diese habe ich wie folgt geändert:
#define LED_DOWN (1<<24) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED_POSOK (1<<25) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED_UP (1<<23) /* PA2 & PWM2 SCK0 44 */
#define LED1 (1<<0) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED2 (1<<1) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED3 (1<<2) /* PA2 & PWM2 SCK0 44 */
#define LED4 (1<<3) /* PA3 & TWD NPCS3 43 */
#define LED_MASK (LED1|LED2|LED3|LED4|LED_DOWN|LED_POSOK|LED_UP)
...somit habe ich dem Beispiel folgen können, und eigens auf meine Bedürfnisse erweitern können, wobei ich hier aber noch nicht weiss,
woher der Compiler wissen will, wie er die Nummer hinter den Zeichen '<<' als den entsprechenden I/O Pin interpretieren will.
Dann habe ich versucht, die ersten zwei Taster auf dem Board anzusprechen,
was ja in dem Beispielprogramm zu funktionieren scheint.
Leider ohne Erfolg.
Ich bin durch Messungen dahinter gekommen, dass die zuschaltbaren, internen Pullup-
Wiederstände anscheinend bei den ersten zwei Tastern nicht geschaltet sind,
allerdings aber bei den restlichen zwei Tastern.
Mit denen hat es dann auch geklappt, mein Test-Programm erweitern zu können.
Bis zu folgendem Punkt.
Mir ist ein Gedanke gekommen. Wenn es mir nicht einmal gelingt, die ersten zwei Taster
entsprechend aus zu lesen (Pullup aktiviert und deaktiviert funktionierte laut Messung an den letzten zwei Tastern, aber nicht an den ersten beiden), wie sollte ich dann in der Lage sein, ein sicher funktionierendes Programm zu schreiben ?
Beispielsweise lässt man mit diesen recht komplizierten Codezeilen nach dem Tastendruck von Taster 3 die LED1 dauerhaft leuchten:
if ( (AT91F_PIO_GetInput(AT91C_BASE_PIOA) & SW3_MASK) == 0 )
{
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED1) ;
}
(und ähnlich komplex wird z.B. der A/D Wandler angesprochen)
Und hier erkennt man vielleicht schon das Problem:
Woher will man wissen, erstens einmal, mit welchem Befehl man eine Taste auswerten kann,
ohne das Beispielprogramm zu haben. In diesem Falle wäre das der Befehl ‚AT91F_PIO_GetInput’ .
Also gut. Aber woher will man, ohne Beispielprogramm, wissen, welche weiteren Parameter
diesem Befehl übergeben werden müssen, dass man einen Erfolg erzielt ?
Selbst wenn man den Befehl durch mehr oder weniger Zufall in einer anderen Datei
entdeckt hat, und zwar in der ‚lib_AT91SAM7S64.h’ , worin steht :
__inline unsigned int AT91F_PIO_GetInput( // \return PIO input
AT91PS_PIO pPio) // \arg pointer to a PIO controller
{
return pPio->PIO_PDSR;
}
...hat man noch lange keinen Pokal gewonnen ;-)
Jetzt geht es weiter... !
Da fragt man sich dann, was bedeutet hier der Ausdruck ‚return pPio->PIO_PDSR;’ ??
So. Dann sucht man in den verschiedenen Dateien weitere Befehle, Ausdrücke und Registerdefinitionen etc.,
bis man irgendwann am Ziel ist, oder zumindest den Eindruck hat, dort angelangt zu sein,
wohin man eigentlich hin wollte.
Und das geht bis zum bitteren psychologischem Zusammenbruch, im wahrsten Sinne des
Wortes.
Dieses ‚Hin und her’ habe ich beim ersten Versuch mit den A/D-Wandlern erlebt.
Also ich sage Euch, es hat mehrere Tage gedauert, um ein paar funktionierende Codezeilen
gestaltet zu haben, und dementsprechend frustriert war ich, als ich schliesslich bemerken musste, wie kompliziert es in ‚C’ ist, einfach nur eine Peripherie ansprechen zu wollen.
Und was ist mit Timern und Countern ? Oder PWM ?
Soweit bin ich aus dem Grunde nicht gekommen, weil es schlicht und einfach
frustrierend ist, für so eine einfache Aufgabe wieder einige Tage und Nächte verbringen zu
müssen, um irgendwann ein funktioniernedes Ergebnis im Sinne von ein paar wenigen
Codezeilen zu haben.
Und jetzt bin ich wieder so weit, dass ich wieder das Problem mit diesem ‚C’ habe,
zwar jetzt ein anderes, aber es ist im Endeffekt dasselbe in grün.
Dabei geht es schliesslich nur um ein paar funktionierender Codezeilen,
welche zwei Taster auswerten (!!)
Es gibt hier anscheinend keine ordentliche Beschreibung, wie man die zahlreichen Register
anzusprechen hat.
Oder liegt es an der wirren und Gestaltung der verschiedenen Dateien und der Tatsache,
aus diesen vielen Faktoren und/oder Parametern sich das hoffentlich Richtige heraus zu
suchen ?
Oder liegt es nur an mir selbst, weil ich vorher noch nicht in C programmiert habe ?
Auch habe ich mich ein klein wenig in das Board mit dem LPCxxxx von Phillips
eingelesen. Aber das scheint mir, trotz des selben Prozessorkerns, etwas komplett
anderes zu sein, angesichts der Codezeilen oder/und Programmheaders oder wie man das nennen mag.
Auch die Befehle sind anders, auf diesem Board sind ja auch ein paar Taster und LED’s
drauf.
Aber es ist komplett anders, so wie es mir scheint.
Also wenn jemand generell in der Sache ‚Programmiersprache C’ weiter zu helfen weiss,
bitte schreiben O:)
Wenn noch jemand das Atmel-Board hat, wäre es wirklich von grossem Nutzen,
einen Informationsaustausch hier im Forum verwirklichen zu können.
Schon mal sehr vielen Dank für die (hoffentlich noch kommenden) Antworten.
Viele Grüsse,
Markus ](*,)
Ich habe mich jetzt lange zurück gehalten mit meinem Anliegen.
Kurz zu den Gegebenheiten.
Seit mehreren Monaten, bzw. mindestens einem halben Jahr,
habe ich dieses Development-Board von Atmel.
Also nicht von Phillips (LPCxxxx), sondern Atmel, mit dem AT91SAM7S64 drauf.
Erste Versuche mit den vier Tasten und den vier LED’s, den acht A/D Wandlern und der seriellen Schnittstelle sind erfolgreich gewesen.
Beispiele der Versuche sind (relativ gut zeitlich geordnet, aufsteigend):
· Veränderungen des mitgelieferten Beispielprogramms ‚Led-Lauflicht’;
· serielle Schnittstelle, Ein- und Ausgaben;
· A/D Wandler ansprechen und Werte auf serielle Schnittstelle ausgeben;
· Adaption an KFZ, Werte der Drosselklappenstellung und des Unterdrucksensors
bei einer 17-minütigen Probefahrt auf den Laptop übertragen;
· Versuch der Drehzahlerfassung, blieb beim Versuch;
· Programmierung einer Schrittmotorsteuerung mit Anfahrts- und Abstiegskurve, Schrittdaten und Richtung über serieller Schnittstelle übertragbar;
Das alles ist natürlich nach sehr langwierigem Suchen und Ausprobieren mit der Programmiersprache C und den in den mitgelieferten Libraries entstanden.
Und so recht viel ist das nicht, wenn man bedenkt, wieviele sehr nützliche Funktionen
der Prozessor beinhaltet.
Jetzt sieht es so aus, dass ich mir mein eigenes Prozessor Board aufbauen möchte,
bzw. muss.
Deshalb habe ich jetzt seit Langem (aus Frust) wieder dieses IAR Embedded Workbench geöffnet und wollte ein Test-Program in C schreiben.
Ich bin leider nur soweit gekommen, dass ich schonmal auf andere Ausgangspins,
als die vom Board für die vier LED’s verwendeten, schreiben konnte.
Eine kleine datailliertere Erklärung dazu folgt hier:
Die Datei Board.h sieht, unter anderem, original (Beispielprogramm) so aus :
#define LED1 (1<<0) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED2 (1<<1) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED3 (1<<2) /* PA2 & PWM2 SCK0 44 */
#define LED4 (1<<3) /* PA3 & TWD NPCS3 43 */
#define LED_MASK (LED1|LED2|LED3|LED4)
Diese habe ich wie folgt geändert:
#define LED_DOWN (1<<24) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED_POSOK (1<<25) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED_UP (1<<23) /* PA2 & PWM2 SCK0 44 */
#define LED1 (1<<0) /* PA0 / PGMEN0 & PWM0 TIOA0 48 */
#define LED2 (1<<1) /* PA1 / PGMEN1 & PWM1 TIOB0 47 */
#define LED3 (1<<2) /* PA2 & PWM2 SCK0 44 */
#define LED4 (1<<3) /* PA3 & TWD NPCS3 43 */
#define LED_MASK (LED1|LED2|LED3|LED4|LED_DOWN|LED_POSOK|LED_UP)
...somit habe ich dem Beispiel folgen können, und eigens auf meine Bedürfnisse erweitern können, wobei ich hier aber noch nicht weiss,
woher der Compiler wissen will, wie er die Nummer hinter den Zeichen '<<' als den entsprechenden I/O Pin interpretieren will.
Dann habe ich versucht, die ersten zwei Taster auf dem Board anzusprechen,
was ja in dem Beispielprogramm zu funktionieren scheint.
Leider ohne Erfolg.
Ich bin durch Messungen dahinter gekommen, dass die zuschaltbaren, internen Pullup-
Wiederstände anscheinend bei den ersten zwei Tastern nicht geschaltet sind,
allerdings aber bei den restlichen zwei Tastern.
Mit denen hat es dann auch geklappt, mein Test-Programm erweitern zu können.
Bis zu folgendem Punkt.
Mir ist ein Gedanke gekommen. Wenn es mir nicht einmal gelingt, die ersten zwei Taster
entsprechend aus zu lesen (Pullup aktiviert und deaktiviert funktionierte laut Messung an den letzten zwei Tastern, aber nicht an den ersten beiden), wie sollte ich dann in der Lage sein, ein sicher funktionierendes Programm zu schreiben ?
Beispielsweise lässt man mit diesen recht komplizierten Codezeilen nach dem Tastendruck von Taster 3 die LED1 dauerhaft leuchten:
if ( (AT91F_PIO_GetInput(AT91C_BASE_PIOA) & SW3_MASK) == 0 )
{
AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED1) ;
}
(und ähnlich komplex wird z.B. der A/D Wandler angesprochen)
Und hier erkennt man vielleicht schon das Problem:
Woher will man wissen, erstens einmal, mit welchem Befehl man eine Taste auswerten kann,
ohne das Beispielprogramm zu haben. In diesem Falle wäre das der Befehl ‚AT91F_PIO_GetInput’ .
Also gut. Aber woher will man, ohne Beispielprogramm, wissen, welche weiteren Parameter
diesem Befehl übergeben werden müssen, dass man einen Erfolg erzielt ?
Selbst wenn man den Befehl durch mehr oder weniger Zufall in einer anderen Datei
entdeckt hat, und zwar in der ‚lib_AT91SAM7S64.h’ , worin steht :
__inline unsigned int AT91F_PIO_GetInput( // \return PIO input
AT91PS_PIO pPio) // \arg pointer to a PIO controller
{
return pPio->PIO_PDSR;
}
...hat man noch lange keinen Pokal gewonnen ;-)
Jetzt geht es weiter... !
Da fragt man sich dann, was bedeutet hier der Ausdruck ‚return pPio->PIO_PDSR;’ ??
So. Dann sucht man in den verschiedenen Dateien weitere Befehle, Ausdrücke und Registerdefinitionen etc.,
bis man irgendwann am Ziel ist, oder zumindest den Eindruck hat, dort angelangt zu sein,
wohin man eigentlich hin wollte.
Und das geht bis zum bitteren psychologischem Zusammenbruch, im wahrsten Sinne des
Wortes.
Dieses ‚Hin und her’ habe ich beim ersten Versuch mit den A/D-Wandlern erlebt.
Also ich sage Euch, es hat mehrere Tage gedauert, um ein paar funktionierende Codezeilen
gestaltet zu haben, und dementsprechend frustriert war ich, als ich schliesslich bemerken musste, wie kompliziert es in ‚C’ ist, einfach nur eine Peripherie ansprechen zu wollen.
Und was ist mit Timern und Countern ? Oder PWM ?
Soweit bin ich aus dem Grunde nicht gekommen, weil es schlicht und einfach
frustrierend ist, für so eine einfache Aufgabe wieder einige Tage und Nächte verbringen zu
müssen, um irgendwann ein funktioniernedes Ergebnis im Sinne von ein paar wenigen
Codezeilen zu haben.
Und jetzt bin ich wieder so weit, dass ich wieder das Problem mit diesem ‚C’ habe,
zwar jetzt ein anderes, aber es ist im Endeffekt dasselbe in grün.
Dabei geht es schliesslich nur um ein paar funktionierender Codezeilen,
welche zwei Taster auswerten (!!)
Es gibt hier anscheinend keine ordentliche Beschreibung, wie man die zahlreichen Register
anzusprechen hat.
Oder liegt es an der wirren und Gestaltung der verschiedenen Dateien und der Tatsache,
aus diesen vielen Faktoren und/oder Parametern sich das hoffentlich Richtige heraus zu
suchen ?
Oder liegt es nur an mir selbst, weil ich vorher noch nicht in C programmiert habe ?
Auch habe ich mich ein klein wenig in das Board mit dem LPCxxxx von Phillips
eingelesen. Aber das scheint mir, trotz des selben Prozessorkerns, etwas komplett
anderes zu sein, angesichts der Codezeilen oder/und Programmheaders oder wie man das nennen mag.
Auch die Befehle sind anders, auf diesem Board sind ja auch ein paar Taster und LED’s
drauf.
Aber es ist komplett anders, so wie es mir scheint.
Also wenn jemand generell in der Sache ‚Programmiersprache C’ weiter zu helfen weiss,
bitte schreiben O:)
Wenn noch jemand das Atmel-Board hat, wäre es wirklich von grossem Nutzen,
einen Informationsaustausch hier im Forum verwirklichen zu können.
Schon mal sehr vielen Dank für die (hoffentlich noch kommenden) Antworten.
Viele Grüsse,
Markus ](*,)