mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Unlösbares Problem - Serielle Schnittstelle LPC2138


Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ihr seid meine letzte Hoffnung.
Ich habe vor einiger Zeit einen seriellen Treiber für den LPC2138
programmiert. Habe diesen auch ausgetestet, aber anscheinend nicht
genau genug.

Dieser Treiber kann IRQ gesteuert Daten senden und empfangen.

Das Problem:
Wenn ich Daten vom µC sende und dieser gleichzeitig Daten erhält, dann
stürzt er ab und startet neu und ich habe keine Ahnung warum.

Ich habe jetzt das Programm soweit verkleinert und auch die
Initialisierungen minimiert. Ich habe den Stack vergrößert.

Das Hauptprogramm holt ein empfangenes Zeichen ab und und sendet bei
jedem Durchlauf ein 'X' raus. Mehr macht das Programm zur Zeit
nicht.
Es ist nur der Empfangs- und SendeIRQ eingeschaltet. Die
Empfangs-IrQ-Routine holt sich das Zeichen in eine Variable und setzt
das Flag rx_counter1. Somit weiß das Hauptprogramm, dass es etwas zu
holen gibt.
Wird ein Sende-IRQ ausgelöst, so wird die Variable tx1sendezel auf 0
gesetzt, somit weiß PUTCHAR, dass ein weiteres Zeichen gesendet werden
darf.

Nun könnte man natürlich sagen, dass das Ganze natürlich ohne
IRQ-Routine wesentlich konfortabler funktionieren würde, aber es
handelt sich hierbei normalerweise um eine hochfunktionale Routine, die
den Hardwarebuffer vollständig ausnutzt und zudem noch einen
Sofwarebuffer besitzt.

Das Witzige ist, dass wenn ich in UART1-IRQ.c bei der Funktion putchar
die Zeile tx1sendezel++; durch die Zeile tx1senezel=1; ersetzte, dann
stürzt der Kontroller bei einem Empfang nicht mehr ab?!?

Hei, bitte Profis. Schaut euch den Code bitte mal durch. Ich weiß
nicht, wo der Fehler liegen könnte.

Danke.

Gruß, Martin

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht fischig aus:

status=U1IIR&0x0F; // Statusregister abfragen.
                   // Sende-IRQ wird jetzt gelöscht.
switch(status)
{
   case 0x04:  // Empfangen
               // Hardware-Buffer wird entleert und
               // in den Soft-Buffer geschoben.
               rx_buffer1=U1RBR;
         rx_counter1=1;
               break;

   case 0x02:  // Senden
               // Kein Zeichen befindet sich mehr im Hard-Buffer.
               // Zähler auf 0.
               tx1sendezel=0;
               break;
}

status schreit nach Bitabfrage. Dein switch-code geht schief, wenn
gleichzeitig das Statusbit für Empfangen und für Senden gesetzt sind (=
case 0x06). Genau der Fall "Crash beim gleichzeitigen Senden und
Empfangen".

Statt dem Switch/Case würde ich if-Abfragen mit anständiger Bitmaske
programmieren.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin,

sollte der Vorschlag von Stefan zur Behebung Deiner Probleme fuehren,
einfach diesen Beitrag ignorieren, anderfalls mal in Erwaegung ziehen.


Ein Schuss ins Blaue. Bitte mal die Application Note ueber "Spurious
Interrupts" lesen.
http://www.standardics.philips.com/support/documen...

Zusammenfassend, unter bestimmten Umstaenden ist es moeglich Interrupts
zu bekommen, die keinen Vector zugeordnet haben. Dazu sollte dann eine
Routine da sein, die diese abfaengt.
War gerade ein grosses Thema im LPC2000 Forum unter Yahoo mit den
Praktikern, die sagen, ein Interrupt der keine identifizierbare Source
hat wird einfach weggeworfen und dem akademischen Ansatz der sagt, es
darf keine unidentifizierbaren Interrupts geben.
Hoert sich jetzt vielleicht etwas off topic an aber deine Symptome sind
recht typisch fuer Spurious Interrupts.

Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"und dem akademischen Ansatz der sagt, es darf keine
unidentifizierbaren Interrupts geben."


