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

[Peter Heitzer]

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

On 13.08.19 09:33, Ralph Aichinger wrote:

Ich werde vermtulich erst mal einen 8-Bit-Atmel verwenden
(fĂźr den Prototypen einen Arduino Mega 2560, fĂźrs fertige
Gerät vielleicht eine Teensy 2.0 mit 32u4). Ja, wie mich jemand
zu recht belehrt hat ist das "Geriatronik", es gibt ARM-Controller
die das alles mit links erschlagen, aber trotzdem wĂźrde mich eine
"saubere" Vorgehensweise interessieren. Das ganze mit roher
Rechenpower lĂśsen kann ich ja noch immer. Ein Teensy 4.0 mit
600MHz-Arm Cortex hat sicher keinerlei Probleme, wie unelegant
man auch immer programmiert.

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
der aller aller aller schlechteste Cortex-M0 (z.B. STM32F030) schlägt
den Atmel noch um LÄNGEN in Geschwindigkeit, Peripherie und
Flexibilität. Eine gescheite Open Source Toolchain, statt diesem avr-gcc
Gefummel gibt's obendrein. Und viel billiger als diese AVRs ist er auch
noch.

Die Auswahl an ARMs in DIP oder 50 mil SO Gehäusen ist aber recht gering,
was den Selbstbau etwas erschwert, so man nicht vom freundlichen Chinesen
ein preiswertes Board erwirbt. FĂźr den ARM spricht allerdings die Tatsache,
daß viele bereits eine RTC mit Kalenderfunktion eingebaut haben.
Auch die hĂśhere Wortbreite von 16 oder 32 Bit erleichtert einiges.

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.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

 

[Markus Faust]

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

 

[Ralph Aichinger]

Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:

Die Auswahl an ARMs in DIP oder 50 mil SO Gehäusen ist aber recht gering,
was den Selbstbau etwas erschwert, so man nicht vom freundlichen Chinesen
ein preiswertes Board erwirbt.

Bei der FĂźlle an tollen Boards wĂźrde ich da nicht selber an SMD-Teilen
mehr rumlĂśten, so hoch ist meine Motivation nicht. Besonders nett finde
ich die Teensy-Boards: Arduino-kompatibel (ist fĂźr mich wichtig,
die Arduino-Plattform hat so einen reichen Schatz an Libraries
für quasi alles, in dem Ökosystem gibtes fast nix was nicht schon
vorher jemand gemacht hat), relativ billig (15-25 Euro), gut supportet
(der Entwickler Paul Stoffregen antwortet oft persĂśnlich im Forum),
in einem mechanisch praktischen Formfaktor (paßt in DIL-Sockel), und
neuerdings auch rohe Power bis 600MHz.

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

Allerdings finde ich einstweilen die Datenblätter der ARM-CPUs noch
eine Spur einschĂźchternder als die von AVR. 3000 Seiten Doku fĂźr den
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.

FĂźr den ARM spricht allerdings die Tatsache,
daß viele bereits eine RTC mit Kalenderfunktion eingebaut haben.
Auch die hĂśhere Wortbreite von 16 oder 32 Bit erleichtert einiges.

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.
indem man die AnkĂźndigung der Schaltsekunden aus DCF77 einliest oder
mit einer Taste aktiviert, daß am nächsten Quartalsende eine eingefügt
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.

Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der
Implementierung in gcc. Andere Compiler kĂśnnen das deutlich besser.

Naja, in der Arduino-Umgebung ist das gut gekapselt, auch wenn dem
ganzen der gcc zugrundeliegt. Bei bisherigen Projekten hab ich
überhaupt noch nie so tief runtersteigen müssen, daß ich das
Datenblatt des Controllers gelesen hätte. Bei den Countern muß
das aber sein, dafĂźr hat Arduino keine sinnvolle Abstraktion.

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

 

[Joerg Niggemeyer]

In message <ErptXkKirLB@smial.prima.de>
Rainer Knaepper <rainerk@smial.prima.de> wrote:

