(Atmel-) Mikrocontroller: Interrupts und "lange" ISRs

Ja, NEVER CHANGE A WINNING TEAM!

Jedoch in FORTH braucht man i.a. nur 1-3 Tage um es auf einen völlig anderen Prozessor umzusetzen. Die FORTH Engine besteht aus nur knapp 30 Low Level (Maschinensprache) (sog. Primitives) Routinen und die sind recht einfach, da alle nur eine kleine Sache erledigen. z.B. @ (fetch) hole einen Wert von einer Adresse die auf dem Stack liegt und gib den statt dessen auf dem Stack zurück. Alles oberhalb der Primitives ist normalerweise HLL, also auf 'allen' Maschinen gleich, solange es da keine speziellen Dinge mit der Peripherie gibt. (also 1 Tag AUfwand bis 3 Tage)

Für Z80 z.B. als @ primitive sowas wie: CODE @ HL POP DE,(HL) LD DE PUSH RET ENDCODE

Ups, FORTH hat noch die Hürde UPN, wer die nicht überwindet, wird es nie verstehen. Auch nicht warum die hp Taschenrechner so genial waren (und immer noch sind) Mein hp 16C hilft mir nach über 40a immer noch täglich. IIRC erst mit dem 2. oder 3. Satz Batterien. Ja damals(tm) war hp noch ein excellenter Laden, die wussten, was sie machten.

Ich schrub extra Maschinensprache, nicht ASS, denn es gibt auch CPUs, die FORTH (Primtives) als Maschinensprache haben, da ist die Engine sehr leicht zu erstellen. Und kann fliegen durch Raum und Zeit, Rosetta und Philae lassen grüssen.

Ein weiterer Vorteil in FORTH, man kann nix verwenden, was nicht vorher deklariert ist, es gibt keinen Linker, der einen linkt!

FORTH ist Interpreter und Compiler gleichzeitig, muss man nicht verstehen, ist aber genial. Als Anfänger bloss keinen Kopp darüber machen (viel mir schwer), einfach nur machen. Das Verständnis, wann compiliert und wann interpretiert wird, trifft einen eines Tages wie ein Blitz und dann geht die Programmierer Sonne auf und man will nix anderes mehr.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Ja, die Microchip SAM C20 können es auch. Cypress hat was mit 8 Pins im Angebot. Lange Zeit aber eher einzelne Exoten und es sah sonst meistens so aus:

Wie Johannes geschrieben hat wird das vermutlich schon irgendwann den

Nimm als Beispiel 12V oder zwei AA-Zellen als Supply. Mehrere Regler oder externe Transistoren sind nicht schön.

Am 15.08.2019 um 13:53 schrieb Wolfgang Allinger:

Hmm, welches FORTH hast Du da (für Skripte...) verwendet?

DoDi

Am 15.08.2019 um 14:26 schrieb Wolfgang Allinger:

Aha, das beantwortet meine Frage schon fast. Heute versteht man unter FORTH eine Compilersprache (embedded...), ohne Interpreter.

Das FIG FORTH habe ich auch auf etlichen Mikroprozessoren implementiert, war wirklich ein Klacks. Aber wie Du damit auf Echtzeit und parallele Prozesse (Interrupts...) kommst, ist mir Echt schleierhaft.

DoDi

Am 13.08.2019 um 09:33 schrieb Ralph Aichinger:

Auf einem 8051 hab ich aber sowas ähnliches mal gemacht:

Wenn in der IRQ Routine festgestellt wird, dass die aufwändige Berechnung gemacht werden soll, die Adresse einer normalen Subroutine auf den Stack schreiben, dann einen RETI ausführen woraufhin das Programm nicht dorthin springt, wo INT das Programm unterbrochen hat, sondern in die Subroutine deren Adresse jetzt auf dem Stack steht. Jetzt kann der IRQ erneut aufgerufen werden während die aufwändige Berechnung läuft. Wenn die Berechnungen fertig sind mit RET dorthin zurückspringen, wo der erste INT aufgetreten ist.

Ich glaube, das Status Register musste man auch noch auf den Stack schreiben. Genau weiß ich das nicht mehr.

War damals in Assembler, in C auf dem AVR würde ich da heute die Finger von lassen und das so machen, wie weiter oben von anderen Postern beschrieben.

Am 15.08.2019 um 20:22 schrieb Stefan:

Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu erlauben. Wenn die Rechnerei lange genug dauert, stürzt das irgendwann mit Stack Overflow ab, so oder so. Andernfalls baut sich der Stack wieder ab, so oder so.

DoDi

Nein, FORTH ist immer Interpreter und Compiler, wenn man nicht will, dass der Endanwender die Macht erhält, dann wird der Outer Interpreter verrammelt (also das Eingabe Prompt) und wenn man das in ein kleines ROM/ FLASH pumpen muss, dann kann man auch noch das Wörterbuch samt Compiler, Assembler wegmachen und nur noch der Inner Interpreter bleibt drin. Das ist Aufgabe des META-Compiler, der erzeugt auf dem HOST das image für das TARGET, das Target kann, muss aber nicht kastriert sein.

Ganz spannend wird es im Umbilcal-Mode (Nabelschnur Mode), dann ist die gesamte Umgebung auf dem Host und im Target ist ein kleiner Inner- Interpreter, der vom Host über Nabelschnur (früher Serielle Schnittstelle, heute USB, Ethernet, LAN, WAN...) bedient wird, Du hast also sowas wie Compiler Interpreter auf Host und Target verstreut. Wenn Du dann noch etwas hast, um gleichzeitig das Flash im Target neu zu befüllen, geht die Lutzi ab. Das Target ist dann voll unter Deiner Fuchtel und klomuniziehrt mit Dir, jedenfalls solange Du die Sache im Griff hast. Wenn nicht RESET :)