In meinen Augen ist das kein akademischer Ansatz sondern eine Frage der
Zuverlässigkeit !

Wenn die es nicht mal schaffen, die Interruptlogik vernünftig gebacken
zu kriegen, wie soll man dann dem Rest vertrauen können ?

Beim 8051-er habe ich noch nie einen Interrupt verloren oder zuviel
gehabt.
Ist es denn wirklich zuviel verlangt von einen 32-Bitter genau so
zuverlässig zu sein, wie ein 8-Bitter ?

Falsche Interrupts dürften in jedem Fall ein absolutes K.O.-Kriterium
für den militärischen oder medizinischen Einsatz sein.


Peter

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter,

anscheinend ist es zuviel verlangt zuerst zugehoerige Information in
der Applikation Note zu lesen. Sorry, falls ich da zuviel erwartet hab.


Robert

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verfolge auch gerade die Mailings in der LPC2000-Group.

Philips hat sich mit den Teilen nicht mit Ruhm bekleckert. Die LPCs
sind ja anscheinend ein Sack voller Bugs.
Erstaunlich, wo die doch schon relativ lange auf dem Markt sind.

Vielleicht sollte Philips mal wieder weg von der "Umsatz, egal
wie"-Devise und ein bißchen mehr auf Qualität achten.
Haben die überhaupt eine vernünftige Qualitätssicherung? Oder liegt das
daran, daß Philips einfach nur unerfahren ist mit Controllern, die
komplexer sind als die uralten 8051er?

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert,

sorry.

So ich habe jetzt die AN gelesen und finde das ganze nur umso
seltsamer.

Der Interrupt-Bug ist also von den ARM-Entwicklern so vorgegeben und
darum mußte ihn Philips mit einbauen und darum wird es wohl auch keinen
Bugfix bei neueren LPCs geben.


Mein Kollege benutzt ja den LPC2129 und hat auch genau diesen Bug
festgestellt (hatte aber einige Tage gedauert), er muß Interrupts
zeitweise disablen, um 1-wire Sensoren abzufragen.


Für mich bleibt es jedenfalls ein kritischer Bug, egal wer dafür
verantwortlich ist und ich werde solche Bauteile meiden.


Peter

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:
Bin ich etwa vom 8051 zu sehr verwöhnt worden, was die Zuverlässigkeit
und Vorhersagbarkeit betrifft ?


Peter

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter,

nun mal ganz ehrlich, es gibt bessere Interrupt Controller als den auf
irgeneinem ARM (oder Intel x86 oder PPC oder AVR..) und die sind auf
den Infineon Chips. Falls mir der Interrupt das wichtigste Feature ist,
dann hab ich noch nichts besseres als den 166 im 16-bit und den TriCore
im 32-bit gefunden. Wuerde ich diese Chips deshalb einsetzen?
Vielleicht den 166, zumindest in der Vergangenheit war der Chip eine
Klasse fuer sich, fuer TriCore gibt es spezielle Anwendungen wie
Motormanagement, da ist der kaum zu schlagen aber ich mache keine
Motormanagement Anwendungen also ist der fuer mich nicht so attraktiv.

