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

[Andreas Neumann]

Wolfgang Allinger wrote:

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

Ja genau, so macht man das.

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

Rest angepasst.

 

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article qj0uhj$1hdh$1@gioia.aioe.org
<an5275@sedo.com> (Andreas Neumann) wrote:

Wolfgang Allinger wrote:

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

Ja genau, so macht man das.

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

Weist Du das mit der Anmeldung wirklich? Gängig war ja eine vor Kollegen
verheimlichte Anmeldung. Öfters erlebt, Idee geklaut und angemeldet

Rest angepasst.

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

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

 

[Peter Heitzer]

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

 

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>

 

[Johannes Bauer]

On 14.08.19 16:46, Michael Bäuerle wrote:

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.

Doch, tut es. Denn wenn du die Adressräume vermischst und per "unified"
Pointer drauf zugreifen willst, dann kannst du das mit einem Pointer,
der groß genug ist, problemlos machen. Also Beispiel: 32 Bit pointer,
bei dem das MSB angibt, ob jetzt SRAM oder Flash gemeint ist.

Dann "funktioniert" alles so wie einer nicht-Harvard-Architektur
gewohnt, aber ist natĂźrlich arschlangsam, weil der Compiler bei jeder
Indirektion wieder schauen muss und eine Fallunterscheidung machen
mßsste. Wäre aber /theoretisch/ denkbar.

Wenn die Pointer aber kleiner sind als die kombinierte Größe, ist es
/nichtmal/ theoretisch denkbar.

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.

Falsch. Adressierung in einem AVR erfolgt byteweise, d.h. jeweils auch
nur bis 64 kiB Flash. FĂźr 128 kiB Flash brauchst du eben also KrĂźcken
(siehe pgm_read_byte_far() im Vergleich zu pgm_read_byte_near()).

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.

Ein größerer Cortex-M hat mit einer MPU und Privilegienseparierung
sicherlich deutlich mächtigere Mittel, die Laufzeitumgebung abzusichern.
Und eben nicht die krĂźckigen Nachteile von dem Murks-AVR.

Gruß,
Johannes

 

[Johannes Bauer]

On 14.08.19 15:58, Peter Heitzer wrote:

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.

Größere Pointer würden erlauben, einen "normalen" UMA Zugriff zu
emulieren, aber das wäre immernoch nicht performant.

Stell dir vor, der AVR hätte ein 64-Bit breites Pointerregister.
Unglaublich viel Platz um alles unterzubrigen. Trotzdem gibt es jede
Adresse zweimal: 0x0 kann entweder also an den Start des Flashes zeigen
oder an den Start des SRAMs. Wegen Hardvard. Du hast also dasselbe
Problem, dass du in den Funktionen jeweils wissen musst, was "gemeint"
ist, wenn du mit Pointern handtierst.

Und auch in nicht Harvard CPU gibt es sowas, z.B. beim 8086 mit seinem
segmentieren Speicher.

Die Segmentselektoren zusammen mit dem Offset ergeben aber auch beim
8086 jeweils eine lineare Adresse, x + 16y. Und 0123:4567 zeigt immer
auf dasselbe Byte und das gibt die nicht einmal im RAM und ein anderes
Mal, durch andere Befehle zugegriffen, irgendwo anders.

Gruß,
Johannes

 

[Johannes Bauer]

On 14.08.19 13:34, Wolfgang Allinger wrote:

Das gibt nicht mal eine WARNUNG (-Wall, avr-gcc 5.4.0) dass getx(&foo)
eben totale GrĂźtze macht, weil das Symbol woanders liegt. Und immernoch
brauchst du also int getx_P() mit __flash und getx() ohne __flash. Das
ist unendlich ätzend.

Schöne Betätigung für meine Ätzerei: Bei C hat der Programmierer den
Compiler im Kopp

Bei FORTH im Target

Naja, wir reden erstens hier von AVRs. Und klar kannst du mit beliebig
viel Abstraktionsebenen und entsprechendem Overhead fĂźr den Nutzer alles
"schĂśn" erscheinen lassen, aber es wird dann halt echt lahm. 32-Bit
Pointer auf einem AVR zu emulieren ist Ăźberhaupt kein Problem und dann
kannste in deinen virtuellen Adressraum auch den EEPROM einblenden und
sogar Schreibzugriffe auf den einfach so "magisch" erledigen lassen.

Ich kenne zu FORTH interessanterweise keine Performance-Benchmarks. Aber
wĂźrde mich mal interessieren, z.B. das hier:

https://en.wikipedia.org/wiki/Forth_(programming_language)#A_complete_RC4_cipher_program

Wieviel RAM und welche Laufzeit braucht das auf einem ATmega32 @ 16 MHz um

- Den Key Schedule zu machen
- 128 Bytes Strom zu generieren

WĂźrde mich echt interessieren. Wenn das einer von den FORTHlern mal
misst und die Ergebnisse schreibt, mach ich das auch in C und poste die
Ergebnisse. Bin gespannt wie weit die auseinander liegen, ob das jetzt
25, 50, 200 oder 1000% Unterschied in der Laufzeit sind.

Gruß,
Johannes

 

[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.
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

 

Johannes Bauer wrote:

On 14.08.19 16:46, Michael Bäuerle wrote:
Peter Heitzer wrote:
Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

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.

Doch, tut es. Denn wenn du die Adressräume vermischst und per "unified"
Pointer drauf zugreifen willst, dann kannst du das mit einem Pointer,
der groß genug ist, problemlos machen. Also Beispiel: 32 Bit pointer,
bei dem das MSB angibt, ob jetzt SRAM oder Flash gemeint ist.

Der avr-gcc macht das intern auch in der Art, s.u.

Dann "funktioniert" alles so wie einer nicht-Harvard-Architektur
gewohnt, aber ist natürlich arschlangsam, weil der Compiler bei jeder
Indirektion wieder schauen muss und eine Fallunterscheidung machen
müsste. Wäre aber /theoretisch/ denkbar.

C ist für von Neumann Architektur vorgesehen und die verschiedenen
Adressräume sind dort eigentlich prinzipiell eine Krücke. Wirklich
schön wird das nie sein.

Wenn die Pointer aber kleiner sind als die kombinierte Größe, ist es
/nichtmal/ theoretisch denkbar.

Wenn man via avr-objdump aus einem ELF-Binary die Symbol-Table anzeigen
lässt, stehen die Offsets für SRAM und EEPROM dort noch drin.
Der Compiler macht es intern also im Prinzip so und erst am Ende wird
alles zerlegt.

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.

Falsch. Adressierung in einem AVR erfolgt byteweise, d.h. jeweils auch
nur bis 64 kiB Flash. Für 128 kiB Flash brauchst du eben also Krücken
(siehe pgm_read_byte_far() im Vergleich zu pgm_read_byte_near()).

Du hast Recht. Für SPM wird der Z-Pointer wordweise (wie hardwaremäßig
implementiertš), für LPM aber byteweise interpretiert. Allgemein ist das
Limit also für das Flash auch 64KiByte.

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.

Ein größerer Cortex-M hat mit einer MPU und Privilegienseparierung
sicherlich deutlich mächtigere Mittel, die Laufzeitumgebung abzusichern.

Dass etwas prinzipiell nicht funktioniert hat IMHO schon auch seinen
Reiz.

> Und eben nicht die krückigen Nachteile von dem Murks-AVR.

Ich wollte die für "große" AVRs nötigen Krücken nicht schönreden.
Unterhalb dieser Limits empfinde ich die Architektur an sich aber
deutlich weniger schlimm als du beschrieben hast.


______________
š Zitat aus einem AVR-Datenblatt:
"Since all AVR instructions are 16 or 32 bits wide,
the Flash is organized as [Anzahl Words] x 16 bits."

 

[Johannes Bauer]

On 14.08.19 18:23, Michael Bäuerle wrote:

Ein größerer Cortex-M hat mit einer MPU und Privilegienseparierung
sicherlich deutlich mächtigere Mittel, die Laufzeitumgebung abzusichern.

Dass etwas prinzipiell nicht funktioniert hat IMHO schon auch seinen
Reiz.

Ist natĂźrlich richtig.

Und eben nicht die krĂźckigen Nachteile von dem Murks-AVR.

Ich wollte die für "große" AVRs nötigen Krücken nicht schönreden.
Unterhalb dieser Limits empfinde ich die Architektur an sich aber
deutlich weniger schlimm als du beschrieben hast.

Ja, ich dramatisiere. Man muss die AVRs halt auch im Kontext ihrer Zeit
sehen. Als ich mit ÂľC Programmierung angefangen habe war das 6800 und
8051, mit fast komplett externer Peripherie. Die ersten AVRs die ich
dann in der Hand hatte, AT90S1200 und AT90S2313, waren dagegen eine
ECHTE Offenbarung. Der 2313 hatte sogar ein UART mit drin, das war schon
ziemlich cool und tonnenweise RAM. Das ist jetzt aber halt auch 14 Jahre
her und fĂźr damals war das echt bahnbrechend. Ein Open-Source Compiler
noch dazu, echt krass.

Mittlerweile hat aber ja auch Atmel/Microchip auf Cortex-M umgesattelt,
dagegen konvergiert der Embedded-Bereich offenbar komplett -- und nicht
ohne Grund. Das ist nämlich auch eine extrem sauber durchdachte, tolle
Architektur.

Aber ich werde mir deinen Tipp zu Herzen nehmen und versuchen,
wohlwollender gegenĂźber den AVRs zu sein.

Viele Grüße,
Johannes

 

[Hans-Peter Diettrich]

Am 14.08.2019 um 12:44 schrieb Wolfgang Allinger:

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

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

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

JBC ist als atomarer Befehl nicht unterbrechbar. WOWEREIT.

Du hast atomare Zugriffe nicht verstanden :-(

DoDi

 

[Hans-Peter Diettrich]

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

 

[Hans-Peter Diettrich]

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

 

[Hans-Peter Diettrich]

Am 14.08.2019 um 17:29 schrieb Johannes Bauer:

Die Segmentselektoren zusammen mit dem Offset ergeben aber auch beim
8086 jeweils eine lineare Adresse, x + 16y. Und 0123:4567 zeigt immer
auf dasselbe Byte und das gibt die nicht einmal im RAM und ein anderes
Mal, durch andere Befehle zugegriffen, irgendwo anders.

Das ist nicht ganz richtig. Die Segmentregister werden in eigenen
Befehlen gesetzt, die Ăźbrigen Befehle greifen dann auf denjenigen
Speicherbereich zu, der (zufällig?) gerade im Segmentregister steht.

DafĂźr hat beim 8086 jedes Byte 16 verschiedene Adressen - was fĂźr 'ne
Verschwendung ;-)

DoDi

 

[Johannes Bauer]

On 15.08.19 06:10, Hans-Peter Diettrich wrote:

Am 14.08.2019 um 17:29 schrieb Johannes Bauer:

Die Segmentselektoren zusammen mit dem Offset ergeben aber auch beim
8086 jeweils eine lineare Adresse, x + 16y. Und 0123:4567 zeigt immer
auf dasselbe Byte und das gibt die nicht einmal im RAM und ein anderes
Mal, durch andere Befehle zugegriffen, irgendwo anders.

Das ist nicht ganz richtig. Die Segmentregister werden in eigenen
Befehlen gesetzt, die Ăźbrigen Befehle greifen dann auf denjenigen
Speicherbereich zu, der (zufällig?) gerade im Segmentregister steht.

Das mag sein, aber war gar nicht meine Aussage. Sondern eben, dass die
Adresse 0123:4567 immer der linearen Adresse 0x5797 im RAM entspricht,
ganz gleich wo das passiert. Wenn im Segmentselektor-Register oder
Offset, der in der Instruktion codiert ist, jeweils was drin steht, das
eben nicht 0x0123 respektive 0x4567 ist, landest du natĂźrlich
mĂśglicherweise woanders.

Es gibt da natĂźrlich aber auch viele Adressen, die auf dasselbe Byte
zeigen aber nie zwei *identische* Adressen, die auf unterschiedliche
Bytes zeigen. Und das ist bei einer Harvard-Archtitektur anders und
darum ging's mir.

DafĂźr hat beim 8086 jedes Byte 16 verschiedene Adressen - was fĂźr 'ne
Verschwendung ;-)