ra@pi.h5.or.at (Ralph Aichinger) am 13.08.19 um 13:56:
Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote:
Eine übliche Vorgehensweise ist es mit dem scope die zeitlichen
Längen der Funktionen und die Abarbeitung der IRs sichtbar zu
machen, indem man ein paar Pins des Micros als logig flags dem
scope zuführt und einen Portpin hi schaltet beim Funktionseintritt
und beim verlassen den pin wieder runterzieht, toggeln etc. Man
kann dann auf dem scope schön sehen ob eine Firmware rund läuft,
insbesondere mit meherern IRs...

Ah, das ist clever. Gerade wenn das Timing gefragt ist, dann ist
Ausgeben von Debug-Statements über die serielle Schnittstelle keine
wirkliche Option.

Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an
oder nie aus (je nach Implementierung) ist was faul. Flimmert oder
glimmt sie vor sich hin, ist alles schön ;-)

Na klar, die LED, die z.B. durch langsames Blinken diverese Codes
dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt
werden, wenn man ein scope dransetzt.


--
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 13.08.19 17:10, Joerg Niggemeyer wrote:

In message <ErmpcRszQoB@allinger-307049.user.uni-berlin
"Wolfgang Allinger" <all2001@spambog.com> wrote:




Einfach nur einen Zähler im IR hochzählen, ggf. per SW verlängern.

Dann irgendwann in der (Display) Routine diesen Zähler abfragen, und zwar
mehrfach, bis 2 Abfragen nacheinander den gleichen Wert haben (weg. IR
Bearbeitung kÜnnte der sich gerade ändern!) dann vergleichen mit dem
letzten Wert aus dem vorherigen Durchgang. Dann alle Berechnungen
anstellen samt Ablage des aktuellen Wertes als Altwert und fertig ist die
Laube.

Was fĂźr ein Polling Aufwand ;-)

Muß nicht sein:
Man legt den uC mit freigeschalteten Interrupts schlafen:
sei();
sleep_mode();
Er kehrt dann aus dem "sleep_mode()" zurĂźck, wenn die ISR beendet ist.

Leider ist der Spareffekt abhängig von der "Schlaftiefe": insbesondere
die ATmegas lassen sich fĂźr einige Interrupt-Quellen nicht in einen
Tiefschlaf versetzen.

Josef

 

[Hans-Peter Diettrich]

Am 14.08.2019 um 11:10 schrieb Johannes Bauer:

Teilweise brauchst du sogar, für die großen Devices, perverse
Workarounds um das Laden von Programmspeicher Ăźberhalb der 16-Bit Grenze
zu ermöglichen. Stichwort pgm_read_byte_far(). Das heißt, ich muss als
Programmierer zur Compilezeit (!) wissen, wo mir mein Linker (!!) später
ein Objekt hinlegt, damit ich unterscheiden kann, welche Funktion die
geeignete ist.

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
Beschränkung auf 4GB.

Entsprechend sollte man halt in ÂľC nicht mehr Speicher einbauen als die
Pointerregister verkraften, bzw. bei Mehrbedarf auf einen größeren
(32... Bit) Kern umsteigen. FĂźr den Entwickler ist es dann schĂśn, wenn
er seinen alten Arduino Code erst einmal auf dem neuen Controller
weiterlaufen lassen kann.

DoDi

 

[Josef Moellers]

On 14.08.19 10:56, Hans-Peter Diettrich wrote:

Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer:
In message <ErptXkKirLB@smial.prima.de
          Rainer Knaepper <rainerk@smial.prima.de> wrote:
Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an
oder nie aus (je nach Implementierung) ist was faul. Flimmert oder
glimmt sie vor sich hin, ist alles schön ;-)

Na klar, die LED, die z.B. durch langsames Blinken diverese Codes
dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt
werden, wenn man ein scope dransetzt.

Wenn schon Debuggen dann gleich richtig mit einem Logik-Analysator. Ist
weit billiger als ein Scope und erlaubt bessere Diagnosen.

Dann mußt Du aber mehrere Bits ausgeben und per LA abfragen.

Josef

 

[Joerg Niggemeyer]

In message <Ermpt8dzQoB@allinger-307049.user.uni-berlin>
"Wolfgang Allinger" <all2001@spambog.com> wrote:

Was für ein Polling Aufwand ;-)

Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden
ist.
Nachdem die Berechnung fertig ist, wird das Flag gelöscht.
Dann wird auch nicht soviel Rechenzeit unnütz verbraten.......

Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr
Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR
auf und zu. Auch Semaphoren hickhack ist aufwendiger...

Es ging darum, dass man Berechnungen, die vielleicht einmal am Tag
notwendig sind, nicht jede Sekunde durchführen muss. Kann man wohl machen,
da es die Rechenleistung vielleicht hergibt, ist aber IMHO schlechter
Stil.

Über ein globales Flag einen Status zu übermitteln, ist eine Technik, die
man anwenden kann, um entsprechend in einer anderen Wiederholschleife, die
nicht in sync zu einem Timer stehen muss und auch unterbrochen werden kann
z.B. in der main loop, dann Aktionen durchzuführen.

Das Flag, ob eine Berechnung notwendig ist oder nicht , muss oder kann
nicht unbedingt über den Timer Wert auslesbar sein. Insbesondere, wenn
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.

Aktionen in dem T-IR nach Bedarf durchführen, falls häufige Reaktionen
oder Berechnungen periodisch schnell dazu nötig sind.

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.

Das Polling des Bits gibt die gewünschte Aktualisierungsrate vor. Im
übrigen würde es in diesem Falle zu keinem "langem" Fehler führen, sondern
lediglich zu einer langsamen Reaktion, die eine einstellbare Eigenschaft
ist, falls man einem IR (1s) zu spät das Datum/Wochentag berechnen würde.
Und das ist für mich auch ein wichtiges Kriterium, ob eine Funktion in
einem IR laufen muss also zeitlich zu einem event kritisch ist oder nicht.

Mit der Alt/Neu Zählerstand Methode, funzt
das sogar, wenn man mal einen verschlabbert, auch Überläufe musse
latürnicht da korrekt behandeln.

Verschlabbern von kritischen IRs, wie bei der Programmierung von DCDC,
wenns denn mal etwas schneller gehen soll, ist schlecht, dann machts
Puff.....
Alt Neu Variablenvergleich, um z.B. eine Wertveränderung abzuprüfen, oder
Fehler zu detektieren ist zweckmässig.
Auch das Anhalten per Debugger im ungünstigen Moment kann zum Himmeln der
HW führen. So etwas führt dann zu einer steilen Lernkurve oder man gibt
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.E 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.

 

[Hans-Peter Diettrich]

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

 

[Johannes Bauer]

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.

Klar kĂśnnte ein Compiler das einfach emulieren und 24 oder 32-Bit
Pointer machen oder so ein gemurkse. Dann wird halt *jede* Indirektion
im Programm unendlich lahm. Und klar, in einfachen Fällen (also wenn der
Compiler garantiert entscheiden kann, welcher Bereich addressiert ist)
geht das natßrlich auch. Aber *Allgemein* lässt es sich nicht lÜsen,
ohne dass der Programmierer "hints" geben muss, was gemeint ist.

Teilweise brauchst du sogar, für die großen Devices, perverse
Workarounds um das Laden von Programmspeicher Ăźberhalb der 16-Bit Grenze
zu ermöglichen. Stichwort pgm_read_byte_far(). Das heißt, ich muss als
Programmierer zur Compilezeit (!) wissen, wo mir mein Linker (!!) später
ein Objekt hinlegt, damit ich unterscheiden kann, welche Funktion die
geeignete ist. Oder natĂźrlich die lahme _far() Variante immer nehmen.
Das sind so viele Layer von Murks aufeinandergestapelt dass mir davon
echt Ăźbel wird.

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
viel schĂśneren und portableren Code schreiben kann.

Gruß,
Johannes

 

[Johannes Bauer]

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

 

[Johannes Bauer]

On 14.08.19 09:58, Ralph Aichinger wrote:

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

Allerdings finde ich einstweilen die Datenblätter der ARM-CPUs noch
eine Spur einschĂźchternder als die von AVR. 3000 Seiten Doku fĂźr den
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.

