A. K. schrieb:> Zuweisungen funktionieren nur innerhalb von Funktionen.
ist das nicht ein Widerspruch zu
Joachim B. schrieb:> char jar_str[] = "Rollo"; // klappt
mir war mal so als wenn Variableninit auch ausserhalb klappt!
Joachim B. schrieb:> ist das nicht ein Widerspruch zu
Nö. Zuweisung und Initialisierung sehen zwar entfernt ähnlich aus, sind
aber verschiedene Sachen. Auch eine struct kann initialisiert werden.
aber nicht so wie gezeigt.
A. K. schrieb:> Auch eine struct kann initialisiert werden.> aber nicht so wie gezeigt.
dann vermutlich nur so
Joachim B. schrieb:> in *.h> struct eep_var{> uint8_t backlicht=9; // eep_var> uint8_t contra=63; // eep_var> uint8_t bias=4; // eep_var> char mesz_str[5]; // "MESZ" || " MEZ"> };
OK, danke
Joachim B. schrieb:> dann vermutlich nur so
Programmieren lernt man nicht, indem man alles durchprobiert, was einem
gerade in den Sinn kommt, sondern indem man ein entsprechendes Buch
liest. Egal ob Papier oder Online. Gibts die heute nicht mehr, nur noch
Youtube Channels?
A. K. schrieb:> Gibts die heute nicht mehr
vergiss es , das ist das erste Mal das ich mich mit Struct plage, habe
ich seit '88 nie gebraucht ausser in dbase und clipper, nie in C
Joachim B. schrieb:> dann vermutlich nur so
In Header Files tut man keine Variablen definieren. Nein
das tut man nicht tuten!
Joachim B. schrieb:> struct eep_var MY_EEP_VAR;
In Variablen benutzt man nicht durchgehend Grossbuchstaben.
Grossbuchstaben sind für Konstanten und Defines gedacht.
Das wäre allgemein guter Programmierstil! Alles andere
ist stümperhaft, auch wenn es prinzipiell erlaubt ist.
jo mei schrieb:> Das wäre allgemein guter Programmierstil!
ich lerne noch immer wieder jeden Tag, hört nie auf!
Ich war noch nie ein "guter" Programmierer(dafür gibt es Informatiker!),
stört mich ja selber aber es ist nur nach dem Studium immer mehr zur
Hauptsache geworden, irgendwie ein Nebeneffekt zur Elektrotechnik.
nun dürft ihr weiter auf mich rumhacken!
Joachim B. schrieb:> nun dürft ihr weiter auf mich rumhacken!
Nutzt du Arduino?
Dann ist das Verfahren eigentlich üblicherweise etwas anders, als du es
hier zeigst...
Joachim B. schrieb:> Programmierer(dafür gibt es Informatiker!)
Nö, Informatiker sind keine Programmierer.
Die basteln dir Algorithmen, von denen bekommst du sowas wie ein qsort,
von denen bekommst du auch ein printf. Und natürlich bekommst du von
denen einen Compiler.
Programmieren müssen die Ingenieure schon selbst, denn nur sie kennen
die Probleme, die der Computer ihnen lösen soll. Die kann man nicht erst
lang und breit einem Informatiker erklären.
Dafür ist es außerordentlich hilfreich, wenn sich auch
Nicht-Informatiker an bestimmte Gepflogenheiten halten. ;-)
Jörg W. schrieb:> Nö, Informatiker sind keine Programmierer.>> Die basteln dir Algorithmen
ich weiss aber vor dem Programmieren haben die Klugen die SW Architektur
gesetzt und ich lernte von einem Informatiker das es erst mal um
Architektur geht.
Jeder kann irgendwie mit dem Akkuschrauber umgehen und Holzbalken
verbinden, ein Haus (Holzständerwerk) welches nicht zusammenbricht ist
aber mehr ;)
So sehe ich das!
A. K. schrieb:> Wo er das doch seit 1988 tut...
ah da war doch was?
A. K. schrieb:> Man kann C/C++ gut oder schlecht finden, aber wenn man nicht vorhat,> eine eigene Sprache zu definieren, sondern die vorhandene nutzen will,> ist der Standard stets stärker als der eigene Wunsch.
hat sich der Standard seit K&R nicht mehrfach geändert, dazu noch die
Compileroptionen, mal ehrlich wer kennt ALLES?
aber OK:
Joachim B. schrieb:> nun dürft ihr weiter auf mich rumhacken!
geht an mir vorbei, ich progge nun weiter und suche meine bugs.
Jetzt gehts immerhin weiter, DANKE trotzdem
Joachim B. schrieb:> hat sich der Standard seit K&R nicht mehrfach geändert,
Die Syntax der Initialisierung einer struct, die in den 70er in K&R-C
funktionierte, die funktioniert auch heute noch und wäre in diesem
Beispiel immer noch eine sinnvolle Wahl.
A. K. schrieb:> Die Initialisierung einer struct, die in den 70er in K&R-C> funktionierte, die funktioniert auch heute noch
aber die Initialisierung von Variablen haben sich auch nicht verändert,
das kann kein Argument sein!
Joachim B. schrieb:> in der *.c ausserhalb einer Funktion als Init> char jar_str[] = "Rollo"; // klappt
OK ich nehme es wie es ist, du hattest ja einen schlauen Satz dazu
geschrieben
A. K. schrieb:> Man kann C/C++ gut oder schlecht finden, aber wenn man nicht vorhat,> eine eigene Sprache zu definieren, sondern die vorhandene nutzen will,> ist der Standard stets stärker als der eigene Wunsch.
oder so: (wenn man die Reihenfolge der Structvariablen einhält)
Asdf schrieb:> struct eep_var MY_EEP_VAR = {42,42,42,“Hell“};
oder eine Funktion zum Initialisieren verwenden:
Joachim B. schrieb:> das kann kein Argument sein!
Eine korrekte Syntax wurde im Thread bereits gezeigt. Die hätte mit
K&R-C auch schon so funktioniert.
Ich damit will nicht sagen, dass man heute C nach K&R Erstauflage lernen
sollte. Aber die Entwicklung der Standards taugt nicht als Ausrede.
A. K. schrieb:> Die Syntax der Initialisierung einer struct, die in den 70er in K&R-C> funktionierte, die funktioniert auch heute noch und wäre in diesem> Beispiel immer noch eine sinnvolle Wahl.
Alternativ kann man seit C99 auch eine besser auto-dokumentierende
Initialisierung benutzen, aber dann müsste man sich schon mal mit den
Grundlagen der Sprache vertraut machen. Den Unterschied zwischen einer
Initialisierung (beim Erstellen des Objekts) und einer Zuweisung (bei C
nur innerhalb einer Funktion gestattet) sollte man als Minimalkenntnisse
verstehen.
Hmmm...
Keine Reaktion auf meine Frage+Ansage.....
Hallo Joachim, ich gehe mal davon aus, dass du trotz des, in den anderen
Thread hineingrätschen, kein Interesse mehr an dem Thema hast.
zitter_ned_aso schrieb:> oder eine Funktion zum Initialisieren verwenden:
Das bringt bei einer EEPROM-Variablen übrigens nicht den gewünschten
Effekt.
Die Initialisierung dort macht man üblicherweise ja, damit man in der
entsprechenden Section im ELF-File einen Inhalt hat, den der Programmer
dann in den EEPROM als Initialwerte übertragen kann.
Wenn man diese Variable zur Laufzeit befüllt, bringt das rein gar
nichts. Der EEPROM bleibt davon völlig unbeeindruckt. Alles, was man mit
der entsprechenden EEPROM-Variablen zur Laufzeit noch tun kann ist, ihre
Adresse zu nehmen und sie an eine der EEPROM-Block-Lese- oder
-Schreib-Funktionen zu übergeben. Üblicherweise hält man sich davon dann
noch eine RAM-Kopie mit gleicher Strukturdefinition. In die wird beim
Start aus dem EEPROM eingelesen, und wenn man sie im RAM geändert hat,
bekommt die Applikation irgendwie (manuell oder automatisch) die Option,
diese Daten dann in den EEPROM zurück zu schreiben, um sie so beim
nächsten Start zu haben.
Natürlich ist es bei so einem Szenario auch wichtig, dass man den
EEPROM-Inhalt nicht zwingend bei jedem Flashen befüllt, denn ansonsten
hat man danach immer wieder die Defaultwerte statt der zuletzt
gespeicherten. Damit der EEPROM beim Flashen nicht geleert wird, muss
man überdies noch die EESAVE-Fuse gesetzt haben.
Du siehst: ganz ohne Verständnis der Zusammenhänge ist das alles nicht
praktikabel, und ein Grundverständnis, was in C eine Initialisierung ist
(im Gegensatz zu einer Zuweisung) ist schlicht notwendig, damit man das
Ganze überhaupt sinnvoll nutzen kann. Mit trial & error dürften diese
Details kaum erschließbar sein (weil man nach dem "error" gar nicht
weiß, wo man für die Veränderung beim nächsten "trial" ansetzen soll).
Arduino Fanboy D. schrieb:> Hallo Joachim, ich gehe mal davon aus, dass du trotz des, in den anderen> Thread hineingrätschen, kein Interesse mehr an dem Thema hast.
ne ich habe Interesse an allen Themen, nur hier ging das langsam in Häme
über und das ist wenig hilfreich, ich muss halt noch viel lernen was
"gute" Programmierung sein soll, sind ja alles auch nur "Meinungen" und
"Empfehlungen", manche fundiert und manche persönlich eingefärbt!
A. K. schrieb:> Aber die Entwicklung der Standards taugt nicht als Ausrede.
Häme aber auch nicht!
Zumal es durchaus Compileroptionen und Eigenarten gibt die einem gut
"beschäftigen" können.
Ich weiss gerade nicht welchen Compiler der ESP32 in der Arduino IDE
nutzt, es fallen mir halt "Merkwürdigkeiten" auf, z.B. das ein doppeltes
Wire.begin(); im AVR folgenlos bleibt, beim Aufruf von I2C scan und
hinterher bei der DS1307new LIB, der ESP32 aber abschmiert wegen dem
doppelten Wire.begin(); in der LIB.
Das sind "Eigenheiten" die eher behindern als mich voran bringen, die
ich also umschiffen muss.
Joachim B. schrieb:> nur hier ging das langsam in Häme über
Nein, aber es ist eben (wie ich einen Beitrag darüber dargelegt habe)
auch notwendig, dass man sich zumindest mit den Grundlagen der
verwendeten Sprache und Umgebung befasst, bevor man mit der
Programmiererei loslegt. Ein paar syntaktische Konzepte gehören schlicht
dazu, sonst vermplemperst du am Ende nur deine Zeit.
Klar kann man nicht jede Feinheit einer Implementierung parat haben, für
Detailfragen ist ein Forum wirklich gut. Ich habe kürzlich angefangen,
endlich mal VHDL zu lernen (das hatte ich schon seit mindestens 10
Jahren vor), das Forum war wirklich hilfreich – aber ehrlich, die Syntax
der Sprache musste ich mir schon in ein paar Tutorials und Referenzen
anlesen, da kann ich nicht für jede Zeile einen Forenbeitrag schreiben.
Jörg W. schrieb:> Ein paar syntaktische Konzepte gehören schlicht> dazu, sonst vermplemperst du am Ende nur deine Zeit.
stimmt und da habe ich auch Defizite und versuche sie zu beheben, muss
mich aber mit der Häme nicht beschäftiggen und sie ausblenden und mich
möglichst fernhalten, gelingt mir nicht immer und ehrlich manchmal ist
man selber nicht mal frei von Häme, ist auch menschlich.
Ich sag ja nicht das ich von NULL anfange, aber auch nicht das ich alles
weiss und einiges nie gebraucht hatte!
Viele können deutsch, aber wer kann aus dem Stehgreif Plusquamperfekt
erklären oder kommt mit 'wie & als' klar? (nach dem Komperativ steht
immer als!)
Joachim B. schrieb:> Viele können deutsch, aber wer kann aus dem Stehgreif Plusquamperfekt> erklären oder kommt mit 'wie & als' klar?
Damit habe ich kein Problem, auch nicht damit, dass man "Stegreif" ohne
"h" schreibt. (Die Redewendung kommt vom Reiten.) – SCNR
Lies dir bitte nochmal meinen Beitrag ein bisschen weiter oben durch und
versuche zu verstehen, wie man EEPROM-Variablen verwendet und warum eine
Zuweisung an sie keinen Sinn hat.
Wenn du keine wirklichen (zur Compilezeit bekannten und konstanten)
Default-Werte für den EEPROM brauchst, kannst du dir die komplette
EEPROM-Variable auch sparen, die ist dann sinnlos. Die Adressen im
EEPROM kannst du genauso gut mit der Hand verwalten, du wirst ja am Ende
sowieso als Programmierer wissen wollen, an welcher Stelle im EEPROM was
steht. Diese händisch verwalteten Adressen gibst du dann an
eeprom_read_block/eeprom_write_block. Die SRAM-Kopie der EEPROM-Daten
brauchst du sowieso. (Prinzipiell kann man natürlich statt einer ganzen
Struktur auch häppchenweise den EEPROM bedienen. Sein Feature ist ja,
dass er byteweise beschreibbar ist, anders als Flash. Musst du selbst
wissen, ob dir das lieber ist.)
Initialwerte in den EEPROM kann man natürlich dann auch anders aus der
laufenden Applikation hinterlegen, bspw. indem man den EEPROM-Datensatz
mit einer CRC versieht und wenn diese nicht stimmt da alles neu
reinzimmert. Das erledigt man dann immer in einer Funktion.
Wenn du ein wenig mehr erläuterst, was du überhaupt vor hast, kann man
dir da sicher besser helfen.
Jörg W. schrieb:> Wenn du ein wenig mehr erläuterst, was du überhaupt vor hast, kann man> dir da sicher besser helfen.
Ich baue ein Gerippe welches mit dem nano328p und ESP32 eine RTC,
Nokia5110 Display und anderes bedient, z.B. 433 MHz Sender, Empfänger,
DHT22, DS18B20 Sensoren uvam.
Das fing mal an mit dem nano328p auf dem Steckbrett der so seit 2015
meine Rolladen anfunkt und die nach Sonnen Auf- und -Untergang
berechnet nach Geo Koordinaten steuert.
Dann kam Fernabfrage mit dem ESP32 für Temperatur und Feuchtesensoren
dazu.
Nun brauchte man ein Speichermedium, den EEPROM im AVR schloß ich aus
weil ich lieber die RTC mit EEPROM oder einen DIL8 I2C EEPROM wechsle
als den 328p.
Der ESP nutzt eine andere LIB und die Parameter BIAS Contrast sind also
abweichend und sollen nach Neustart aus dem EEPROM gelesen werden.
An die rotierende Beschreibung für das EEPROM bin ich noch nicht
gekommen, aber nicht jede Änderung muss ich ja sofort ins EEPROM
reinschreiben, ich warte also bis sich keine Werte mehr ändern, z.B.
weil man mehrere Steps probiert bis man die optimale Einstellung
gefunden hat.
Ich hänge halt noch ein wenig das in eine Statemaschine zu überführen
weil ein nano ja ein Single Core ist, und der ESP mit seinen dual Core
natürlich auch besonders bedient werden will, da muss ich halt
aufpassen.
Merkwürdigerweise hatte ich das schon mal fertig und es funktionierte,
aber mit verschiedenen SW Ständen der IDE auf verschiedenen Rechnern,
dann kam mir (die doofe?) Idee alle SW der IDE und LIBs auf alle Rechner
gleich zu bringen, zwischendurch änderte sich auch eine LIB und es
crashte. Da bin ich nun am Suchen und anpassen, alles Nebenschauplätze
die ich eigentlich nicht will. Einige Probleme wie die doppelte
Wire.begin(); habe ich schon in der LIB per # ausgeräumt
Jörg W. schrieb:> Wenn du ein wenig mehr erläuterst, was du überhaupt vor hast, kann man> dir da sicher besser helfen.
da muss ich viel selbst durch, denn keiner wird mein komplettes Projekt
debuggen und aufräumen, es können hier nur immer einzelne Fragen geklärt
werden und ICH muss lernen!
Joachim B. schrieb:> Nun brauchte man ein Speichermedium, den EEPROM im AVR schloß ich aus> weil ich lieber die RTC mit EEPROM oder einen DIL8 I2C EEPROM wechsle> als den 328p.
Dann nützen dir aber diese ganzen EEPROM-Dinge aus der avr-libc rein gar
nichts. Die zielen auf den internen EEPROM des AVR ab.
OK, prinzipiell könntest du sie natürlich trotzdem verwenden und daraus
dann eine externe Lade-Datei für deinen EEPROM generieren, aber
vermutlich wird da die Soße teurer als das Fleisch.
Mein Tipp: bau dir eine Initialisierungs-Struktur für die EEPROM-Daten
im Flash, die du beim ersten Start in den leeren EEPROM schreibst.
Ansonsten wie oben schon geschrieben stets mit einer RAM-Kopie der
EEPROM-Daten hantieren.
Jörg W. schrieb:> Dann nützen dir aber diese ganzen EEPROM-Dinge aus der avr-libc rein gar> nichts. Die zielen auf den internen EEPROM des AVR ab.
die nutze ich auch nicht, ich nutze quasi eine LIB von Fleury
http://www.peterfleury.epizy.com/i2cmaster.zip
auch etwas angepasst weil mir die 5-10ms delay Wartezeit nicht gefallen
die in fast jeder Arduino LIB zu finden ist!
// same tests but now with a 5 millisec delay in between.
delay(5);
ich finde das so nach jedem Schreibvorgang besser
1
voidvoidMyI2C_EepromWaitReady(void){
2
Wire.setClock(I2C_CLOCK_LOW);
3
// Wait until EEPROM gives ACK again.
4
// this is a bit faster than the hardcoded 5 milli
5
do{
6
Wire.beginTransmission((int)(eep_address>>1));
7
Wire.requestFrom((int)(eep_address>>1),(int)1);
8
Wire.read();
9
}while(Wire.endTransmission());
10
Wire.setClock(I2C_CLOCK_HIGH);
11
}// void voidMyI2C_EepromWaitReady(void)
alles andere läuft mit schnellerem I2C clock, nur das EEPROM nicht
Joachim B. schrieb:> ich finde das so nach jedem Schreibvorgang besser> void voidMyI2C_EepromWaitReady(void) {> Wire.setClock(I2C_CLOCK_LOW);> // Wait until EEPROM gives ACK again.> // this is a bit faster than the hardcoded 5 milli> do {> Wire.beginTransmission((int)(eep_address>>1));> Wire.requestFrom((int)(eep_address>>1), (int)1);> Wire.read();> }while(Wire.endTransmission());> Wire.setClock(I2C_CLOCK_HIGH);> } // void voidMyI2C_EepromWaitReady(void)
Tut mir leid, aber das macht keinen Sinn!
Nada!
Du meist sicherlich sowas:
1
// prüft, ob Baustein unter der Adresse beschäftigt ist
Arduino Fanboy D. schrieb:> Tut mir leid, aber das macht keinen Sinn!
den Satz muss ich erklärt bekommen, er ist für mich so nicht
verständlich.
Ich habe die Zeiten gemessen für 4096 Schreibvorgänge mit 5ms Wartezeit
in Arduino LIBs und nach "meiner" Methode nach fleury die wesentlich
kürzer ist.
Was da keinen Sinn machen soll erschliesst sich mir nicht!
Beitrag "Re: ESP32 mit Nokia 5110"
Tatsache bleibt, viele Probleme löst man doch selbst, das ganze Projekt
ist ja nicht im Rahmen des Forums lösbar.
Joachim B. schrieb:> Was da keinen Sinn machen soll erschliesst sich mir nicht!Joachim B. schrieb:> do {> Wire.beginTransmission((int)(eep_address>>1));> Wire.requestFrom((int)(eep_address>>1), (int)1);> Wire.read();> }while(Wire.endTransmission());
Ich sehe da ein
> Wire.requestFrom
umrahmt von
> Wire.beginTransmission> Wire.endTransmission
Das sagt mir mehr als deutlich, dass da irgendjemand Wire, wie man Wire
nutzt, überhaupt nicht verstanden hat!
Wire.requestFrom ist eine Read Operation!
Wire.beginTransmission
Wire.endTransmission
handeln eine Write Operation ab
Das sind 2 paar Schuhe.
Und du schachtest sie ineinander.
Das ist logischer Unsinn.
Wenn es bei dir zufällig klappt, dann ok.
Aber Unsinn ist es und bleibt es auch.
OK, vielleicht bin ich ja auch zu blöd, und mir erschließt sich der Sinn
einfach nur nicht.
Dann nenne mir ihn bitte, damit ich nicht doof sterben muss.
Arduino Fanboy D. schrieb:> Wire.requestFrom ist eine Read Operation!
ach (Loriot)
für mein Verständnis, wenn ich Erfolg beim Read habe und mir das EEPROM
wieder antwortet ist es bereit, der interne Write.Byte Vorgang ist
abgeschlossen und darauf warte ich eben keine 5-10ms wie in den Arduino
LIBs
Arduino Fanboy D. schrieb:> Wire.beginTransmission> Wire.endTransmission> handeln eine Write Operation ab
ja und?
was willst du mir mitteilen?
erst wenn mir Read antwortet ist das EEPROM bereit, aber jeder darf die
Arduino LIBs mit den 5-10 ms Wartezeit nutzen, ist mir egal. Meine
Methode funktioniert seit 5 Jahren ob zufällig oder nicht.
In Arduino LIBs finde ich immer NUR die 5-10ms warten pro Bytewrite, das
finde ich halt blöd!
Andere dürfen das toll finden.
wie viele Arduinio LIBs kennst du die keine 5-10ms warten?
Joachim B. schrieb:> ja und?> was willst du mir mitteilen?
Dass dein gezeigter Code unsinnig ist.
Und auch "Warum?" das Unsinn ist.
Allerdings: Mittlerweile ist es mir auch recht egal ob du das kapierst.
Ist dein Groschen.
Joachim B. schrieb:> NUR die 5-10ms warten pro Bytewrite, das> finde ich halt blöd!
Da sage ich ja nichts gegen.
Habe dir sogar ein funktionsfähiges Beispiel geliefert.
(aber das interessiert dich ja offensichtlich nicht)
Joachim B. schrieb:> Meine Methode funktioniert seit 5 Jahren ob zufällig oder nicht.
Leute erschlagen, kann auch ein paar Jahre prächtig funktionieren.
Ist darum aber noch lange nicht "gut".
Oder?
Trump "funktioniert" auch schon seit ein paar Jahren.
Arduino Fanboy D. schrieb:> Dass dein gezeigter Code unsinnig ist.> Und auch "Warum?" das Unsinn ist.> Joachim B. schrieb:>> NUR die 5-10ms warten pro Bytewrite, das>> finde ich halt blöd!> Da sage ich ja nichts gegen.> Habe dir sogar ein funktionsfähiges Beispiel geliefert.> (aber das interessiert dich ja offensichtlich nicht)
doch doch, ich probiere ihn auch, nur sind das eigentlich immer wieder
Dinge die ich eigentlich nicht immer wieder neu ergründen wollte, was
mir aber gefällt ist dein Satz!
Arduino Fanboy D. schrieb:> Da sage ich ja nichts gegen.
warum muss fast jeder Arduino LIB Schreiber die ominösen 5-10ms delay
reinbringen wenn die Lösung doch so einfach ist?
Ich hatte nun für mich schon längst eine bessere Methode gefunden was ja
nicht heisst das es nicht noch bessere gibt!
Die werde ich probieren!
Joachim B. schrieb:> Die werde ich probieren!
ich bin zwar noch nicht soweit aber immerhin nähere ich mich meinen
Wunsch das SW Gerippe für nano und ESP zumindest nach allen Updates
wieder auf gleichen Stand zu bringen, für Nano und ESP werden andere
5110 Module und LIBs verwendet die bedingt vom #preprozessor eingebunden
werden. Hier nicht so gut zu sehen das ESP5110 mit den nun weissen LEDs
0805 von
https://www.ebay.de/itm/370874053309
die blue leds waren doch dann unerträglich für meine Augen.
Der Unterschied ist das das 5110 zwar 5V tolerant ist in den
Datenleitungen aber die LEDs angepasste Vorwiderstände brauchen deswegen
sollte den blauen PCB keine 5V zugemutet werden, die roten PCB laufen
auch mit 3,3V aber die LEDs sind dann dunkler, den blauen PCB droht an
5V der LED Tod, warnen auch einige Seller! in komischen english, kann
leicht übersehen werden!
Joachim B. schrieb:> nur sind das eigentlich immer wieder> Dinge die ich eigentlich nicht immer wieder neu ergründen wollte,
Da gibts diesen schönen Spruch:
> Wir lernen, indem wir es tun!
Hier das: Ergründen!
Und Strukturen solltest du auch tiefer ergründen!
Die sind in dem Zusammenhang Gold wert.
Tipp: offsetof()
Joachim B. schrieb:> wenn die Lösung doch so einfach ist?
Ist sie nicht.
Du verplemperst die Zeit einfach.
Die kann man auch sinnvoller nutzen.
z.B. yield() aufrufen.
Arduino Fanboy D. schrieb:> Joachim B. schrieb:>> wenn die Lösung doch so einfach ist?> Ist sie nicht.> Du verplemperst die Zeit einfach.
hast du ein Leseproblem oder ein Leseverständnisproblem?
So langsam gehts du mir auf den Geist und bist kein bischen mehr
hilfreich.
Nochmal für dich, meine I2C Eepromroutine ist schneller als alles was
ich in Arduino LIBs fand, auch nicht vom dir du großer Meister!
Wo sind deine SuperLIBs die ja 1000x besser sind als meine eigenen?
Bis jetzt bist du nur am rumnöhlen und am demotivieren, mag ja sein das
deine Lösung besser ist und vielleicht auch funktioniert DANN pflege sie
doch in eine Arduino LIB ein, habe ich aber nie gefunden, als was soll
das hier nun?
Nun kommst du mit yield, schon wieder etwas was bestimmt interessant ist
zu wissen aber gerade nicht im Moment für mich, denn man kann mit
Computer und µC prima Probleme lösen die man früher NIE hatte!
Ja es gibt viel zu lernen, dabei kann man prima vom Weg abkommen und
irgendwann so ein Spezialist sein der ALLES von NICHTS weiss!
ob man nun über yield geht oder gleich eine Statemaschine baut ist sowas
von egal und die Zeit die ich mit meiner Methode verplempere, was soll
denn der arme µC sonst machen, Zeit hat er genug!
Joachim B. schrieb:> Wo sind deine SuperLIBs die ja 1000x besser sind als meine eigenen?
Kann dir mein Modell ja mal zeigen.....
Das Urteil, ob "Besser", oder nicht, überlasse ich ganz dir.
Ist noch ganz dolle Baustelle!
Für einen Schönheitswettbewerb wirds nicht reichen.
Immerhin ist sie seit Jahren zuverlässig im Einsatz.
Falls dir irgendwelche Fehler auffallen, bitte ich dich sie mir
mitzuteilen.
Ich verspreche dir auch, nicht boshaft darauf zu reagieren.
Was drin ist, ist eine Routine um die Warte-/Rechenzeit per Callback
abzugeben.
Dort kann man natürlich auch yield() als Callback angeben.
Geeignet ist sie auch für FRAM usw.
------
Joachim B. schrieb:> und die Zeit die ich mit meiner Methode verplempere, was soll> denn der arme µC sonst machen, Zeit hat er genug!
Deine hier gezeigte Methode ist schlicht falsch!
Es ist ok, dass dir das nicht schmeckt.
Es ist auch ok den Boten zu töten.
Und natürlich darfst du auch weiter dein Fehler behaftetes Stück Code
verwenden.
Arduino Fanboy D. schrieb:> Es ist auch ok den Boten zu töten.
nö nur wenn er frech wird, was nun besser oder nicht ist darf jeder
selbst entscheiden.
Ich finde meine Methode lesbarer und verständlicher, aber das sollen
andere entscheiden!
Fakt ist, deine Methode war unter den Arduinos LIBs von mir nicht zu
finden, ein Armutszeugnis für die LIB Ersteller, nicht mehr und nicht
weniger.
Ich baute mir also meine Methode
Beitrag "Re: arduino oder GCC Programmierung"
und du zerreisst sie nun, ist deine Sache!
Joachim B. schrieb:> und du zerreisst sie nun, ist deine Sache!
Wenn ich irgendwas zerreiße, dann hört sich das so an:
Du hast Scheiße gebaut.
Deine void voidMyI2C_EepromWaitReady(void) ist scheiße.
Ich kann sie auch nur kritisieren, weil sie einen derben logischen
Fehler enthält.
Und jetzt kritisiere ich dich Persönlich:
Rat willst du nicht annehmen.
Überträgst die Kritik, an deiner Funktion, auf deine Person.
Fühlst dich persönlich angegriffen, obwohl ich nur die Funktion
kritisiere.
Jedem, der die Arduino Wire Doku halbwegs aufmerksam gelesen hat, muss
es klar sein, dass die Funktion einen logischen Fehler im Bauch hat.
Dir ist es nicht klar.
Selbst nach Erklärung nicht!
Im Gegenteil, du willst den Mist beibehalten.
Tue es!
Man, man ...
Und jetzt zu der größten Blamage:
Du kannst über die anderen Lib Hersteller herziehen, wie du lustig bist,
weil sie zu blöd sind das abzuhandeln.
Aber selber zu blöd um es richtig zu tun.
Merke:
Den Splitter im Auge des anderen, den siehst du, aber das eigene Brett
vom Schädel, das nicht.
Ganz ehrlich:
Ich bin froh, wenn ich auf einen Fehler in meinen Programmen hingewiesen
werde.
Ok, vielleicht muss ich kurz schlucken, aber auf lange Sicht: Froh!
Dass du dich so gegen den Hinweis sperrst, wirft schon ein recht
seltsames Licht.
Arduino Fanboy D. schrieb:> Dass du dich so gegen den Hinweis sperrst, wirft schon ein recht> seltsames Licht.
wo liest du das?
du hast wirklich eine komische Art zu lesen!
Ich schrieb doch sehr deutlich:
Joachim B. schrieb:> doch doch, ich probiere ihn auch, nur sind das eigentlich immer wieder> Dinge die ich eigentlich nicht immer wieder neu ergründen wollte, was> mir aber gefällt ist dein Satz!> Ich hatte nun für mich schon längst eine bessere Methode gefunden was ja> nicht heisst das es nicht noch bessere gibt!>> Die werde ich probieren!
und nun?
Bis jetzt sehe ich da nur borniertes Beharren!
Und ich glaube auch nicht, dass du schon den Fehler in deiner
Wartefunktion gefunden hast.
Kein Ton von dir dazu bisher...
Auch scheinst du 100kHz und 400kHz Devices auf dem Bus zu mischen.
Aus meiner Sicht ein gruseliges Unterfangen.
Aber du bist da ja schmerzfrei.
Joachim B. schrieb:> Ich finde meine Methode lesbarer und verständlicher,> aber das sollen andere entscheiden!
Sie mag lesbarer und verständlicher sein, deswegen ist sie trotzdem
falsch. Ein lesbarer und verständlicher Beweis, dass 2+2=5 ist, macht
die Rechnung auch nicht richtiger...
Aber was soll's.
Veit D. schrieb:> seltsame Wartezeiten habe ich damit nicht.
Das sind keine seltsamen Wartezeiten, sondern die im EEPROM Datenblatt
angegebenen.
Wenn du die ignorierst, wird dein Programm (bis zu ca 10ms lang) nach
dem Schreiben versagen.
Dieses Versagen fängst du ab:
> if (Wire.endTransmission() > 0) { // war Connect fehlerfrei?> return false; // I2C Busfehler ?
Wichtig ist dann nur, dass dieses return false; auch in der Anwendung zu
einer Wiederholung des Zugriffs führt.
Dann hast du "seltsame Wartezeit" abgehandelt, ohne es zu merken.
Auf jeden ist es sehr konsequent, auf den Erfolg der I2C Aktionen zu
prüfen.
Hallo,
aja okay, ich hatte nicht bedacht das es sich um die EEProm Wartezeiten
handelt. Die Funktionen nutze ich für andere Dinge wie zum Bsp. RTC oder
MCP Portexpander o.ä.
Danke für die Erläuterung.
Veit D. schrieb:> aja okay, ich hatte nicht bedacht das es sich um die EEProm Wartezeiten> handelt. Die Funktionen nutze ich für andere Dinge wie zum Bsp. RTC
und bei einigen RTC ist das EEPROM dabei welches ich nutze, wenn auch
angeblich falsch, aber es funktioniert (was nicht heisst das ich es
nicht noch verbessern kann).
Es soll Berichte geben das ATmega o.ä. nicht mit clockstretching zu
recht kommen, da wäre noch ein Port und ein Timeout nötig, nicht das
sich der Arduino in einer Endlos Schleife aufhängt und bis zum Jahr 2500
wartet.
Ist bei mir nie vorgekommen, aber meist mache ich die Versorgung eh aus
Ports und somit schaltbar.
Joachim B. schrieb:> Es soll Berichte geben das ATmega o.ä. nicht mit clockstretching zu> recht kommen,
Solche Berichte mag es geben.
Sind das vielleicht die berühmten "Fake News"?
Joachim B. schrieb:> und ein Timeout nötig,
Ist in Wire eingebaut.
(muss man nur nutzen)
Joachim B. schrieb:> nicht das> sich der Arduino in einer Endlos Schleife aufhängt und bis zum Jahr 2500> wartet.
Wenn der Programmierer das zulässt und den eingebauten Wire Timeout
ignoriert/ausblendet, dann selber Schuld!
Arduino Fanboy D. schrieb:> Immerhin schon seit über einem Monat.> Bisher übersehen?
witzig ich hatte sogar gerade gesucht unter "wire timeout"
rate mal was man findet!
https://www.arduino.cc/en/Reference/Wire
und wer "wire timeout" sucht findet, mag jeder selber probieren!
Die Funktion heisst nun mal wire!
unter TWI timeout zu suchen ich gestehe darauf kam ich nicht!
Joachim B. schrieb:> Die Funktion heisst nun mal wire!
Nein!
Die Klasse heißt TwoWire und die Instanz dann Wire.
Ein wire gibts da nicht. Weit und breit nicht.
In der Klasse TwoWire findest du die nötigen Methoden um dein Timeout
abzuhandeln.
Die Doku hängt leider etwas hinterher...
Kannste ja mal Hand anlegen, wenn dir danach ist.
Hi
>Die Doku hängt leider etwas hinterher...
Nö. Das ganze Arduinogedödel hängt hinter her.
Timeout habe ich seit 1999 in meinen I2C-Libs drin. Da war an die
Arduinoseuche noch nicht zu denken.
MfG Spess
Joachim B. schrieb:> Das man bei Wire.begin() auch Pins angeben kann ist ja schon der Gipfel> der guten Beschreibung, leider nicht mal in Beispielen der Reihenfolge,> ich kann mir das nicht mal merken ob zerst SDA oder SCL kommen muss und> man findet es nicht auf der Arduino Seite!
Natürlich findet man das nicht auf der Arduino Seite, da Diese Wire Lib
keine Arduino Wire Lib ist, sondern vom ESP Team bereitgestellt wird.
Du vergleichst Äpfel mit Birnen.
--------
Joachim B. schrieb:> wo ist da die Fuktion Timeout?
Ich schrub dir:
> Die Doku hängt leider etwas hinterher...> Kannste ja mal Hand anlegen, wenn dir danach ist.
Was du davon hältst ist dein Problem.
----------
Joachim B. schrieb:> am ESP kann man sogar 2 I2C nutzen
Der DUE kann das auch...
Ganz ohne Pins angeben zu müssen/können.
---------
Die Arduino Doku kann sich nur auf das beziehen, was Arduino selber so
ausliefert.
Irgendwas anderes anzunehmen ist hochgradig irrational.
Du setzt dich ja auch nicht mit dem Handbuch eines Renault R4 in einen
modernen Porsche und meinst so die Bedienung des Getriebes zu lernen,
oder?
Arduino Fanboy D. schrieb:> da Diese Wire Lib> keine Arduino Wire Lib ist, sondern vom ESP Team bereitgestellt wird.> Du vergleichst Äpfel mit Birnen.
hier muss ich klar widersprechen, ich meine schon die Arduinio Wire LIB
denen man auch Ports mitgeben kann!
Rede dich doch nicht raus, wenn ich den "Arduino" ATmega 1284p nutze
nutzt der keine ESP LIB.
Nun wirst du wieder kontern und schreiben es gibt keinen offiziellen
Arduino m1284p!
Aber nicht desto trotz wird die Arduino Wire LIB genutzt und keine
andere!
(nur die board.txt ist angepasst erweitert worden!)
OK soll mir recht sein!
was streiten wir hier um Kaisers Bart? ich mag Arduino auch bin ein Fan
und du musst mich hier nicht versuchen zu demontieren!
Joachim B. schrieb:> ich meine schon die Arduinio Wire LIB> denen man auch Ports mitgeben kann!
Dieses ist die offizielle Arduino Wire Lib für AVRhttps://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.h
Wo kann man da die Pins übergeben?
Joachim B. schrieb:> du musst mich hier nicht versuchen zu demontieren!
Wenn ich jemanden demontieren will, dann gehe ich das anders an!
Z.B. So:
Du lügst.
Du lügst entweder mit Absicht, oder weil du zu ***** bist
Hmmm...
Wenn ich annehmen müsste, du würdest absichtlich die Unwahrheit sagen,
dann würde ich auch annehmen müssen, dass du ein Arschloch bist.
Aber ganz ehrlich:
Ich glaube nicht, dass du ein Arschloch bist.
Wirfst manchmal ein paar Dinge durcheinander, die nicht in einem Topf
gehören...
Gibst dich viel zu häufig mit der ersten (leider häufig falschen)
Annahme zufrieden...
Aber dass du wirklich böse bist, oder so...
Nee, das traue ich dir nicht zu.
Leider verarscht du dich mehr selber mit den Dingen, als mich.
Wirfst dir natürlich so selber die Stöcke zwischen die Beine.
Leider kann ich da nichts dran ändern.
Kann dich nur darauf hinweisen, wenn du irrst.
Wie du dann auf den Hinweis eingehst, ist nun wirklich deine Sache.
Johannes S. schrieb:> könntet ihr euch nicht einfach mal auf ein Bier zusammensetzen und das> lösen?
Starrsinn und Beratungsresistenz hört nach einem Bier noch
nicht auf. Da braucht es schon mehrere ... je nach Konstitution.
Oft hilft auch Bier und andere ähnliche Getränke gar nicht.
Grösste Schwierigkeit scheint darin zu bestehen sein Nichtrechthaben
einzugestehen.
jo mei schrieb:> Grösste Schwierigkeit scheint darin zu bestehen sein Nichtrechthaben> einzugestehen.
wen meinst du denn?
Ich habe hier einen "Arduino" m1284p erfolgreich mit der Arduino IDE
arbeiten lassen, der nutzt 100% nicht die ESP LIB
Irgendwie muss er also die Arduino LIB nutzen denn ich hatte keine
andere installiert!
Nun wird aber behauptet es geht nicht das man der Arduino LIB Pins
übergibt
Arduino Fanboy D. schrieb:> Wo kann man da die Pins übergeben?
gute Frage, aber hier in der boards.txt auch nicht
und trotzdem funktionert er im I2C
wie sollte das denn sonst gehen wenn SDA und SCL nicht bekannt gemacht
werden?
die grünen und gelben Leitungen zur RTC
Arduino Fanboy D. schrieb:> Wo kann man da die Pins übergeben?
Joachim B. schrieb:> wie sollte das denn sonst gehen wenn SDA und SCL nicht bekannt gemacht> werden?
Indem ein ATmega1284P halt nur zwei Pins für SDA und SCL hat, die vom
IC-Design her festgelegt sind (PC0 und PC1).
Jörg W. schrieb:> Indem ein ATmega1284P halt nur zwei Pins für SDA und SCL hat, die vom> IC-Design her festgelegt sind (PC0 und PC1).
das steht doch im Widerspruch zu:
Arduino Fanboy D. schrieb:> Wo kann man da die Pins übergeben?
Also man kann also angeblich der Arduino LIB keine SCL und SDA Pins
übergeben und trotzdem funktionieren alle Arduino m1284p Clones mit der
LIB, merkt hier noch jemand was?
ausserdem gilt weiter:
Joachim B. schrieb:> was streiten wir hier um Kaisers Bart? ich mag Arduino auch bin ein Fan> und du musst mich hier nicht versuchen zu demontieren!Johannes S. schrieb:> könntet ihr euch nicht einfach mal auf ein Bier zusammensetzen und das> lösen?
wird sehr schwer, ich trinke nie Bier!
Joachim B. schrieb:> Also man kann also angeblich der Arduino LIB keine SCL und SDA Pins> übergeben und trotzdem funktionieren alle Arduino m1284p Clones mit der> LIB, merkt hier noch jemand was?
Ich verstehe zumindest nicht mehr, was du da willst.
Viele AVRs haben halt nur genau eine TWI-Einheit, die hat zwei vom
Chipdesign her fest vorgegebene Pins für SDA und SCL.
Daher kann das Arduino-Framework eine Bibliothek bauen, die (abhängig
vom MCU-Typ, aber der steht ja zur Compilezeit fest) genau diese beiden
Pins bei der Initialisierung der TWI-Klasse passend festlegt. Da muss
man nichts "übergeben".
Wenn man natürlich auf eine völlig andere Controllerfamilie geht, sieht
die Sache ganz anders aus. Schon bei einigen Xmega-Modellen gibt es mehr
als eine TWI-Einheit.
Joachim B. schrieb:> Nun wird aber behauptet es geht nicht das man der Arduino LIB Pins> übergibt
Das behaupte ich nicht, sondern das habe ich dir bewiesen.
Das ist vielleicht für dich nur ein winziger Unterschied.
Aber in Sachen "Faktenlage", macht das ganz schön was her.
Joachim B. schrieb:> Irgendwie muss er also die Arduino LIB nutzen denn ich hatte keine> andere installiert!
Wenn du dir die ausführlichen Ausgaben anschaust, erklärt dir die
Arduino IDE genau, welche Libs verwendet werden.
Leider reichen meine Augen nicht bis auf deinen Monitor.
Darum sehe ich weder deinen Code, noch deine Ausgaben.
Ich glaube dir einfach nicht dass du da Pins beim Wire.begin() angegeben
hast.
No!
Da sprichst du die Unwahrheit.
Bedenke::
Der der m1284p hat nur eine einzige TWI Einheit.
Irgendeinen Pin/Port Multiplexer hat es auch nicht.
Warum sollte man da Pins angeben?
Dazu gibt es keine Notwendigkeit, da die Pins fest vergeben sind..
Aus meiner Sicht gibts da nur 2 Möglichkeiten:
1 Du irrst dich (mal wieder)
2 Du verwendest irgendeine exotische SoftI2C Lib
Jörg W. schrieb:> Ich verstehe zumindest nicht mehr, was du da willst.
ich bald auch nicht mehr, halten wir fest,
es wird behauptet der Arduino LIB kann man die I2C Pins nicht übergeben!
Arduino Fanboy D. schrieb:> Dieses ist die offizielle Arduino Wire Lib für AVR> https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.h> Wo kann man da die Pins übergeben?
dann wird geschrieben:
Arduino Fanboy D. schrieb:> Ich glaube nicht, dass du ein Arschloch bist.> Wirfst manchmal ein paar Dinge durcheinander, die nicht in einem Topf> gehören...
das würde ja dann heissen KEIN Arduino Clone mit m1284p funktioniert,
was aber definitiv nicht stimmt!
es wird für den m1284p Arduino Clone auch keine extra LIB als die vom
AVR genutzt!
Das mit der ESP32 Lib ist also ein echt unnötiger Tiefschlag und lenkt
nur vom Thema ab!
Arduino Fanboy D. schrieb:> Natürlich findet man das nicht auf der Arduino Seite, da Diese Wire Lib> keine Arduino Wire Lib ist, sondern vom ESP Team bereitgestellt wird.> Du vergleichst Äpfel mit Birnen.
ist eine Nebelkerze!
es gibt mittlerweile unzählige m1284p Arduino Clones
also was soll das vom Arduino Fan?
Joachim B. schrieb:> Das mit der ESP32 Lib ist also ein echt unnötiger Tiefschlag und lenkt> nur vom Thema ab!
Tut mir leid, aber auch hier irrst du dich.
Du bist mit den ESP, im Anschlag, hier aufgetreten.
Das ist im Thread nachzulesen.
Somit beweisbar.
Joachim B. schrieb:> ist eine Nebelkerze!
(Fast)Gute Diagnose, ja!
Allerdings: Eine deiner Nebelkerzen.
Joachim B. schrieb:> also was soll das vom Arduino Fan?
Tja....
Mir scheint, du lebst im Irrtum und hast es dir da schön eingerichtet.
Ja, da werde ich wohl nichts dran ändern können.
Aber ich versuchs weiter.... vielleicht kommt da ja doch nochmal sowas
wie Einsicht.
Kann es nicht einfach sein dass die Arduino-Klasse die Pins die
man übergibt einfach ignoriert wenn sie weiss auf welchem Prozessor
sie gerade implementiert wird?
Joachim B. schrieb:> das würde ja dann heissen KEIN Arduino Clone mit m1284p funktioniert
Mir ist schleierhaft, wie du zu dieser Schlussfolgerung kommst.
Solange eine solche Bibliothek für den ATmega1284P compiliert worden
ist, kann sie implizit (zur Compilezeit) wissen, dass sie dafür andere
IO-Pins benutzen muss als für einen ATmega328.
jo mei schrieb:> Kann es nicht einfach sein dass die Arduino-Klasse die Pins die> man übergibt einfach ignoriert wenn sie weiss auf welchem Prozessor> sie gerade implementiert wird?
Nein!
Jörg W. schrieb:> Edit: ufuf war ein wenig schneller …
ja und? und das beweist das der Arduino Wire.h Pins zugewiesen werden
kann!
und steht im krassen Widerspruch zu
Arduino Fanboy D. schrieb:> Dieses ist die offizielle Arduino Wire Lib für AVR> https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.h> Wo kann man da die Pins übergeben?
Es funktionieren alle Arduino m1284p clones mit der wire LIB von
Arduino!
der ja angeblich keine SDA und SCL Pins übergeben werden kann.
OMG, ich gebe auf
wer ist hier eigentlich der Falschfahrer?
Joachim B. schrieb:> das beweist das der Arduino Wire.h Pins zugewiesen werden kann!
Nein, Joachim, auf dieser Basis ist es wirklich sinnlos, mit dir zu
diskutieren.
Du schmeißt frischfröhlich alles durcheinander, ein Headerfile mit einer
Bibliothek, also eine Interface-Beschreibung mit etwas, wo sich jemand
anders die Mühe gemacht hat, die (anschließend zu compilierende)
Bibliothek anzupassen für einen neuen Controller.
Das ist eine Art Bibliotheks-Portierung, was derjenige da getan hat. Es
ist natürlich schön, dass die Arduino-Bibliothek offenbar da recht
einfach auf einen anderen (zumindest AVR-)Prozessor portiert werden kann
¹), aber das ist eine Aufgabe, die jemand einmal macht, und zwar
nicht der „Endkunde“ (also Arduino-Nutzer).
Unter „Zuweisung“ würde man gemeinhin in diesem Kontext wohl eher etwas
verstehen, was du in deiner Applikation frei weg ändern kannst. Das
ist hier absolut nicht gegeben. Du kannst und musst die SDA und SCL Pins
einfach nur exakt an PC1 und PC0 benutzen, wenn du einen ATmega1284P
hast.
¹) Diese Eleganz hat natürlich an vielen Stellen performancemäßig ihren
Preis. Aber für die ursprüngliche Zielgruppe der Arduinos spielt das
eine untergeordnete Rolle, der sich daraus ergebende Komfort ist für sie
wichtiger als maximale Performance.
Joachim B. schrieb:> wer ist hier eigentlich der Falschfahrer?
Eindeutig du!
Joachim B. schrieb:> Das man bei Wire.begin() auch Pins angeben kann ist ja schon der Gipfel> der guten Beschreibung, leider nicht mal in Beispielen der Reihenfolge,> ich kann mir das nicht mal merken ob zerst SDA oder SCL kommen muss und> man findet es nicht auf der Arduino Seite!
Das ist falsch.
Die Unwahrheit, eine Lüge, oder ein Irrtum, wenn es sich auf die
originale Arduino AVR Wire Lib bezieht.
Und da du dich auf die offizielle Arduino Doku beziehst, und behauptest
diese originale Arduino AVR Wire Lib zu verwenden, muss das wohl so
sein.
Bedenke:
Es ist bewiesen, dass man bei dem AVR Arduino Wire.begin() nicht die
Pins angeben kann.
Bei den ESP Wire und anderen Wire Libs, mag das anders aussehen...
Man könnte eine I2C-Lib so schreiben, daß sie ohne Pindefinition das
HW-I2C benutzt und mit Pindefinition einen single-Master in SW
implementiert. Von der Codegröße her ist das kaum ein Unterschied. Und
wenn das HW-I2C nicht als Interrupt implementiert wird, ist auch die
CPU-Last gleich.
Hier mal SW-I2C:
Beitrag "Re: Soft I2C Master"
Arduino Fanboy D. schrieb:>> Das man bei Wire.begin() auch Pins angeben kann […]> Das ist falsch.
In der Form ganz eindeutig.
Man kann das natürlich als Designfehler ansehen, denn schon der
ATmega328PB hat 2 x TWI, Xmegas und ARMs sowieso. Ich hätte es
allerdings, wenn schon, nicht im Wire.begin() angeben wollen sondern im
Konstruktor des Wire-Objekts (für das es bei entsprechender Hardware ja
mehr als eins geben könnte).
Arduino Fanboy D. schrieb:> Bedenke:> Es ist bewiesen, dass man bei Wire.begin() nicht die Pins angeben kann.Veit D. schrieb:> Joachim, liest du auch was man dir zeigt?
ja, lest ihr was ich schreibe?
wenn man der Wire LIB wie auch immer keine Pins mitgeben könnte,
dann würde ja nicht mal der original Arduino m2560 und der nano328p
funktionieren!
wo das geschieht ist doch egal,
https://www.arduino.cc/en/Reference/Wire
also muss Wire sich die Pins holen das ist logisch, also warum wird hier
behauptet man kann der Wire keine Pins mitgeben?
Es ist richtig das AVR Wire keine Funktion der PIN Übergabe hat und
trotzdem wird Arduino Wire! (nicht ESP32 Wire) mit verschiedenen TWI
Pins genutzt und innerhalb der AVR Familie ohne eine andere LIB als AVR
einzubinden.
https://www.arduino.cc/en/Reference/Wire
Klar bindet ein ESP32 eine andere LIB ein unter hardware, aber nicht AVR
Ich versuche ja meinen angeblichen Fehler zu verstehen, bis jetzt waren
alle Erklärungen aber unlogisch oder zumindest für mich unverständlich.
Joachim B. schrieb:> ohne eine andere LIB als AVR
Das ist dein Trugschluss.
Selbstverständlich ist die Bibliothek für den ATmega124P eine andere als
die für den ATmega328. Beide benutzen allerdings das exakt gleiche API,
was sich im gleichen (und auch nicht irgendwie mit #ifdef MCU-abhängig
modifizierten) Wire.h ausdrückt. Diese Datei ist nicht „die
Bibliothek“, sondern lediglich die Interface-Beschreibung der
tatsächlichen Bibliothek (die der Linker dann dazu linkt).
Deine Gleichsetzung ist ungefähr so, wie wenn du sagst, dass x86 und ARM
beim GCC „ohne eine andere Lib“ funktionieren würden, nur weil man bei
beiden bspw. das gleiche printf() benutzen kann, dessen Interface im
gleichen <stdio.h> beschrieben wird.
> bis jetzt waren alle Erklärungen aber unlogisch oder zumindest für mich> unverständlich.
Dann können wir daran versuchen zu arbeiten, wie man dir das nun noch
verständlich rüberbringen kann. Aber du siehst uns hier alle ein wenig
ratlos.
Joachim B. schrieb:> wenn man der Wire LIB wie auch immer keine Pins mitgeben könnte,>> dann würde ja nicht mal der original Arduino m2560 und der nano328p> funktionieren!
Tja, das ist die Magie eines in Hardware implementierten Moduls.
Da schreibt man in ein Register, und der Prozessor wackelt dann mit
irgendwelchen Pins. Und das alles ganz ohne Pinzuweisung.
Prinzipiell braucht eine TWI-lib gar nicht zu wissen, an welchen Pins
SCL und SDA liegen. Daher muß der auch nichts dazu übergeben werden.
Oliver
Jörg W. schrieb:> Aber du siehst uns hier alle ein wenig> ratlos.
und du mich erst, ich will ja lernen, aber wenn so salopp geschrieben
wird der Wire Lib können keine Pins übergeben werden dann kann das so
nicht funktionieren, denn Wire wird genutzt und Wire muss wissen welche
Pins gelten!
Oliver S. schrieb:> Prinzipiell braucht eine TWI-lib gar nicht zu wissen, an welchen Pins> SCL und SDA liegen.
Höchstens, um die den PORT-Pins zugeordneten internen Pullups zu
aktivieren. Das hatte ufuf ja oben schon mal angedeutet. Bei langsamen
Peripheriegeräten kommt man auf diese Weise ggf. ohne externe Pullups
aus.
Der Vollständigkeit halber möchte ich noch die in Assembler geschriebene
I2C-Master Bibliothek auf Fleury basierend für AVRs erwähnen mit der ich
bei 328/1284 sehr gute Erfahrungen genacht habe. Die hängt sich auch bei
Übertragungsfehlern nicht auf. Auch kann man beliebige Pins wählen.
https://github.com/chrisramsay/i2cmaster
Die Arduino Version gefiel mir da weniger aus dem Grund, daß IC
Datenblätter ihre Transaktionen immer mit Start, Write, Read, Stop
beschreiben und die Arduinoversion mir das zu sehr abstrahiert. Mir ist
lieber die Datenblattbeschreibung im Code nachverfolgen zu können.
Auch ist Acknowledgment Polling bei EEPROMS beschreiben nützlich was bei
der Arduinoversion nicht so offensichtlich ist.
Gerhard O. schrieb:> Der Vollständigkeit halber möchte ich noch die in Assembler geschriebene> I2C-Master Bibliothek auf Fleury basierend für AVRs erwähnen mit der ich> bei 328/1284 sehr gute Erfahrungen genacht habe.
und mit der ich vor Arduino auch im AVR Studio 4.18 angefangen hatte und
sie auch irgendwie im Arduino nutze um die Temperatur der RTC DS3231
auszulesen!
Joachim B. schrieb:> und du mich erst, ich will ja lernen, aber wenn so salopp geschrieben> wird der Wire Lib können keine Pins übergeben werden dann kann das so> nicht funktionieren, denn Wire wird genutzt und Wire muss wissen welche> Pins gelten!
Dann sieh dir das hier mal an.
https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/Wire.cpp
Es ist tatsächlich so, wie Oliver schrieb: das macht alles die Hardware.
Die Worte SCL und SDA tauchen in der kompletten Implementierung der
I²C-Routinen schlicht nicht auf; es werden also auch keine internen
Pullups eingeschaltet. (Wer das will, müsste das daher explizit über
pinMode() setzen, und an dieser Stelle muss derjenige sehr wohl
natürlich wissen, ob er es mit einem ATmega328 oder ATmega1284 zu tun
hat.)
Jörg W. schrieb:> Die Worte SCL und SDA tauchen in der kompletten Implementierung der> I²C-Routinen schlicht nicht auf;
das glaube ich ja gerne und trotzdem funktionierte der mighty mini 1284p
sofort in der Arduino IDE ich glaube damals noch v1.0.5
Ohne das ich einen Finger dafür rühren musste! obwohl die TWI Pins
woanders liegen!
Selbst beim originalen nano328p und m2560 musste man nichts weiter
angeben, also muss Wire Kenntnis bekommen welche Pins beim AVR genutzt
werden.
Joachim B. schrieb:> und trotzdem
… hast du dir wohl Olivers Kommentar oben nach wie vor noch nicht
durchgelesen.
Und trotzdem war das mehr Zufall und Glück: die IO-Register für TWI
unterscheiden sich zwischen ATmega328 und ATmega1284P nicht. Das ist
aber keineswegs für alle AVRs so gegeben: während viele neuere AVRs
diesen Registerblock ab Adresse 0xB8 haben, liegt er bei älteren AVRs
(ATmega8, ATmega16, ATmega128) ab Adresse 0x70. Für diese würde der
"Trick" nicht funktionieren, für diese muss man die Library neu
compilieren, wenn man damit einen Arduino-Clone bauen will.
Schätzungsweise fiel die Wahl für diese "erweiterten Clones" wohl auch
genau deshalb auf den ATmega1284P, weil er tatsächlich in weiten Teilen
register- und damit binärkompatibel mit dem ATmega328 ist.
Jörg W. schrieb:> Man kann das natürlich als Designfehler ansehen, denn schon der> ATmega328PB hat 2 x TWI, Xmegas und ARMs sowieso.
ATmega328PB:
Soweit mir bekannt gibt es keinen Arduino mit ATmega328PB
ARM:
Der Arduino DUE kennt Wire und Wire1
Xmega:
Da kann ich nix zu sagen.
Jörg W. schrieb:> Es ist tatsächlich so, wie Oliver schrieb: das macht alles die Hardware.>> Die Worte SCL und SDA tauchen in der kompletten Implementierung der> I²C-Routinen schlicht nicht auf; es werden also auch keine internen> Pullups eingeschaltet. (Wer das will, müsste das daher explizit über> pinMode() setzen, und an dieser Stelle muss derjenige sehr wohl> natürlich wissen, ob er es mit einem ATmega328 oder ATmega1284 zu tun> hat.)
Das ist nur zu bestenfalls 50% richtig.
Siehe:
https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/utility/twi.c#L88
Ist aber Detailkram.
Der Pullup ist nicht wirklich immer hilfreich, da zu groß für eine
Vielzahl Anwendungen
Verhindert allerdings Busblockaden bzw. Wire Fehlfunktionen, wenn nix
angeschlossen ist.
Jörg W. schrieb:> Und trotzdem war das mehr Zufall und Glück: die IO-Register für TWI> unterscheiden sich zwischen ATmega328 und ATmega1284P nicht.
und für den m2560 ohne nachzusehen?
egal, vielleicht klemmt mein Verständnis nur an dem Wort LIB.
Ist denn die Wire nur ein Überbau und gar keine LIB?
Alle LIB was ich so sah haben CPP und H Files, manchmal auch HPP Files.
Wenn die Wire nur eine Klassensammlung ist und gar keine LIB dann ist
klar warum ich es nicht verstehe.
Dann wäre aber für Wire der Begriff LIB wohl falsch?
Trotzdem wird es LIB genannt???
https://arduino.stackexchange.com/questions/65507/i2c-interference-sensorsclsda-and-masterslave-comm>// masterSlave - generates problem with BMP280...
Wire.begin(0,2);//Change to Wire.begin() for non ESP. D3 SDA D4
SCL
>The Adafruit BMP280 library uses the Wire library. It calls begin() at default
pins (D1, D2).
In Arduino ist eine Library = der Quelltext einer oder mehrerer Klassen.
Das was wir normalerweise Bibliothek nennen, ist bei Arduino ein Core -
aber in der Regel als Quelltext, nicht in Binärform.
Und ein Schild ist eine Aufsteckplatine - manche andere Baukästen nennen
es Hut.
Die Arduino Macher wollten sich wohl durch eigene Sprache vom Fußvolk
abheben.
Arduino Fanboy D. schrieb:> https://github.com/arduino/ArduinoCore-avr/blob/master/libraries/Wire/src/utility/twi.c#L88
OK, die hatte ich vorhin nicht gefunden.
Joachim B. schrieb:>> Und trotzdem war das mehr Zufall und Glück: die IO-Register für TWI>> unterscheiden sich zwischen ATmega328 und ATmega1284P nicht.>> und für den m2560 ohne nachzusehen?
Der ATmega2560 ist der erste AVR aus dieser Generation. Wesentliche
Unterschiede zu den älteren:
* ein RC-Oszillator statt dreier
* clock prescaler, den man on the fly umschalten kann
* watchdog, der "anhängig" ist; wenn er getriggert hat, muss man das
WDRF-Bit löschen, sonst feuert er gleich wieder
Wahrscheinlich habe ich noch welche vergessen, das AVR-Wissen verblasst
allmählich :), benutze zu viel ARM in letzter Zeit.
Mit diesen Architekturänderungen waren auch einige Änderungen in den
IO-Adressen einher gegangen.
Aber: der ATmega2560 ist nicht binärkompatibel mit den anderen ATmegas
(<= 128 KiB Flash). Er hat nämlich einen 3-Byte-PC und entsprechend
geändertes CALL/RET-Verhalten. Schon daraus wird offensichtlich, dass
die Bibliotheken sehr wohl spezifisch für den jeweiligen Controller
gebaut werden müssen.
> egal, vielleicht klemmt mein Verständnis nur an dem Wort LIB.> Ist denn die Wire nur ein Überbau und gar keine LIB?
Eine Library ist ein vorcompiliertes Gebilde, welches vom Linker dazu
gelinkt wird. Das wird (in diesem Falle) auf einen bestimmten Controller
compiliert (-mmcu=<controller name>). Dadurch werden auch die Änderungen
der Pullup-Konfiguration, die ufuf ja gerade gezeigt hat, mit rein
compiliert.
Der Sourcecode (*.c / *.cpp) ist dabei üblicherweise für alle der
gleiche, der Objektcode nicht (notwendigerweise).
Die Headerdatei (*.h) beschreibt das Interface der Objektmodule.
Es ist mehr als wahrscheinlich, dass die Arduino-IDE nun sehr wohl in
der Lage ist, die verschiedenen Controller dahingehend auseinander zu
halten, dass sie dann auch im Linkerkommando die passende (für diesen
Controllertyp konfigurierte) Bibliothek linkt.
Beim Arduino kommt nun als Spezifik noch hinzu, dass das Framework
gleich noch "vorab" die Objektinstanzen erzgeut ("Wire" bzw. wie oben
genannt auch "Wire1"). Ich weiß nicht, ob das die IDE selbst hinzufügt
oder ob das statische Objekte innerhalb der Bibliothek sind; beides wäre
möglich. Schließlich liefert dir die IDE ja dort ein Framework, das
selbst ein main() besitzt und darin dann init() und loop() aufruft.
Jörg W. schrieb:> Ich weiß nicht, ob das die IDE selbst hinzufügt> oder ob das statische Objekte innerhalb der Bibliothek sind;
Es sind statische Objekte im Core für das jeweilige Board (um mal bei
der Arduino Sprache zu bleiben).
Stefan ⛄ F. schrieb:> In Arduino ist eine Library = der Quelltext einer oder mehrerer Klassen.
Das ist so nicht richtig.
Der Hauptbestandteil einer Lib ist eine *.h Datei.
Soweit mir bekannt, wird die Lib sonst nicht von der IDE zur Auswahl
angeboten.
Ansonsten gibts keinerlei absolut notwendigen Bestandteile.
Klassen sind üblich.
Gibt aber auch einige Libs, welche keine Klassen beinhalten.
Für die Funktionalität, eben die *.h, und je nach Bedarf *.c *.cpp und
.S Dateien.
Hier finden sich die Regeln für Benutzerdefinierte Libraries:
https://arduino.github.io/arduino-cli/library-specification/
Stefan ⛄ F. schrieb:> Das was wir normalerweise Bibliothek nennen, ist bei Arduino ein Core
Nö. Im Arduino Core sind die nötigen Funktionen des Arduino API, darauf
aufbauend sind ein paar Libs
https://github.com/arduino/ArduinoCore-avr/tree/master/libraries
Das ganze Paket funktioniert für einen Satz Varianten wie in
https://github.com/arduino/ArduinoCore-avr/tree/master/variants
definiert.
Zusammen mit Compiler und Tools ist das ein Package das mit dem
Boardverwalter installiert wird.
Für andere Prozessoren existiert der ganze Krempel parallel und
unabhängig. Wenn das API im AVR Core geändert wird, dann
kann/müssen/sollten andere nachziehen. Der Stand ist aber nie
einheitlich, wie man auch an dem STM32 Wirrwar sehen konnte. Was
natürlich die Freiheit eines jeden Entwicklers so eines Cores ist.
Der m1284 ist auch ein Core unabhängig vom ArduinoAVR, implmentiert aber
als Kern das gleiche Arduino API. Die Libraries sind auf die geänderte
Hardware angepasst und z.B. um einiges umfangreicher als die ArduinoAVR
Basis: https://github.com/MCUdude/MightyCore/tree/master/avr/libraries
Wire ist hier eine Bibliothek, mit gleichem Interface, aber angepasster
Implementierung.
Eine Auswahl verschiedener TWI ist im Interface nicht vorgesehen
gewesen, also hat man hier (die wie ich finde unelegante) Varinate
zweier Klassen gewählt. Es wird einfach zweimal das gleiche mit anderem
Klassennamen dupliziert. Nicht C++, aber funktioniert.
Es gibt durchaus OS wo man SPI oder I2C Hardware Resourcen im
Konstruktor angeben kann, aber die ganze Welt krallt sich ja lieber an
Arduino...
Jörg W. schrieb:> Eine Library ist ein vorcompiliertes Gebilde, welches vom Linker dazu> gelinkt wird.
Das ist in der Arduino Welt (bisher) nicht üblich.
Arduino definiert das Wort Library etwas anders.
Der Grund ist schlicht:
Da viele der Libraries für unterschiedliche µC Familien verwendet werden
können, müssen diese für jede Zielmaschine kompiliert werden können.
Das ändert sich gerade. Demnächst können auch ClosedCode *.a Dateien in
Library Paketen ausgeliefert und dann auch eingebunden den werden.
Rufus hatte hier im darauf rumgeritten das ein Library etwas
kompiliertes ist. Sehe ich nicht so und wo steht das? Eine Library ist
eine Codesammlung, als Quellcode oder vorkompiliert, in einzelnen
Objektdateien oder als Archiv zusammengepackt. .a steht für Library oder
Archive?
Finde ich hier Haarspalterei.
Jörg W. schrieb:> Aber: der ATmega2560 ist nicht binärkompatibel mit den anderen ATmegas> (<= 128 KiB Flash). Er hat nämlich einen 3-Byte-PC und entsprechend> geändertes CALL/RET-Verhalten. Schon daraus wird offensichtlich, dass> die Bibliotheken sehr wohl spezifisch für den jeweiligen Controller> gebaut werden müssen.
sehr merkwürdig, denn der Arduino m2560 original funktioniert ja mit der
fastLED Lib
Ich stolperte beim m2560 nur als ich Bilder in dne Adressraum einbinden
wollte, die BMP mussten in den ersten 64k liegen!
display3000 mit m2560 und TFT 2,1"
aber als ich fastLED auf dem m1284p los lies:
Beitrag "Arduino FastLED LIB vs. WS28xx LIB"
war der Zugriff im m1284p 10% langsamer durch das dritte Adressregister!
obwohl doch <=128k und alles 16-bitig abläuft.
ich konnte es für mich ja richten mit einem #define
Beitrag "Re: Arduino FastLED LIB vs. WS28xx LIB"
einfach für den m1284p den F_CPU Takt auf 90% gesetzt!
Arduino Fanboy D. schrieb:> Das ändert sich gerade. Demnächst können auch ClosedCode *.a Dateien in> Library Paketen ausgeliefert und dann auch eingebunden den werden.
Also alles vorprogrammiert für den Ritt in den endgültigen Abgrund
(jedenfalls aus Benutzersicht)...
War eigentlich auch nicht anders zu erwarten unter den Bedingungen des
realexistierenden Kapitalismus...
was definiert Arduino an einer Lib anders? Die C++ Stdlib implementiert
auch alles in header files. Wenn sichergestellt ist das die nur einmal
eingefügt werden geht das genauso. Nachteil ist das man den Code nicht
verstecken kann weil das Interface (die .h) immer gebraucht wird, das
c(pp) kann im Kompilat versteckt werden. Es ist weniger Schreibarbeit
weil in der Deklaration auch gleich der Code steckt. Da ist es logisch
das die IDE nur .h braucht, das Buildsystem braucht natürlich die Quelle
oder das Objekt oder das Archive.
Joachim B. schrieb:> sehr merkwürdig, denn der Arduino m2560 original funktioniert ja mit der> fastLED Lib
Es funktionieren alle Libs wenn die Abhängigkeiten aufgelöst werden
können. Und wenn eine Lib Hardwareabhängig ist, dann muss das in der
Implementierung berücksichtig werden, bei Arduino üblicherweise durch
#ifdef Orgien wo verschiedene Basen berücksichtigt werden. Aber mit
Sicherheit nie alle.
Fastled ist mühsam gewachsen, 1280 MightCore ist wohl seit 10/2019 drin:
https://github.com/FastLED/FastLED/blob/master/platforms/avr/fastpin_avr.h
Johannes S. schrieb:> 1280 MightCore ist wohl seit 10/2019 drin:
dann war ich (wie Edinson mit seinem DC) wohl 2015 zu auch früh.
Heute würde sich Edinson über HGÜ freuen!
Arduino Fanboy D. schrieb:> Da viele der Libraries für unterschiedliche µC Familien verwendet werden> können, müssen diese für jede Zielmaschine kompiliert werden können.
Das ist ja an anderen Stellen auch gelöst, beim Compiler beispielsweise
über die multilib-Konfiguration. So gibt es dann pro
multilib-Konstellation halt eine libgcc.a, eine libc.a, eine libm.a.
Die benutzt sogar Arduino am Ende. :-)
Wenn sich jedesmal jeder alles davon compilieren müsste, würde das sich
ziemlich in die Länge ziehen, schon deshalb hat es Sinn, Kram
vorzucompilieren.
Auch das Arduino-Environment sollte in der Lage sein, für jede
Architektur (so sehr viele sind es ja nicht) eine passende binäre
Library vorzuhalten und per -L-Option beim Linken auszuwählen.
Johannes S. schrieb:> Die C++ Stdlib implementiert auch alles in header files.
Nö, boost macht sowas, aber libstdc++ ist eine binäre (vorcompilierte)
Library (und eins der "missing pieces" beim AVR-GCC, das hat nie jemand
bis zu Ende gebracht). Durch all den Template-Kram kann man bei C++ zwar
auch mehr in Headerfiles unterbringen, aber das Argument der Compilezeit
bleibt dabei natürlich.
Jörg W. schrieb:> Auch das Arduino-Environment sollte in der Lage sein, für jede> Architektur (so sehr viele sind es ja nicht) eine passende binäre> Library vorzuhalten und per -L-Option beim Linken auszuwählen.
Beim ersten kompilieren des Projektes wird alles übersetzt.
Bei weiteren Läufen nur die veränderten Dateien.
Joachim B. schrieb:> dann war ich (wie Edinson mit seinem DC) wohl 2015 zu auch früh.
ja, der Kommentar vom commit hat mich fehlgeleitet. Es geht aber doch um
das Prinzip. Eine Lib funktioniert wenn sie auf API Funktionen aufbauen
kann (und der µC genügend Resourcen hat). Wenn es Hardwareabhängig wird,
dann muss Code angepasst werden oder die Lib funktioniert nicht.
Beim Wire wird ein ganz anderes Paket verwendet, Fastled ist eine
gemeinsame die alle Kerne kennen muss die sie unterstützen will.
Jörg W. schrieb:> Nö, boost macht sowas, aber libstdc++ ist eine binäre (vorcompilierte)> Library
ja, ok. In eigenen Libs kann man im .h Interface mit Code unterbringen,
finde ich Geschmacksache. Ich mags nicht so weil das Interface damit
unübersichtlich wird. Aber IDE/Editoren haben ja auch Hilfsmittel das
wieder übersichtlich zu machen.
Vorkompiliert hat noch den Nachteil das man auch Optionen fest setzt:
Release/Debugbuild, irgendwelche Buffersizes, Defaulteinstellungen für
Stdio, und viele viele mehr.
Arduino Fanboy D. schrieb:> Beim ersten kompilieren des Projektes wird alles übersetzt.> Bei weiteren Läufen nur die veränderten Dateien.
Das hat ja nichts mit einer Bibliothek (im klassischen Sinne) zu tun,
das ist einfach normale Funktionalität von "make" oder vergleichbaren
Buildsystemen.
Wenn du auf dem PC ein helloworld.c compilierst, dann willst du doch
nicht auch beim ersten Mal gleich noch eine ganze Litanei an
Quelldateien der C-Bibliothek compilieren müssen.
Johannes S. schrieb:> Vorkompiliert hat noch den Nachteil das man auch Optionen fest setzt:> Release/Debugbuild, irgendwelche Buffersizes, Defaulteinstellungen für> Stdio, und viele viele mehr.
Release/Debug unterscheidet sowieso nur Microsoft. ;-) GCC compiliert
den gleichen Code daraus, egal ob mit oder ohne "-g", und ab man in der
vorcompilierten Bibliothek die Debugsymbole drin lässt oder nicht, kann
man selbst entscheiden. (Eigentlich haben sie ohne den zugehörigen
Quelltext nicht viel Sinn, denn der Debugger kann dann sowieso nichts
tun.)
Dinge wie Buffer sizes baut man halt in richtige Bibliotheken nicht hart
ein. Siehe setvbuf() im stdio-Teil der Standardbibliothek.
Jörg W. schrieb:> Das hat ja nichts mit einer Bibliothek (im klassischen Sinne) zu tun,
Wie auch immer...
Ich kann nur sagen, wie es ist, und vielleicht auch etwas von dem was
kommt.
Für alles andere ....
Jörg W. schrieb:> Release/Debug unterscheidet sowieso nur Microsoft.
ich meine nicht nur das -g, sondern Profile die auch Optimierung und
defines anders setzen. Die Optimierung macht debuggen schwieriger.
Arduino Fanboy D. schrieb:> Ich kann nur sagen, wie es ist, und vielleicht auch etwas von dem was> kommt.
Trägt halt noch einen zusätzlichen Teil zur Verwirrung bei, wenn man
Dinge anders benennt, als das zuvor in der Computerei gemacht worden ist
… (das ist natürlich jetzt keine Kritik an dir, sondern daran, wie
Arduino die Benamsung festgelegt hat).
Sketches und .ino mag ich nicht, aber die Libs sind mir Schnuppe. Klar,
früher gab es die meist kompiliert weil man damit noch Geld verdienen
konnte und Quellen nicht verschenken wollte.
In der Bücherei gibts Bücher in Quellform als Buch und vorkompiliert als
Hörbuch. Deshalb wird es trotzdem nicht Hörbücherei genannt :)
Johannes S. schrieb:> Klar, früher gab es die meist kompiliert weil man damit noch Geld> verdienen konnte und Quellen nicht verschenken wollte.
Das allein ist kein Argument.
Ich möchte die Arduino-Macher und -Community mal sehen, wenn sie sich
die libgcc und avr-libc bei jedem Sketch neu compilieren müssen.
Ganz früher waren übrigens die Quellen auch schon zugänglich (UNIX gab's
als Sourcecode), trotzdem hatte man Bibliotheken.
Das wird mir jetzt zu akademisch, brauche endlich ein Bier.
Als Source oder vorkompiliert, ich kann beides mit meinem Lieblings
Mbed-os. Mit Arduino beschäftige ich mich nur weil es da auch gute Libs
gibt und die konvertiere ich mir dann :)
Eijeijei ... da diskutiert das Mikrocontrollernetz doch mal ernsthaft
über die Arduino-Libraries. Ich würde sagen, cyblord würde sich im Grabe
umdrehen ( wenn er da schon wäre ) ...
Beitrag "Re: Arduino - bringt's das ?"
( immerhin, nach 7 Jahren ... )
Zum Thema:
Wie bei fast allen größeren Softwareprojekten auch, entwickeln sich in
der Arduino-Welt verschiedene Forks, die unterschiedliche Eigenschaften
aufweisen können. Ein Beispiel mag die ESP-Library sein, die an
verschiedensten Stellen vom Atmega328 Framework abweicht.
Der Atmega328 hat nur eine TWI manche anderen Prozessoren haben mehrere.
Es gibt in der Arduino-Welt keine Standardisierungskommision, die für
einen einheitlich API sorgt. Die Firma Arduino-LCC selbst hat natürlich
nur Interesse, ihre Boards zu unterstützen, aber nicht unbedingt die der
Fremdhersteller ( wie alle Boards mit dem ESP32 ).
STM versucht mit seinem Framework möglichst nahe an der original
Arduino-API zu bleiben
https://github.com/stm32duino/Arduino_Core_STM32
was allerdings den ärgerlichen Nachteil hat, dass wesentliche
Peripheriekomponenten wie die I2S Audioschnittstellen nicht unterstützt
werden, aber Prozessoren in der Leistungsklasse hervorragend für
Audioanwendungen geeignet wären.
Da ist PRJC mit seinen Teenssies schon viel weiter
https://www.pjrc.com/
und schaffen es auch in vernünftiger Weise passende APIs zu
implementieren.
Oft ist es auch extrem hinderlich, dass es im Standardframework keinen
Timercallback gibt, was manche Echtzeitanwendungen vereinfachen würde.
Hans schrieb:> Timercallback
Eine Timer ISR zu etablieren ist ein Fingerschnippen.
Recht schlank, und einfach da sowieso schon alle AVR Timer laufen.
Ein benutzerdefinierbarer Timercallback ist erstaunlich teuer.
Es mündet in einer maximalen Push Pop Kaskade
Will man das?
Ich sage:
Das ist schon ok so.
Veit D. schrieb:> hast du den Stickstoff gekühlt? :-) :-)
nö, aber genau dort musste es rein, ich habe ja die fastLED nicht
geschrieben, die hatten zwar an schneller Prozzis gedacht aber nicht an
das Timing vom 1284p.
Warum der überhaupt ein drittes Adressbyte brauchte verstehe ich auch
nicht:
Jörg W. schrieb:> Aber: der ATmega2560 ist nicht binärkompatibel mit den anderen ATmegas> (<= 128 KiB Flash). Er hat nämlich einen 3-Byte-PC und entsprechend> geändertes CALL/RET-Verhalten.
und genau da habe ich auch Verständnisprobleme
Der 2560 hat logisch 3 Adressbyte, der 1284p braucht es nicht und
trotzdem ist der Zugriff 10% langsamer was nur auf das dritte Adressbyte
hinweisst.
Joachim B. schrieb:> nö, aber genau dort musste es rein,
Ich habs mal aufgeteilt, damit man den Bock besser sieht!
#if F_CPU < 96'000'000
Dein Mega läuft mit 96 MHz.
> hast du den Stickstoff gekühlt? :-) :-)
Ohne Stickstoff, oder flüssig Helium, wird das nix....
Arduino Fanboy D. schrieb:> #if F_CPU < 96'000'000> Dein Mega läuft mit 96 MHz.
Nö, er hat doch nur eine Fallunterscheidung für solche Atmegas, die
weniger als 96 MHz schnell sind. :-)
Hallo,
die besagten "3 Address Bytes" beziehen sich auf den Programmspeicher
(Flash) beim ATmega2560. Nur worauf beziehen sich die 10%? Sind das nur
Vermutungen oder wie gemessen? Dazu müßte man konkreter werden.
Veit D. schrieb:> Nur worauf beziehen sich die 10%? Sind das nur> Vermutungen oder wie gemessen? Dazu müßte man konkreter werden.Jörg W. schrieb:> Welcher Zugriff wo ist 10 % langsamer? Wogegen verglichen?
nicht gelesen?
Beitrag "Arduino FastLED LIB vs. WS28xx LIB"Joachim B. schrieb:> aber als ich fastLED auf dem m1284p los lies:> Beitrag "Arduino FastLED LIB vs. WS28xx LIB">> war der Zugriff im m1284p 10% langsamer durch das dritte Adressregister!> obwohl doch <=128k und alles 16-bitig abläuft.>> ich konnte es für mich ja richten mit einem #define> Beitrag "Re: Arduino FastLED LIB vs. WS28xx LIB"
Hallo,
laut FastLED Doku ist das Problem seit 2015 behoben. Lag an der
ATmega1284er Pinout Definition die mal jemand erstellt hatte. Stand ist
v3.3.3 von 02-2020. Verwendest du die aktuelle Version? Problem behoben?
Du betreibst demnach seit 2015 extremes Overclocking. Interessant. :-)
Veit D. schrieb:> laut FastLED Doku ist das Problem seit 2015 behoben.
nicht als ich das Problem hatte!
Veit D. schrieb:> Du betreibst demnach seit 2015 extremes Overclocking. Interessant.
auch das nicht, die Zeile stammte aus der original LIB und gerade weil
ich keinen µC > 96 MHz zu der Zeit hatte und meine Arduino niedriger
takteten fand ich genau diese Stelle passend um meine Anpassung dort
einzufügen.
Mittlerweile nutze ich ja 2 core ESP32 und einer davon hat sogar 240
MHz.
Jörg W. schrieb:> Mein Tipp: bau dir eine Initialisierungs-Struktur für die EEPROM-Daten> im Flash, die du beim ersten Start in den leeren EEPROM schreibst.> Ansonsten wie oben schon geschrieben stets mit einer RAM-Kopie der> EEPROM-Daten hantieren.
Du wirst lachen das mache ich schon seit 5 Jahren, mit dem internen
EEPROM hatte ich mal angefangen und dabei nervte auch das das interne
EEPROM per default immer in der IDE gelöscht wird, also wenns nicht im
flash steht stehts beim nächsten flashen auch nicht mehr im EEPROM. eine
extra eep zu generieren wie im AVR Studio könnte möglich sein habe ich
aber seit dem nicht mehr gesucht!
Joachim B. schrieb:> nervte auch das das interne EEPROM per default immer in der IDE gelöscht> wird
Das hat mit "IDE" überhaupt nichts zu tun. Das ist ein Feature der
AVRs, und das hat schon seinen Sinn: wenn du ein Chip Erase machst
(anders lässt sich bei klassischen AVRs leider der Flash nicht neu
programmieren), dann sollst du dich danach auch drauf verlassen können,
dass alle Daten gelöscht sind. Ansonsten könnte jemand auf einem AVR,
der die Lockbits gesetzt hat, nach dem Chip Erase (der einzige Weg, die
Lockbits zu löschen) noch auf den EEPROM-Inhalt zugreifen.
Wenn dir diese Funktionalität im Wege ist und du gern den EEPROM über
die Neuprogrammierung (und damit das Chip Erase) hinweg erhalten
möchtest, dann gibt es genau dafür die EESAVE-Fuse, die du aktiv setzen
kannst. Damit teilst du mit, dass dir die Sicherheit des EEPROM-Inhaltes
unwichtig ist, und er auch nach dem Erase erhalten bleiben soll.
Hallo,
Joachim, ich kann deiner seltsamen Argumentationsweise nicht mehr
folgen. Du behauptest erst Dinge die dann plötzlich nicht mehr gelten.
Hätte ich bei FastLED nicht nachgeschaut würdest du immer noch behaupten
mit dem ATmega1284 wäre es 10% langsamer. Die "96MHz" war auch so ein
Ding was völlig aus dem Zusammenhang gerissen für den ATmega dargestellt
wurde. Ich weiß ehrlich gesagt nicht was das soll. Ich bin hier raus.
Joachim B. schrieb:> eine extra eep zu generieren wie im AVR Studio könnte möglich sein
Eine *.epp wird automatisch von der Arduino IDE, bei jedem Build
Vorgang, erzeugt.
Arduino Fanboy D. schrieb:> Eine *.epp wird automatisch von der Arduino IDE, bei jedem Build> Vorgang, erzeugt.
Eigentlich braucht man die seit vielen Jahren auch nicht mehr, das ist
wie die Flash-Hex-Datei nur ein Überbleibsel, "haben wir schon immer so
gemacht".
Alle Information ist im ELF-File ja drin, und man kann genauso gut
sagen:
Jörg W. schrieb:> Eigentlich braucht man die seit vielen Jahren auch nicht mehr, das ist> wie die Flash-Hex-Datei nur ein Überbleibsel, "haben wir schon immer so> gemacht".
Erstens:
Außerhalb meiner Verantwortung.
Zweitens:
Der übliche Arduino Bootloader kann das EEPROM nicht beschreiben
(soweit mir bekannt)
Drittens:
Es werden zwei *.hex Dateien erzeugt.
Eine ohne und eine mit integriertem Bootloader.
Arduino Fanboy D. schrieb:> Der übliche Arduino Bootloader kann das EEPROM nicht beschreiben (soweit> mir bekannt)
Das heißt, wenn die Arduino-IDE diese Datei bereitstellt, kann man sie
nur ohne Bootloader (mit echtem ISP) benutzen?
Hmm. Bisschen inkonsistent.
Jörg W. schrieb:> Hmm. Bisschen inkonsistent.
Mag sein....
Hier mal ein älterer Text von mir. Mag für den ein oder anderen
hilfreich sein, der sich mit Arduino und AVR EEPROMs rumschlagen muss:
--------
Wie bekommen wir die gewünschten *.eep Daten ins EEPROM?
So sehr uns die Arduino IDE dabei hilft, die *.eep Datei zu erzeugen,
sowenig ist sie dabei behilflich sie auf den µC zu schreiben.
Über den Bootloader geht es nicht.
Arduino trägt avrdude in sich. Damit, und einem ISP Programmer, geht
das.
Die Kommandozeile wie man Avrdude aufruft, sieht man, wenn man die
ausführlichen Meldungen in der IDE aktiviert und dann "Upload mit
Programmer" drückt.
Das ist eine gute Vorlage für das eigene EEPROM Schreib Kommando.
Einfach das flash schreiben, durch das eeprom schreiben ersetzen.
Aus meiner persönlichen Sicht, ist die die IDE Funktion "Upload mit
Programmer" sowieso problematisch, wenn nicht sogar defekt. Sie
überschreibt den Bootloader. Und das, ohne dessen Ressourcen frei zu
geben.
Die Fuses bleiben falsch stehen, der reservierte Flash Bereich kann
nicht von der Anwendung genutzt werden.
Bei anderen Boarddefinitionen sieht das manchmal anders aus. Aber die
Originalen Arduino Boarddefinitionen tragen das Problem in sich.
Mein Vorschlag ist:
Reparieren des Menupunktes "Upload mit Programmer"!
Hier gehe ich davon aus:
1. Dass man einen der üblichen AVR Arduinos, oder einen der vielen
kompatiblen verwendet.
2. Dass man den Bootloader behalten möchte.
3. Auch die *.eep Datei übertragen möchte
Die Anweisung, welche ausgeführt wird, wenn man auf "Upload mit
Programmer" drückt findet sich in der jeweiligen platform.txt.
Den Arduino Entwicklern sei Dank, werden die nötigen Dateien "Anwendung
mit Bootloader" und *.eep schon für uns erzeugt.
Sie finden sich im jeweiligen Build Ordner.
Es reicht eine platform.local.txt mit einer Zeile anzulegen, damit wir
das Ziel erreichen.
Code:
Der original Eintrag in der platform.txt kommt nicht mehr zur Geltung,
wenn ein gleich benannter Eintrag in der platform.local.txt existiert.
Wenn man die ausführlichen Meldungen beim kompilieren aktiviert, zeigt
die IDE, welche Hardwaredefinition sie verwendet, und dort muss diese
platform.local.txt angelegt werden.
Zur Klärung:
Hier wird nur die Funktion "Upload mit Programmer" geändert.
Der normale Upload ändert sich nicht.
Auch das "Bootloader brennen" bleibt unberührt erhalten.
Arduino Fanboy D. schrieb:> Aus meiner persönlichen Sicht, ist die die IDE Funktion "Upload mit> Programmer" sowieso problematisch, wenn nicht sogar defekt.
Wäre natürlich schön, wenn dein Vorschlag da irgendwie mal in die
offizielle Distribution einfließen könnte, statt dass man den Leuten
"offline-Kochrezepte" bereitstellen muss.
Veit D. schrieb:> Hätte ich bei FastLED nicht nachgeschaut würdest du immer noch behaupten> mit dem ATmega1284 wäre es 10% langsamer.
ich verstehe nicht wieso du eine Messergebnis mit der LIB von Januar
2015 anzweifelst?
Wenn du natürlich eine spätere Version der LIB nimmst wo das korrigiert
ist dann gilt natürlich der Vergleich nicht!
Das Oszi Bild vom 9.1.2015 ist doch eindeutig,
https://www.mikrocontroller.net/attachment/244099/m1284p_timing.jpg
eine LED angesteuert vom nano328 gelber Kurvenzug 30µs = 24 Bit x
1,25µs.
Derselbe Code, dieselbe LED vom m1284p 33µs.
Mit der Korrektur auf 90% F_CPU für den m1284p passte es dann!
Veit D. schrieb:> Die "96MHz" war auch so ein> Ding was völlig aus dem Zusammenhang gerissen für den ATmega dargestellt> wurde. Ich weiß ehrlich gesagt nicht was das soll.
dann hast du nicht gelesen das ich mich in der fastLED Lib orientierte
und mich bis dahin vorarbeitete.
Die <96 MHz waren in der LIB von vor Januar 2015 der Angriffspunkt um
die Anpassungen für den m1284p einzubauen!
hier wird immer wieder versucht mich lächerlich zu machen auch mit
deinen Worten!
Veit D. schrieb:> Du betreibst demnach seit 2015 extremes Overclocking. Interessant. :-)
liegt es an deimem Verständnis oder ist es nur bösartig?
Joachim B. schrieb:> hier wird immer wieder versucht mich lächerlich zu machen
Niemand macht dich lächerlich.
Allerdings schmeißt du so viele Dinge in einen Topf, dass kaum noch wer
durchblickt. Falls du an Problemlösungen interessiert bist, solltest du
etwas strukturierter deine Probleme darlegen, und voneinander getrennte
Themen auch getrennt behandeln, am besten in separaten Threads. Diesem
"ich habe hier gerade meinen Thread, und die Überschrift ist doch schön
allgemein gehalten" kann irgendwann keiner mehr folgen.
Joachim B. schrieb:> geschrieben, die hatten zwar an schneller Prozzis gedacht aber nicht an> das Timing vom 1284p.>> Warum der überhaupt ein drittes Adressbyte brauchte verstehe ich auch> nicht:
Falls du damit einen 3-Byte-PC meinst, sag ich mal: braucht er nicht,
und hat er auch nicht. Das ist mal wieder einer der klassischen
Atmel-Copy-Paste-Fehler im Datenblatt.
Da steht zwar tatsächlich:
"return from an interrupt handling routine takes four clock cycles.
During these four clock cycles, the Program
Counter (three bytes) is popped back from the Stack, the Stack Pointer
is incremented by two, and the I-bit in
SREG is set."
Da aber eben der Return (per Reti) nur 4 Zyklen brauchte, ebenso wie
auch Call und Ret, ist das mit den drei bytes (ziemlich sicher) falsch.
Die Befehle dauern bei den Prozessoren mit 3-Byte-PC fünf Zyklen.
Der PC im Mega1284 hat nur 2 Byte.
Oliver
Oliver S. schrieb:> Falls du damit einen 3-Byte-PC meinst, sag ich mal: braucht er nicht,> und hat er auch nicht. Das ist mal wieder einer der klassischen> Atmel-Copy-Paste-Fehler im Datenblatt.....................> Der PC im Mega1284 hat nur 2 Byte.
das mag ja sein war auch mein Gedanke und steht im Einklang mit meinem
Gedanken und dieser Meinung hier:
Jörg W. schrieb:> Aber: der ATmega2560 ist nicht binärkompatibel mit den anderen ATmegas> (<= 128 KiB Flash).
Trotzdem muss es eine Erklärung geben für den 10% langsameren Zugriff.
Für mich war es sie zu diesem Zeitpunkt halt. Eine andere Erklärung wäre
ja nur ein Fehler in der LIB, für denich keinen Beweis hatte!
Jörg W. schrieb:> solltest du> etwas strukturierter deine Probleme darlegen
aus diesem Grunde antworte ich nur noch je zu einem Thema, damit es hier
mal verständlicher und durchsichtiger wird.
Ich bin offensichtlich nicht alleine hier einiges zu vermischen und aus
Zusammenhänge zu reissen.
Hier wurde ja geschrieben:
Veit D. schrieb:> Hätte ich bei FastLED nicht nachgeschaut
ach, ohne die LIB Version und Datum zu nennen?
Was interessiert denn eine LIB Version die NACH meiner Feststellung ist?
Ist sowas hilfreich?
Also muss ich doch annehmen es geht nur darum!
Veit D. schrieb:> Du betreibst demnach seit 2015 extremes Overclocking. Interessant. :-)
andere "Bosheiten" wurden ja schon gelöscht!
Joachim B. schrieb:> Trotzdem muss es eine Erklärung geben für den 10% langsameren Zugriff.
Wenn mich sowas interessiert, würde ich es analysieren: generierten
Assemblercode vergleichen, ggf. mit dem Logikanalysator messen.
Alles andere ist Kaffeesatzlesen.
Hallo Joachim,
meine letzte Antwort. Ich zweifel deine Messung von 2015 nicht an. Aber
das du genau das 2020 immer noch rausholst obwohl das längt behoben ist,
dass sollte doch schon wundern. Und genau durch solche wilden Aktionen
deinerseits bringst du alles durcheinander. Du machst völlig unnütze
Nebenkriegsschauplätze auf. Du bringst nämlich durch solche 5 Jahre
alten Behauptungen auch die Entwickler der FastLED Lib in falsche
Verrufung, obwohl die das längst behoben haben. Sowas finde ich nicht
lustig.
> Trotzdem muss es eine Erklärung geben für den 10% langsameren Zugriff.> Für mich war es sie zu diesem Zeitpunkt halt. Eine andere Erklärung wäre> ja nur ein Fehler in der LIB, für den ich keinen Beweis hatte!
Absolut unlustig ist es, wenn du den gleichen Sch... jetzt bewusst
weiter treibst. Die Antwort steht auf Github.
>> Hätte ich bei FastLED nicht nachgeschaut> ach, ohne die LIB Version und Datum zu nennen?> Was interessiert denn eine LIB Version die NACH meiner Feststellung ist?> Ist sowas hilfreich?
Aha. Du verlinkst wild verteilt alles was jeder lesen soll, kannst dir
aber nicht die aktuelle FastLED Lib runterladen und in deren Doku lesen
wenn man dich schon darauf hinweist. Außerdem bist du selbst in deren
Threads beteiligt, demnach solltest du schon 2015 die Antwort bekommen
haben. Ich finde das nicht lustig.
Genauso der Bezug auf 96MHz und ATmega. Mein Overclocking Kommentar
sollte dich auf lustige Art und Weise auf einen Tippfehler hinweisen.
Ich bin ja immer noch der Meinung das du den Hinweis nicht verstanden
hast und du nicht auf 96MHz sondern auf 9,6MHz abfragen möchtest. Aber
dann bist mit dem Hinweis auf deinen ESP um die Ecke gekommen obwohl der
kein 10% Problem hat. Wieder so ein überflüssiger Nebenkriegsschauplatz.
und Tschüss.
Joachim B. schrieb:> Ich bin offensichtlich nicht alleine hier einiges zu> vermischen und aus Zusammenhänge zu reissen.
Das liegt daran, dass du dich weder klar ausdrückst noch eindeutig
beschreibst, was dein Anliegen ist. Stattdessen ziehst du viele Jahre
alte Anekdoten aus dem Hut, auf denen du dein jetziges Handeln
begründest.
Dabei könnte es für dich viel einfacher sein, wenn du dein Handeln auf
eine Basis von (a) einem halbwegs aktuellen Wissensstand und (b) mit
wesentlich weniger Halbwissen bringen könntest. Dazu gehört vor allem
auch Zuhören.
Niemand bezweifelt, dass du 2015 so eine Messung gemacht hast.
Die Schlussfolgerung, dass deswegen die Entwickler heute noch Idioten
sind und dein Workaround das einzig Wahre ist (obwohl er unglaublich
hässlich und falsch ist, auch wenn er für deinen Anwendungsfall
funktioniert), ist dagegen einfach nur falsch. Vor allem dann, wenn die
Begründung hauptsächlich darauf basiert, dass du etwas richtig gemessen
und falsch verstanden zu scheinen hast.
Das EEPROM-Problem ist genau das gleiche: Du hast eine Lösung für ein
Problem gefunden, welches du durch eigenes Unwissen erst geschaffen
hast. Soweit kein Problem, das macht jeder. Aber du verteidigst deine
Lösung um jeden Preis, weil alle anderen Idioten sind und du nicht.
Achso: Und natürlich ist jeder, der dich darauf hinweist, dass deine
Lösung nicht gerade der absolute Stein der Weisen ist jemand, der dir
nur Böses will, dich in aller Augen lächerlich machen und für dumm
erklären. Weil alles Arschlöcher in diesem Universum und so. Dem ist
nicht so.
Und dann ziehst du für jedes Argument wieder eine neue Anekdote aus dem
Hut. Das macht die Diskussion für Unbeteiligte zwar amüsant, aber eben
auch allgemein nutzlos.
ich bin gerade dabei den nützlichen Hinweisen zu folgen, nicht so
leicht!
Veit D. schrieb:> Joachim, ich kann deiner seltsamen Argumentationsweise nicht mehr> folgen.
wolltest du das denn?
Veit D. schrieb:> Die "96MHz" war auch so ein> Ding was völlig aus dem Zusammenhang gerissen für den ATmega dargestellt> wurde.Veit D. schrieb:> Genauso der Bezug auf 96MHz und ATmega. Mein Overclocking Kommentar> sollte dich auf lustige Art und Weise auf einen Tippfehler hinweisen.Jörg W. schrieb:> Arduino Fanboy D. schrieb:>> #if F_CPU < 96'000'000>> Dein Mega läuft mit 96 MHz.>> Nö, er hat doch nur eine Fallunterscheidung für solche Atmegas, die> weniger als 96 MHz schnell sind. :-)
nein das war kein Tippfehler, Jörg W. hats verstanden, sondern logisch
da es keinen AVR ATmega gibt der >=96MHz, also musste der Eingriff der
patch genau dort erfolgen!
Wie kommst du also auf Tippfehler?
Wenn dann nicht meiner denn die <96MHz stehen im Orginalcode!
Veit D. schrieb:> Die Antwort steht auf Github.
wo, wer schreibt denn geheimnisvoll?
Wenn du weisst das es ein Tippfehler im Originalcode ist dann nenne das
so, wenn du denkst es ist mein Tippfehler dann irrst du!
Also ich gehe, jetzt weiter der Sache auf den Grund!
Arduino Fanboy D. schrieb:> Du meist sicherlich sowas:Arduino Fanboy D. schrieb:> Dass dein gezeigter Code unsinnig ist.
ich denke ich sehe meinen geschossenen Bock?
Arduino Fanboy D. schrieb:> Ist denn mittlerweile der Groschen gefallen, welchen Bock du in deiner> Funktion geschossen hast?
möglicherweise.....
Arduino Fanboy D. schrieb:> Auch scheinst du 100kHz und 400kHz Devices auf dem Bus zu mischen.> Aus meiner Sicht ein gruseliges Unterfangen.
na gut, ich gestehe ich habe nicht alle Datenblätter aller meine I2C
Chips, besonders bei OLEDs, ich bin ja auch eher Praktiker, bis jetzt
haben alle meine I2C Komponenten bei 400kHz gut funktioniert AUSSER die
I2C Eeproms und genau deswegen takte ich beim Zugriff auf das I2C EEPROM
runter, du meinst es ist gruselig, ich hatte bis jetzt über 5 Jahre
deswegen nicht einen Mißerfolg, so what, aber ich kann es bei
auftretenen Problemen ja im Hinterkopf behalten. (ich suche nur ohne Not
keine Probleme wo keine sind ausser es geht um Menschenleben und
Spannung)
Arduino Fanboy D. schrieb:> Du meist sicherlich sowas: // prüft, ob Baustein unter der Adresse> beschäftigt ist> bool busy(byte i2cAdr) // ACKNOWLEDGE POLLING> {> Wire.beginTransmission(i2cAdr);> return Wire.endTransmission();> }
das teste ich nun! (auch bei allen Differenzen, vielen Dank!)
wobei ich mich nun wundere,
bool busy(byte i2cAdr) kennt nur TRUE oder FALSE
aber
return Wire.endTransmission();
ist lt. Arduino
https://www.arduino.cc/en/Reference/WireEndTransmission
Returns
byte, which indicates the status of the transmission:
0:success
1:data too long to fit in transmit buffer
2:received NACK on transmit of address
3:received NACK on transmit of data
4:other error
also kein bool!
und du hälst mich für dusslig?
Joachim B. schrieb:> ich suche nur ohne Not> keine Probleme wo keine sind
Falls dir in der I2C Spezifikation die Stelle bekannt ist, wo
geschrieben steht, dass man einen Bus mit 400kHz betreiben kann, wenn
auch 100kHz only Bausteine mit drauf sind, dann zeige sie mir bitte.
Joachim B. schrieb:> also kein bool!> und du hälst mich für dusslig?
Natürlich!
Da dir der implizite Cast fremd ist, musst du dusselig sein.
Oder, gibts noch mehr Möglichkeiten?
Arduino Fanboy D. schrieb:> Falls dir in der I2C Spezifikation die Stelle bekannt ist, wo> geschrieben steht, dass man einen Bus mit 400kHz betreiben kann, wenn> auch 100kHz only Bausteine mit drauf sind, dann zeige sie mir bitte.
erst wenn du mir sagst warum du
Joachim B. schrieb:> bool busy(byte i2cAdr)
deklarierst mit return von byte
wobei NULL nur bei success kommt, also kann man ja mal machen wenn einen
die Fehler nicht interessieren.
Das ist doch logisch. Wenn ich einen langsamen Busteilnehmer mit zu
schnellen Signalen überfordere, dann kann da alles mögliche passieren.
Falls er sich angesprochen fühlt, wird er die Kommunikation der anderen
stören.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Die Anmerkung unter Tabelle 8 sagt ganz klar aus, dass die Taktrate des
Bus durch den langsamsten Teilnehmer beschränkt wird.
Stefan ⛄ F. schrieb:> Das ist doch logisch.
Politikererklärungen sind auch oft logisch, sonst würden ihnen die
Menschen ja nicht hinterher rennen!
Wenn ich seit über 5 Jahre mit dem EEPROM keine Probleme habe im Zugriff
auf 400kHz Devices, kann ich den Zugriff auf andere generell langsamer
gestalten, muss es aber nicht!
Ausserdem ist das gerade nicht die Baustelle um die es geht, man kann
sich auch ablenken lassen oder das Ziel im Auge behalten, momentan einen
(möglichen) Fehler nach dem anderen zu eleminieren.
Wie arbeitet ihr?
Aus meiner Industriezeit weiss ich das es schief geht an allen Stellen
gleichzeitig zu schrauben!
Stefan ⛄ F. schrieb:> Die Anmerkung unter Tabelle 8 sagt ganz klar aus, dass die Taktrate des> Bus durch den langsamsten Teilnehmer beschränkt wird.
Zu viele Fakten!
Ignorieren ist doch viel schöner....
Joachim B. schrieb:> erst wenn du mir sagst warum du>> Joachim B. schrieb:>> bool busy(byte i2cAdr)>> deklarierst mit return von byte> wobei NULL nur bei success kommt,
Richtig!
busy() liefert true, wenn kein ansprechbarer Baustein unter der Adressen
auf dem Bus zu finden ist.
busy() liefert false , wenn der Baustein an der Adresse bereit ist.
Was gibts dagegen einzuwenden?
Es ist faktisch egal welche der folgenden Varianten du verwendest:
1
boolbusy(bytei2cAdr)// ACKNOWLEDGE POLLING
2
{
3
Wire.beginTransmission(i2cAdr);
4
returnWire.endTransmission();
5
}
6
7
boolbusy(bytei2cAdr)// ACKNOWLEDGE POLLING
8
{
9
Wire.beginTransmission(i2cAdr);
10
return(bool)Wire.endTransmission();
11
}
12
13
boolbusy(bytei2cAdr)// ACKNOWLEDGE POLLING
14
{
15
Wire.beginTransmission(i2cAdr);
16
returnbool(Wire.endTransmission());
17
}
18
19
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
20
{
21
Wire.beginTransmission(i2cAdr);
22
return0==Wire.endTransmission();
23
}
24
25
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
26
{
27
Wire.beginTransmission(i2cAdr);
28
return0==Wire.endTransmission();
29
}
30
31
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
32
{
33
Wire.beginTransmission(i2cAdr);
34
returnnotWire.endTransmission();
35
}
36
37
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
38
{
39
Wire.beginTransmission(i2cAdr);
40
return!Wire.endTransmission();
41
}
42
43
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
44
{
45
Wire.beginTransmission(i2cAdr);
46
return!bool(Wire.endTransmission());
47
}
48
49
boolready(bytei2cAdr)// ACKNOWLEDGE POLLING
50
{
51
Wire.beginTransmission(i2cAdr);
52
return!(bool)Wire.endTransmission();
53
}
Es ist doch völlig scheißegal, ob der Cast implizit oder explizit
erfolgt.
Ich habe echt keine Ahnung, was du da für einen Wurm im Kopp hast.
Ich stehe da wie ein Ochs vorm Berg.
Arduino Fanboy D. schrieb:> busy() liefert false , wenn der Baustein an der Adresse bereit ist.>> Was gibts dagegen einzuwenden?
nichts unter Einschränkungen wenn
Joachim B. schrieb:> kann man ja mal machen wenn einen> die Fehler nicht interessieren.
ich wunderte mich halt nur!
so und nun deinen Vorschlag weiter verfolgen, der gefällt mir wenns
funktioniert!
https://www.youtube.com/watch?v=ay6GjmiJTPM
Joachim B. schrieb:> Wie arbeitet ihr?
Auf jeden Fall nicht so dass man absichtlich und sehenden Auges die Spec
verletzt und nicht geeignet Busteilnehmer viel zu schnell taktet.
Joachim B. schrieb:> }while(Wire.endTransmission());
Hier (in deiner kaputten Funktion) machst du den gleichen impliziten
Cast.
Wobei dein Cast gut ist, und mein Cast böse.
Was ja auch logisch ist, da du gut bist und ich böse.
Das färbt natürlich auf den Cast ab.
Arduino Fanboy D. schrieb:> Joachim B. schrieb:>> }while(Wire.endTransmission());> Hier (in deiner kaputten Funktion) machst du den gleichen impliziten> Cast.>> Wobei dein Cast gut ist, und mein Cast böse.> Was ja auch logisch ist, da du gut bist und ich böse.> Das färbt natürlich auf den Cast ab.
Joachim hat bezüglich Programmierung recht wenig Ahnung aber eine sehr
sehr starke Meinung. Die Kombination ist schlecht!
Arduino Fanboy D. schrieb:> Wobei dein Cast gut ist, und mein Cast böse.
nö
Arduino Fanboy D. schrieb:> Es ist doch völlig scheißegal, ob der Cast implizit oder explizit> erfolgt.
es geht nicht um den cast!
aber OK ich habe ihn weggelassen (erwähnte ich schon das ich kein
Informatiker aka SW Architekt bin?) und sollte ihn nachrüsten!
Immer wieder wird hier betont, sauber zu programmieren und dann das.
Dir ist es egal ein byte nur auf false zurückzugeben, bei mir ist es
sträflich?
Joachim B. schrieb:> Dir ist es egal ein byte nur auf false zurückzugeben, bei mir ist es> sträflich?
Du gibst kein Byte zurück.
Wenn der Rückkehrwert als Boolean deklariert ist, kann er nur die Werte
0 oder 1 annehmen. Darum, dass er das macht, kümmert sich im Zweifel der
Compiler (das ist das, was ufuf als "impliziten Cast" bezeichnet).
> erwähnte ich schon das ich kein Informatiker aka SW Architekt bin?
Zählt als Ausrede allerdings nicht. Ich bin auch studierter
Elektroniker. Wenn ich programmieren will, muss ich mich trotzdem damit
beschäftigen, wie die entsprechenden Werkzeuge funktionieren, statt
damit drauf los zu hantieren.
Joachim B. schrieb:> Immer wieder wird hier betont, sauber zu programmieren und dann das.
Das ist sauber!
Der implizite Cast wird von der C++ Spezifikation
abgedeckt/eingefordert.
Der Compiler macht das ordentlich.
Joachim B. schrieb:> Dir ist es egal ein byte nur auf false zurückzugeben, bei mir ist es> sträflich?
Der Cast ist mir egal.
Dir war es wichtig, ihn mir anzukreiden, obwohl du es doch genau so
machst.
Oder?
> Wobei dein Cast gut ist, und mein Cast böse.
Merke:
Deine Funktion ist falsch/kaputt.
(und damit meine ich nicht den Cast)
Arduino Fanboy D. schrieb:> Deine Funktion ist falsch/kaputt.
wenn du auf mein wait ready anspielst,
falsch OK kann man so sehen, ich habe deine nun eingebaut klappt auch!
(also zum x-ten Mal Danke, es soll nicht immer als pöbeln rüberkommen)
Meine wird nun verworfen, deine ist eingebaut und DAS ist abgehakt, ich
hatte da wohl einen Gedankenfehler, ich dachte doch glatt erst wenn ich
wieder ein Byte lesen kann ist das EEPROM bereit, offensichtlich gehts
auch so, jedenfalls mit diesem EEPROM.
Ich nutze ja etliche auf RTC Module und kann jetzt nicht alle Module
durchtesten!
Dabei war der RTC Chip und alle anderen immer 400kHz fähig, es klemmte
nur bei einem oder mehreren I2C EEPROM wobei ich auch nicht jedes EEPROM
auf Datenblatt prüfte!
zu:
Stefan ⛄ F. schrieb:> Das ist doch logisch.
auch dem Stefan DANKE, er führte mich auf den rechten Weg, weil mehrfach
Wire.begin() im Arduino bei AVR mit ATmega NIE störte, aber beim ESP32
zu Abstürzen führte, auch das konnte ich ausräumen, bei allen
Animositäten die wir gelegentlich haben.
Womit aber auch bewiesen ist was bei einem µC keine Probleme bereitet,
man darf sich beim Wechsel eben nicht auf seinen Code verlassen auch
wenn das bis dahin IMMER geklappt hat!
S. R. schrieb:> Das EEPROM-Problem ist genau das gleiche: Du hast eine Lösung für ein> Problem gefunden, welches du durch eigenes Unwissen erst geschaffen> hast. Soweit kein Problem, das macht jeder. Aber du verteidigst deine> Lösung um jeden Preis, weil alle anderen Idioten sind und du nicht.
was soll man denn sonst machen wenn es noch nicht angekommen ist, man
darf seine Fehler um jeden Preis verteidigen, Beispiele sieht man
überall genug, selbst wenn die Fehler nachweislich bewiesen sind haben
viele nicht die cojones ihren Fehler zuzugeben, ICH schon seit ich weiss
das ich falsch liege!
zum I2C clock, klar kann ich alles auf 100kHz lassen, tut in meinen
Anwendungen auch nicht weh, nur hielt ich es mal für ne gute Idee es nur
beim klemmenden EEPROM Zugriff zu reduzieren bis jetzt auch ohne
Probleme.
Darüber kann man streiten, muss man aber nicht!
so nun weiter im Code und peace!
Joachim B. schrieb:> ich> hatte da wohl einen Gedankenfehler, ich dachte doch glatt erst wenn ich> wieder ein Byte lesen kann ist das EEPROM bereit,
Das IST nicht der Fehler in der Funktion!
Sondern das request(),
Eingemauert/Umrahmt in/von beginTransmission() und endTransmission()
Das ist unsinnig.
Das ist IMMER unsinnig.
Und nochmal zum mitmeißeln:
Arduino macht den I2C Read mit Wire.request()
Arduino verwendet für den Write beginTransmission() und
endTransmission()
Das kann/darf man nicht schachteln.
NIEMALS unter keinen Umständen.
NEVERJoachim B. schrieb:> falsch OK kann man so sehen,
Nein, das kann man nicht so sehen, sondern das MUSS man so sehen.
Aber da du das nicht so sehen möchtest, hast du immer noch nicht I2C
verstanden, und auch nicht, wie Wire damit umgeht.
---------
Ebenso mit deiner Taktumschaltung...
Merke:
Wenn man seien Liebsten 5 Jahre lang verprügelt, dann ist das nicht ok.
Selbst wenn diese sich nicht wehren.
Auch wenn es nicht zur Anzeige kommt.
Es ist falsch, es bleibt falsch.
-----------
Joachim B. schrieb:> haben> viele nicht die cojones ihren Fehler zuzugeben, ICH schon seit ich weiss> das ich falsch liege!
Offensichtlich bist du kaum erreichbar.
Offensichtlich nimmst du Kritik an deinem Code persönlich.
Offensichtlich hast du unglaubliche Schwierigkeiten deine Fehler
einzusehen und zuzugeben.
Arduino Fanboy D. schrieb:> Ebenso mit deiner Taktumschaltung...
du kennst offensichtlich nicht die Geschichte:
F:"Warum sind sie mit nacktem Hintern in das Kaktusfeld gehüpft?"
A:"Ich hielt das in dem Moment für eine gute Idee"
Ein Glück das es hier auch absolut Perfekte gibt.
Arduino Fanboy D. schrieb:> Arduino verwendet für den Write beginTransmission() und> endTransmission()> Das kann/darf man nicht schachteln.
Das habe ich auch verstanden, ich muss nur in meinen C-Code gucken vor
Arduino.
Das sich Fehler einschleichen, ist mir passiert und auch das ich den
nicht bemerkte WEIL es eben funktionierte.
Der wäre vermutlich ohne mehr Augenprinzip nie aufgefallen, ich weiss ja
das es falsch ist nur hatte das nie Auswirkungen im Ergebnis, allenfalls
verschenkte CPU Takte!
Aber das ist eher die Baustelle vom c-hater
Ein Glück das es hier auch absolut Perfekte gibt.
Arduino Fanboy D. schrieb:> Offensichtlich nimmst du Kritik an deinem Code persönlich.
logisch wer nicht?
Joachim B. schrieb:>> Offensichtlich nimmst du Kritik an deinem Code persönlich.>> logisch wer nicht?
Leute, die professionell programmieren, also ihre Brötchen damit
verdienen.
Code Reviews gehören da ganz normal dazu, und dass sich jemand mal mit
irgendwas geirrt hat, ist menschlich. Wenn ein Reviewer das kritisiert,
kann und darf ich das nicht persönlich nehmen.
Jörg W. schrieb:> Wenn ein Reviewer das kritisiert,> kann und darf ich das nicht persönlich nehmen.
da hast du Recht, aber du weisst ja als Moderator selber was hier für
Kommentare aufschlagen.
Mal flappsig und nicht böse gemeint, mal echt nur um andere
herabzuwürdigen.
Es ist nicht immer leicht das Eine vom Anderen zu unterscheiden.
Ich habe natürlich zielführende Kommentare (vom Arduino Fanboy D. und
Stefan F.) umgesetzt und bin dankbar dafür, mit Häme kann ich schlecht
umgehen, ich weiss sollte man drüber stehen, mal gelingt es mir mal
nicht (mal ist man selber nicht ganz frei davon), ist auch menschlich!
Joachim B. schrieb:> Ich habe natürlich zielführende Kommentare (vom Arduino Fanboy D. und> Stefan F.) umgesetzt und bin dankbar dafür
Korrekt - hat ja auch nur ca. 160 Posts lang gedauert :-) - aber besser
spät als nie.
Hugo H. schrieb:> Korrekt - hat ja auch nur ca. 160 Posts lang gedauert :-) - aber besser> spät als nie.
Ich sehe den Zusammenhang den du unterstellst nicht, ich hüpfe auch
nicht auf Kommando, du etwa?
Es muss halt auch zeitlich passen ohne zu weit vom Weg abzukommen.
Also wieder nur ein unsinniger, wenn nicht sogar bösartiger Kommentar.
Joachim B. schrieb:> Ich sehe den Zusammenhang den du unterstellst nicht
Verstehe ich vollkommen.
Joachim B. schrieb:> Also wieder nur ein unsinniger, wenn nicht sogar bösartiger Kommentar.
Was unsinnig angeht solltest Du Deine Posts mal durchlesen - bösartig
kann ich ganz anders :-) - wenn ich will.
Hugo H. schrieb:> Was unsinnig angeht solltest Du Deine Posts mal durchlesen - bösartig> kann ich ganz anders :-) - wenn ich will.
ja sehe ich :)
Beitrag "Re: Zündkerze - ADAC dein Gelber Nichthelfer"
Alles hat 2 Seiten!
Wir wissen nur was geschrieben wird, auch du, meinst aber dir ein Urteil
bilden zu können!
Joachim B. schrieb:> ja sehe ich :)> Beitrag "Re: Zündkerze - ADAC dein Gelber Nichthelfer"
Bist Du ADAC-Mitglied?
Das Abschleppen bis zur nächsten Werkstatt (bis 300 € - das sollte bei 1
km nicht überschritten werden) ist kostenlos. Der Poster erzählt
schlicht Unsinn - wie so manch anderer.
Joachim B. schrieb:> Wir wissen nur was geschrieben wird, auch du, meinst aber dir ein Urteil> bilden zu können!
Ich kann mir immer ein Urteil bilden - basierend auf den Fakten und
Impressionen, die mir bekannt sind. Wenn ich das nicht könnte wäre ich
wohl nicht / schlecht Lebensfähig.
Hugo H. schrieb:> Bist Du ADAC-Mitglied?
war ich über 30 Jahre, aber der Kundendienst ist für mich jedenfalls
unerträglich schlecht geworden so das ich nun kein Mitglied mehr bin.
Ich will mal so sagen, wie immer im Leben kann das mein persönliches
Pech gewesen sein wie auch bei Anderen.
Keiner ausser dem TO und dem ADAC Techniker war dabei, es kann durchaus
mehr Sichtweisen geben, vom TO oder vom ADAC Techniker.
Ich hatte als RFS Techniker auch einiges erlebt, der "Kunde" hat nicht
immer den vollen Durchblick und sieht nur was er sehen will.Ich bekam
auch als RFS Techniker ungerechtfertigt Reklamationen, ich wurde von
hinten von einem betrunkenen Kunden angefallen und gewürgt weil ich den
Plastikbrei ehemals Tastatur im TV nicht reparieren konnte weil der
Kunde reingetreten hatte.
Auch als Mensch ist man nicht immer gut drauf, das muss man jedem
zugestehen, also aus einseitigen Erzählungen zu urteilen muss schwer
fallen auch wenn ich dem Forenmitglied gerne glauben möchte, ich war
nicht dabei.
Du urteilst also aus 160 Post über die Dauer der Umsetzung, die du nicht
mal kennst?
Joachim B. schrieb:> Du urteilst also aus 160 Post über die Dauer der Umsetzung, die du nicht> mal kennst?
Nein - ich urteile aus > 160 Posts über die Resistenz zur Einsicht :-)
Hugo H. schrieb:> Korrekt - hat ja auch nur ca. 160 Posts lang gedauert :-)Hugo H. schrieb:> Nein - ich urteile aus > 160 Posts über die Resistenz zur Einsicht :-)
du schriebst aber was anderes!
Für dich Posts != Umsetzungsdauer und über ungelegte Eier lohnt es nicht
zu diskutieren!
Nach über 100 Postings hier aufzuschlagen mit deinen Worten sonst nichts
zum Thema bleibe ich bei bösartig!
Hugo H. schrieb:> bösartig> kann ich ganz anders :-) - wenn ich will.
auch das glaube ich dir!
Joachim B. schrieb:> du schriebst aber was anderes!
Wo?
Joachim B. schrieb:> Nach über 100 Postings hier aufzuschlagen mit deinen Worten sonst nichts> zum Thema bleibe ich bei bösartig!
Nein - nur ein wenig belustigt wegen Deiner Ignoranz.
Joachim B. schrieb:> auch das glaube ich dir!
Na, wenigstens etwas :-)
Hugo H. schrieb:> nur ein wenig belustigt
freut mich, Lachen soll ja Medizin sein!
hier gehen ja einige zum Lachen in den Keller, ich bin auch für mehr
Humor!
Joachim B. schrieb:> du kennst offensichtlich nicht die Geschichte:> F:"Warum sind sie mit nacktem Hintern in das Kaktusfeld gehüpft?"> A:"Ich hielt das in dem Moment für eine gute Idee">> Ein Glück das es hier auch absolut Perfekte gibt.
Der Unterschied ist, dass wir gelernt haben, dass man nicht mit nacktem
Hintern in das Kaktusfeld hüpft. Und daraus extrapolieren, dass man das
mit Lederhosen auch nicht machen sollte. Selbst, wenn es
eins...zwei...vierzig Mal geklappt hat.
Thread beobachten
Seitenaufteilung abschalten