Groups > de.sci.electronics > #261597 > unrolled thread

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

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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →

#261691

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-14 17:24 +0200
Message-ID	<qj192o$tcf$1@news2.open-news-network.org>
In reply to	#261690

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

[toc] | [prev] | [next] | [standalone]

#261695

From	Michael Bäuerle <michael.baeuerle@stz-e.de>
Date	2019-08-14 18:23 +0200
Message-ID	<AABdVDWe/2EAAAeb.A1.flnews@WStation5.stz-e.de>
In reply to	#261691

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

[toc] | [prev] | [next] | [standalone]

#261696

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-14 19:05 +0200
Message-ID	<qj1f1c$2h5$1@news2.open-news-network.org>
In reply to	#261695

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

[toc] | [prev] | [next] | [standalone]

#261704

From	Michael Bäuerle <michael.baeuerle@stz-e.de>
Date	2019-08-15 11:28 +0200
Message-ID	<AABdVSXNpGoAAAMq.A1.flnews@WStation5.stz-e.de>
In reply to	#261696

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.

[toc] | [prev] | [next] | [standalone]

#261706

From	Joerg Niggemeyer <joerg.niggemeyer@nucon.de>
Date	2019-08-15 13:43 +0200
Message-ID	<8a84e8e357.assel@nuconverter.de>
In reply to	#261704

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.:DE 31372201

[toc] | [prev] | [next] | [standalone]

#261712

From	Michael Bäuerle <michael.baeuerle@stz-e.de>
Date	2019-08-15 15:03 +0200
Message-ID	<AABdVVgZzoIAAAMq.A1.flnews@WStation5.stz-e.de>
In reply to	#261706

Joerg Niggemeyer wrote:
> Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:
> > 
> > 8-Bit MCUs nimmt man meistens auch gar nicht wegen der Architektur.
> > Wenn man eine Schaltung mit 5V laufen lassen möchte (z.B. weil 3.3V für
> > die InGaN-LEDs nicht ausreichen), dann ist es schon nett wenn die MCU
> > das direkt kann. Mit 32-Bit MCUs ist üblicherweise bei 3.3V Ende.
> 
> Sooo klein ist die Auswahl von 32bit ARM 5.5V Vcc nun auch wieder nicht.
> 
> z.B. Farnell KE0x Cortex M0+   2.7-5.5V ca. 1 EUR/st  (including RTC)

Ja, die Microchip SAM C20 können es auch. Cypress hat was mit 8 Pins
im Angebot. Lange Zeit aber eher einzelne Exoten und es sah sonst
meistens so aus:
<https://de.farnell.com/microchip/atsamd11c14a-ssut/mcu-32bit-cortex-m0-48mhz-soic/dp/2484375?st=Cortex%20M0>

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

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

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

[toc] | [prev] | [next] | [standalone]

#261769

From	Joerg Niggemeyer <joerg.niggemeyer@nucon.de>
Date	2019-08-16 13:45 +0200
Message-ID	<58876ce457.assel@nuconverter.de>
In reply to	#261712

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

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

Der Einsatz von 3V3 uCs ist nicht wirklich ein Problem, bzw. der Mangel an
Auswahl von 5V ARM, ein eventueller extra LDO 5->3.3 MIC5504 kostet in der 
Apotheke nur 0.07 cent (bei 100st)

System Basic chips (KFZ 12V) unterstützen ebenfalls wahlweise
5.0 oder 3V3 - würde man ja nicht wahlweise anbieten, wenn es keiner
verlangt ;-)

Bei zwei AA würde ich ohnehin eher zu einem uC greifen, der nicht
bis 5.5V geht, sondern bis  max 3V3 dafür deutlich runter in Kombi
mit z.B. adjustable LDO  AP7330

Falls mehrere ICs 5V VCC benötigen, dann würde ich einen passenden
5V uC dazu nehmen - insbesondere wenn z.B. bei automotive einige ICs ein
Enable von min. 4.5V haben.

Bei meinen uC gesteuerten Buck Platinen nehme ich natürlich eine
rote Signal LED, um  empty Batt Warnung anzeigen zu können ;-)
Ob da jetzt weiss schöner wäre - möglich aber nicht sinnvoll.
Da drei AAA (NimH) für die w P-LED direkt zu knapp sind habe ich 4 AAA.

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

[toc] | [prev] | [next] | [standalone]

#261692

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-14 17:29 +0200
Message-ID	<qj19c1$tga$1@news2.open-news-network.org>
In reply to	#261687

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

[toc] | [prev] | [next] | [standalone]

#261700