Genug der Lobeshymnen fuer Konkurrenzprodukte ;-) Der ARM Interrupt
Controller ist "OK" egal ob er VIC, AIC oder sonstwie heisst, alles
ist besser als das original ARM Schema mit IRQ und FIQ, (das weiterhin
benuetzt werden kann falls so gewollt).
Im Prinzip handelt es sich um eine Kombination von Pipeline Effekt und
kaskadierter Interrupt Controller.
Wir von Philips versuchen wo irgend moeglich original ARM Komponenten
einzusetzen, der VIC gehoert dazu. Warum? Kompatibilitaet und Tool
Unterstuetzung von Compilern bis Operating Systems.
Nun zum eigentlichen Punkt der sporadischen Interrupts wie in der
ApNote beschrieben; ist das was schoenes? Nein, aber es ist ungemein
schwierig den ARM Core zu nehmen, einen verbesserten vorgeschaltenen
Interrupt Controller einzubauen und nicht in ein solches Dilemma zu
laufen. Es scheint, es hat noch keiner geschafft. Alle mir bekannten
Loesungen von anderen Herstellern verweissen irgendwo auf aehnliche
Probleme. Schau die ApNote als Workaround an.
Die entscheidende Frage fuer mich ist allerdings, soll mich diese
"Unschoenheit" davon abhalten Microcontroller mit dem besten
Preis/Leistungsverhaeltnis einzusetzen, mal egal von welcher Firma sie
hergestellt werden?
Die Antwort muss sich jeder selbst geben.

p.s verwoehnt vom 8051? In 2 Punkten vielleicht schon, Interrupts
inklusive Registerbankswitch und Bitverarbeitung, da ist der schon
seiner Zeit lange voraus gewesen bei der Einfuehrung 1979!

Gruss, Robert

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert,

Unter "2.3 Handling of spurious interrupts" steht ja, daß ich die
Interruptquelle herausfinden und behandeln muß.

Da kann ich mir ja gleich verschiedene Vektoren für verschiedene
Interrupts schenken und alles in diesem einen Interrupthandler machen
(müssen).

Ich hatte eigentlich so gedacht, daß ich für den spurious Interrupt
einfach einen leeren Interrupthandler aufsetze, damit mein Programm
nicht abschmiert und daß ich danach den richtigen Interruptvektor
kriege, da ich ja keine Interrupt-Flags lösche.


Peter

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmm, mal eine Frage als nicht ganz so Versierter:

Was sind denn spurious interrupts und warum sind sie so schlimm?

Bei meinem Linux erscheint auch ab und an so ein Eintrag mit diesen
Interrupts im Log. Abgeschmiert ist das aber bisher noch nicht.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Was sind denn spurious interrupts und warum sind sie so schlimm?"


Wenn dieser spurious Interrupt eigentlich den Airbag in Deinem KFZ
auslösen hätte sollen, wäre das etwa nicht schlimm ?


Peter

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt 2 Sachen, die mir am 8051 gegenüber dem ARM besonders gefallen:

1.
Nach einem Interrupt wird immer erst eine Instruktion des Main
ausgeführt. Sollte mal die CPUs mit Interrupts zugeschissen werden,
läuft sie immer noch, zwar sehr langsam, aber sie läuft.

Ich hab z.B. mal Debugausgaben über die UART gemacht, als
Interrupthandler hats nicht funktioniert, aber im Main im Polling-Mode
habe ich alle Debugausgaben erhalten.


2.
Jeder Zugriff auf die Interruptregister sperrt Interrupts auch für den
nächsten Befehl und startet die Interrupterkennung neu. Somit kann es
nie passieren, daß sich Interruptlogik und CPU in die Quere kommen.


Ich weiß natürlich, daß man den ARM nicht so einfach verbessern kann,
weil es ein Standard ist. Aber ärgerlich ist es schon, daß
CPU-Entwickler zu selten über den eigenen Tellerrand schauen.


Peter

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn dieser spurious Interrupt eigentlich den Airbag in Deinem KFZ
auslösen hätte sollen, wäre das etwa nicht schlimm ?"


Hallo Peter,

ein nicht ausgelöster Interrupt ist natürlich ist natürlich schlimm,
aber mit ist immer noch nicht klar, was das eigentlich ist.

Ist das ein Interrupt, der nicht als solcher erkannt wurde bzw. der
unter einer anderen Quelle erscheint?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Danke für die Antworten.