Du vergleichst aber halt auch Äpfel mit Birnen. Das ist wie wenn du das
Handbuch von ner Cessna 172 gelesen und verstanden hast und dich dann
wunderst, dass das einer Boeing 737 deutlich dicker und komplizierter ist.

Die nächste Stufe vom AVR ist ein M0, M0+ oder vielleicht ein kleiner
(!) M3 ohne viel Peripherie. Die M4s kommen dann schon deutlich dicker
daher und die M7s sind eine GANZ andere Klasse.

Das hat aber weniger mit Harvard Architektur zu tun, sondern mit der
Implementierung in gcc. Andere Compiler kĂśnnen das deutlich besser.

Naja, in der Arduino-Umgebung ist das gut gekapselt, auch wenn dem
ganzen der gcc zugrundeliegt. Bei bisherigen Projekten hab ich
überhaupt noch nie so tief runtersteigen müssen, daß ich das
Datenblatt des Controllers gelesen hätte. Bei den Countern muß
das aber sein, dafĂźr hat Arduino keine sinnvolle Abstraktion.

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.

Gruß,
JOhannes

 

[Hans-Peter Diettrich]

Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer:

In message <ErptXkKirLB@smial.prima.de
Rainer Knaepper <rainerk@smial.prima.de> wrote:
Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an
oder nie aus (je nach Implementierung) ist was faul. Flimmert oder
glimmt sie vor sich hin, ist alles schön ;-)

Na klar, die LED, die z.B. durch langsames Blinken diverese Codes
dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt
werden, wenn man ein scope dransetzt.

Wenn schon Debuggen dann gleich richtig mit einem Logik-Analysator. Ist
weit billiger als ein Scope und erlaubt bessere Diagnosen.

DoDi

 

[Hans-Peter Diettrich]

Am 13.08.2019 um 19:54 schrieb Wolfgang Allinger:

On 13 Aug 19 at group /de/sci/electronics in article 23ccf3e257.assel@nuconverter.de
joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote:

Was für ein Polling Aufwand ;-)

Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden
ist.
Nachdem die Berechnung fertig ist, wird das Flag gelöscht.
Dann wird auch nicht soviel Rechenzeit unnütz verbraten.......

Genau so ist das richtig gemacht.

Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr
Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR
auf und zu. Auch Semaphoren hickhack ist aufwendiger...

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?

DoDi

 

[Josef Moellers]

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

 

[Josef Moellers]

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.

 

[Wolfgang Allinger]

JBC war ein
On 14 Aug 19 at group /de/sci/electronics in article gri0fsFrhm3U1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 13.08.2019 um 19:54 schrieb Wolfgang Allinger:

On 13 Aug 19 at group /de/sci/electronics in article
23ccf3e257.assel@nuconverter.de <joerg.niggemeyer@nucon.de> (Joerg
Niggemeyer) wrote:

Was für ein Polling Aufwand ;-)

Im IR selbst einfach ein Flag setzen, dass eine Berechnung nötig geworden
ist.
Nachdem die Berechnung fertig ist, wird das Flag gelöscht.
Dann wird auch nicht soviel Rechenzeit unnütz verbraten.......

Genau so ist das richtig gemacht.

Das ist mindestens genauso aufwendig wie 2mal lesen und hat noch mehr
Chancen für Race-Conditions, bzw. umzingeln der Abfrage mit DI und EI IR
auf und zu. Auch Semaphoren hickhack ist aufwendiger...

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.


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

 

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article gri0m9Friq2U1@mid.individual.net
<DrDiettrich1@aol.com> (Hans-Peter Diettrich) wrote:

Am 14.08.2019 um 09:53 schrieb Joerg Niggemeyer:
In message <ErptXkKirLB@smial.prima.de
Rainer Knaepper <rainerk@smial.prima.de> wrote:
Geht oft auch mit einer geschickt eingesetzten LED. Geht sie nie an
oder nie aus (je nach Implementierung) ist was faul. Flimmert oder
glimmt sie vor sich hin, ist alles schön ;-)

