www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LPC2148 Flash zu langsam


Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute ich habe folgendes Problem.
Ich habe eine Applikation für den LPC2148 geschrieben. Im Debugmodus ( 
Programm im RAM ) funktioniert alles ohne Probleme. Wenn ich das 
Programm ins Flash schreibe, wird die Applikation nicht mehr richtig 
ausgeführt, da ständig Interrupts anliegen. Ich habe den LPC mit 60 MHz 
am laufen und einen 1 µs TimerInterrupt um meine Appl. Zeitgesteuert 
ablaufen zu lassen.
Ich habe natürlich den MAM schon ausprobiert, aber trozdem funktioniert 
es nicht. Hat von euch noch jmd eine Lösung ?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:
> ausgeführt, da ständig Interrupts anliegen. Ich habe den LPC mit 60 MHz
> am laufen und einen 1 µs TimerInterrupt um meine Appl. Zeitgesteuert
> ablaufen zu lassen.

Lächerliche 60 Zyklen Interruptrate, vergiß es.
Für nen RISC sind 60 Zyklen nur Pinats.
Außerdem macht er erstmal noch ne Menge Getöse bein Betreten und 
Verlassen des Interrupts.

Je nachdem, wieviel der Timerinterrupt machen muß, solltest Du nicht 
unter 1000 Zyklen gehen, damit das Main und andere Interrupts auch noch 
etwas CPU-Zeit abkriegen.


Peter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:

> ausgeführt, da ständig Interrupts anliegen. Ich habe den LPC mit 60 MHz
> am laufen und einen 1 µs TimerInterrupt um meine Appl. Zeitgesteuert
> ablaufen zu lassen.

Entweder Timer-Interrupt mit zur Geschwindigkeit des Controllers 
passender Rate laufen lassen, oder einen Controller mit zur Timer-Rate 
passenden Taktfrequenz verwenden. Alle 60 Takte, also ein Interrupt pro 
ungefähr 30 Befehle, ist jedenfalls ziemlich krass.

Rechne mit einer Grössenordnung von 50-150 Takten für einen Interrupt.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok.... das hab ich mir auch schon gedacht, denn wenn ich die Zeit des 
Int nur ein klein wenig größer mache funzt es, meine Arbeitskollegen 
meinen das muss funktionieren. Ich brauche auch die kleine Auflösung.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Interrupts liegen "staendig" an?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu langsam... :)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:

> ok.... das hab ich mir auch schon gedacht, denn wenn ich die Zeit des
> Int nur ein klein wenig größer mache funzt es, meine Arbeitskollegen
> meinen das muss funktionieren. Ich brauche auch die kleine Auflösung.

Wollen deine Kollegen dich loswerden?

Für solche Raten: für's Zeitkritische den FIQ in Assembler verwenden. In 
C dürfte sich alles unter 5-10µs über kurz oder lang rächen.

Und lege den Interrupt-Handler ins RAM. Das ist nun einmal schneller.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich definieren dass der Interrupt Handler im Ram liegt, und wie 
funktioniert das mit dem FIQ, gibts da auch ne Liste wo ich die Adressen 
der Interrupts eintragen kann ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt nach vollständiger und bedingungsloser Ahnungslosigkeit über ARM 
und deren Interrupts. Sorry, das hier runterzudeklinieren artet mir zu 
sehr in Arbeit aus.

Wie man Code in RAM verfrachtet obwohl sonst im ROM gearbeitet wird, das 
verrät möglicherweise das Handbuch des Compilers deines Vertrauens.

Wie man einen FIQ Interrupt schreibt, das verrät hoffentlich das 
Handbuch des Compilers deines Vertrauens. Und was ein FIQ ist, verrät 
ein ARM Handbuch.

Und wo die Interrupt-Vektoren stehen, das verrät das Handbuch (a) von 
ARM und (b) vom verwendeten Controller (bei normalen vektorierten IRQs).

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, wie Du ja schon gemerkt hast, habe ich vorher nie was mit Arm 
gemacht, nur mit Atmel, NEC, und TriCore, womöglich habe ich noch einen 
oder zwei Typen vergessen. Ich arbeite aber bereits seit 2 Jahren im 
Bereich Embedded Hard und Software, deshalb bin ich nicht ganz 
Ahnungslos ;-) . Du solltest ja auch nicht alles runterdeklarieren, 
sondern eher ein paar Stichworte in den Raum werfen. Ich brauch niemand 
der mir meine Arbeit macht, nur jemand der mir hilft wenn er das will 
;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann sollte dir eigentlich klar sein, dass dies ohne Kenntnis der 
Entwicklungsumgebung eine einwandfrei funktionierende Kristallkugel 
voraussetzt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nützlich: http://www.arm.com/documentation/books.html:
- ARM Architecture Reference Manual
- ARM System Developer's Guide

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss sagen meine Kristallkugel funktioniert ganz gut, ich hab 
rausgefunden wie der FIQ funzt, was pro Int ein Bit setzen heisst. Und 
wie ich die INTRoutine ins Ram bekomm hab ich auch gefunden. ----> hilft 
aber nix.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du mit dem GCC arbeitest, kannst du das verlagern ins RAM mit 
"__attribute__ ((section(.ram)))" machen, wobei "ram" natuerlich ersetzt 
werden muss mit deinem namen fuers RAM aus dem Linker.