Ja, die Vorteile einer solchen Segmentierung erschließen sich mir
ehrlichgesagt auch nicht so ganz. War damals bestimmt sinnvoll, die
werden sich schon was gedacht haben dabei

Viele Grüße,
Johannes

 

[Joerg Niggemeyer]

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.E 31372201

 

[Josef Moellers]

On 15.08.19 09:13, Johannes Bauer wrote:

On 15.08.19 06:10, Hans-Peter Diettrich wrote:
Am 14.08.2019 um 17:29 schrieb Johannes Bauer:

Die Segmentselektoren zusammen mit dem Offset ergeben aber auch beim
8086 jeweils eine lineare Adresse, x + 16y. Und 0123:4567 zeigt immer
auf dasselbe Byte und das gibt die nicht einmal im RAM und ein anderes
Mal, durch andere Befehle zugegriffen, irgendwo anders.

Das ist nicht ganz richtig. Die Segmentregister werden in eigenen
Befehlen gesetzt, die Ăźbrigen Befehle greifen dann auf denjenigen
Speicherbereich zu, der (zufällig?) gerade im Segmentregister steht.

Das mag sein, aber war gar nicht meine Aussage. Sondern eben, dass die
Adresse 0123:4567 immer der linearen Adresse 0x5797 im RAM entspricht,
ganz gleich wo das passiert. Wenn im Segmentselektor-Register oder
Offset, der in der Instruktion codiert ist, jeweils was drin steht, das
eben nicht 0x0123 respektive 0x4567 ist, landest du natĂźrlich
mĂśglicherweise woanders.

