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

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article grk27uFakibU1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 14.08.2019 um 12:44 schrieb Wolfgang Allinger:

Es sei denn, Du hast sowas wie JBC (8051), dann ist das sauberer und
schneller, setzt aber voraus, dass Du genügend häufig das Bit abfragst,
nicht das da mal 2 IRs waren.

Hmm, auf welchen Controllern soll das unsauberer oder langsamer sein?

WIMRE hatte der Z80&Co kein JBC
War damals(tm) eine Besonderheit im 8051, die vieles einfacher und besser
machte. AFAIR ging das sogar mit PortBits. Leider gabs kein Bit_toggle.
Und beim Port update gabs auch irgendwas als Falle für IR. HIV, Han Ich
Verjässe.

JBC ist als atomarer Befehl nicht unterbrechbar. WOWEREIT.

Du hast atomare Zugriffe nicht verstanden :-(

Egal, für mich ist Theorie nicht (mehr) wichtig. Muss(te) damit keine
Brötchen (mehr) verdienen. Ich musste meine Sachen immer rechtzeitig und
gut zur Tür rausbringen. Was mir eigentlich lt. meinen Kunden immer gut
gelungen ist.

Wolf(wenigTheorieaber)gan(zvielPraxis)g


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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article grk2okFank4U1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 14.08.2019 um 13:15 schrieb Wolfgang Allinger:

On 14 Aug 19 at group /de/sci/electronics in article
gri0m9Friq2U1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter
Diettrich) wrote:

Wenn schon Debuggen dann gleich richtig mit einem Logik-Analysator. Ist
weit billiger als ein Scope und erlaubt bessere Diagnosen.

Stimmt, so hab ichs auch immer gehandhabt... LA billiger? damals(tm) eher
nicht...
Im DIY als Vorsatz vor den Oszi

Bei meinen damaligen Aufgaben hätte ich das in ECL gebraucht, war zu teuer
zum frickeln. Und später nicht mehr gebraucht, dank anderer Vorgehensweise
mit FORTH.