Autor: ARM für Arme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hilft das dir nicht?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:
> ok.... das hab ich mir auch schon gedacht, denn wenn ich die Zeit des
> Int nur ein klein wenig größer mache funzt es, meine Arbeitskollegen
> meinen das muss funktionieren.

Die ARM haben einen entscheidendeen Unterschied zu vielen anderen MCs, 
nach nem Interrupt kann sofort wieder ein Interrupt ausgeführt werden!
D.h. kommen die Interrupts zu oft, wird das Main nicht langsamer, 
sondern steht total.
Daher ist es extrem wichtig beim ARM, daß immer reichlich Zeit zwischen 
2 Interrupts ist.
Ich stimme daher A. K. zu, vergiß alles kleiner 5-10µs.


> Ich brauche auch die kleine Auflösung.

Was willst Du mit ner kleinen Auflösung, wenn Du keine Zeit hast, damit 
zu rechnen?
Ein Interrupt, der nur die 1µs hochzählt, ist ziemlich nutzlos.


Peter

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da fehlt mir was!?
Im Debug von RAM tuts, wenn die Routine aber normal im RAM liegt bei 
Ausfuehrung tuts nicht!?
Uebrigens, eine Ausfuehrung aus dem RAM ist nur ca. 5-10% schneller als 
vom Flash, vorausgesetzt das MAM ist richtig initialisiert.
Nur zum Spass, nicht fuer die Serie geeignet, dreh doch mal die PLL von 
Faktor 5 auf Faktor 6, dann laeuft der Chip mit 72 MHz, sollte er 
normalerweisse tun, wenn er nicht gerade in einer heissen Umgebung 
sitzt. Falls es dann tut, koennten ASM Optimierungen helfen.
Soweit habe ich versucht zu helfen, jetzt kommen die echten Fragen.
Was um alles in der Welt soll mit einer Taktrate von 1MHz abgefragt 
werden? Wenn da tatsaechlich Daten kommen, wer soll sich wann darum 
kuemmern was da kam? Also mein Vorschlag bei einer solchen Frequenz 
waere Timer-unterstuetzes Polling. Gar nicht in einen Interrupt gehen, 
der Micro kann sowieso nichts anderes mehr tun, sondern das 
Interrupt-Flag des Timers Pollen und jeweils die Abfrage dann einleiten, 
das nimmt den Interrupt Overhead beinahe komplett raus.
Nur so eine Idee!

Robert
p.s. So schicke Interrupts wie beim TriCore wirst Du sonst nirgends auf 
irgendwelchen Micros finden. Hat ein Freund von mir designed ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel wrote:

> p.s. So schicke Interrupts wie beim TriCore wirst Du sonst nirgends auf
> irgendwelchen Micros finden. Hat ein Freund von mir designed ;-)

Schon mal beim Parallax Propeller reingesehen? Einfach einen der 8 Cores 
derart zeitkritische Dinge pollen lassen. Da ist auch eine Zeitauflösung 
unterhalb 1µs drin, und zwar deterministisch.

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal genau schauen, ob MAM und alle Zeiteinstellungen/Takte 
tatsächlich auch 'schnellstmöglich' eingestellt sind. Das MAM hilft - 
sofern richtig in Erinnerung - nur dabei ein paar Speicherworte 
vorauszuschauen und diese schnell bereitzustellen, bei Sprüngen 
"querbeet" im Flash also nicht das Allheilmittel.