From	Hans-Peter Diettrich <DrDiettrich1@aol.com>
Date	2019-08-15 06:10 +0200
Message-ID	<grk4ahFb0osU1@mid.individual.net>
In reply to	#261692

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

[toc] | [prev] | [next] | [standalone]

#261701

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-15 09:13 +0200
Message-ID	<qj30mg$9uo$1@news2.open-news-network.org>
In reply to	#261700

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

[toc] | [prev] | [next] | [standalone]

#261703

From	Josef Moellers <josef.moellers@invalid.invalid>
Date	2019-08-15 11:16 +0200
Message-ID	<grkm85Fem5qU1@mid.individual.net>
In reply to	#261701

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

[toc] | [prev] | [next] | [standalone]

#261637

From	Rainer Knaepper <rainerk@smial.prima.de>
Date	2019-08-14 00:27 +0200
Message-ID	<ErptXG-TrLB@smial.prima.de>
In reply to	#261617

dfnsonfsduifb@gmx.de (Johannes Bauer)  am 13.08.19 um 18:52:

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

Mithin jedesmal, wenn die ISR zweimal nacheinander zu lange dauert.

Aber welche ISR soll ständig mehr als 16.000 instruktionen abarbeiten,
oder meinetwegen 10.000, wenn man im Schnitt mit 1.6 Takten pro Befehl
rechnet?

Die muß doch in der Anwendung nur bei jedem IRQ ein paar Register
updaten, Warteschleifen legt man da ja nicht rein.

Der Rest läuft außerhalb.

Rainer

-- 
Es ging bei dem Überwachungswahn noch nie um Terrorismus, sondern um
die allgemeine Paranoia eines Staates vor seinen eigenen Bürgern.
(Hergen Lehmann in ger.ct)

[toc] | [prev] | [next] | [standalone]

#261657

From	Markus Faust <mfaust@htwm.de>
Date	2019-08-14 10:31 +0200
Message-ID	<qj0gtd$3cd$1@news.albasani.net>
In reply to	#261617

Am 13.08.2019 um 18:52 schrieb Johannes Bauer:
> 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.

Das geht seit ca. 5 Jahren auch einfacher:
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_flash_und_Embedded-C

HTH
Markus

[toc] | [prev] | [next] | [standalone]

#261663

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-14 11:01 +0200
Message-ID	<qj0ilp$car$1@news2.open-news-network.org>
In reply to	#261657

On 14.08.19 10:31, Markus Faust wrote:
> Am 13.08.2019 um 18:52 schrieb Johannes Bauer:
>> 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.
> 
> Das geht seit ca. 5 Jahren auch einfacher:
> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_flash_und_Embedded-C

Naja, ob ich da jetzt PROGMEM stehen habe oder __flash ist ja Jacke wie
Hose. Tatsache ist, dass du immernoch wissen musst, wo das Objekt liegt,
damit die Zugriffe richtig generiert werden. Also beispielsweise:

int getx(const int *addr) {
	return *addr;
}

erzeugt im Assembly:

  a6:	fc 01       	movw	r30, r24
  a8:	80 81       	ld	r24, Z
  aa:	91 81       	ldd	r25, Z+1	; 0x01

während

int getx(const int __flash *addr) {
	return *addr;
}

  a6:	fc 01       	movw	r30, r24
  a8:	85 91       	lpm	r24, Z+
  aa:	95 91       	lpm	r25, Z+

erzeugt. So und jetzt nutzen wir die:

extern const int __flash x;

int main() {
	const int foo = 0;
	getx(&x);
	getx(&foo);
}

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.

Gruß,
Johannes

[toc] | [prev] | [next] | [standalone]

#261666

From	Hans-Peter Diettrich <DrDiettrich1@aol.com>
Date	2019-08-14 11:23 +0200
Message-ID	<gri27vFrtsbU1@mid.individual.net>
In reply to	#261663

Am 14.08.2019 um 11:01 schrieb Johannes Bauer:

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

Tja, einen Tod muß man sterben. Entweder greift man auf Konstanten im 
ROM (flash...) zu, oder kopiert sie von dort beim Reset ins RAM.

Wobei ich nicht so recht verstehe, warum die Hardware Unterschiede 
zwischen Flash und RAM lesen macht. Beim EEPROM ist das noch 
verständlich, wenn dort die Zugriffe weit langsamer sind, aber beim 
schnellen Flash???

DoDi

[toc] | [prev] | [next] | [standalone]

#261671

From	Josef Moellers <josef.moellers@invalid.invalid>
Date	2019-08-14 11:42 +0200
Message-ID	<gri3boFs49bU1@mid.individual.net>
In reply to	#261666

