Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #261597 > unrolled thread
| Started by | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| First post | 2019-08-13 09:33 +0200 |
| Last post | 2019-08-16 13:06 +0200 |
| Articles | 20 on this page of 85 — 17 participants |
Back to article view | Back to de.sci.electronics
(Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 09:33 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-13 10:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 07:25 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-13 15:15 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 13:45 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-14 07:33 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-14 14:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 08:36 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-08-21 20:39 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 21:14 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Heinz Saathoff <newshsaat@arcor.de> - 2019-08-22 09:00 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-22 10:35 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-22 10:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-22 15:19 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-24 10:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-13 17:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 13:54 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 10:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 06:44 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:35 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:29 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-14 11:20 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:32 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 09:49 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-13 19:29 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 14:54 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-13 21:06 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-13 13:45 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 13:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-14 00:38 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-14 09:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 10:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:36 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:15 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:44 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:53 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 15:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 17:06 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-15 09:27 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 08:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-16 11:25 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-08-21 20:49 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-13 15:11 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 18:47 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rafael Deliano <rafael_deliano@arcor.de> - 2019-08-13 18:28 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 18:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rafael Deliano <rafael_deliano@arcor.de> - 2019-08-14 17:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:47 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-15 10:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 08:26 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 15:36 +0200
Forth 2: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 17:28 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-13 18:52 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-14 06:49 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-14 09:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 10:57 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 11:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 11:40 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-14 13:58 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-14 16:46 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-14 18:23 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 19:05 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-15 11:28 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-15 13:43 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-15 15:03 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-16 13:45 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:29 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 06:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-15 09:13 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-15 11:16 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-14 00:27 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Markus Faust <mfaust@htwm.de> - 2019-08-14 10:31 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 11:01 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 11:23 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:50 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:34 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:21 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-15 20:22 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 23:18 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-16 06:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 09:06 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-16 13:06 +0200
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-13 09:33 +0200 |
| Subject | (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <qitp4d$g19$1@pi.h5.or.at> |
Ich bin dabei derzeit eine Atomuhr zu basteln (Physics Package
ist noch unterwegs), und bin gerade beim Zählen und auswerten
der Pulse angelangt.
Ich werde vermtulich erst mal einen 8-Bit-Atmel verwenden
(für den Prototypen einen Arduino Mega 2560, fürs fertige
Gerät vielleicht eine Teensy 2.0 mit 32u4). Ja, wie mich jemand
zu recht belehrt hat ist das "Geriatronik", es gibt ARM-Controller
die das alles mit links erschlagen, aber trotzdem würde mich eine
"saubere" Vorgehensweise interessieren. Das ganze mit roher
Rechenpower lösen kann ich ja noch immer. Ein Teensy 4.0 mit
600MHz-Arm Cortex hat sicher keinerlei Probleme, wie unelegant
man auch immer programmiert.
Die AVR-Controller können einen Zähler an einen externen
Pin hängen, mit oder ohne Prescaler und recht schnell
zählen, ohne daß die eigentliche CPU belästigt wird.
Das hab ich mittlerweile geschafft (nach einigem Datenblatt-
Studium).
Meine Idee wäre die Pulse unterhalb der Sekunde so zu
zählen (egal ob die vollen 10MHz oder schon was runtergeteiltes,
z.B. 1000Hz für eine Millisekundenanzeige), und jede
Sekunde, d.h. beim Überlauf des Zählers der Sekundenbruchteile,
einen ausgelösten Interrupt mit einer ISR zu behandeln.
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?
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [next] | [standalone]
| From | Thorsten Böttcher <thorsten_nospam@gmx.net> |
|---|---|
| Date | 2019-08-13 10:42 +0200 |
| Message-ID | <qitt5f$vus$1@news.albasani.net> |
| In reply to | #261597 |
On 13.08.2019 09:33, Ralph Aichinger wrote: > 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? Du machst den Rest einfach außerhalb des IRQ. Zum Beispiel setzt Du Dir im IRQ eine Variable, die Du von außerhalb abfragst. Und dann kannst Du in Ruhe z.B. das Datum berechnen, während die Sekunden weiter laufen. Wobei das auch nicht so arg lange dauern sollte.
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-13 07:25 -0400 |
| Message-ID | <ErmpcRszQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261600 |
On 13 Aug 19 at group /de/sci/electronics in article qitt5f$vus$1@news.albasani.net <thorsten_nospam@gmx.net> (Thorsten Böttcher) wrote: > On 13.08.2019 09:33, Ralph Aichinger wrote: >> 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? > Du machst den Rest einfach außerhalb des IRQ. Zum Beispiel setzt Du Dir > im IRQ eine Variable, die Du von außerhalb abfragst. > Und dann kannst Du in Ruhe z.B. das Datum berechnen, während die > Sekunden weiter laufen. > Wobei das auch nicht so arg lange dauern sollte. Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern. Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die Laube. Das ganze Geraffel sollte nicht länger sein, als der Display Anzeige zyklus. Aber auch dann gibt es noch weitere Tricks wie Zeitscheiben im Foreground Programm. Falls die CPU auch SW-IR erzeugen kann (z.B. wie der Z80 mit RST0..7), dann ein SW-IR in der Zähler IRQ setzen, falls msec voll. Der erzeugte SW- IR wird wird dann in einer msecIRQ verarztet, der dann ggf. einen 1secIR triggert. die 1seq IR Routine löst dann ggf. einen 1min SW-IR aus... usw.usf. Das eine IRroutine sauber die IR Anforderung zurücksetzt, ist Ehrensache :) Auch die benutzen REG schön sauber wegschreiben und vorkramen (mit IR- OFF IR-ON. Das übt und ist in Assembler übersichtlich. So kannste wg. mir auch einen Weiteren Timer aufsetzen, der periodisch ein Display update Ausgabe zusammenbaut. Krumme Frequenz zu 50Hz Netzbrumm ist da angebracht, damit es nicht flackert und schnell genug fürs Auge. ggf. auch den Display MUXER per periodischem SW-IR erledigen Dann brauch sich das Foreground Programm nur noch um den Userinput kümmern, die tippen selten so schnell, dass es da überfordert wird. Mein wildestes Gerät hatte so mal 14 verschiedene IR-Ebenen 64180 (Z80 Abart) um die verschiedenen völlig asynchronen Vorgänge zu verarzten. Messfrequenz schneller/langsamer als Display update, serielle Schnittstelle, Uhrzeit und Dutzend andere Sachen, alle munter Durcheinander. Das war mein 1. Gerät mit FORTH. (IR) Routinen in HLL, debuggen, wenn die zu langsam waren, dann eben in CODE (Assembler) umgefrickelt. Ging super, da man ja am Algorithmus nix mehr nachdenken muss, nur noch HLL in ASS nachbilden. Parallel beide HLL und CODE in (Endlos)Schleife antriggern, und Ergebnisse vergleichen, bei Abweichungen den CODE debuggen. OK ich war Hardcore Echtzeit Programmierer, der vorher nur in ASS gearbeitet hat. 3 Dutzend verschiedenste CPU, MiniComputer (ja echter, z.B. Hp2114 bis hp2100(mein pers. Liebling), AEG, SIEMENS Prozessrechner), Grossrchner TR440 (Telefunken), Nova (DG), TANDEM, PDP8, PDP11) und dann aberetliche uC von intel, über Motzorola, AMD, RTX ... Langwierige Sachen wurden mal in Fortran und Basic programmiert. C kam gerade auf, aber GSD hab ich da FORTH gefunden und so eine Scheisse nie benutzt. Auch Algol, ADA, COBOLd und hunderter andere 'moderne' Sprachen/ Methoden immer per FORTH outperformed :) So genug gebrunzt :) Mein Spitzname war Microprofessor :) 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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Böttcher <thorsten_nospam@gmx.net> |
|---|---|
| Date | 2019-08-13 15:15 +0200 |
| Message-ID | <qiud5a$pkr$1@news.albasani.net> |
| In reply to | #261606 |
On 13.08.2019 13:25, Wolfgang Allinger wrote: > > Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern. > > Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar > mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR > Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem > letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen > anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die > Laube. Das ganze Geraffel sollte nicht länger sein, als der Display > Anzeige zyklus. Aber auch dann gibt es noch weitere Tricks wie Das erscheint mir ein wenig umständlich. Warum soll man mehrfach pro Sekunde Werte berechnen, die sich einmal am Tag oder noch seltener ändern? MfG
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-13 13:45 -0400 |
| Message-ID | <ErmpspJUQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261609 |
On 13 Aug 19 at group /de/sci/electronics in article qiud5a$pkr$1@news.albasani.net <thorsten_nospam@gmx.net> (Thorsten Böttcher) wrote: > On 13.08.2019 13:25, Wolfgang Allinger wrote: >> >> Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern. >> >> Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar >> mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR >> Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem >> letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen >> anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die >> Laube. Das ganze Geraffel sollte nicht länger sein, als der Display >> Anzeige zyklus. Aber auch dann gibt es noch weitere Tricks wie > Das erscheint mir ein wenig umständlich. > Warum soll man mehrfach pro Sekunde Werte berechnen, die sich einmal am > Tag oder noch seltener ändern? Da haste was flasch verstanden oder ich mich schlecht ausgedückt, latürnich rechnet man Sachen nur neu aus, wenn eine Veränderung stattfindet. Aber muss alles immer seit dem Urknall erklärt werden? Im Rest vom posting sind weitere Möglichkeiten zu finden. 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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Böttcher <thorsten_nospam@gmx.net> |
|---|---|
| Date | 2019-08-14 07:33 +0200 |
| Message-ID | <qj06fs$mbm$1@news.albasani.net> |
| In reply to | #261622 |
On 13.08.2019 19:45, Wolfgang Allinger wrote: > > On 13 Aug 19 at group /de/sci/electronics in article qiud5a$pkr$1@news.albasani.net > <thorsten_nospam@gmx.net> (Thorsten Böttcher) wrote: > >> On 13.08.2019 13:25, Wolfgang Allinger wrote: > >>> >>> Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern. >>> >>> Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar >>> mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR >>> Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem >>> letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen >>> anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die >>> Laube. Das ganze Geraffel sollte nicht länger sein, als der Display >>> Anzeige zyklus. Aber auch dann gibt es noch weitere Tricks wie > >> Das erscheint mir ein wenig umständlich. >> Warum soll man mehrfach pro Sekunde Werte berechnen, die sich einmal am >> Tag oder noch seltener ändern? > > Da haste was flasch verstanden oder ich mich schlecht ausgedückt, > latürnich rechnet man Sachen nur neu aus, wenn eine Veränderung > stattfindet. Naja, Du hast geschrieben "dann alle Berechnungen anstellen". Das hab ich halt genau so verstanden. > Aber muss alles immer seit dem Urknall erklärt werden? Nein, Du hast vollkommen Recht. Es war mein Fehler dass ich nicht wusste was Du gedacht hast, sondern nur das gesehen hab was Du geschrieben hast.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Neumann <an5275@sedo.com> |
|---|---|
| Date | 2019-08-14 14:24 +0200 |
| Message-ID | <qj0uhj$1hdh$1@gioia.aioe.org> |
| In reply to | #261622 |
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? Rest angepasst.
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-14 08:36 -0400 |
| Message-ID | <ErqqOqsjQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261680 |
On 14 Aug 19 at group /de/sci/electronics in article qj0uhj$1hdh$1@gioia.aioe.org <an5275@sedo.com> (Andreas Neumann) wrote: > 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? Weist Du das mit der Anmeldung wirklich? Gängig war ja eine vor Kollegen verheimlichte Anmeldung. Öfters erlebt, Idee geklaut und angemeldet :( > Rest angepasst. 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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2019-08-21 20:39 +0200 |
| Message-ID | <qjk352$9d0$1@dont-email.me> |
| In reply to | #261680 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-21 21:14 +0200 |
| Message-ID | <qjk57j$1ao$1@solani.org> |
| In reply to | #262022 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Heinz Saathoff <newshsaat@arcor.de> |
|---|---|
| Date | 2019-08-22 09:00 +0200 |
| Message-ID | <1keslet65i9kiu44341gikr3ag9ks6sgbf@4ax.com> |
| In reply to | #262028 |
Gerhard Hoffmann schrieb: >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. 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
[toc] | [prev] | [next] | [standalone]
| From | Andreas Neumann <an5275@sedo.com> |
|---|---|
| Date | 2019-08-22 10:35 +0200 |
| Message-ID | <qjlk40$16eu$3@gioia.aioe.org> |
| In reply to | #262086 |
Heinz Saathoff wrote: > 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. Äpfel. Birnen.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Neumann <an5275@sedo.com> |
|---|---|
| Date | 2019-08-22 10:34 +0200 |
| Message-ID | <qjlk29$16eu$2@gioia.aioe.org> |
| In reply to | #262028 |
Gerhard Hoffmann wrote: > 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. Ach, und wie "sieht man" denn nach? Ach so, dazu schaltet man den Empfänger ein? Wer hätte das gedacht! [ ] Du hast verstanden.
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2019-08-22 15:19 +0200 |
| Message-ID | <qjm4og$a72$1@solani.org> |
| In reply to | #262091 |
Am 22.08.19 um 10:34 schrieb Andreas Neumann: > Gerhard Hoffmann wrote: > >> 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. > > Ach, und wie "sieht man" denn nach? Ach so, dazu schaltet man den Empfänger > ein? Wer hätte das gedacht! > > [ ] Du hast verstanden. > > Man schaltet in 5% der Zeit einen Teil des Empfängers ein. Hinweis: Ein Empfänger mag in deiner vereinfachten Welt ein einzelnes Ding sein, aber er besteht aus einer ganzen Anzahl von Komponenten, die durchaus unterschiedliche Aufgaben haben. Den Demodulator braucht man zum Nachsehen z.B. schon nicht mehr, falls du das Wort schon mal aufgeschnappt hast, und was nach dem Demodulator kommt sowie nicht. Hast du denn schon mal ein Stück Elektronik offen gesehen? Oder wenigstens ein drahtloses Telefon in der Hand gehabt? Wie lange kannste telefonieren? Wie lange kann so ein Ding standby sein?
[toc] | [prev] | [next] | [standalone]
| From | Andreas Neumann <an5275@sedo.com> |
|---|---|
| Date | 2019-08-24 10:34 +0200 |
| Message-ID | <qjqsq9$4nl$1@gioia.aioe.org> |
| In reply to | #262112 |
Gerhard Hoffmann wrote: Oh, du musst den Empfänger nicht einschalten um festzustellen ob ein Funksignal kommt. Du bist so klug, ich bewundere dich. Damit kannst du zu Siemens gehen. Wo ist dein Patent? Ach, warte mal... >> Man sieht 3* pro Sekunde für 5 ms nach, ob überhaupt etwas > Man schaltet in 5% der Zeit einen Teil des Empfängers ein. Du musst den Empfänger doch einschalten? Doch nicht so klug wie gedacht. > Hinweis: Ein Empfänger mag in deiner vereinfachten Welt > ein einzelnes Ding sein, aber er besteht aus einer ganzen > Anzahl von Komponenten, die durchaus unterschiedliche > Aufgaben haben. Ach, wir nennen das Teil nicht Empfänger? Super, Politiker bist du auch noch. Wie wär's mit "Funkwellennachschauer"? Nee, das ist zu sperrig. Der gemeine Ahnungslose (also nahezu jeder außer dir) nennt das Teil einfach Empfänger. Und bei Siemens haben sie den Demodulator auch noch dazu gebraucht um das Startbyte zu erkennen, wie lame. > Hast du denn schon mal ein Stück Elektronik offen gesehen? Nein, ich habe mein Diplom auf der Kirmes geschossen, und die Amateurfunklizenz gleich mit dazu. > Oder wenigstens ein drahtloses Telefon in der Hand gehabt? > Wie lange kannste telefonieren? > Wie lange kann so ein Ding standby sein? Jaja. Du bist so klug. Not.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-13 17:10 +0200 |
| Message-ID | <23ccf3e257.assel@nuconverter.de> |
| In reply to | #261606 |
In message <ErmpcRszQoB@allinger-307049.user.uni-berlin>
"Wolfgang Allinger" <all2001@spambog.com> wrote:
> Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern.
> Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar
> mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR
> Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem
> letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen
> anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die
> Laube.
Was für ein Polling Aufwand ;-)
Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden
ist.
Nachdem die Berechnung fertig ist, wird das Flag gelöscht.
Dann wird auch nicht soviel Rechenzeit unnütz verbraten.......
> So genug gebrunzt :)
> Mein Spitzname war Microprofessor :)
;-O
--
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.:DE 31372201
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-13 13:54 -0400 |
| Message-ID | <Ermpt8dzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261611 |
On 13 Aug 19 at group /de/sci/electronics in article 23ccf3e257.assel@nuconverter.de <joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote: > In message <ErmpcRszQoB@allinger-307049.user.uni-berlin> > "Wolfgang Allinger" <all2001@spambog.com> wrote: >> Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern. >> Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar >> mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR >> Bearbeitung könnte der sich gerade ändern!) dann vergleichen mit dem >> letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen >> anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die >> Laube. > Was für ein Polling Aufwand ;-) > Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden > ist. > Nachdem die Berechnung fertig ist, wird das Flag gelöscht. > Dann wird auch nicht soviel Rechenzeit unnütz verbraten....... Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR auf und zu. Auch Semaphoren hickhack ist aufwendiger... 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. Mit der Alt/Neu Zählerstand Methode, funzt das sogar, wenn man mal einen verschlabbert, auch Überläufe musse latürnicht da korrekt behandeln. Latürnicht das SETB in der IRserv nach dem Ändern des Zählers... >> So genug gebrunzt :) >> Mein Spitzname war Microprofessor :) > ;-O :))) 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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-14 10:53 +0200 |
| Message-ID | <gri0fsFrhm3U1@mid.individual.net> |
| In reply to | #261623 |
Am 13.08.2019 um 19:54 schrieb Wolfgang Allinger: > > On 13 Aug 19 at group /de/sci/electronics in article 23ccf3e257.assel@nuconverter.de > <joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote: >> Was für ein Polling Aufwand ;-) > >> Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden >> ist. >> Nachdem die Berechnung fertig ist, wird das Flag gelöscht. >> Dann wird auch nicht soviel Rechenzeit unnütz verbraten....... Genau so ist das richtig gemacht. > Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr > Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR > auf und zu. Auch Semaphoren hickhack ist aufwendiger... > > 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? DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-14 06:44 -0400 |
| Message-ID | <ErqqIbzEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261660 |
JBC war ein On 14 Aug 19 at group /de/sci/electronics in article gri0fsFrhm3U1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 13.08.2019 um 19:54 schrieb Wolfgang Allinger: >> >> On 13 Aug 19 at group /de/sci/electronics in article >> 23ccf3e257.assel@nuconverter.de <joerg.niggemeyer@nucon.de> (Joerg >> Niggemeyer) wrote: >>> Was für ein Polling Aufwand ;-) >> >>> Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden >>> ist. >>> Nachdem die Berechnung fertig ist, wird das Flag gelöscht. >>> Dann wird auch nicht soviel Rechenzeit unnütz verbraten....... > Genau so ist das richtig gemacht. >> Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr >> Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR >> auf und zu. Auch Semaphoren hickhack ist aufwendiger... >> >> 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. 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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-15 05:35 +0200 |
| Message-ID | <grk27uFakibU1@mid.individual.net> |
| In reply to | #261681 |
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 :-( DoDi
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web