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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-15 07:29 -0400 |
| Message-ID | <EruqiUuEQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261697 |
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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-14 11:20 +0200 |
| Message-ID | <ad9e57e357.assel@nuconverter.de> |
| In reply to | #261623 |
In message <Ermpt8dzQoB@allinger-307049.user.uni-berlin>
"Wolfgang Allinger" <all2001@spambog.com> 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.......
> 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 ging darum, dass man Berechnungen, die vielleicht einmal am Tag
notwendig sind, nicht jede Sekunde durchführen muss. Kann man wohl machen,
da es die Rechenleistung vielleicht hergibt, ist aber IMHO schlechter
Stil.
Über ein globales Flag einen Status zu übermitteln, ist eine Technik, die
man anwenden kann, um entsprechend in einer anderen Wiederholschleife, die
nicht in sync zu einem Timer stehen muss und auch unterbrochen werden kann
z.B. in der main loop, dann Aktionen durchzuführen.
Das Flag, ob eine Berechnung notwendig ist oder nicht , muss oder kann
nicht unbedingt über den Timer Wert auslesbar sein. Insbesondere, wenn
eine Berechnung nur sehr selten vorkommt.
Das Flag bietet zudem den Vorteil, eine Berechnung auch aus einem anderen
Event zu triggern, z.B. die Uhr wurde gestellt oder User command.
Aktionen in dem T-IR nach Bedarf durchführen, falls häufige Reaktionen
oder Berechnungen periodisch schnell dazu nötig sind.
> 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.
Das Polling des Bits gibt die gewünschte Aktualisierungsrate vor. Im
übrigen würde es in diesem Falle zu keinem "langem" Fehler führen, sondern
lediglich zu einer langsamen Reaktion, die eine einstellbare Eigenschaft
ist, falls man einem IR (1s) zu spät das Datum/Wochentag berechnen würde.
Und das ist für mich auch ein wichtiges Kriterium, ob eine Funktion in
einem IR laufen muss also zeitlich zu einem event kritisch ist oder nicht.
> Mit der Alt/Neu Zählerstand Methode, funzt
> das sogar, wenn man mal einen verschlabbert, auch Überläufe musse
> latürnicht da korrekt behandeln.
Verschlabbern von kritischen IRs, wie bei der Programmierung von DCDC,
wenns denn mal etwas schneller gehen soll, ist schlecht, dann machts
Puff.....
Alt Neu Variablenvergleich, um z.B. eine Wertveränderung abzuprüfen, oder
Fehler zu detektieren ist zweckmässig.
Auch das Anhalten per Debugger im ungünstigen Moment kann zum Himmeln der
HW führen. So etwas führt dann zu einer steilen Lernkurve oder man gibt
frustiert auf ;-)
--
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
This electronic transmission (and any attached document) may contain
confidential and/or privileged information. It is intended only for the
person or entity to whom it is adressed.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender and destroy this e-mail or any attached
document immediatly. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden.
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-14 07:32 -0400 |
| Message-ID | <ErqqJFVUQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261667 |
On 14 Aug 19 at group /de/sci/electronics in article ad9e57e357.assel@nuconverter.de <joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote: > In message <Ermpt8dzQoB@allinger-307049.user.uni-berlin> > "Wolfgang Allinger" <all2001@spambog.com> wrote: >> Mit der Alt/Neu Zählerstand Methode, funzt >> das sogar, wenn man mal einen verschlabbert, auch Überläufe musse >> latürnicht da korrekt behandeln. > Verschlabbern von kritischen IRs, wie bei der Programmierung von DCDC, > wenns denn mal etwas schneller gehen soll, ist schlecht, dann machts > Puff..... > Alt Neu Variablenvergleich, um z.B. eine Wertveränderung abzuprüfen, oder > Fehler zu detektieren ist zweckmässig. > Auch das Anhalten per Debugger im ungünstigen Moment kann zum Himmeln der > HW führen. BTDT 400V 8kA Stromrichter, da lernste was fürs Leben :) Das macht nicht puff, sondern KAWUMMMMMMM :) Hört der halbe Betrieb, dass der Allinger wieder Scheisse gebaut hat, aber das härtet ab. Hab da seinerzeit Versuche fahren müssen, zur Bestimmung der Wechselrichtertrittgrenze, sehr lange her, jedesmal beim Anfahren der Grenze (lastabhängig) war ein 1000DM Satz Silized Sicherungen fällig. Keine Ahnung, wie das heutzutage gemacht wird und ob man sowas überhaupt simulieren kann. Damals gabs nur die KAWUMMMMM Methode. > So etwas führt dann zu einer steilen Lernkurve oder man gibt > frustiert auf ;-) Jau, steil und LAUT und viel magischer Rauch, wieder ätze ich: C Programmierer schreiben schlechte Programme, fühlen sich mies und geben beim debuggen auf. FORTH Programmierer schreiben schlechte Programme, fühlen sich gut und bringen die Programme zum laufen :p 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 | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2019-08-14 09:49 +0200 |
| Message-ID | <grhso4FqoihU1@mid.individual.net> |
| In reply to | #261611 |
On 13.08.19 17:10, 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 ;-) Muß nicht sein: Man legt den uC mit freigeschalteten Interrupts schlafen: sei(); sleep_mode(); Er kehrt dann aus dem "sleep_mode()" zurück, wenn die ISR beendet ist. Leider ist der Spareffekt abhängig von der "Schlaftiefe": insbesondere die ATmegas lassen sich für einige Interrupt-Quellen nicht in einen Tiefschlaf versetzen. Josef
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-13 19:29 +0200 |
| Message-ID | <grgabaFghlmU1@mid.individual.net> |
| In reply to | #261606 |
Am 13.08.2019 um 13:25 schrieb Wolfgang Allinger: > 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. Sorry, das ist furchtbarer Murks :-( Zugriffe auf Variablen, die in Interrupts geändert werden können, müssen atomar erfolgen, d.h. Interrupts ausschalten, lokale Kopie erzeugen, Interrupts wieder einschalten. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-13 14:54 -0400 |
| Message-ID | <ErmpvtXzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261620 |
On 13 Aug 19 at group /de/sci/electronics in article grgabaFghlmU1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 13.08.2019 um 13:25 schrieb Wolfgang Allinger: >> 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. > Sorry, das ist furchtbarer Murks :-( > Zugriffe auf Variablen, die in Interrupts geändert werden können, müssen > atomar erfolgen, d.h. Interrupts ausschalten, lokale Kopie erzeugen, > Interrupts wieder einschalten. Ja, das ist mit atomar auch ok, aber jedenfalls aufwändiger. KISS \ meine Lösung ist idiotensicher (hoffe ich mal) vZakt @ DUP vZakt @ <> IF DROP vZakt @ THEN \ ?race condition vZalt @ = IF DROP EXIT THEN DUP vZalt ! \ weiterverwursten FEDDICH \ Deine atomar Lösung (theoretisch korrekt(er) :o ) DiIr vZakt @ EiIr \ IR auf und nieder, verhindert race condition DUP vZalt @ = IF DROP EXIT THEN DUP vZalt ! \ weiterverwursten FEDDICH Deine Lösung ist auf den 1. Blick kürzer, aber wehe das DiIr wird erst ein (paar) Takte später wirksam, so wie beim Pleassy MICPROC 16AS (zeigt den Stinkefinger hinter seinem Rücken :o) dann bisse gEiIrt :p Ich erinnere mich noch schwach, dass da auch ein paar andere uC da Fallen aufgestellt haben. Dann musse noch ein paar NOP einbauen und wenn einer das Quarz ändert, fängste u.U. wieder an zu suchen. Vor allem weiss das nach ein paar Jahren keiner mehr. Einkauf: die CPU mit doppelter Taktfrequenz ist halb so teuer... ja kein Problem. Und irgendwan nörgelt ein Kunde Allinger, dass es da manchmal Hickup bei den neuen Geräten gibt. :] WIMRE ist das mit Verzögerungen auch eine beliebte Falle bei pipelined CPU und wenn dann noch mehrere Kerne rumfuchteln, gehts leicht bergab. Kann man machen, muss man aber nicht. Ich steh auf KISS, das sollte jeder Depp verstehen, sogar ich. Q.E.D. . Irgenswie den Faden verloren, oder ich hab noch was übersehen. Schon sehr lange nicht mehr programmiert. Im Ruhestand bin ich so unruhig, dass ich keine Zeit mehr dazu hab :) So und noch schnell zum Abschluss geätzt (Insider Witz): Bei C hat der Programmierer den Compiler im Kopf, bei FORTH hat der Programmierer den Compiler im Target! 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 | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-13 21:06 +0200 |
| Message-ID | <qiv1o0$4c5$1@news2.open-news-network.org> |
| In reply to | #261620 |
On 13.08.19 19:29, Hans-Peter Diettrich wrote: > Am 13.08.2019 um 13:25 schrieb Wolfgang Allinger: > >> 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. > > Sorry, das ist furchtbarer Murks :-( Ja. Insbesondere weil C auch zwei hintereinander folgende "lese" Abfragen schlicht wegoptimieren darf. D.h. man fängt dann mit volatile gemurkse an. > Zugriffe auf Variablen, die in Interrupts geändert werden können, müssen > atomar erfolgen, d.h. Interrupts ausschalten, lokale Kopie erzeugen, > Interrupts wieder einschalten. Bzw IRQ aus, lesen, ändern, schreiben, IRQ an. Viel einfacher zu implementieren als IRQ aus, lesen, IRQ an, ändern, IRQ aus, prüfen ob schreiben OK, schreiben/wiederholen, IRQ an. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-13 13:45 +0200 |
| Message-ID | <9efee0e257.assel@nuconverter.de> |
| In reply to | #261600 |
In message <qitt5f$vus$1@news.albasani.net>
Thorsten Böttcher <thorsten_nospam@gmx.net> 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.
Jau ;-)
Eine übliche Vorgehensweise ist es mit dem scope die zeitlichen
Längen der Funktionen und die Abarbeitung der IRs sichtbar zu machen,
indem man ein paar Pins des Micros als logig flags dem scope zuführt
und einen Portpin hi schaltet beim Funktionseintritt und beim verlassen
den pin wieder runterzieht, toggeln etc. Man kann dann auf dem scope
schön sehen ob eine Firmware rund läuft, insbesondere mit meherern IRs...
Bei dem Abfragen der Variablen (Speicherbereich des RAMs) aufpassen,
falls diese Variablen länger sind als 8bit. Da der IR Dir just genau
in dem Moment neue Werte in den Speicher schreiben kann, wenn die
Berechnungsroutine den Wert ausliest. Abhilfe dazu z.B. den IR sperren
und nach dem Lesen wieder freigeben.
--
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 | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-13 13:56 +0200 |
| Message-ID | <qiu8hf$7ks$1@pi.h5.or.at> |
| In reply to | #261607 |
Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote:
> Eine übliche Vorgehensweise ist es mit dem scope die zeitlichen
> Längen der Funktionen und die Abarbeitung der IRs sichtbar zu machen,
> indem man ein paar Pins des Micros als logig flags dem scope zuführt
> und einen Portpin hi schaltet beim Funktionseintritt und beim verlassen
> den pin wieder runterzieht, toggeln etc. Man kann dann auf dem scope
> schön sehen ob eine Firmware rund läuft, insbesondere mit meherern IRs...
Ah, das ist clever. Gerade wenn das Timing gefragt ist, dann ist
Ausgeben von Debug-Statements über die serielle Schnittstelle keine
wirkliche Option.
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Rainer Knaepper <rainerk@smial.prima.de> |
|---|---|
| Date | 2019-08-14 00:38 +0200 |
| Message-ID | <ErptXkKirLB@smial.prima.de> |
| In reply to | #261608 |
ra@pi.h5.or.at (Ralph Aichinger) am 13.08.19 um 13:56: > Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote: >> Eine übliche Vorgehensweise ist es mit dem scope die zeitlichen >> Längen der Funktionen und die Abarbeitung der IRs sichtbar zu >> machen, indem man ein paar Pins des Micros als logig flags dem >> scope zuführt und einen Portpin hi schaltet beim Funktionseintritt >> und beim verlassen den pin wieder runterzieht, toggeln etc. Man >> kann dann auf dem scope schön sehen ob eine Firmware rund läuft, >> insbesondere mit meherern IRs... > Ah, das ist clever. Gerade wenn das Timing gefragt ist, dann ist > Ausgeben von Debug-Statements über die serielle Schnittstelle keine > wirkliche Option. Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an oder nie aus (je nach Implementierung) ist was faul. Flimmert oder glimmt sie vor sich hin, ist alles schön ;-) Rainer -- Wenn Du eine Platte brauchst, dann kaufe sie jetzt. Oder morgen. Oder wann immer Du sie wirklich brauchst, denn irgendwann muss man sterben und den Tag darauf ist es sowieso billiger ;-) (Christian Dürrhauer in de.comp.hardware.laufwerke.festplatten)
[toc] | [prev] | [next] | [standalone]
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-14 09:53 +0200 |
| Message-ID | <31a44fe357.assel@nuconverter.de> |
| In reply to | #261636 |
In message <ErptXkKirLB@smial.prima.de>
Rainer Knaepper <rainerk@smial.prima.de> wrote:
> ra@pi.h5.or.at (Ralph Aichinger) am 13.08.19 um 13:56:
>> Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote:
>>> Eine übliche Vorgehensweise ist es mit dem scope die zeitlichen
>>> Längen der Funktionen und die Abarbeitung der IRs sichtbar zu
>>> machen, indem man ein paar Pins des Micros als logig flags dem
>>> scope zuführt und einen Portpin hi schaltet beim Funktionseintritt
>>> und beim verlassen den pin wieder runterzieht, toggeln etc. Man
>>> kann dann auf dem scope schön sehen ob eine Firmware rund läuft,
>>> insbesondere mit meherern IRs...
>> Ah, das ist clever. Gerade wenn das Timing gefragt ist, dann ist
>> Ausgeben von Debug-Statements über die serielle Schnittstelle keine
>> wirkliche Option.
> Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an
> oder nie aus (je nach Implementierung) ist was faul. Flimmert oder
> glimmt sie vor sich hin, ist alles schön ;-)
Na klar, die LED, die z.B. durch langsames Blinken diverese Codes
dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt
werden, wenn man ein scope dransetzt.
--
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 | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-14 10:56 +0200 |
| Message-ID | <gri0m9Friq2U1@mid.individual.net> |
| In reply to | #261643 |
Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer: > In message <ErptXkKirLB@smial.prima.de> > Rainer Knaepper <rainerk@smial.prima.de> wrote: >> Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an >> oder nie aus (je nach Implementierung) ist was faul. Flimmert oder >> glimmt sie vor sich hin, ist alles schön ;-) > > Na klar, die LED, die z.B. durch langsames Blinken diverese Codes > dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt > werden, wenn man ein scope dransetzt. Wenn schon Debuggen dann gleich richtig mit einem Logik-Analysator. Ist weit billiger als ein Scope und erlaubt bessere Diagnosen. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2019-08-14 11:36 +0200 |
| Message-ID | <gri30sFs1k2U1@mid.individual.net> |
| In reply to | #261661 |
On 14.08.19 10:56, Hans-Peter Diettrich wrote: > Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer: >> In message <ErptXkKirLB@smial.prima.de> >> Rainer Knaepper <rainerk@smial.prima.de> wrote: >>> Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an >>> oder nie aus (je nach Implementierung) ist was faul. Flimmert oder >>> glimmt sie vor sich hin, ist alles schön ;-) >> >> Na klar, die LED, die z.B. durch langsames Blinken diverese Codes >> dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt >> werden, wenn man ein scope dransetzt. > > Wenn schon Debuggen dann gleich richtig mit einem Logik-Analysator. Ist > weit billiger als ein Scope und erlaubt bessere Diagnosen. Dann mußt Du aber mehrere Bits ausgeben und per LA abfragen. Josef
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-14 07:15 -0400 |
| Message-ID | <ErqqIy+EQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261661 |
On 14 Aug 19 at group /de/sci/electronics in article gri0m9Friq2U1@mid.individual.net <DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote: > Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer: >> In message <ErptXkKirLB@smial.prima.de> >> Rainer Knaepper <rainerk@smial.prima.de> wrote: >>> Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an >>> oder nie aus (je nach Implementierung) ist was faul. Flimmert oder >>> glimmt sie vor sich hin, ist alles schön ;-) >> >> Na klar, die LED, die z.B. durch langsames Blinken diverese Codes >> dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt >> werden, wenn man ein scope dransetzt. > 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... ..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 :) Für seltene Fälle dann wieder mit Portpin und Oscar. Meistens ein Port (wenn frei) mit einem WrapPfosten und 8 LEDs für guckometrische Überwachung. Reichte mir völlig, selbst bei dem Trumm mit den 14 aktiven IR Ebenen (selten, PWF, BrownOut, 50Hz, 100Hz, 1kHz, 20kHz, 19kBd, ...) und alles völlig asynchron, wobei dann auch noch bei bestimmten Umständen, die IR Prioritäten abgewandelt wurden. Damals standen mir diverse edelste LA im Dutzend zur Verfügung, so hp1608 . hp16500(?) samt einem schweineteuren, aber völlig unbrauchbarem Dolch (8050?) Mein Liebling war der hp1608|1604(?) nannte sich LogigStateAnalyzer, hatte nur 16 Speicherplätze aber ein grandioses Triggermenü mit sehr vielen Ebenen. Brauchte man auch, sonst waren die 16 Plätze ruckzuck voll. Hab ihn sogar fast immer benutzt, wenn ich mal Langzeit Protokolle abspeichern musste. Den hp als Trigger für den Dolch als Datengrab/ Speichererweiterung... Mit dem hp konnte man leicht sowas fangen wie: 3x an pin1 gewackelt, dann 7 fallende Flanken an pin2, rückfall in pin1 Ebene, wenn pin3 7x gewackelt hat und pin4 positiv war, jedoch nicht wenn pin5 rattert... sonst nächste Ebene bit triggerung für Channel/Platz 1, dann wieder auf der Lauer legen... Man konnte sich dann auch anzeigen lassen, bis wo er gerade im Triggerbaum geklommen war. Hab sowas später nie mehr an anderen LA gefunden, allerdings auch die LA Schiene nie weiter benutzt, s.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-15 05:44 +0200 |
| Message-ID | <grk2okFank4U1@mid.individual.net> |
| In reply to | #261683 |
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 :-) > ..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. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-15 07:53 -0400 |
| Message-ID | <Eruqic2EQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261698 |
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! :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 15:24 +0200 |
| Message-ID | <grl5qvFi07iU1@mid.individual.net> |
| In reply to | #261710 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-15 17:06 -0400 |
| Message-ID | <EruqxzAUQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261714 |
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! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [next] | [standalone]
| From | Rainer Knaepper <rainerk@smial.prima.de> |
|---|---|
| Date | 2019-08-15 09:27 +0200 |
| Message-ID | <Ertv3HTirLB@smial.prima.de> |
| In reply to | #261698 |
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...
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-16 08:58 +0200 |
| Message-ID | <grn472Fcm4U2@mid.individual.net> |
| In reply to | #261750 |
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
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web