Das ist unglaublich komfortabel und produktiv, Du merkst die meisten Fehler sofort und kannst sie ausbessern, noch bevor Du den Faden/Gedanken verlierst. Mit Edit/Compile/Link Orgien haste meist nicht mehr im Kopp, was gerade wichtig war und suchst Dir nen Wolf, weil der Linker Dich gelinkt hat. NO-MEN ist O-MEN,

CODE END-CODE sind Deine Freunde. Dann die jeweiligen Startadressen in die IR-Vectoren oder was auch immer setzen und feddich is die Laube.

Du kannst auch langsame Sachen zum Versuch mal in HLL schreiben, bissu weist, was Du machen musst, danach ggf. über CODE verschnellern.

Sh, auch Paralell Faden FORTH 1.

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich:

Aber wie schon geschrieben: Einfacher ist es, solche Dinge in eine Idl-Routine zu verlegen, d.h. das Programm besteht aus einer Hauptschleife in der zeitunkritische Dinge zyklisch abgearbeitet werden und INT-Routinen, in denen der Rest passiert. Eine INT-Routine kann dann ein Flag setzen, mit dem der Hauptschleife signalisiert, dass etwas berechnet werden soll.

Am 15.08.2019 um 09:27 schrieb Rainer Knaepper:

Früher hatten wir einen Oszi zum Betrachten von Signalen, heute einen PC. Oder wie verschickst Du Deine Mail? ;-)

Abgesehen davon habe ich auch schon einen LA mit einem Arduino und LCD Display programmiert, liegt ja beides hier herum.

Ich habe zwar auch keinen direkten Bedarf, habe mir aber schon überlegt, interessehalber die 20-30€ zu investieren.

DoDi

Am 16.08.2019 um 06:56 schrieb Stefan:

Das verstehe ich nicht. Es liegt doch weniger am Prozessor als an der reentrant Programmierung des Handlers.

DoDi

mit dem entsprechenden Fabrikaten der Hersteller kompatibel ist.

Extras (serielle Dekodierung etc.) wie bei Rigol freigeschaltet habe ;-)

-- mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker WEB:

Am 16.08.2019 um 09:06 schrieb Hans-Peter Diettrich:

Weiß ich nicht genau. Ich habe da Erfahrungen mit dem 8051 in Assembler. Da wurde der jeweils aktivierte INT wieder scharf geschaltet, wenn ein RETURN_From_INT ausgeführt wurde. Wenn die INT-Routine zu lang war, konnte der folgende INT verloren gehen.

Mit AVR habe ich sowas nicht gemacht weil ich den eh nur in C programmiere und solche Dinge wie vom OP beschreiben nicht nötig waren.

Beim STM32 muss/kann man auch in "C" das entsprechende Flag selber frei geben bevor man die INT-Routine verlässt, d.h. es müsste möglich sein, reentrante Routinen zu schreiben. Hab ich bisher vermieden.

Der Einsatz von 3V3 uCs ist nicht wirklich ein Problem, bzw. der Mangel an Auswahl von 5V ARM, ein eventueller extra LDO 5->3.3 MIC5504 kostet in der Apotheke nur 0.07 cent (bei 100st)

System Basic chips (KFZ 12V) unterstützen ebenfalls wahlweise

Bei zwei AA würde ich ohnehin eher zu einem uC greifen, der nicht bis 5.5V geht, sondern bis max 3V3 dafür deutlich runter in Kombi mit z.B. adjustable LDO AP7330

Falls mehrere ICs 5V VCC benötigen, dann würde ich einen passenden

Bei meinen uC gesteuerten Buck Platinen nehme ich natürlich eine rote Signal LED, um empty Batt Warnung anzeigen zu können ;-) Ob da jetzt weiss schöner wäre - möglich aber nicht sinnvoll. Da drei AAA (NimH) für die w P-LED direkt zu knapp sind habe ich 4 AAA.

Man kann ja kurz vorher anrufen *duck*

Hans-Peter Diettrich schrieb:

Heute kannst du mit dem Oszi surfen und mailen, viele haben ein bekanntes Betrübssystem.

Am 21.08.19 um 20:39 schrieb Rolf Bombach:

Das wird bei Handfunkgeräten durchaus so gemacht. Man sieht 3* pro Sekunde für 5 ms nach, ob überhaupt etwas empfangswürdiges da ist und schaltet erst dann den ganzen Empfänger ein.

Gerhard Hoffmann schrieb:

Ebenfalls bei Wetterstationen mit Funk-Außensensor. Der Außensensor sendet dabei z.B alle 5 Minuten ein neues Telegramm. Da der Empfänger das weiß, schaltet er sich in einem Zeitfenster z.B 10s vor dem erwartetem Telegram ein, bis entweder das Telegramm empfangen wurde oder die max. Wartezeit abgelaufen ist. Deshalb muß nach einem Batteriewechsel auch eine neue Suche des Sensors am Empfänger gestartet werden, der dann für z.B. 10 Min auf ein Telegramm wartet und nach Empfang eines Telegramms wieder im Zeittakt weiterarbeitet. So ist es bei 2 meiner kleinen Wetterstationen implementiert.

- Heinz

Ach, und wie "sieht man" denn nach? Ach so, dazu schaltet man den Empfänger ein? Wer hätte das gedacht!