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

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

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)

brauchst du also int getx_P() mit __flash und getx() ohne __flash. Das

Johannes

notwendigerweise eben nicht die Information tragen, in welchen Bereich der jetzt zeigt.

Pointer machen oder so ein gemurkse. Dann wird halt *jede* Indirektion

Compiler garantiert entscheiden kann, welcher Bereich addressiert ist)

ohne dass der Programmierer "hints" geben muss, was gemeint ist.

ein Objekt hinlegt, damit ich unterscheiden kann, welche Funktion die

Das sind so viele Layer von Murks aufeinandergestapelt dass mir davon

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

Johannes

Es ging darum, dass man Berechnungen, die vielleicht einmal am Tag

da es die Rechenleistung vielleicht hergibt, ist aber IMHO schlechter Stil.

man anwenden kann, um entsprechend in einer anderen Wiederholschleife, die nicht in sync zu einem Timer stehen muss und auch unterbrochen werden kann

Das Flag, ob eine Berechnung notwendig ist oder nicht , muss oder kann

eine Berechnung nur sehr selten vorkommt.

Das Flag bietet zudem den Vorteil, eine Berechnung auch aus einem anderen Event zu triggern, z.B. die Uhr wurde gestellt oder User command.

lediglich zu einer langsamen Reaktion, die eine einstellbare Eigenschaft

einem IR laufen muss also zeitlich zu einem event kritisch ist oder nicht.

Verschlabbern von kritischen IRs, wie bei der Programmierung von DCDC, wenns denn mal etwas schneller gehen soll, ist schlecht, dann machts Puff.....

frustiert auf ;-)

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

This electronic transmission (and any attached document) may contain  
confidential and/or privileged information. It is intended only for the  
person or entity to whom it is adressed. 
If you are not the intended recipient (or have received this e-mail in  
error) please notify the sender and destroy this e-mail or any attached  
document immediatly. Any unauthorized copying, disclosure or distribution  
of the material in this e-mail is strictly forbidden.

Am 14.08.2019 um 11:01 schrieb Johannes Bauer:

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

schnellen Flash???

DoDi

Josef

Am 14.08.2019 um 11:10 schrieb Johannes Bauer:

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

er seinen alten Arduino Code erst einmal auf dem neuen Controller weiterlaufen lassen kann.

DoDi

Es geht nicht um den Unterschied in der Geschwindigkeit sondern um die

(LPM) liegen kann!

Josef

Achso ja ... wollte noch sagen: PIC24 kann einen Teil seines Flash in den RAM-Adressraum mappen. Was aber nicht wirklich hilft, weil Befehle

"Phantom" Byte hat, welches immer 0 ist.

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.

JBC ist als atomarer Befehl nicht unterbrechbar. WOWEREIT.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Stimmt, so hab ichs auch immer gehandhabt... LA billiger? damals(tm) eher nicht...

Einsatz gehabt. Nachdem ich FORTH dann richtig(?) kapiert habe, brauchte

sparen :)

IR Ebenen (selten, PWF, BrownOut, 50Hz, 100Hz, 1kHz, 20kHz, 19kBd, ...)

(8050?)

Mein Liebling war der hp1608|1604(?) nannte sich LogigStateAnalyzer, hatte

Ebenen.

Hab ihn sogar fast immer benutzt, wenn ich mal Langzeit Protokolle

Speichererweiterung...

Mit dem hp konnte man leicht sowas fangen wie: 3x an pin1 gewackelt, dann

legen... Man konnte sich dann auch anzeigen lassen, bis wo er gerade im Triggerbaum geklommen war.

Schiene nie weiter benutzt, s.o.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Wechselrichtertrittgrenze, sehr lange her, jedesmal beim Anfahren der

simulieren kann. Damals gabs nur die KAWUMMMMM Methode.

beim debuggen auf.

bringen die Programme zum laufen :p

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Compiler im Kopp :)

Bei FORTH im Target ;)

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Ja genau, so macht man das.

Wie ein Kollege (Ex-Siemens) mal sagte, du kannst doch zum Stromsparen den

Ja. tolle Idee. Und so praktisch. Und so Siemens. Warum hat sich der das nicht patentieren lassen?

Rest angepasst.

Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! 

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Das kann man aber nicht der Harvard Architektur als solche anlasten, sondern

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

"kombiniert" spielt keine Rolle. Flash und SRAM haben je einen eigenen

Flash plus 64KiByte SRAM.

auch die begrenzte Rechenleistung nicht ausreichen.

Sicherheitstechnisch hat diese Architektur auch Vorteile. Daten im

die einfachen Angriffe funktionieren nicht.

______________ [1]

Pointer drauf zugreifen willst, dann kannst du das mit einem Pointer,

bei dem das MSB angibt, ob jetzt SRAM oder Flash gemeint ist.

Dann "funktioniert" alles so wie einer nicht-Harvard-Architektur

Indirektion wieder schauen muss und eine Fallunterscheidung machen

/nichtmal/ theoretisch denkbar.

Falsch. Adressierung in einem AVR erfolgt byteweise, d.h. jeweils auch

(siehe pgm_read_byte_far() im Vergleich zu pgm_read_byte_near()).

Johannes

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.

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.

Johannes

Naja, wir reden erstens hier von AVRs. Und klar kannst du mit beliebig

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

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

- Den Key Schedule zu machen

- 128 Bytes Strom zu generieren

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.

Johannes