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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-16 11:25 +0200 |
| Message-ID | <feb75fe457.assel@nuconverter.de> |
| In reply to | #261755 |
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.:DE 31372201
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2019-08-21 20:49 +0200 |
| Message-ID | <qjk3nd$ec8$1@dont-email.me> |
| In reply to | #261755 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2019-08-13 15:11 +0000 |
| Message-ID | <grg29bFedieU1@mid.individual.net> |
| In reply to | #261597 |
Ralph Aichinger <ra@pi.h5.or.at> wrote: >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 ... [Zählen der Pulse und Update der Uhrzeit in TimerISR] >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 Keine dieser Zeitpunkte dürfte grosse Rechenzeit zum Ermitteln erfordern. Vieles kann man vorab ermitteln und in einer Tabelle halten, z.B. die beweglichen Feiertage. Da sich der Wert für einen Tag immer erst um 0:00 Uhr ändert, hat der Controller fast den ganzen Tag Zeit zum Ausrechnen. Den Termin für die Schaltsekunden kannst du sowieso nicht errechnen; der wird bei uns von der PTB festgelegt. Interessanter wird die initiale Synchronisation mit der exakten Atomzeit. Da wirst du wohl ein GPS Zeitnormal, das auf 1ms genau ist, brauchen. Eine Handeinstellung wie bei einer normalen Digitaluhr geht ja nicht. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-13 18:47 +0200 |
| Message-ID | <qiupil$qq7$1@pi.h5.or.at> |
| In reply to | #261612 |
Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
> Feiertage. Da sich der Wert für einen Tag immer erst um 0:00 Uhr ändert,
> hat der Controller fast den ganzen Tag Zeit zum Ausrechnen.
> Den Termin für die Schaltsekunden kannst du sowieso nicht errechnen; der wird
> bei uns von der PTB festgelegt.
Ich hätte gedacht vom "Amt für die Erdrotation" in Paris ;)
Aber es stimmt, ich könnte einiges in vorberechneten Tabellen ablegen.
Mal sehen.
> Interessanter wird die initiale Synchronisation mit der exakten Atomzeit.
> Da wirst du wohl ein GPS Zeitnormal, das auf 1ms genau ist, brauchen.
> Eine Handeinstellung wie bei einer normalen Digitaluhr geht ja nicht.
Ja ;)
Ich werde dazu einen GPS-Empfänger mit PPS-Ausgang nehmen, die sind
so 15-150 ns genau relativ zu UTC, sofern man ein brauchbares Signal
hat. Gibt es mittlerweile recht kostengünstig, z.B.:
https://www.adafruit.com/product/746
Die Idee ist, daß ich einen "Set"-Knopf mache, und wenn der gedrückt
wird, dann wird:
1. das an der seriellen Schnittstelle anliegende NMEA-Zeitsignal auf
Plausibilität geprüft
2. wenn das OK war beim nächsten PPS-Signal der Counter (und/oder
externe Vorteiler resetted)
3 die aus dem NMEA-Signal geparste Uhrzeit und das Datum in den internen
Zähler übernommen.
Ja ;)
Ich werde dazu einen GPS-Empfänger mit PPS-Ausgang nehmen, die sind
so 15-150 ns genau relativ zu UTC, sofern man ein brauchbares Signal
hat. Gibt es mittlerweile recht kostengünstig, z.B.:
https://www.adafruit.com/product/746
Die Idee ist, daß ich einen "Set"-Knopf mache, und wenn der gedrückt
wird, dann wird:
1. das an der seriellen Schnittstelle anliegende NMEA-Zeitsignal auf
Plausibilität geprüft
2. wenn das OK war beim nächsten PPS-Signal der Counter (und/oder
externe Vorteiler resetted)
3 die aus dem NMEA-Signal geparste Uhrzeit und das Datum in den internen
Zähler übernommen.
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Rafael Deliano <rafael_deliano@arcor.de> |
|---|---|
| Date | 2019-08-13 18:28 +0200 |
| Message-ID | <qiuoej$dq2$1@dont-email.me> |
| In reply to | #261597 |
> Zähler an einen externen Pin hängen Können die 10MHz nicht die CPU takten ? Hängt oft vom Prescaler der UART ab ob man noch sinnvolle Baudrate erhält. Hier sicherlich unkritisch. Aber oft vermeidet man, wenn möglich, weitere asynchrone Takte. Liefern manchmal merkwürdige Effekte die schwer zu debuggen sind wenn sie selten auftreten. > Oder ist die Idee mit dem Interrupt überhaupt schlecht? Interrupts erhöhen die Komplexität. Wenn man sie aus Geschwindigkeitsgründen nicht benötigt verwendet man sie nicht. Alle meine simplen Anwendungen a la Fertigungs-Prüfgeräte laufen in simpler Endlosschleife die bei Tastendruck am Terminal in die Kommandozeile zurückkehrt: : RUN \ ( --- ) BEGIN < Anwendung > TERMINAL? UNTIL ; FORTH ist eben etwas anders. Aber keep it simpel ist wohl für alle Programmiersprachen empfehlenswert. MfG JRD
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-13 18:53 +0200 |
| Message-ID | <qiupu1$r3d$1@pi.h5.or.at> |
| In reply to | #261615 |
Rafael Deliano <rafael_deliano@arcor.de> wrote:
> Können die 10MHz nicht die CPU takten ?
Ja, auch das überlege ich, aber:
1. Müßte ich da einige "convenience functions"
beim Arduino anpassen oder auf sie verzichten
(die laufen entweder mit 16MHz oder 8MHz), z.B.
läuft dann die serielle Schnittstelle mit der falschen
Baudrate.
2. bin ich mir nicht sicher ob das ohne Auslöten
des Quarzes (oder ähnliche Modifikationen am Board)
geht.
Aber ja, das ist auch eine Sache die ich probieren möchte.
> Hängt oft vom Prescaler der UART ab ob man
> noch sinnvolle Baudrate erhält.
Manche Leute schreiben, daß das zumindest nicht trivial
ist, wenn man kein rundes Verhältnis zu 16MHz hat.
> Hier sicherlich unkritisch. Aber
> oft vermeidet man, wenn möglich,
> weitere asynchrone Takte. Liefern manchmal
> merkwürdige Effekte die schwer
> zu debuggen sind wenn sie selten auftreten.
Ich werde es zumindest probieren, sobald ich die 10MHz da
liegen habe ;)
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Rafael Deliano <rafael_deliano@arcor.de> |
|---|---|
| Date | 2019-08-14 17:42 +0200 |
| Message-ID | <qj1a5p$c15$1@dont-email.me> |
| In reply to | #261618 |
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. Dessen Endwert ist 0001... FFFFh per Register einstellbar, dann startet er wieder ab 0000. Er kann also einen krummen Teiler machen. Hier wäre das 16000d. Der Softwareteiler um auf 1Hz zu kommen ist dann 625d. Also auch ein 16 Bit Zähler. Der Interrupt des Timers kommt alle 1,6msec. Dieser Zähler wäre also ein kurzes Assemblerprogramm im Interrupt das ein 1Hz Flagbyte setzt. Das Flag wird in der Endloschleife die in HLL programmiert ist ausgelesen. Ausgabe der Hauptschleife wäre z.B. ein LCD-Display mit HD44780 bei dem die Sekunden mit diesen 1Hz geschrieben werden. MfG JRD
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-15 05:47 +0200 |
| Message-ID | <grk2vbFaopuU1@mid.individual.net> |
| In reply to | #261694 |
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. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Joerg Niggemeyer <joerg.niggemeyer@nucon.de> |
|---|---|
| Date | 2019-08-15 10:58 +0200 |
| Message-ID | <d65ed9e357.assel@nuconverter.de> |
| In reply to | #261699 |
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 ;-)
Liest man doch z.B. im KEA128Ref manual bei Real-Time-Counter , der genau
fuer diesen Zweck als Software Calendar fungiert (genau was Ralph braucht
mit Bsp. code), dass als Quelle ein externer Pin ohne Bus-sync eingesetzt
werden kann :)
Benutzt man einen ext Pin als Quelle für z.B. ein Timer-Module,
dann wird der externe Takt mit dem Bus Takt synchronisiert.
Hinweis im Manual, "This clock signal must not exceed 1/4 of system clock
frequency."
--
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-15 08:26 -0400 |
| Message-ID | <EruqilhzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261702 |
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! :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:36 +0200 |
| Message-ID | <grl5r0Fi07iU2@mid.individual.net> |
| In reply to | #261711 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2019-08-15 17:28 -0400 |
| Subject | Forth 2: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs |
| Message-ID | <Eruqy0bzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #261713 |
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! :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 18:52 +0200 |
| Message-ID | <qiupt4$u0k$1@news2.open-news-network.org> |
| In reply to | #261597 |
On 13.08.19 09:33, Ralph Aichinger wrote: > 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 moderne Alternative zum AVR ist der Cortex-M und die laufen nicht mit 600 MHz, sondern eher so mit 48...200 MHz, je nach Modell. Selbst der aller aller aller schlechteste Cortex-M0 (z.B. STM32F030) schlägt den Atmel noch um LÄNGEN in Geschwindigkeit, Peripherie und Flexibilität. Eine gescheite Open Source Toolchain, statt diesem avr-gcc Gefummel gibt's obendrein. Und viel billiger als diese AVRs ist er auch noch. Das schicke ist aber, dass man kein ätzendes Rumgefummel mehr mit der ekelhaften AVR Harvard Architektur mehr hat. Lookuptable im ROM? Einfach per Pointer drauf zugreifen. Endlich hat PROGMEM und read_pgm_byte() ein Ende. Bah hat mich das immer genervt. Würde ich mir echt NIE wieder antun, wenn ich in 2019 das µC Programmieren neu anfangen würde, NIE NIE wieder. Trotzdem ist es nicht so, dass du mit grober Rechenleistung so schlecht programmieren kannst, wie du willst. Gerade wenn dir Latenz wichtig ist, musst du schon nachdenken, wie du's hinschreibst. > 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? Stichwort hier ist ISR/DSR. Im ISR machst du nur die unbedingt notwendigen Sachen, in der DSR (Deferred Service Routine) dann das, wofür du Zeit hast. Anderes Stichwort ist WCET-Berechnung/Modellierung. Aber ehrlichgesagt klingen deine "langwierigen" Aufgaben nicht so, als ob du sie nicht alle im ISR abhandeln könntest. Sagen wir du hast einen 2560, du clockst den mit 16 MHz. Du wolltest 1 kHz ISR-Frequenz. In den zwei (!) Millisekunden die du da also hast, bevor du IRQs verlierst, kannst du also 32000 Clock Cycles ausführen. Viele Instuktionen des AVR sind single cycle. Das ist UNGLAUBLICH viel Leistung, die du da hast. Wenn du die eine Millisekunde überschreitest, während der ISR noch läuft, wird lediglich das IF gesetzt. Der ISR macht munter weiter und sobald du den dann verlässt, wird er sofort wieder angesprungen und IF gecleared. Interrupts verlierst du nur, wenn ein IRQ kommt wärend IF = 1 ist. Viele Grüße, Johannes
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2019-08-14 06:49 +0000 |
| Message-ID | <grhp6uFpmkqU1@mid.individual.net> |
| In reply to | #261617 |
Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: >On 13.08.19 09:33, Ralph Aichinger wrote: >> 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 moderne Alternative zum AVR ist der Cortex-M und die laufen nicht >mit 600 MHz, sondern eher so mit 48...200 MHz, je nach Modell. Selbst >der aller aller aller schlechteste Cortex-M0 (z.B. STM32F030) schlägt >den Atmel noch um LÄNGEN in Geschwindigkeit, Peripherie und >Flexibilität. Eine gescheite Open Source Toolchain, statt diesem avr-gcc >Gefummel gibt's obendrein. Und viel billiger als diese AVRs ist er auch >noch. Die Auswahl an ARMs in DIP oder 50 mil SO Gehäusen ist aber recht gering, was den Selbstbau etwas erschwert, so man nicht vom freundlichen Chinesen ein preiswertes Board erwirbt. Für den ARM spricht allerdings die Tatsache, daß viele bereits eine RTC mit Kalenderfunktion eingebaut haben. Auch die höhere Wortbreite von 16 oder 32 Bit erleichtert einiges. >Das schicke ist aber, dass man kein ätzendes Rumgefummel mehr mit der >ekelhaften AVR Harvard Architektur mehr hat. Lookuptable im ROM? Einfach >per Pointer drauf zugreifen. Endlich hat PROGMEM und read_pgm_byte() ein >Ende. Bah hat mich das immer genervt. Würde ich mir echt NIE wieder >antun, wenn ich in 2019 das µC Programmieren neu anfangen würde, NIE NIE >wieder. Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der Implementierung in gcc. Andere Compiler können das deutlich besser. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-08-14 09:58 +0200 |
| Message-ID | <qj0ev2$30s$1@pi.h5.or.at> |
| In reply to | #261635 |
Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
> Die Auswahl an ARMs in DIP oder 50 mil SO Gehäusen ist aber recht gering,
> was den Selbstbau etwas erschwert, so man nicht vom freundlichen Chinesen
> ein preiswertes Board erwirbt.
Bei der Fülle an tollen Boards würde ich da nicht selber an SMD-Teilen
mehr rumlöten, so hoch ist meine Motivation nicht. Besonders nett finde
ich die Teensy-Boards: Arduino-kompatibel (ist für mich wichtig,
die Arduino-Plattform hat so einen reichen Schatz an Libraries
für quasi alles, in dem Ökosystem gibtes fast nix was nicht schon
vorher jemand gemacht hat), relativ billig (15-25 Euro), gut supportet
(der Entwickler Paul Stoffregen antwortet oft persönlich im Forum),
in einem mechanisch praktischen Formfaktor (paßt in DIL-Sockel), und
neuerdings auch rohe Power bis 600MHz.
https://www.pjrc.com/store/teensy32.html
Allerdings finde ich einstweilen die Datenblätter der ARM-CPUs noch
eine Spur einschüchternder als die von AVR. 3000 Seiten Doku für den
Chip der im Teensy 4.0 steckt (i.MXRT1060, 600MHz Cortex-M7) ist schon
eine Ansage.
Aber auch die Cortex M4 aus den kleineren Modellen sind deutlich
komplexer als die 8-Bit-Atmels. Wenn man erst einsteigt in die
Materie, ist das nicht so ohne.
> Für den ARM spricht allerdings die Tatsache,
> daß viele bereits eine RTC mit Kalenderfunktion eingebaut haben.
> Auch die höhere Wortbreite von 16 oder 32 Bit erleichtert einiges.
Leider sind viele der im embedded-Bereich verwendeten Kalenderfunktionen
und Zeitfunktionen stark simplifiziert: Schaltsekunden werden ignoriert,
Sommerzeit-Wechsel nach irgendeinem starren Schema, etc.
Vor allem die fehlende Behandlung der Schaltsekunden tut mir weh. Wenn
ich schon eine Atomuhr bastle, dann soll sie das hinkriegen (z.B.
indem man die Ankündigung der Schaltsekunden aus DCF77 einliest oder
mit einer Taste aktiviert, daß am nächsten Quartalsende eine eingefügt
wird.
Allerdings werde ich viele viele andere Convenience-Libraries nutzen,
die es fertig gibt: Ansteuern von billigen Chinesen-Displays mit
dem TM1637-Treiberchip, parsen der NMEA-Sentences vom GPS an
der seriellen Schnittstelle, etc.
> Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der
> Implementierung in gcc. Andere Compiler können das deutlich besser.
Naja, in der Arduino-Umgebung ist das gut gekapselt, auch wenn dem
ganzen der gcc zugrundeliegt. Bei bisherigen Projekten hab ich
überhaupt noch nie so tief runtersteigen müssen, daß ich das
Datenblatt des Controllers gelesen hätte. Bei den Countern muß
das aber sein, dafür hat Arduino keine sinnvolle Abstraktion.
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-14 10:57 +0200 |
| Message-ID | <qj0idp$c6m$1@news2.open-news-network.org> |
| In reply to | #261647 |
On 14.08.19 09:58, Ralph Aichinger wrote: > https://www.pjrc.com/store/teensy32.html > > Allerdings finde ich einstweilen die Datenblätter der ARM-CPUs noch > eine Spur einschüchternder als die von AVR. 3000 Seiten Doku für den > Chip der im Teensy 4.0 steckt (i.MXRT1060, 600MHz Cortex-M7) ist schon > eine Ansage. > > Aber auch die Cortex M4 aus den kleineren Modellen sind deutlich > komplexer als die 8-Bit-Atmels. Wenn man erst einsteigt in die > Materie, ist das nicht so ohne. Du vergleichst aber halt auch Äpfel mit Birnen. Das ist wie wenn du das Handbuch von ner Cessna 172 gelesen und verstanden hast und dich dann wunderst, dass das einer Boeing 737 deutlich dicker und komplizierter ist. Die nächste Stufe vom AVR ist ein M0, M0+ oder vielleicht ein kleiner (!) M3 ohne viel Peripherie. Die M4s kommen dann schon deutlich dicker daher und die M7s sind eine GANZ andere Klasse. >> Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der >> Implementierung in gcc. Andere Compiler können das deutlich besser. > > Naja, in der Arduino-Umgebung ist das gut gekapselt, auch wenn dem > ganzen der gcc zugrundeliegt. Bei bisherigen Projekten hab ich > überhaupt noch nie so tief runtersteigen müssen, daß ich das > Datenblatt des Controllers gelesen hätte. Bei den Countern muß > das aber sein, dafür hat Arduino keine sinnvolle Abstraktion. Vermutlich ist das nicht gekapselt, sondern auch deine globalen const-Arrays liegen einfach im RAM. Das geht deshalb, weil der Mega2560 vergleichsweise viel RAM hat, ganz okay. Ist aber trotzdem eine Travestie. Gruß, JOhannes
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2019-08-14 11:10 +0200 |
| Message-ID | <qj0j5q$cqg$1@news2.open-news-network.org> |
| In reply to | #261635 |
On 14.08.19 08:49, Peter Heitzer wrote: >> Das schicke ist aber, dass man kein ätzendes Rumgefummel mehr mit der >> ekelhaften AVR Harvard Architektur mehr hat. Lookuptable im ROM? Einfach >> per Pointer drauf zugreifen. Endlich hat PROGMEM und read_pgm_byte() ein >> Ende. Bah hat mich das immer genervt. Würde ich mir echt NIE wieder >> antun, wenn ich in 2019 das µC Programmieren neu anfangen würde, NIE NIE >> wieder. > > Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der > Implementierung in gcc. Andere Compiler können das deutlich besser. Das hat sogar *ausschließlich* mit der Architektur zu tun. Du hast im AVR eine Pointergröße von 16 Bit, aber teilweise mehr als 64 kiB kombinierten Flash/SRAM. Das heißt, der Pointer kann notwendigerweise eben nicht die Information tragen, in welchen Bereich der jetzt zeigt. Klar könnte ein Compiler das einfach emulieren und 24 oder 32-Bit Pointer machen oder so ein gemurkse. Dann wird halt *jede* Indirektion im Programm unendlich lahm. Und klar, in einfachen Fällen (also wenn der Compiler garantiert entscheiden kann, welcher Bereich addressiert ist) geht das natürlich auch. Aber *Allgemein* lässt es sich nicht lösen, ohne dass der Programmierer "hints" geben muss, was gemeint ist. Teilweise brauchst du sogar, für die großen Devices, perverse Workarounds um das Laden von Programmspeicher überhalb der 16-Bit Grenze zu ermöglichen. Stichwort pgm_read_byte_far(). Das heißt, ich muss als Programmierer zur Compilezeit (!) wissen, wo mir mein Linker (!!) später ein Objekt hinlegt, damit ich unterscheiden kann, welche Funktion die geeignete ist. Oder natürlich die lahme _far() Variante immer nehmen. Das sind so viele Layer von Murks aufeinandergestapelt dass mir davon echt übel wird. Und das zieht sich dann durch alle Layer durch und erzeugt eine elendige Kopplung von Code zu Datenstrukturen. Genau die Kopplung, die man bei modernen Prozessoren halt nicht mehr braucht, weswegen man eben auch viel schöneren und portableren Code schreiben kann. Gruß, Johannes
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-14 11:40 +0200 |
| Message-ID | <gri38iFs4a6U1@mid.individual.net> |
| In reply to | #261664 |
Am 14.08.2019 um 11:10 schrieb Johannes Bauer: > Teilweise brauchst du sogar, für die großen Devices, perverse > Workarounds um das Laden von Programmspeicher überhalb der 16-Bit Grenze > zu ermöglichen. Stichwort pgm_read_byte_far(). Das heißt, ich muss als > Programmierer zur Compilezeit (!) wissen, wo mir mein Linker (!!) später > ein Objekt hinlegt, damit ich unterscheiden kann, welche Funktion die > geeignete ist. Aus genau diesem Grund habe ich seinerzeit die Benutzung der 8086 Architektur (mit Segmentierung) nicht verstanden. Bis ich dann das (MS?) Modell mit SEGMENT und GROUP verstanden habe. Das hielt dann bis zum 486, ab dem die Segmentierung wegen zu schlechter Performance durch Paging und flachen Adressraum ersetzt wurde, mit freiwilliger Beschränkung auf 4GB. Entsprechend sollte man halt in µC nicht mehr Speicher einbauen als die Pointerregister verkraften, bzw. bei Mehrbedarf auf einen größeren (32... Bit) Kern umsteigen. Für den Entwickler ist es dann schön, wenn er seinen alten Arduino Code erst einmal auf dem neuen Controller weiterlaufen lassen kann. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2019-08-14 13:58 +0000 |
| Message-ID | <griibmFjkbU1@mid.individual.net> |
| In reply to | #261664 |
Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: >On 14.08.19 08:49, Peter Heitzer wrote: >>> Das schicke ist aber, dass man kein ätzendes Rumgefummel mehr mit der >>> ekelhaften AVR Harvard Architektur mehr hat. Lookuptable im ROM? Einfach >>> per Pointer drauf zugreifen. Endlich hat PROGMEM und read_pgm_byte() ein >>> Ende. Bah hat mich das immer genervt. Würde ich mir echt NIE wieder >>> antun, wenn ich in 2019 das µC Programmieren neu anfangen würde, NIE NIE >>> wieder. >> >> Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der >> Implementierung in gcc. Andere Compiler können das deutlich besser. >Das hat sogar *ausschließlich* mit der Architektur zu tun. >Du hast im AVR eine Pointergröße von 16 Bit, aber teilweise mehr als 64 >kiB kombinierten Flash/SRAM. Das heißt, der Pointer kann >notwendigerweise eben nicht die Information tragen, in welchen Bereich >der jetzt zeigt. Das kann man aber nicht der Harvard Architektur als solche anlasten, sondern der Umsetzung im AVR-Core. Man hätte auch grössere Pointer einbauen können. Und auch in nicht Harvard CPU gibt es sowas, z.B. beim 8086 mit seinem segmentieren Speicher. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Michael Bäuerle <michael.baeuerle@stz-e.de> |
|---|---|
| Date | 2019-08-14 16:46 +0200 |
| Message-ID | <AABdVB7guVkAAAeb.A1.flnews@WStation5.stz-e.de> |
| In reply to | #261687 |
Peter Heitzer wrote: > Johannes Bauer <dfnsonfsduifb@gmx.de> wrote: > > On 14.08.19 08:49, Peter Heitzer wrote: > > > > > > [Nie wieder PROGMEM und read_pgm_byte()] > > > Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der > > > Implementierung in gcc. Andere Compiler können das deutlich besser. > > > > Das hat sogar *ausschließlich* mit der Architektur zu tun. > > > > Du hast im AVR eine Pointergröße von 16 Bit, aber teilweise mehr als 64 > > kiB kombinierten Flash/SRAM. Das heißt, der Pointer kann > > notwendigerweise eben nicht die Information tragen, in welchen Bereich > > der jetzt zeigt. "kombiniert" spielt keine Rolle. Flash und SRAM haben je einen eigenen Adressraum. Da die AVR RISC-Befehle 16-Bit groß sind wird das Flash auch so adressiert, d.h. die 16-Bit Pointer taugen ohne Krücken für 128KiByte Flash plus 64KiByte SRAM. Für so eine vergleichsweise langsame (max. 33MHz) 8-Bit Architektur ist das eigentlich ausreichend. Wer mehr Speicher braucht, dem dürfte i.d.R. auch die begrenzte Rechenleistung nicht ausreichen. > Das kann man aber nicht der Harvard Architektur als solche anlasten, sondern > der Umsetzung im AVR-Core. Man hätte auch grössere Pointer einbauen können. Ack. Das hätte dann aber etwas gekostet (Performance, Stromverbrauch, Chipfläche, etc.). Eine kleine MCU ist eigentlich immer ein Kompromiss. Sicherheitstechnisch hat diese Architektur auch Vorteile. Daten im Hauptspeicher (wo üblicherweise auch der Stack liegt) sind z.B. per Definition nicht als Code ausführbar. Auch ein verbogener Pointer oder eine verbogene Rücksprungadresse auf dem Stack kann nie auf Code des Angreifers zeigen. Die Tür bleibt offen für Sachen wie ROP [1], aber die einfachen Angriffe funktionieren nicht. ______________ [1] <https://de.wikipedia.org/wiki/Return_Oriented_Programming>
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web