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

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
Am 15.08.2019 um 14:26 schrieb Wolfgang Allinger:


Quoted text here. Click to load it

Aha, das beantwortet meine Frage schon fast. Heute versteht man unter  
FORTH eine Compilersprache (embedded...), ohne Interpreter.

Quoted text here. Click to load it

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

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

On 15 Aug 19 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net

Quoted text here. Click to load it


Quoted text here. Click to load it


Nein, FORTH ist immer Interpreter und Compiler, wenn man nicht will, dass  

verrammelt (also das Eingabe Prompt) und wenn man das in ein kleines ROM/  

Assembler wegmachen und nur noch der Inner Interpreter bleibt drin.

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-  

heute USB, Ethernet, LAN, WAN...) bedient wird, Du hast also sowas wie    
Compiler Interpreter auf Host und Target verstreut. Wenn Du dann noch  

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,

Quoted text here. Click to load it


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  


Sh, auch Paralell Faden FORTH 1.




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 13.08.19 09:33, Ralph Aichinger 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

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



Gefummel gibt's obendrein. Und viel billiger als diese AVRs ist er auch
noch.


ekelhaften AVR Harvard Architektur mehr hat. Lookuptable im ROM? Einfach
per Pointer drauf zugreifen. Endlich hat PROGMEM und read_pgm_byte() ein


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.

Quoted text here. Click to load it




Quoted text here. Click to load it

Stichwort hier ist ISR/DSR. Im ISR machst du nur die unbedingt
notwendigen Sachen, in der DSR (Deferred Service Routine) dann das,


Aber ehrlichgesagt klingen deine "langwierigen" Aufgaben nicht so, als

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,

sind single cycle. Das ist UNGLAUBLICH viel Leistung, die du da hast.





ist.


Johannes

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
snipped-for-privacy@gmx.de (Johannes Bauer)  am 13.08.19 um 18:52:



Quoted text here. Click to load it


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


oder meinetwegen 10.000, wenn man im Schnitt mit 1.6 Takten pro Befehl
rechnet?


updaten, Warteschleifen legt man da ja nicht rein.



Rainer

--  


(Hergen Lehmann in ger.ct)

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
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


was den Selbstbau etwas erschwert, so man nicht vom freundlichen Chinesen





Quoted text here. Click to load it


Quoted text here. Click to load it

Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der  


--  
Dipl.-Inform(FH) Peter Heitzer, snipped-for-privacy@rz.uni-regensburg.de

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

Quoted text here. Click to load it




die Arduino-Plattform hat so einen reichen Schatz an Libraries

vorher jemand gemacht hat), relativ billig (15-25 Euro), gut supportet


neuerdings auch rohe Power bis 600MHz.

https://www.pjrc.com/store/teensy32.html



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.





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.


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.

Quoted text here. Click to load it


Naja, in der Arduino-Umgebung ist das gut gekapselt, auch wenn dem
ganzen der gcc zugrundeliegt. Bei bisherigen Projekten hab ich  




/ralph
--  
-----------------------------------------------------------------------------
                                                              https://aisg.at
We've slightly trimmed the long signature. Click to see the full one.
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 09:58, Ralph Aichinger wrote:

Quoted text here. Click to load it


Quoted text here. Click to load it


Handbuch von ner Cessna 172 gelesen und verstanden hast und dich dann
wunderst, dass das einer Boeing 737 deutlich dicker und komplizierter ist.


(!) M3 ohne viel Peripherie. Die M4s kommen dann schon deutlich dicker
daher und die M7s sind eine GANZ andere Klasse.

Quoted text here. Click to load it

Quoted text here. Click to load it




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.


JOhannes


Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 08:49, Peter Heitzer wrote:


Quoted text here. Click to load it


Quoted text here. Click to load it






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

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





Quoted text here. Click to load it

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

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
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 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, snipped-for-privacy@rz.uni-regensburg.de

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Peter Heitzer 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

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


Flash plus 64KiByte SRAM.


auch die begrenzte Rechenleistung nicht ausreichen.

Quoted text here. Click to load it





Sicherheitstechnisch hat diese Architektur auch Vorteile. Daten im




die einfachen Angriffe funktionieren nicht.


______________
[1] <https://de.wikipedia.org/wiki/Return_Oriented_Programming

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



Quoted text here. Click to load it


Quoted text here. Click to load it


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.

Quoted text here. Click to load it


Quoted text here. Click to load it

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

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

Quoted text here. Click to load it




Quoted text here. Click to load it






Johannes

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Quoted text here. Click to load it







Quoted text here. Click to load it

Wenn man via avr-objdump aus einem ELF-Binary die Symbol-Table anzeigen

Der Compiler macht es intern also im Prinzip so und erst am Ende wird
alles zerlegt.

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



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




Unterhalb dieser Limits empfinde ich die Architektur an sich aber
deutlich weniger schlimm als du beschrieben hast.


______________

  "Since all AVR instructions are 16 or 32 bits wide,
  the Flash is organized as [Anzahl Words] x 16 bits."

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




Quoted text here. Click to load it




Quoted text here. Click to load it

Quoted text here. Click to load it

Ja, ich dramatisiere. Man muss die AVRs halt auch im Kontext ihrer Zeit

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

noch dazu, echt krass.

Mittlerweile hat aber ja auch Atmel/Microchip auf Cortex-M umgesattelt,
dagegen konvergiert der Embedded-Bereich offenbar komplett -- und nicht

Architektur.

Aber ich werde mir deinen Tipp zu Herzen nehmen und versuchen,



Johannes

Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
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

Quoted text here. Click to load it




mehr erkannt wurde. AT90S2313 und AT90S8515 waren gut.

Quoted text here. Click to load it

Quoted text here. Click to load it

Ja, was anderes wollte ich auch nicht unterstellen.

Quoted text here. Click to load it


8-Bit MCUs nimmt man meistens auch gar nicht wegen der Architektur.

die InGaN-LEDs nicht ausreichen), dann ist es schon nett wenn die MCU





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



Quoted text here. Click to load it

Quoted text here. Click to load it

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)


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
We've slightly trimmed the long signature. Click to see the full one.
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
Joerg Niggemeyer wrote:

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it


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



neue Varianten auf den Markt (die sich die Peripherie-Einheiten mit
den PICs teilen).


Quoted text here. Click to load it

Nimm als Beispiel 12V oder zwei AA-Zellen als Supply. Mehrere Regler


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


Quoted text here. Click to load it


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)



verlangt ;-)



mit z.B. adjustable LDO  AP7330


5V uC dazu nehmen - insbesondere wenn z.B. bei automotive einige ICs ein
Enable von min. 4.5V haben.






--  
mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker
WEB: http://www.nucon.de https://www.led-temperature-protection.com
We've slightly trimmed the long signature. Click to see the full one.
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs
On 14.08.19 15:58, Peter Heitzer 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






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.

Quoted text here. Click to load it

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

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

Quoted text here. Click to load it

Das ist nicht ganz richtig. Die Segmentregister werden in eigenen  




Verschwendung ;-)

DoDi

Site Timeline