..bis ich FORTH entdeckt habe, seitdem höchstens noch 2-3x einen LA im
Einsatz gehabt. Nachdem ich FORTH dann richtig(?) kapiert habe, brauchte
ich keinen LA mehr (konnte mir dann in meinem Ing.Büro diese Investition
sparen

In Echtzeit (nebenläufige Prozesse...) kann man mit FORTH genausoviel
Mist bauen wie mit anderen Sprachen.

Ja natürlich, und in FORTH sogar besonders schnell und einfach... hat aber
auch die grosse Chance, das sehr schnell rauszufinden. i.a. in Echtzeit

Ich bin harte Echtzeit Hardcore Assembler Programmierer gewesen, immer an
der Geschwindigkeitsgrenze, Umfang und Zeit waren meine größten Gegner.
Bin immer siegreich vom Platz gekommen, manchmal mit einem blauen Auge,
aber nie verloren. D.h. auch in hochsensiblen Bereichen, MIL, Offshore,
KKW, Stahlwerke, Medizin, Verkehr, eX, Raffinerien...

Mit FORTH hab ich dann das angenehme mit dem nützlichen vereinen können.
FORTH ist METAsprache, Scriptsprache, HLL und ASM, und zwar alles in
einem, so schnell mein Hirn und Finger wollen.

BTW FORTH kennt keine Objects, Linker (der einen eh immer linkt, daher der
Name Hase und BinLibs, nur Sourcen.
Letzteres wohl der Hauptgrund für die Heimlichtuer, es nicht zu benutzen.
Dann kann jeder lesen und sehen, wenn man Scheisse gebaut hat.

Muss der Kunde halt entscheiden, ob er nur ein Kompilat kauft oder alle
Quellen. FORTH ist da völlig offen, es geht alles.





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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 15 Aug 19 at group /de/sci/electronics in article d65ed9e357.assel@nuconverter.de
<joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote:

In message <grk2vbFaopuU1@mid.individual.net
Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

Am 14.08.2019 um 17:42 schrieb Rafael Deliano:
Ich habs mirs mal für den (MC68HC908)-GP32 8 Bit Controller
den ich normalerweise verwende angesehen:

Der läuft mit seinem normalen 2,54MHz CPU-Takt.
Die 10MHz würden über Portpin einen 16 Bit Timer takten.

Das geht bei den Atmels nicht, wenn die ihre Eingänge (typischerweise)
mit dem Systemtakt synchronisieren.

Ja das ist das Problem wenn man als "Alter Experte" womöglich immer am
gewohnten Controller kleben bleiben will, weil man da womöglich Forth
einsetzen kann ;-)

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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

Joerg Niggemeyer wrote:

Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:

8-Bit MCUs nimmt man meistens auch gar nicht wegen der Architektur.
Wenn man eine Schaltung mit 5V laufen lassen möchte (z.B. weil 3.3V für
die InGaN-LEDs nicht ausreichen), dann ist es schon nett wenn die MCU
das direkt kann. Mit 32-Bit MCUs ist üblicherweise bei 3.3V Ende.

Sooo klein ist die Auswahl von 32bit ARM 5.5V Vcc nun auch wieder nicht.

z.B. Farnell KE0x Cortex M0+ 2.7-5.5V ca. 1 EUR/st (including RTC)

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:
<https://de.farnell.com/microchip/atsamd11c14a-ssut/mcu-32bit-cortex-m0-48mhz-soic/dp/2484375?st=Cortex%20M0>

Wie Johannes geschrieben hat wird das vermutlich schon irgendwann den
8-Bit Bereich verdrängen. Aber das dürfte noch eine Weile dauern.
Sieht wohl auch Microchip so, sonst hätten sie nach der Atmel-Übernahme
die AVRs auslaufen lassen können. Stattdessen bringen sie jetzt aber
neue Varianten auf den Markt (die sich die Peripherie-Einheiten mit
den PICs teilen).

Was spricht dagegen, eine (power-) LED aus einer höheren V zu treiben
als die MCU bei 3V3 oder kleiner ?

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

 

[Hans-Peter Diettrich]

Am 15.08.2019 um 13:53 schrieb Wolfgang Allinger:

FORTH ist METAsprache, Scriptsprache, HLL und ASM, und zwar alles in
einem, so schnell mein Hirn und Finger wollen.

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

DoDi

 

[Hans-Peter Diettrich]

Am 15.08.2019 um 14:26 schrieb Wolfgang Allinger:

Jedoch in FORTH braucht man i.a. nur 1-3 Tage um es auf einen völlig
anderen Prozessor umzusetzen.

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

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.

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

 

[Stefan]

Am 13.08.2019 um 09:33 schrieb Ralph Aichinger:

Jetzt habe ich folgendes Problem: Das ganze geht "meistens"
sehr schnell (Sekunden erhÜhen, fertig, Counter läuft alleine
auf 0 zurück). Bei vollen Minuten muß ich die Minute erhöhen,
das tut auch nicht weh.

Nur zu manchen Zeitpunkten (Jahresanfang Mitternacht GMT,
Anfang Sommerzeit, Schaltjahre, Schaltsekunden) muß ich
eventuell langwierigere Dinge machen. Gibt es außer
"ganz ganz sicher sein, daß die Berechnung keine Sekunde dauert"
noch MĂśglichkeiten wie man sowas abhandelt? Z.B. wie man den
zeitkritischen Teil (Sekunden, Minuten) vom weniger zeitkritischen
Teil (Stunden, Tage, Wochentag, Monat ...) getrennt abzuarbeiten?

Oder ist die Idee mit dem Interrupt Ăźberhaupt schlecht?

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.

 

[Wolfgang Allinger]

On 15 Aug 19 at group /de/sci/electronics in article grl5qvFi07iU1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 15.08.2019 um 13:53 schrieb Wolfgang Allinger:

FORTH ist METAsprache, Scriptsprache, HLL und ASM, und zwar alles in
einem, so schnell mein Hirn und Finger wollen.

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

Kannst jedes dafür nehmen, was auf entsprechende Umgebung zugreifen kann.

Ich hab z.B. ausführbare Schriftstücke an meine Kunden verschickt, also
z.B. startup_4712.src, das System hab ich so eingerichtet, dass es beim
Start in einem bestimmten Verzeichnis (START nach ner neuen Datei
gesucht hat, wenn es die gefunden hat wurde die einfach interpretiert/
compiliert und die Anlage war wieder auf dem neuesten Stand.

So konnte man Patches oder Versuche einspielen, so dass der Kunde die
Abläufe/Parameter anpassen konnte. Wenn er zB. ne Kalibrierung geändert
hatte konnte er damit arbeiten, wenn er wollte, dann einfach
"startup_4712.src FSAVE" (kurz für FileSave) tippern und ENTER. Beim
nächsten Start war es dann, als wenns immer schon so geplant war.

Wenns nix war, dann per Editor, zB. dem im benutzten FORTH eingebauten
oder einen externen nehmen und startup_xxxx.src verbasteln.

Und warten, bis der eingewiesene Programmierer oder der Allinger ne
angepasste exe lieferte.

FORTH ist halt ein Interpiler und Compreter gleichzeitig.

Die Kunden (häufig Maschbauer) waren begeister, wie einfach sie was
verfummeln oder probieren konnten.

kurzes langatmiges Gesabbel von mir:
Beispiel Anfrage: wir ham jetzt 999 Geräte die nach einer besonderen
Justierung justiert werden sollen, wie geht das? Ich hab denen dann eine
datei geschickt, wo die HLL Definitionen drinstanden. Konnte er dann beim
nächsten Start mit der Eingabe Typ999 starten, wenn er wieder ein paar
normale Geräte dazwischen fahren wollte, dann eben nur START eingeben bzw.
das als letztes Wort in die update_Typ999 reinfrickeln, oder wenns
dauerhaft bleiben sollte, dann eben \ (Backslash) START einflicken und
darunter die Zeile Typ999 reinschreiben. Falls doch wieder wankelmütig,
dann eben das Kommentarwort "\ " vor Start weg und gut wars.
Alles was FORTH im Eingabestrom (prompt OK ) liest, wird bei einem <SP>
oder EOL als Wort behandelt und im Wörterverzeichnis nachgeschlagen und
ausgeführt, wenns nicht gefunden wurde, wurde versucht es als Zahl zu
verwursten, wenn ja, dann wurde die Zahl auf den STACK gelegt und weiter
geparst, wenn nicht, weil BlaFasel nicht gefunden wurde, kommt ein
"Blafasel is undefined" , der STACK wird gelöscht und der Eingabe prompt
'OK ' erscheint wieder für einen neuen Try und Error

(Mausmelodie tüdel füdel und das war der Forth Outer Interpreter

Der Outer Interpreter ist einfach die Endlosschleife, die auf Keys wartet.
Mit dem einfachen Wort ":" name bla blu blubber ; wird der Compiler
eingeschaltet und versucht eine neue Definition 'name' zusammenzubringen,
falls der Eingabestrom nur definierte Sachen finden, passiert
of(f)ensichtlich nix, bis das Wort ';' den Compiler wieder ausschaltet und
die Endlosschleife (Outer Interpreter) wieder einschaltet und auf neue
Worte wartet. Sonst kommt halt "blubber" is undefined. Das ist die Colon-
Definition, also der HLL Compiler.

undefined? Ja stimmt, HIV han ich verjässe, also fix

: blubber tüdelfüdel Tschingerrassabum Mausmelodie ; <CR>

eintippern und das Problem ist hoffentlich behoben.

Dann blubber eintippen und beobachten Was passiert? War nix? Doch lieber

: blubber füdel fiep tröt ; <CR>

blubber is redifined OK

Äh, hüstel, wollemer nit
FORGET blubber<CR>

OK

und alles ist wieder sauber.

Ahh ja, und wie ist das kompiliert? Der Compiler setzt ins RAM an die
Stelle für den Eintrag name eine Liste mit den Anfängen von füdel fiep
tröt rein. Das Wörterbuch zeigt einfach auf den Beginn von name und
feddich is die Laube.

Und wie läuft dann so ein Proggie ab? Wenn das Wort im Eingabestrom
gefunden wurde, hampelt der Inner Interpreter eifach die aktuelle Liste
ab. Also eine Liste mit Verweisen auf Listen von Listen... Es wird also
solange die Aufgabe vor sich hergeschoben, bis irgendwann in diesem
gefädelten Code irgendjemand aufgerufen wird, der weis was damit
anzufangen ist und dann zurückkehrt hinter den letzten Aufruf.

Kannste Dir also etwa so vorstellen, wie eine Liste mit CALL 1234 CALL
4567 CALL 8134 ... vobei der CALL niht drinsteht, sondern nur die
Verweisadresse und der Inner Interpreter macht dann die CALLs.

Zack, so einfach ist FORTH.


Ein weiteres wichtiges Wortpaar ist CODE ... END-CODE das macht im Prinzip
das gleiche wie : ... ; aber eben in Assembler, das ist dann für Kenner
und Könner.

Der Anwender wird CODE END-CODE kaum brauchen, das mach dann ggf. ich oder
ein anderer Kenner.

Der Kunde schickt mir nur seine Latte von neuen :- Definitionen und sagt,
funzt alles, aber zu langsam, muss 3x schneller ablaufen. Ich frickel dann
interaktiv raus, wo wie die Zeit verplempert wird und verbessere das oder
schreib das Wort als CODE-Definition. Ist nur ein simples umkodieren, um
den Algorithmus brauch ich mich ja nicht zu kümmern, den hat der Kunde ja
schon als gut befunden. Macht die Sache unglaublich einfach. Meist sind
das nur wenige Stellen, die mit CODE getuned werden müssen. Und zum Test
wird halt eine oder mehrere Testschleifen definiert, wo die :- und die
CODE- Definition beide mit den gleichen Parametern aufgerufen und die
Ergebnisse verglichen werden, wenn abweicht, Schleifenabbruch und
weitersuchen, sonst kommt OK und alles ist womöglich schon ok.

Wer bisher durchgehalten hat: BRAVO nun kommt das ENDE bald




Auch sonstige Parameter standen in der Startup Datei

zB. Hubweg wurde mit der syntax

12,3 inch als Hubweg

festgelegt. Oh heute cm? kein Problem, dann eben

17,3 cm als Hubweg

eintippern, wg. mir erst mal zur Probe interaktiv, dann per editor in die
Start. Ja alle meine Projekte wurden als META Sprache in den jeweiligen
Anwender eigenen Fachsprache geschrieben, wegen mir auch in seiner
Landesprache. Ist praktisch Bestandteil von (Vollausbau) FORTH. Genauso
wie METAkompiler. Wenn ich die Fachsprache des Kunden kapiert habe, bin
ich auch einfacher auf seiner Ebene für Klärungen und ich habe vieles von
ihm zu seinem Nutzen gelernt und wir reden weniger aneinander vorbei.
WIN-WIN



So nun zum Schluss:

Schau mal nach Gforth für Windoof, Linux, Android, MAC oder was weis ich
noch alles. Ist eins der mächtigsten Systeme, das ich kenne.

Ich selber hab fast alles unter LMI PCF und F-PC gemacht. Gibs aber nicht
mehr. Nur für Windoof gibbet auch Win32Forth , auch ziemlich fettes Paket.

So genug für heute.
May the FORTH be with you!




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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 15 Aug 19 at group /de/sci/electronics in article grl5r0Fi07iU2@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 15.08.2019 um 14:26 schrieb Wolfgang Allinger:

Jedoch in FORTH braucht man i.a. nur 1-3 Tage um es auf einen völlig
anderen Prozessor umzusetzen.

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

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,

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.

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.

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

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Hans-Peter Diettrich]

Am 15.08.2019 um 20:22 schrieb Stefan:

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.

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

 

[Rainer Knaepper]

DrDiettrich1@aol.com (Hans-Peter Diettrich) am 15.08.19 um 05:44:

Am 14.08.2019 um 13:15 schrieb Wolfgang Allinger:

On 14 Aug 19 at group /de/sci/electronics in article
gri0m9Friq2U1@mid.individual.net <DrDiettrich1@aol.com
(Hans-Peter Diettrich) wrote:

Wenn schon Debuggen dann gleich richtig mit einem
Logik-Analysator. Ist weit billiger als ein Scope und erlaubt
bessere Diagnosen.

Stimmt, so hab ichs auch immer gehandhabt... LA billiger?
damals(tm) eher nicht...
Im DIY als Vorsatz vor den Oszi

Dann ist es aber nicht billiger, denn er kommt ja zum Oszi /hinzu/.

Meine Hobbyprojekte sind freilich zwölf Nummern kleiner, weshalb ich
nie über die zusätzliche Anschaffung eines LA nachgedacht habe. Um
herauszufinden, an welcher Stelle sich mein Progrämmchen verläuft,
reichte mir die Portpin/LED/Oszi-Methode bislang immer.

Rainer

--
Die Ente bleibt draußen...

 

[Stefan]

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

Am 15.08.2019 um 20:22 schrieb Stefan:

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.

Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu
erlauben.

Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann,
während er bereits abgearbeitet wird.

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.

Sowas funktioniert natĂźrlich nur, wenn der zeitliche Abstand zwischen
den seltenen Ereignissen, von denen der OP schrieb, niemals kĂźrzer wird,
als die Zeit, die man fßr die aufwändige Berechnung benÜtigt.

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.

 

[Hans-Peter Diettrich]

Am 16.08.2019 um 06:56 schrieb Stefan:

Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich:
Am 15.08.2019 um 20:22 schrieb Stefan:

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.

Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu
erlauben.

Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann,
während er bereits abgearbeitet wird.

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

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.

Da waren dann aber gewisse Leute anderer Ansicht, mir mußt Du das nicht
erklären.

DoDi

 

[Hans-Peter Diettrich]

Am 15.08.2019 um 09:27 schrieb Rainer Knaepper:

DrDiettrich1@aol.com (Hans-Peter Diettrich) am 15.08.19 um 05:44:
Am 14.08.2019 um 13:15 schrieb Wolfgang Allinger:

On 14 Aug 19 at group /de/sci/electronics in article
gri0m9Friq2U1@mid.individual.net <DrDiettrich1@aol.com
(Hans-Peter Diettrich) wrote:

Wenn schon Debuggen dann gleich richtig mit einem
Logik-Analysator. Ist weit billiger als ein Scope und erlaubt
bessere Diagnosen.

Stimmt, so hab ichs auch immer gehandhabt... LA billiger?
damals(tm) eher nicht...
Im DIY als Vorsatz vor den Oszi

Dann ist es aber nicht billiger, denn er kommt ja zum Oszi /hinzu/.

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.

Meine Hobbyprojekte sind freilich zwölf Nummern kleiner, weshalb ich
nie über die zusätzliche Anschaffung eines LA nachgedacht habe. Um
herauszufinden, an welcher Stelle sich mein Progrämmchen verläuft,
reichte mir die Portpin/LED/Oszi-Methode bislang immer.

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

DoDi

 

[Joerg Niggemeyer]

In message <grn472Fcm4U2@mid.individual.net>
Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

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

Ich bevorzuge natürlich als HW Entwickler den Einsatz einses scopes,
insbesondere eine schnelle Stromzange, die dann häufig nur in Kombination
mit dem entsprechenden Fabrikaten der Hersteller kompatibel ist.

Da die Kisten auch meist 16 Logik Kanäle bieten, habe ich bislang keinen
LA extra benötigt. Schön war ist, dass ich auch bei meinen Teks, die
Extras (serielle Dekodierung etc.) wie bei Rigol freigeschaltet habe ;-)


--
mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker
WEB: http://www.nucon.de https://www.led-temperature-protection.com
Nucon GbR Steinbecker Muehlenweg 95, 21244 Buchholz idN, Germany
UST-IDNR.: DE 231373311, phone: +49 4181 290913, fax: +49 4181 350504
WEEE-Reg.-Nr.E 31372201

 

[Stefan]

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

Am 16.08.2019 um 06:56 schrieb Stefan:
Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich:
Am 15.08.2019 um 20:22 schrieb Stefan:


Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann,
während er bereits abgearbeitet wird.

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

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.

 

[Joerg Niggemeyer]

In message <AABdVVgZzoIAAAMq.A1.flnews@WStation5.stz-e.de>
Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:

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

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
5.0 oder 3V3 - würde man ja nicht wahlweise anbieten, wenn es keiner
verlangt ;-)

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
5V uC dazu nehmen - insbesondere wenn z.B. bei automotive einige ICs ein
Enable von min. 4.5V haben.

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.