Ich habe jetzt das probiert, wozu mir Stefan geraten hat. Bist jetzt
hat alles einwandfrei funktioniert.
Ich muss aber nocht Tests mit den komplexeren Teilen des Programmes
durchführen. Aber in der Light-Version funktioniert das Senden und der
Empfang bestens.

Aber was ich nicht verstehe: Auf Seite 105 im Datenblatt (Ver:
22.11.2004) ist das ganze so beschrieben, als ob die verschiedenen IRQs
- Receive-Line-Status, Receive Data Available, Character Time-Out usw.
verschiedene Prioritäten aufweisen.

Aus diesem Grund habe ich ja auch eine Switch-Anweisung geschrieben, da
ich mir dachte, dass auch wenn zwei IRQ gleichzeitig auftreten, nur
einer im Statusregister angezeigt wird, nämlich der mit der höheren
Priorität. Wenn man dann den mit der höheren Priorität abgearbeitet
hat, dann sollte, der mit der niedrigeren angezeigt werden. So war
meine Idee. Ist diese denn so falsch? Vermischen sich hier wirklich die
verschiedenen IRQ's im Statusregister U1IIR?

Dies mit der IF-Abfrage und der Maskierung funktioniert ja nur beim
Senden und Empfangen, aber nicht im folgenden Beispiel.

(Bit 3:1)
011 RLS - Fehler
010 RDA - Empfang
110 CTI - Character Time-out
001 THRE - Senden

Wenn ich nun die Abfragen maskiere.

if((status&0x04)==0x04) // Empfang - RDA
{
      rx_buffer1=U1RBR;
    rx_counter1=1;
}

if((status&0x0C)==0x0C) // CTI- Character Time-Out
{
..
}

Wenn nun im obigen Beispiel ein Time-Out-Irq ansteht, dann glaubt der
Controller anhand der Maskierung, dass nicht nur der Time-Out-Irq
ausgelöst wurde, sondern auch ein Zeichen empfangen wurde. Wie löst man
dieses Problem?

Danke, Tschüss, Martin

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist Zufall, dass der Code jetzt funktioniert.

Du darfst nicht ein einzelnes Bit abfragen, sondern musst die drei Bits
zusammen abfragen. Das war richtig von dir gedacht.

status &= 0b00001110; // Bits 3:1 gelten
status >>= 1;         // um Bit 0 wegzubekommen ;-)

if ( status == 0b010 ) // Empfang - RDA
{
   rx_buffer1 = U1RBR;
   rx_counter1 = 1;
}
else
if ( status == 0b110 ) // CTI- Character Time-Out
{
   ...
}

Jetzt bietet sich auch wieder ein switch/case an.

status = U1IIR & 0x0E; // Bits 3:1 sind relevant

switch ( status )
{
   case 0x04:   // Empfang - RDA
                rx_buffer1 = U1RBR;
                rx_counter1 = 1;
                break;

   case 0x0C:   // CTI- Character Time-Out
                ...
                break;
   ...
   default:
                ASSERT(...);        // ;-)
                break;
}

Ups. Das ist wieder an deine Ausgangsversion. Fast ;-) bis auf die
Maske (früher: 0x0F jetzt 0x0E). Deine Ausgangsversion ist schief
gegangen, wenn Bit 0 in status gesetzt war.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI. Hi. Hi.

Du bist ein Genie.
Danke. Jetzt ist es mir logisch, warum es hier Probleme gab, weil
das Interrupt-Pending-Bit nicht rausgelöscht wurde.

Ich werde das mal alles testen.

Tschüss, Martin

Autor: Andreas Häusler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Hab noch einen kleinen Nachtrag zu obenstehendem Problem.

Wie Robert bereits erwähnt hat, bieten andere Controller nicht nur
einen Empfangs Interrupt. Da wird beispielsweise auch bei einem
falschen Daten Frame ein IRQ auf einem anderen Vektor ausgelöst.