Wenn die Anwendung 'im RAM' läuft aber 'im Flash' nicht 
zufriedenstellend, sind die Chancen nicht so schlecht, dass man die 
Software so anpassen kann, dass sie aus dem Flash startet aber nur Teile 
des Programmcodes 'aus dem Flash' ausgeführt werden. Hinweis betr. 
'Auslagerung' zeitkritischer Routinen ins RAM wurde ja schon gegeben. 
Wenn es tatsächlich nur der Timer-Interrupt und dessen Behandlung ist 
und nicht auch der Rest der Anwendung 'bremst', kann man für die 
Interruptbehandlung eine zur 'RAM-Debug-Konfiguration' vergleichbare 
Einstellung nachbilden. Beim Start:
- Exception-Vector-Table ins RAM kopieren
- Interrupt-Handler ins RAM kopieren
- Remap aktivieren

Da schon auf FIQ "umgestellt": den FIQ-Handler kann man direkt hinter 
den Vector-Table schreiben und spart sich evtl. noch einen Sprung.

Evtl. müssen noch weitere Teile der Anwendung ins RAM ausgelagert 
werden, falls nicht nur der Interrupt und dessen Behandlung bremst.

Wie das alles konkret funktioniert? Vgl. Beitrag von A.K. 9:48.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A.K. (off topic)
Ich kenne den Propeller nicht, allerdings hat der TriCore auch einen 
zusaetzlichen Prozessor drauf, der zeitkritische Transfers erledigt, in 
Echtzeit, single cycle bei Geschwindigkeiten > 100 MHz, ein RISC mit 
hochspezialisierten Befehlen.

Die TriCore Architektur ist toll aber fuer sehr viele Dinge etwas 
kompliziert. Da geht es mir aehlich wie die ewige AVR <-> ARM 
Diskussion. TriCore deutlich performanter als ARM7  ARM9  M3 ABER auch 
deutlich komplexer. Also wer tolle Interrupt Performance zusammen mit 
Timern braucht, die eines Programmierers (Alb)Traum sein koennen, dann 
TriCore.

Der Abschuss belibt fuer mich immer noch der Timer-Block mit bis zu 96 
Timern und ca. 200 Seiten im Manual ;-) Fuer manche ein Traum, fuer 
andere schlafraubend.

Robert

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Abschuss belibt fuer mich immer noch der Timer-Block mit
>bis zu 96 Timern und ca. 200 Seiten im Manual ;-) Fuer manche
>ein Traum, fuer andere schlafraubend.


Ach, das erinnert mich doch wieder an die schönen Zeiten mit der 
Programmierung der Motorola TPU, das war auch so ein komplexes Teil...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja Einfach, nur 2 Seiten je Timer... ;)

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute.... das erste Problem ist ja schon ne Zeit behoben.... aber 
jetzt tauch ab und zu ein neues auf der Abort_Handler ???? Im Dateblatt 
hab ich dazu nicht viel gefunden ausser das es einen DataAbortHandler 
und einen PrefetchAbortHandler. Wie kann ich rausfinden warum der 
Zuschlägt, bzw. wie kann ich das Problem umgehen ?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:
> Hallo Leute.... das erste Problem ist ja schon ne Zeit behoben.... aber
> jetzt tauch ab und zu ein neues auf der Abort_Handler ???? Im Dateblatt
> hab ich dazu nicht viel gefunden ausser das es einen DataAbortHandler
> und einen PrefetchAbortHandler. Wie kann ich rausfinden warum der
> Zuschlägt, bzw. wie kann ich das Problem umgehen ?

Hier gibt's einen längeren Artikel der das erklärt (Testobjekt: LPC2148)
http://www.embedded.com/shared/printableArticle.jh...

Autor: Hartmut Schirra (hartmut)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,
der DataAbortHandler wird dann aufgerufen, wenn ,wie im Datenblatt 
beschrieben, man einen Zugriff auf einen "verbotenen" Speicherbereich 
durchführt.

Das bedeutet:
Wenn der Aborthandler nur "ab und zu" auftritt, haben wir eine Funktion 
die wir nur "ab ud zu" aufrufen, in der der böse Zugriff erfolgt, oder 
wir haben ein Zeigerproblem, bei dem die Adressberechnung nur "ab und 
zu" danebengeht.

> ...., bzw. wie kann ich das Problem umgehen ?

- keine Zeiger
- keine Fehler bei der Zeigerberechnung
- intensiver Blick auf den Quellcode, unter Zuhilfenahme eines
  Kommilitonen (die sehen meist den abgestorbenen Baum im Wald)
- NXP kontaktieren und eine Änderung im Silizium anmahnen, damit alles
  was vor der Exception passiert ist, in einem Zwischenspeicher abgelegt
  wird (das würde uns allen helfen)

Um was gehts eigentlich in der Aufgabe? Warum muss man denn einen 1us 
Interrupt bedienen?

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.