Na klar, die LED, die z.B. durch langsames Blinken diverese Codes
dem DAU übermittelt, kann als schneller Debug output Port mitgenutzt
werden, wenn man ein scope dransetzt.

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

Für seltene Fälle dann wieder mit Portpin und Oscar. Meistens ein Port
(wenn frei) mit einem WrapPfosten und 8 LEDs für guckometrische
Überwachung. Reichte mir völlig, selbst bei dem Trumm mit den 14 aktiven
IR Ebenen (selten, PWF, BrownOut, 50Hz, 100Hz, 1kHz, 20kHz, 19kBd, ...)
und alles völlig asynchron, wobei dann auch noch bei bestimmten Umständen,
die IR Prioritäten abgewandelt wurden.

Damals standen mir diverse edelste LA im Dutzend zur Verfügung, so hp1608
.. hp16500(?) samt einem schweineteuren, aber völlig unbrauchbarem Dolch
(8050?)

Mein Liebling war der hp1608|1604(?) nannte sich LogigStateAnalyzer, hatte
nur 16 Speicherplätze aber ein grandioses Triggermenü mit sehr vielen
Ebenen.
Brauchte man auch, sonst waren die 16 Plätze ruckzuck voll.
Hab ihn sogar fast immer benutzt, wenn ich mal Langzeit Protokolle
abspeichern musste. Den hp als Trigger für den Dolch als Datengrab/
Speichererweiterung...

Mit dem hp konnte man leicht sowas fangen wie: 3x an pin1 gewackelt, dann
7 fallende Flanken an pin2, rückfall in pin1 Ebene, wenn pin3 7x gewackelt
hat und pin4 positiv war, jedoch nicht wenn pin5 rattert... sonst nächste
Ebene bit triggerung für Channel/Platz 1, dann wieder auf der Lauer
legen... Man konnte sich dann auch anzeigen lassen, bis wo er gerade im
Triggerbaum geklommen war.

Hab sowas später nie mehr an anderen LA gefunden, allerdings auch die LA
Schiene nie weiter benutzt, s.o.




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

 

[Wolfgang Allinger]

On 14 Aug 19 at group /de/sci/electronics in article ad9e57e357.assel@nuconverter.de
<joerg.niggemeyer@nucon.de> (Joerg Niggemeyer) wrote:

In message <Ermpt8dzQoB@allinger-307049.user.uni-berlin
"Wolfgang Allinger" <all2001@spambog.com> wrote:

Mit der Alt/Neu Zählerstand Methode, funzt
das sogar, wenn man mal einen verschlabbert, auch Überläufe musse
latürnicht da korrekt behandeln.
Verschlabbern von kritischen IRs, wie bei der Programmierung von DCDC,
wenns denn mal etwas schneller gehen soll, ist schlecht, dann machts
Puff.....
Alt Neu Variablenvergleich, um z.B. eine Wertveränderung abzuprüfen, oder
Fehler zu detektieren ist zweckmässig.
Auch das Anhalten per Debugger im ungünstigen Moment kann zum Himmeln der
HW führen.

BTDT 400V 8kA Stromrichter, da lernste was fürs Leben
Das macht nicht puff, sondern KAWUMMMMMMM Hört der halbe Betrieb, dass
der Allinger wieder Scheisse gebaut hat, aber das härtet ab.

Hab da seinerzeit Versuche fahren müssen, zur Bestimmung der
Wechselrichtertrittgrenze, sehr lange her, jedesmal beim Anfahren der
Grenze (lastabhängig) war ein 1000DM Satz Silized Sicherungen fällig.
Keine Ahnung, wie das heutzutage gemacht wird und ob man sowas überhaupt
simulieren kann. Damals gabs nur die KAWUMMMMM Methode.

So etwas führt dann zu einer steilen Lernkurve oder man gibt
frustiert auf ;-)

Jau, steil und LAUT und viel magischer Rauch, wieder ätze ich:

C Programmierer schreiben schlechte Programme, fühlen sich mies und geben
beim debuggen auf.

FORTH Programmierer schreiben schlechte Programme, fühlen sich gut und
bringen die Programme zum laufen



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

 

[Wolfgang Allinger]

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