Ist dieser nicht implementiert, kann es vorkommen, dass bereits beim
Einstecken des RS232- Kabels ein solcher fehlerhaftes Datenpaket
entstehen kann.
Ist der enstprechende Vektor nicht definiert, hängt die CPU. (Mir
bereits geschehen, aus Schaden wird man klug)

Desshalb mein Rat: Immer sämtliche Empfangs IRQ- Vektoren mit
Rücksprungadressen versehen.

Gruss Andy

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich habe mich leider zu früh gefreut.
Leider hat diese Umstellung nichts gebracht. Der Prozessor startet
trotzdem immer wieder neu.

Wahrscheinlich muss ich mir doch das Datenblatt, welches mir Robert
empfohlen hat anschauen.
Aber eines weiß ich.

Wenn ich herausgefunden habe, wo hier die Ursache liegt, dann habe ich
garantiert viel gelernt.

Gruß, Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe noch eine Frage:
Im AN10414 Datenblatt, indem die spurious Interrupts beschrieben
werden, ist es so, dass der Interrupt-Controller mit
"VICVECTAdrr=0xFF;" am Ende einer Interrupt-Routine geresettet wird.
Doch in den anderen Datenblättern steht immer "VICVECTAdrr=0x00;".
Was ist richtig? Oder gibt es beide Varianten.

Tschüss, Martin

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich habe jetzt das mit dem spurious-IRQ versucht. Der µC stürzt zwar
jetzt nicht mehr ab, aber das heißt nichts, da es nach Veränderung
einer Programmzeile wieder zu einem Absturz kommen kann.

Was mir Sorgen macht ist, dass der Kontroller nicht in die
Spurious-Routine springt. Im Datenblatt steht auch, dass der
Spurious-Interrupt nur dann ausgelöst wird, wenn RDA und CTI-IRQ
verwendet werden. Nur der (CTI)-Time-Out-IRQ wird in der jetzigen
Version nicht mehr verwendet, sondern nur noch der Sende und
Empfangs-IRQ und kein Hardwar-Buffer mehr.

Ich habe euch das Programm nochmal reingestellt. Die
Spurious-Handler-Routine wurde von mir wieder auskommentiert.
Diese Programm-Version stürzt immer wieder ab, wenn man dem Kontroller
Daten schickt. Dazu habe ich einfach ein 12KByte-File angelegt, um
dieses an den µC zu senden. Das Lustige ist, dass dieser dann nicht
mehr abstürzt, wenn man im file UART1-IRQ.c, in der IRQ-Routine
die beiden Zeilen.
IOSET1=0x01<<18;
..
..
IOCLR1=0x01<<18;
wieder aktiv setzt. Leider habe ich immer mehr das Gefühl, dass es sich
um einen Prozessor-Bug handelt.

Hey Profis, bitte helft mir. Ich habe soetwas noch nie erlebt. Ich
dachte, wenn ich das Programm vereinfache, dann kann man den Fehler
leicht finden, aber ich finde keinen Fehler.

Danke im Voraus.

Schönen Gruß, Martin

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

ist leider etwas Offtopic, aber vielleicht nützt es ja:

Ich persönlich würde ein Embedded-OS wie z. B. eCos probieren.
Da ist die serielle Schnittstelle, Interrupt-Handling, Scheduling usw.
schon alles wunderbar implementiert.
Ist außerdem GPL-Software.

Gruß

Olaf

http://ecos.sourceware.org/

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Olaf, aber ein Embedded-OS kommt für mich nicht in Frage.

Ich habe jetzt die ganzen Modi abgeklappert:
Undef_Addr
SWI_Addr
PABT_Addr
DAbt_Addr

Aber der Kontroller bleibt nur beim Breakpoint - Reset_Addr stehen.

Auch der Verdacht, dass versehentlich die Reset-Leitung gezogen werden
könnte, bestätigte sich nicht.