On 14.08.19 11:23, Hans-Peter Diettrich wrote:
> Am 14.08.2019 um 11:01 schrieb Johannes Bauer:
> 
>> 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.
> 
> Tja, einen Tod muß man sterben. Entweder greift man auf Konstanten im
> ROM (flash...) zu, oder kopiert sie von dort beim Reset ins RAM.
> 
> Wobei ich nicht so recht verstehe, warum die Hardware Unterschiede
> zwischen Flash und RAM lesen macht. Beim EEPROM ist das noch
> verständlich, wenn dort die Zugriffe weit langsamer sind, aber beim
> schnellen Flash???
> 

Es geht nicht um den Unterschied in der Geschwindigkeit sondern um die
Tatsache, daß die Adresse X sowohl im RAM (LD/ST) als auch um Flash
(LPM) liegen kann!

Josef

[toc] | [prev] | [next] | [standalone]

#261672

From	Josef Moellers <josef.moellers@invalid.invalid>
Date	2019-08-14 11:50 +0200
Message-ID	<gri3qmFs7uqU1@mid.individual.net>
In reply to	#261671

On 14.08.19 11:42, Josef Moellers wrote:
> On 14.08.19 11:23, Hans-Peter Diettrich wrote:
>> Am 14.08.2019 um 11:01 schrieb Johannes Bauer:
>>
>>> 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.
>>
>> Tja, einen Tod muß man sterben. Entweder greift man auf Konstanten im
>> ROM (flash...) zu, oder kopiert sie von dort beim Reset ins RAM.
>>
>> Wobei ich nicht so recht verstehe, warum die Hardware Unterschiede
>> zwischen Flash und RAM lesen macht. Beim EEPROM ist das noch
>> verständlich, wenn dort die Zugriffe weit langsamer sind, aber beim
>> schnellen Flash???
>>
> 
> Es geht nicht um den Unterschied in der Geschwindigkeit sondern um die
> Tatsache, daß die Adresse X sowohl im RAM (LD/ST) als auch um Flash
> (LPM) liegen kann!

Achso ja ... wollte noch sagen: PIC24 kann einen Teil seines Flash in
den RAM-Adressraum mappen. Was aber nicht wirklich hilft, weil Befehle
24 Bit lang sind und jeder 24-Bit lange Befehl ein zusätzliches
"Phantom" Byte hat, welches immer 0 ist.

[toc] | [prev] | [next] | [standalone]

#261684

From	"Wolfgang Allinger" <all2001@spambog.com>
Date	2019-08-14 07:34 -0400
Message-ID	<ErqqJJTzQoB@allinger-307049.user.uni-berlin>
In reply to	#261663

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

> On 14.08.19 10:31, Markus Faust wrote:
>> Am 13.08.2019 um 18:52 schrieb Johannes Bauer:
>>> 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.
>>
>> Das geht seit ca. 5 Jahren auch einfacher:
>> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_flash_u
>> nd_Embedded-C

> Naja, ob ich da jetzt PROGMEM stehen habe oder __flash ist ja Jacke wie
> Hose. Tatsache ist, dass du immernoch wissen musst, wo das Objekt liegt,
> damit die Zugriffe richtig generiert werden. Also beispielsweise:

> int getx(const int *addr) {
> 	return *addr;
> }

> erzeugt im Assembly:

>   a6:	fc 01       	movw	r30, r24
>   a8:	80 81       	ld	r24, Z
>   aa:	91 81       	ldd	r25, Z+1	; 0x01

> während

> int getx(const int __flash *addr) {
> 	return *addr;
> }

>   a6:	fc 01       	movw	r30, r24
>   a8:	85 91       	lpm	r24, Z+
>   aa:	95 91       	lpm	r25, Z+

> erzeugt. So und jetzt nutzen wir die:

> extern const int __flash x;

> int main() {
> 	const int foo = 0;
> 	getx(&x);
> 	getx(&foo);
> }

> 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 ;)


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]

#261693

From	Johannes Bauer <dfnsonfsduifb@gmx.de>
Date	2019-08-14 17:34 +0200
Message-ID	<qj19m0$toe$1@news2.open-news-network.org>
In reply to	#261684

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

[toc] | [prev] | [next] | [standalone]

#261707

From	"Wolfgang Allinger" <all2001@spambog.com>
Date	2019-08-15 07:21 -0400
Message-ID	<EruqiBxzQoB@allinger-307049.user.uni-berlin>
In reply to	#261693

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 Ren(n)tier 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! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →

csiph-web

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

Contents

#261691

#261695

#261696

#261704

#261706

#261712

#261769

#261692

#261700

#261701

#261703

#261637

#261657

#261663

#261666

#261671

#261672

#261684

#261693

#261707