Hi Werner,
ui, das wäre schlecht!
Es handelt sich um eine Schrittmotorsteuerung für 3 Achsen, der Impuls soll ein 12Bit Datentelegramm via SPI an einen Controller senden, fast mehr nicht.
Wenn ich in der IR nur auf den Interrupt reagiere, den I/O Port einlese und dann in der Vordergrundschleife die gesetzten Flags abarbeite (= 12 Bit SPI pro aufgetretenem IR), sollte das doch in 400 Zyklen machbar sein, oder?
Es darf nur kein IR verloren gehen, wenn die alle mit einem Delta-T abgearbeitet werden, aber in der richtigen Reihenfolge, dann wäre meine Welt wieder in Ordnung...
Gruß Wolfram
@Georg-Johann:
..puh, das erleichtert mich etwas, ich bekam schon nen Schrecken.
Also dann halte ich mich kurz und mache mir intensiv Gedanken um die optimale Struktur.
Die weiter oben angegebene IR-Belegung (=Priorität (in Grenzen)) sollte dann doch i.O. sein, was schätzt Du?
Danke für die vielen Anregungen, auch nochmals an Werner!
Gruß Wolfram
Hallo Georg-Johann,
> Das sollte selbst mit Bascom gehen, oder ist das wiklich so übel?
übel nicht, aber man muß schon ganz genau aufpassen was man wie verwendet.
Was z.B. bereits absolut tödlich ist, ist die Verwendung von Interrupts ohne "nosave". 32 Register pushen a 2 Takte, 32 Register popen a 2 Takte macht 128 Takte nur für einen einzigen Interruptaufruf.
Und wenn man nosave verwendet, dann kann man die Interrupt Routine imo auch gleich in Assembler programmieren. Dann weis man wenigstens welche Register man pushen/popen muss.
Bei Interesse, zähl einfach mal nach, wieviele Takte ein simples 'incr Var' benötigt.
Das hat nix damit zu tun, das Basic schlecht oder übel währe, zum incr Register kommt schlicht das Laden und Speichern der Daten der Variable hinzu. C ist da auch nicht schneller, nur lässt sich in C einfacher direkt mit Registern arbeiten (wobei ich von C keinerlei Ahnung habe).
> In 400 Takten sind schon Weltreiche erblüht und wieder versunken...
Aber nicht in einer Hochsprache.
@ Wolfram
> Wenn ich in der IR nur auf den Interrupt reagiere, den I/O Port einlese
> und dann in der Vordergrundschleife die gesetzten Flags abarbeite (= 12
> Bit SPI pro aufgetretenem IR), sollte das doch in 400 Zyklen machbar
> sein, oder?
Doch, das ist machbar, zumindest was das Datenhandling angeht.
Um Deine 3x12bits über den SPI zu schieben brauchst Du aber eine beträchtliche Datenrate auf der seriellen Leitung.
36bits alle 20µs sind immerhin 1.800.000 baud. 'nen Kabel kannst Du bei den Datenraten imo nicht mehr dazwischenhängen. Das wirst Du (imo) nicht ohne weiteres stabil ans laufen bekommen.
Ciao,
Werner
P.S. mit 'IRAM' lässt sich eine Bytevariable imo direkt einem Register zuweisen. (Stichwort TINYs ohne eigenes RAM). Leider ist das in der Hilfe mehr als dürftig erklärt. Ob IRAM auch bei nicht TINYs unterstützt wird? -Keine Ahnung!
Ok, das mit dem Aufwand fürs sichern ist klar.
Ich kann ja mal die IR-Routine in mein Basic-Programm als ASM-Quelle einbinden und bei niedriger Taktrate testen.
Da der 88er ja bis zu 10MHz SPI Takt fahren kann, sollte das auch kein Problem sein.
Die anzusteuernden Chips befinden sich auf der Platine, bzw. optional max. 20cm über ein Kabel entfernt, wobei diese Option noch nicht sicher geplant ist.
Auch der SPI Transfer scheint mir in ASM nicht sooo der Knackpunkt zu sein, ich denke, ich kann es ja mal versuchen.
Gruß Wolfram
P.S: Was hat es mit dem IRAM auf sich?
Hallo Wolfram,
> Was hat es mit dem IRAM auf sich?
AVRs ohne eigenes RAM können Variablen nur in den Registern ablegen.
Die Definition solcher Register-Variablen geschieht mit
"Dim Var As IRAM Byte"
Manipulationen an solchen IRAM-Variablen müssten in Bascom eigentlich mit voller AVR-Geschwindigkeit ablaufen, da die Variablen weder geladen noch gespeicher werden müssen. Ein INCR Var braucht dann tatsächlich nur 1 Takt und nicht 8 oder 10 Takte wie bei normalen Variablen.
Nachteil, es sind nur 32 Variablen möglich und der Befehlssatz ist stark eingeschränkt. (Vermutlich gehen nur die Befehle, die ein 1:1 pendant in Assembler besitzen.)
Die Bascom Hilfe schweigt sich dazu leider fast vollständig aus.
Ein bischen was findet man in den Samples zu den Tiny AVRs.
Ciao,
Werner
Ok, für Bascom werd ich mich hier nicht aus dem Fenster hängen
Wenn "nur" eine Ausgabe via SPI zu machen ist, kannst du weiter parallelisieren über die SPI-Hardware. Das erste Byte schreibst du ins SPI und lässt nen IRQ triggern, in dem das zweite Byte nachgeschoben wird. Den SPI-Interrupt würd ich für Interrupts offnen, um die Latenzzeit zu verringern und es für die externen so transparent wie möglich zu halten.
Das erfordert allerdings ne genaue Planung, damit ein externer IRQ nicht zwischen das 1. und 2. Byte was dazwischenfummelt und die einzelnen ISR s sich verstehen. Den SPI kannst du bis F_CPU/2 Takten, also bis 10MHz (kein Problem für die meisten HW-SPIs) bei 20MHz CPU-Takt. Das ist eine theoretische Obergranze von über 1MByte/Sek. Kommt eben drauf an, wie fix deine Software ist.
Nochwas zu "Hochsprache". Hochsprache bedeutet nicht automatisch, daß es langsam ist. Das hängt davon ab, was unter der Oberfläche an Optimierung passiert -- oder eben nicht passiert. Es ist z.B. überflüssig, immer alle 32 Register zu sichern (für Compiler-Entwickler ist es natürlich das bequemste
Disclaimer: none. Sue me.
Hmmm, sorry, aber da bin ich nicht ganz mitgekommen..
Wenn "nur" eine Ausgabe via SPI zu machen ist, kannst du weiter parallelisieren über die SPI-Hardware. Das erste Byte schreibst du ins SPI und lässt nen IRQ triggern, in dem das zweite Byte nachgeschoben wird. Den SPI-Interrupt würd ich für Interrupts offnen, um die Latenzzeit zu verringern und es für die externen so transparent wie möglich zu halten.
Kannst Du mir das noch mal erklären bitte?
Danke für Eure Hilfe!
Gruß Wolfram
Hallo Wolfram,
> Kannst Du mir das noch mal erklären bitte?
Du musst das SPI 2x mit Daten füttern um ein komplette Telegramm abzusetzen.
Um die Wartezeit beim Verarbeiten des Telegramms nicht unnötig zu vertrödeln sollst Du den SPI Interrupt verwenden.
z.B.
- Du prüfst ob der vorherige SPI-Transfer beendet ist. (SPIF Flag = 1)
- Du schiebst das erste Byte in den SPI und enablest den SPI Interrupt (SPIE Flag = 1)
- Im SPI Interrupt schiebst Du das 2 Byte hinterher und disablest den SPI Interrupt. (SPIE Flag = 0)
Sobald SPIF, für das Hauptprogramm sichtbar, 1 wird, ist ein Telegramm komplett übertragen worden. (Zwischen den 2 Bytes eines Telegramms wird das SPIF Flag ebenfalls einmal kurz 1, der Atmel springt dabei aber sofort in den SPI-Interupt.)
Durch das verlagern des 2. Bytes in den Interrupt kannst Du erreichen, das die Telegramme nicht zerstückelt werden können und gleichzeitug Dein Hauptprogramm weiterarbeitet. Der SPI Transfer läuft damit parallel zum Programm praktisch komplett in der Hardware.
Du brauchst dann noch einen Buffer, der bis zu 3 Telegramme aufnehmen kann. (3 Telegramme pro 400-Takte-Zyklus)
Anm. ggf. macht es sinn, auch das Buffer-Handling in den SPI Interrupt zu verlagern.
Kommen eigentlich immer 3 Telegramme, oder können auch nur 2 oder 1 Telegramm pro 400-Takte-Zyklus kommen?
Ich denke, dass wars was Georg-Johann gemeint hat.
Ciao,
Werner
Moin,
danke Werner, werde es mir mal langsam durch den Kopf gehen lassen, denke aber, daß ich noch dahinter komme und es so genau verstehe, daß ich es umsetzen kann.
Habe ja bisher nur in Bascom programmiert und die Hardware für Softwareprofis vorbereitet.
Dieses hier muß ich jetzt aber selber programmieren, bin aber eigentlich guter Dinge....
Es ist eher unwahrscheinlich sondern der Worst case, daß 3 Telegramme innerhalb von 400 Zyklen raus müssen.
Viel wahrscheinlicher ist es, daß eher 1, selten 2, grenzwertig 3 abgearbeitet werden müssen...
Gruß Wolfram
Berechtigungen
Zitieren
Lesezeichen