Gruß, Martin

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

warum kommt ein Embedded-OS nicht in Frage?
eCos kannst Du durch compile-Schalter bis auch wenige K kleinkriegen.
Du kannst Dich z. B. auf den HAL für bestimmte Hardware beschränken,
ohne Scheduler oder anderen Schnickschnack.

Gruß

Olaf

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Olaf!

Dies wäre natürlich schon auch interessant. Nur habe ich jetzt von
Embedded-OS-System absolut 0 Ahnung. Die Einarbeitungszeit würde
wahrscheinlich einige Zeit in Anspruch nehmen.

Es ist aber so, dass ich solche technischen Probleme, wie sie z.B. hier
jetzt vorherrschen immer gelöst haben möchte oder zumindest die Antwort
darauf haben möchte, warum so ein Ding nicht funktioniert. Auf diese
Weise lernt man immer eine Menge.

Aber vielleicht schaue ich mir so ein System mal an. Wäre es möglich,
dass du mir deine E-Mail-Adresse zukommen lässt, falls ich mal zu
diesem Thema Fragen habe. Keine Sorge, ich werde dich nicht ständig mit
E-Mails bombardieren, aber für einen Einstieg ist es immer wichtig, dass
man die richtigen Fragen stellen kann und ein paar Hilfestellungen
bekommt, damit das Ganze leichter geht.

Aber zuvor möchte ich dieses Problem lösen, weil von dieser Lösung
abhäng, ob ich den Prozessor in Zukunft überhaupt noch verbauen werde.

Gruß, Martin

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

Ok. Ich schick Dir meine Email-Adresse.
Solltest Du sie nicht erhalten, poste hier nochmal.

Gruß

Olaf

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Hey, das kann doch nicht sein, dass hierzu niemand etwas weiß.
Es gibt so viele hier im Forum, die mit ARM-Prozessoren arbeiten. Da
muss doch schon mal jemand eine IRQ-Gesteuerte UART-Routine
programmiert haben und hierzu Erfahrungen gesammelt haben.

Also mit meinen guten alten AVR-Atmel Prozessoren hatte ich in dieser
Richtung noch nie Schwierigkeiten. Da lief immer alles bestens.

Der ARM7 von Philips wäre der allerbeste Prozessor, mit dem ich jemals
Projekte realisiert habe. Wie ihr erkennt schreibe ich hier leider in
der Konjunkiv II-Form. Leider, diese Bugs, die der Benutzer alle selbst
ausbügeln muss, sind relativ lässtig sind. Man kann sich dann nicht voll
auf das Projekt konzentrieren, sondern muss immer im Hinterkopf haben,
wie man jetzt eventuell auftretende Probleme und Bugs des Prozessors
beseitigt.
Schade, der Prozessor hätte eine Menge von Vorteilen: 32-Bit-Timer,
DA-Wandler, viel SRAM, viel Flash, abwechslungsreiche Peripherie.

Gruß, Martin

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, geschenkt kriegt man nichts. Wenn Du einen 32-bitter willst, mußt
Du eben auch mit seiner erheblich größeren Komplexität zurechtkommen.

Der Preis eines Chips ist nicht entscheidend für dessen Verwendung.

Blöd wäre natürlich, wenn Du den 32-Bitter deswegen nimmst, um
Programme mit vielen Wait-Loops und vielen Portsetzen zu beschleunigen,
damit ists Essig.


Vielleicht versuchst Du ja erstmal den ganzen UART-Schrunz im
Pollingmode zu implementieren.
Und erst, wenn das perfekt läuft, fügt man diese Routine in den
Interrupt ein.


Besonderes Augenmerk ist auf Register und Variablen zu legen, die im
Main und im Interrupt gleichzeitig verwendet werden, dann den
Main-Zugriff mit Interruptsperre klammern.
C-Ausdrücke sind per default nicht atomar !