--
mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker
WEB: http://www.nucon.de https://www.led-temperature-protection.com
Nucon GbR Steinbecker Muehlenweg 95, 21244 Buchholz idN, Germany
UST-IDNR.: DE 231373311, phone: +49 4181 290913, fax: +49 4181 350504
WEEE-Reg.-Nr.E 31372201

 

[Rolf Bombach]

Andreas Neumann schrieb:

Wolfgang Allinger wrote:

latßrnich rechnet man Sachen nur neu aus, wenn eine Veränderung
stattfindet.

Ja genau, so macht man das.

Wie ein Kollege (Ex-Siemens) mal sagte, du kannst doch zum Stromsparen den
Empfänger erst dann einschalten, wenn ein Funktelegramm kommt, oder?
Ja. tolle Idee. Und so praktisch. Und so Siemens. Warum hat sich der das
nicht patentieren lassen?

Man kann ja kurz vorher anrufen *duck*

--
mfg Rolf Bombach

 

[Gerhard Hoffmann]

Am 21.08.19 um 20:39 schrieb Rolf Bombach:

Andreas Neumann schrieb:
Wolfgang Allinger wrote:

latßrnich rechnet man Sachen nur neu aus, wenn eine Veränderung
stattfindet.

Ja genau, so macht man das.

Wie ein Kollege (Ex-Siemens) mal sagte, du kannst doch zum Stromsparen
den
Empfänger erst dann einschalten, wenn ein Funktelegramm kommt, oder?
Ja. tolle Idee. Und so praktisch. Und so Siemens. Warum hat sich der das
nicht patentieren lassen?

Man kann ja kurz vorher anrufen *duck*

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.

 

[Rolf Bombach]

Hans-Peter Diettrich schrieb:

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

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

--
mfg Rolf Bombach