Es gibt da natĂźrlich aber auch viele Adressen, die auf dasselbe Byte
zeigen aber nie zwei *identische* Adressen, die auf unterschiedliche
Bytes zeigen. Und das ist bei einer Harvard-Archtitektur anders und
darum ging's mir.

Das ist aber eben nicht primär etwas spezifisches fßr die Segmentierung
des x86. Denkbar wäre, daß alle Zugriffe über CS in den
Programmspeicher, und alle Ăźber DS, ES und SS in den Datenspeicher gehen.

Josef

 

Johannes Bauer wrote:

On 14.08.19 18:23, Michael Bäuerle wrote:
Johannes Bauer wrote:

[...]
Und eben nicht die krückigen Nachteile von dem Murks-AVR.

Ich wollte die für "große" AVRs nötigen Krücken nicht schönreden.
Unterhalb dieser Limits empfinde ich die Architektur an sich aber
deutlich weniger schlimm als du beschrieben hast.

Ja, ich dramatisiere. Man muss die AVRs halt auch im Kontext ihrer Zeit
sehen. Als ich mit ľC Programmierung angefangen habe war das 6800 und
8051, mit fast komplett externer Peripherie. Die ersten AVRs die ich
dann in der Hand hatte, AT90S1200 und AT90S2313, waren dagegen eine
ECHTE Offenbarung. Der 2313 hatte sogar ein UART mit drin, das war schon
ziemlich cool und tonnenweise RAM. Das ist jetzt aber halt auch 14 Jahre
her und für damals war das echt bahnbrechend. Ein Open-Source Compiler
noch dazu, echt krass.

Der 1200er war mit dem Hardwarestack auch noch arg beschränkt. SRAM
hatte er auch keines. Im realen Einsatz kam es auch öfter vor, dass
er seine Signature "vergessen" hat und dann vom Programmiergerät nicht
mehr erkannt wurde. AT90S2313 und AT90S8515 waren gut.

Mittlerweile hat aber ja auch Atmel/Microchip auf Cortex-M umgesattelt,
dagegen konvergiert der Embedded-Bereich offenbar komplett -- und nicht
ohne Grund. Das ist nämlich auch eine extrem sauber durchdachte, tolle
Architektur.

Ja, was anderes wollte ich auch nicht unterstellen.

Aber ich werde mir deinen Tipp zu Herzen nehmen und versuchen,
wohlwollender gegenüber den AVRs zu sein.

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

Dass alle AVRs teuer wären, wie oft zu lesen, stimmt auch nicht:
Ein ATtiny402 kostet z.B. 30˘@100.

 

[Joerg Niggemeyer]

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

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

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

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



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

 

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article qj19m0$toe$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 14.08.19 13:34, Wolfgang Allinger wrote:

Ich kenne zu FORTH interessanterweise keine Performance-Benchmarks. Aber
würde mich mal interessieren, z.B. das hier:

https://en.wikipedia.org/wiki/Forth_(programming_language)#A_complete_RC4_ci
pher_program

Wieviel RAM und welche Laufzeit braucht das auf einem ATmega32 @ 16 MHz um

- Den Key Schedule zu machen
- 128 Bytes Strom zu generieren

Würde mich echt interessieren. Wenn das einer von den FORTHlern mal
misst und die Ergebnisse schreibt, mach ich das auch in C und poste die
Ergebnisse. Bin gespannt wie weit die auseinander liegen, ob das jetzt
25, 50, 200 oder 1000% Unterschied in der Laufzeit sind.

Sorry, bin zu lange raus aus dem Geschäft. Gerade festgestellt, dass ich
schon 10a als Rentier voll habe


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

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