Wirkt sich aber erst bei echten Interupts aus, nicht bei Abfrage im
Polling. Und beim Interrupt Sperren eben den Spurious Interrupt Handler
aufsetzen.


Peter

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne den ganzen Thread gelesen zu haben: Was spricht gegen die
Verwendung des UART-Codes von Bill Knight / R O Software (file-Archiv
LPC yahoo-Gruppe.) Ich nutze den recht oft, bisher keine Probleme.
Allerdings auch nur bei relativ geringen Baudraten getestet. Die
Abfrage der Statusbits ist dort etwas anderes geloest, es werden jedoch
alle "Ereignisse" verarbeitet.

Betr. Spurious Interrupt sind die Erläuterungen von ARM selbst und
Atmel auch recht informativ. "Nicht ausloesen" eines Interrupts gibt
es nicht - zumindest nicht meines Wissens. Endweder kann der VIC/AIC
den Interrupt verarbeiten oder er "kommt nicht dazu" und ruft dann
den default/spurious-Handler, in dem dann der Enwickler fuer die
korrekte Weiterverarbeitung Sorge tragen muss. Weiterhin gibt es ja
noch FIQ als zusaetzliche "Verarbeitungsebene" die bei einigen
Problemstellungen weiterhelfen kann (wohl aber nicht im konkreten
Fall). Nichts desto trotz - keine glueckliche Loesung. Schade, dass
Philips, Atmel, ST etc. bei ARM keine bessere Loesung erwirken konnten.
Analog hat bei den ADuC7k scheinbar gleich ganz auf eine
Vectored-Interrupt-Controller-Zelle verzichtet, fragt sich, ob aus
Kostengruenden oder weil man dem Problem aus dem Weg gehen wollte.

Martin Thomas

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter!

Das Dumme ist, dass man sich doch zu Beginn besser über entsprechende
Fehlverhalten informieren sollte. Das habe ich nun gelernt. Aber mit
den Fehler, die im Errata-Sheet beschrieben sind, kann ich eigentlich
leben. Leider erfährt man zu Beginn nicht immer alle Nachteile und kann
erst nach einer gewissen Einarbeitungszeit erkennen, ob man mit den
Nachteilen leben kann oder möchte.
Ich finde aber, dass es hier nicht um Komplexität geht, wie du
beschreibst, denn der Kontroller ist relativ verständlich aufgebaut.
Das Dumme ist nur, wenn an derartigen architektonischen Nachteilen der
Endbenutzer zu knabbern hat.
Leider steht im Datenblatt nicht:
"Unser Prozessor ist zwar super, aber Sie müssen auf folgende Bugs
achten und Sie müssen auf die Surious-IRQs achten und ......"

Es ist mir schon klar, dass es bei jedem µC architektonische Nachteile
gibt, aber diese hier finde ich schon relativ gravierend.

Das mit dem Polling waren meine ersten Übungen.

Hallo MThomas.
Ich habe in die yahoo-group reingeschaut, aber ich habe den UART-Code
nicht finden können. Kannst du mir bitte einen Link schicken?

Gruß, Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich möchte euch jetzt mal den Zwischenstand mitteilen.

Das Programm wurde von mir so umgeschrieben, dass nicht die UART1,
sondern die UART0 verwendet wird.
Das brachte keinen Erfolg.

Statt des C-ARM-Keil-Compilers versuche ich nun den Real/View.
Auch jetzt stürzt der Kontroller noch ab.

Ich habe ein selbstgebautes Board und ein Keil-Board. Beide stürzen
ab.

Zusätzlich habe ich jetzt als letzten Verzweiflungsversuch alle
Variable auf 32-Bit umgestellt. Auch das brachte nicht den Erfolg.


Jezt habe ich schon sehr viel versucht und ich bin immer noch so
gescheit oder so blöd wie vorher.

Profis, was kann das nur sein?

Gruß, Martin

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.