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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 15.08.19 06:10, Hans-Peter Diettrich wrote:
Quoted text here. Click to load it



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




zeigen aber nie zwei *identische* Adressen, die auf unterschiedliche
Bytes zeigen. Und das ist bei einer Harvard-Archtitektur anders und
darum ging's mir.


Quoted text here. Click to load it


ehrlichgesagt auch nicht so ganz. War damals bestimmt sinnvoll, die
werden sich schon was gedacht haben dabei :-)


Johannes

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 15.08.19 09:13, Johannes Bauer wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it





Josef

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 13.08.2019 um 18:52 schrieb Johannes Bauer:

Quoted text here. Click to load it

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

HTH
Markus

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 10:31, Markus Faust wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

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

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 14.08.2019 um 11:01 schrieb Johannes Bauer:

Quoted text here. Click to load it

Quoted text here. Click to load it



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

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 11:23, Hans-Peter Diettrich wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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

(LPM) liegen kann!

Josef

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 11:42, Josef Moellers wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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.

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

On 14 Aug 19 at group /de/sci/electronics in article qj0ilp$car$ snipped-for-privacy@news2.open-news-network.org

Quoted text here. Click to load it

Quoted text here. Click to load it







Quoted text here. Click to load it






Quoted text here. Click to load it



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
We've slightly trimmed the long signature. Click to see the full one.
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 13:34, Wolfgang Allinger wrote:

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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


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


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

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

On 14 Aug 19 at group /de/sci/electronics in article qj19m0$toe$ snipped-for-privacy@news2.open-news-network.org

Quoted text here. Click to load it



Quoted text here. Click to load it




Quoted text here. Click to load it


schon 10a als Ren(n)tier voll habe :)



Wolfgang

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

ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
We've slightly trimmed the long signature. Click to see the full one.
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 13.08.2019 um 09:33 schrieb Ralph Aichinger:

Quoted text here. Click to load it


Quoted text here. Click to load it




Quoted text here. Click to load it





Berechnung gemacht werden soll, die Adresse einer normalen Subroutine  

Programm nicht dorthin springt, wo INT das Programm unterbrochen hat,  
sondern in die Subroutine deren Adresse jetzt auf dem Stack steht.




Ich glaube, das Status Register musste man auch noch auf den Stack  



von lassen und das so machen, wie weiter oben von anderen Postern  
beschrieben.


Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 15.08.2019 um 20:22 schrieb Stefan:


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it



mit Stack Overflow ab, so oder so. Andernfalls baut sich der Stack  
wieder ab, so oder so.

DoDi

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it





Quoted text here. Click to load it





Aber wie schon geschrieben: Einfacher ist es, solche Dinge in eine  
Idl-Routine zu verlegen, d.h. das Programm besteht aus einer  
Hauptschleife in der zeitunkritische Dinge zyklisch abgearbeitet werden  
und INT-Routinen, in denen der Rest passiert. Eine INT-Routine kann dann  
ein Flag setzen, mit dem der Hauptschleife signalisiert, dass etwas  
berechnet werden soll.

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 16.08.2019 um 06:56 schrieb Stefan:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it



Das verstehe ich nicht. Es liegt doch weniger am Prozessor als an der  
reentrant Programmierung des Handlers.


Quoted text here. Click to load it




DoDi

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Am 16.08.2019 um 09:06 schrieb Hans-Peter Diettrich:
Quoted text here. Click to load it



Quoted text here. Click to load it


Da wurde der jeweils aktivierte INT wieder scharf geschaltet, wenn ein  

konnte der folgende INT verloren gehen.

Mit AVR habe ich sowas nicht gemacht weil ich den eh nur in C  


Beim STM32 muss/kann man auch in "C" das entsprechende Flag selber frei  

reentrante Routinen zu schreiben. Hab ich bisher vermieden.




Site Timeline