'MY_EEP_VAR' does not name a type
warum klappt das nicht?
_VERSION_ = 5.2.0
_GNUC_MINOR_ = 2
_GNUC_PATCHLEVEL_ = 0
in *.h
struct eep_var{
uint8_t backlicht; // eep_var
uint8_t contra; // eep_var
uint8_t bias; // eep_var
char mesz_str[5]; // "MESZ" || " MEZ"
};
extern struct eep_var MY_EEP_VAR;
in der *.c ausserhalb einer Funktion als Init
char jar_str[] = "Rollo"; // klappt
struct eep_var MY_EEP_VAR;
MY_EEP_VAR.bias=SET_BIAS; // klappt nicht!
Joachim B. schrieb: > MY_EEP_VAR.bias=SET_BIAS; // klappt nicht! Zuweisungen funktionieren nur innerhalb von Funktionen.
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.
Dein Compiler sagt "Klappt nicht"?! Das kann ich kaum glauben. Fehlermeldung?
wer schrieb: > Das kann ich kaum glauben. Fehlermeldung? Erste Zeile seines Beitrags. Leicht zu übersehen. ;-)
Versuche mal Definition und Initialisierung zusammen (sitze am Tablet und kann das gerade nicht testen):
1 | struct eep_var MY_EEP_VAR = {42,42,42,“Hello“}; |
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?
:
Bearbeitet durch User
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: > In Variablen benutzt man nicht durchgehend Grossbuchstaben. Wo er das doch seit 1988 tut...
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
im h-File:
1 | struct eep_var{ |
2 | uint8_t backlicht; // eep_var |
3 | uint8_t contra; // eep_var |
4 | uint8_t bias; // eep_var |
5 | char mesz_str[5]; // "MESZ" || " MEZ" |
6 | };
|
7 | |
8 | extern struct eep_var MY_EEP_VAR; |
im c-File:
1 | struct eep_var MY_EEP_VAR={ .backlicht=42, |
2 | .contra=42, |
3 | .bias=42, |
4 | .mesz_str="42" }; |
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:
1 | |
2 | void init_struct_eep( struct eep_var* my_eep_var, |
3 | const uint8_t arg_backlicht, |
4 | const uint8_t arg_contra, |
5 | const uint8_t arg_bias, |
6 | const char* arg_str) |
7 | {
|
8 | my_eep_var->backlicht=arg_backlicht; |
9 | my_eep_var->contra=arg_contra; |
10 | my_eep_var->bias=arg_bias; |
11 | |
12 | //magic numbers, besser #define verwenden
|
13 | strncpy(my_eep_var->mesz_str, arg_str, 5); |
14 | |
15 | //falls mesz_str ein string-Array sein soll
|
16 | my_eep_var->mesz_str[4]='\0'; |
17 | |
18 | }
|
und dann der Aufruf:
1 | struct eep_var MY_EEP_VAR; |
2 | |
3 | init_struct_eep(&MY_EEP_VAR, 1,2,3, "viel_zu_langer_text"); |
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
Beitrag #6339019 wurde von einem Moderator gelöscht.
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 | void voidMyI2C_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
:
Bearbeitet durch User
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
|
2 | bool busy(byte i2cAdr) // ACKNOWLEDGE POLLING |
3 | {
|
4 | Wire.beginTransmission(i2cAdr); |
5 | return Wire.endTransmission(); |
6 | }
|
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?
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
Angehängte Dateien:
-
web_esp32_nano328p.jpg
110 KB
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!
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
Arduino Fanboy D. schrieb: > Bis jetzt sehe ich da nur borniertes Beharren! >Ich versuche das Feuer sowieso auf mich zu ziehen. gelingt dir gut!
Ja! Ist denn mittlerweile der Groschen gefallen, welchen Bock du in deiner Funktion geschossen hast?
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.
Hallo, was von mir in der Hoffnung das es hilft, seltsame Wartezeiten habe ich damit nicht.
1 | bool readOneRegister (const uint8_t i2cAdr, const uint8_t reg, uint8_t &var) |
2 | {
|
3 | Wire.beginTransmission(i2cAdr); // Connect |
4 | Wire.write(reg); // Anfrage ab/der Register Nummer |
5 | if (Wire.endTransmission() > 0) { // war Connect fehlerfrei? |
6 | return false; // I2C Busfehler ? |
7 | }
|
8 | Wire.requestFrom(i2cAdr, 1); // 1 Byte anfordern/lesen |
9 | if (Wire.available() > 0) { // sind Daten vorhanden? |
10 | var = Wire.read(); |
11 | }
|
12 | return true; |
13 | }
|
14 | |
15 | bool writeOneRegister (const uint8_t i2cAdr, const uint8_t reg, uint8_t data) |
16 | {
|
17 | Wire.beginTransmission(i2cAdr); |
18 | Wire.write(reg); // setzen auf Registeradresse ab der es losgehen soll |
19 | Wire.write(data); // Daten in Register schreiben |
20 | if (Wire.endTransmission() > 0) { // |
21 | return false; // I2C Busfehler ? |
22 | }
|
23 | return true; |
24 | }
|
25 | |
26 | bool readTwoRegister (const uint8_t i2cAdr, const uint8_t firstReg, uint8_t &var1, uint8_t &var2) |
27 | {
|
28 | Wire.beginTransmission(i2cAdr); // Connect |
29 | Wire.write(firstReg); // Anfrage ab/der Register Nummer |
30 | if (Wire.endTransmission() > 0) { // war Connect fehlerfrei? |
31 | return false; // I2C Busfehler ? |
32 | }
|
33 | Wire.requestFrom(i2cAdr, 2); // 2 Bytes in Folge anfordern/lesen |
34 | if (Wire.available() > 0) { // sind Daten vorhanden? |
35 | var1 = Wire.read(); |
36 | var2 = Wire.read(); |
37 | }
|
38 | return true; |
39 | }
|
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.
:
Bearbeitet durch User
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: > Ist in Wire eingebaut. > (muss man nur nutzen) war das wirklich immer so? mal abgesehen von fake news! https://forum.arduino.cc/index.php?topic=343242.30 https://arduino.stackexchange.com/questions/30353/i2c-connection-freezes-master-if-slave-disconnects https://rheingoldheavy.com/changing-the-i2c-library/ https://arduino.stackexchange.com/questions/30353/i2c-connection-freezes-master-if-slave-disconnects interessant zu lesen!
:
Bearbeitet durch User
Joachim B. schrieb: > war das wirklich immer so? Immerhin schon seit über einem Monat. Bisher übersehen? https://github.com/arduino/ArduinoCore-avr/commit/deea9293201dbab724b6b0519c35ddba3e6b92d9#diff-e208cb203d0f81f0c0ef491adcedfcc8
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
Arduino Fanboy D. schrieb: > Nein! OK aber man bindet Wire.h ein und Arduino schreibt auf der Webseite wer schaut: https://www.arduino.cc/en/Reference/Wire wo ist da die Fuktion Timeout? oder ein Beispiel wie man die nutzt? 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! https://www.arduino.cc/en/Reference/WireBegin tolle Wurst! Ja man darf auch als Arduino Fan (ich!!!) mal "meckern"! https://github.com/esp8266/Arduino/issues/2607 https://www.pjrc.com/teensy/td_libs_Wire.html http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/latest/libs/wire.html Wire.begin() Wire.begin(sda, scl) // ah hier z.B. am ESP kann man sogar 2 I2C nutzen https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/esp32-beide-i-c-schnittstellen-verwenden
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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 AVR https://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.
könntet ihr euch nicht einfach mal auf ein Bier zusammensetzen und das lösen?
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.
Angehängte Dateien:
-
m1284p_m328p.jpg
130 KB
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
1 | mighty_opt.name=Mighty 1284p 16MHz using Optiboot |
2 | mighty_opt.upload.protocol=arduino |
3 | mighty_opt.upload.maximum_size=130048 |
4 | mighty_opt.upload.speed=115200 |
5 | mighty_opt.bootloader.low_fuses=0xff |
6 | mighty_opt.bootloader.high_fuses=0xde |
7 | mighty_opt.bootloader.extended_fuses=0xfd |
8 | mighty_opt.bootloader.path=optiboot |
9 | mighty_opt.bootloader.file=optiboot_atmega1284p.hex |
10 | mighty_opt.bootloader.unlock_bits=0x3F |
11 | mighty_opt.bootloader.lock_bits=0x0F |
12 | mighty_opt.build.mcu=atmega1284p |
13 | mighty_opt.build.f_cpu=16000000L |
14 | #mighty_opt.build.core=arduino:arduino
|
15 | mighty_opt.build.core=standard |
16 | mighty_opt.build.variant=standard |
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?
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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?
Arduino Fanboy D. schrieb: > Somit beweisbar. ist doch: 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? alle m1284p Arduino Clones funktionieren mit der Arduino Wire.h https://hackaday.com/2011/08/17/bobuino-arduino-based-on-atmega1284-goodies/ https://forum.arduino.cc/index.php?topic=234895.0 https://github.com/JChristensen/mini1284 https://aptinex.com/product/lakduino-dwee-1284-pro-mini/
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.
Joachim B. schrieb: > alle m1284p Arduino Clones funktionieren mit der Arduino Wire.h Du verwechselst offenbar gerade "header file" mit "library".
Also, wo die Pins definiert werden, welche die originale Arduino AVR Wire Lib nutzt, das kann ich dir sagen. In der zugehörigen Varianten Datei! Beispiel: https://github.com/JChristensen/mighty-1284p/blob/v1.6.3/avr/variants/standard/pins_arduino.h#L53 Dort werden SDA und SCL definiert, und unter dem Namen dann später in der Wire Lib verwendet um die Pullup einzuschalten.
Joachim B. schrieb: > alle m1284p Arduino Clones funktionieren mit der Arduino Wire.h > > https://hackaday.com/2011/08/17/bobuino-arduino-based-on-atmega1284-goodies/ Ah, endlich mal eine Referenz auf ein Stück Code. https://github.com/maniacbug/mighty-1284p/blob/master/variants/bobuino/pins_arduino.h Zitat daraus:
1 | static const uint8_t SDA = 23; |
2 | static const uint8_t SCL = 22; |
So, nun weißt du, woher er die Pinzuordnung kennt. Edit: ufuf war ein wenig schneller …
:
Bearbeitet durch Moderator
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!
1 | E:\Programme\arduino\portable\sketchbook\sketch_jul16d\sketch_jul16d.ino: In function 'void setup()': |
2 | sketch_jul16d:11:21: error: no matching function for call to 'TwoWire::begin(const uint8_t&, const uint8_t&)' |
3 | Wire.begin(SCL,SDA); |
4 | ^
|
5 | In file included from E:\Programme\arduino\portable\sketchbook\sketch_jul16d\sketch_jul16d.ino:1:0: |
6 | E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:53:10: note: candidate: void TwoWire::begin() |
7 | void begin(); |
8 | ^~~~~
|
9 | E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:53:10: note: candidate expects 0 arguments, 2 provided |
10 | E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:54:10: note: candidate: void TwoWire::begin(uint8_t) |
11 | void begin(uint8_t); |
12 | ^~~~~
|
13 | E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:54:10: note: candidate expects 1 argument, 2 provided |
14 | E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:55:10: note: candidate: void TwoWire::begin(int) |
15 | void begin(int); |
16 | ^~~~~
|
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.
:
Bearbeitet durch Moderator
Hallo, Joachim, liest du auch was man dir zeigt? Arduino Fanboy hat Testweise versucht der Wire Lib 2 Pins mitzugeben. Daraufhin kam folgende Meldung.
1 | error: no matching function for call to 'TwoWire::begin(const uint8_t&, const uint8_t&)' |
2 | Wire.begin(SCL,SDA); |
Was sagt dir diese Meldung?
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.
:
Bearbeitet durch Moderator
Joachim B. schrieb: > wenn man der Wire LIB wie auch immer keine Pins mitgeben könnte, Es gibt halt viele verschiedene Wire- (und andere) libs:
1 | $ find . -name Wire |
2 | ./packages/LGT8fx Boards/hardware/avr/1.0.5/libraries/Wire |
3 | ./packages/arduino/hardware/avr/1.8.2/libraries/Wire |
4 | ./packages/arduino/hardware/sam/1.6.12/libraries/Wire |
5 | ./packages/esp8266/hardware/esp8266/2.6.2/libraries/Wire |
6 | ./packages/megaTinyCore/hardware/megaavr/1.1.2/libraries/Wire |
7 | ./packages/STM32/hardware/stm32/1.5.0/libraries/Wire |
8 | ./packages/MiniCore/hardware/avr/2.0.3/libraries/Wire |
9 | ./packages/digistump/hardware/avr/1.6.7/libraries/Wire |
So what leo
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
:
Bearbeitet durch User
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.
aber nur ich bin nicht immer alleine ratlos Beitrag "AVR Inline Optimierung kaputt?" es kann jeden treffen
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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).
:
Bearbeitet durch User
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/
Arduino Fanboy D. schrieb: > Gibt aber auch einige Libs, welche keine Klassen beinhalten. Hast Recht, den Sonderfall habe ich außen vor gelassen.
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!
1 | #if F_CPU < 96000000
|
2 | #if defined(__AVR_ATmega1284P__)
|
3 | #define NS(_NS) ( (_NS * ( ((long)(F_CPU*9L/10L)) / 1000000L))) / 1000
|
4 | #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (((long)(F_CPU*9L/10L)) / 1000000L)
|
5 | #else
|
6 | #define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
|
7 | #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
|
8 | #endif
|
9 | #else
|
10 | #define NS(_NS) ( (_NS * (F_CPU / 2000000L))) / 1000
|
11 | #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 2000000L)
|
12 | #endif
|
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.
Joachim B. schrieb: > einfach für den m1284p den F_CPU Takt auf 90% gesetzt! > >
1 | > #if F_CPU < 96000000 |
2 | > #if defined(__AVR_ATmega1284P__) |
3 | ...
|
4 | >
|
hast du den Stickstoff gekühlt? :-) :-)
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: > trotzdem ist der Zugriff 10% langsamer Welcher Zugriff wo ist 10 % langsamer? Wogegen verglichen?
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"
Beitrag #6343003 wurde von einem Moderator gelöscht.
Beitrag #6343006 wurde von einem Moderator gelöscht.
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
Beitrag #6344034 wurde von einem Moderator gelöscht.
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:
1 | avrdude ... -U eeprom:w:application.elf |
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:
1 | tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.with_bootloader.hex:i" "-Ueeprom:w:{build.path}/{build.project_name}.eep:i" |
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?
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
Beitrag #6344485 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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 | bool busy(byte i2cAdr) // ACKNOWLEDGE POLLING |
2 | {
|
3 | Wire.beginTransmission(i2cAdr); |
4 | return Wire.endTransmission(); |
5 | }
|
6 | |
7 | bool busy(byte i2cAdr) // ACKNOWLEDGE POLLING |
8 | {
|
9 | Wire.beginTransmission(i2cAdr); |
10 | return (bool) Wire.endTransmission(); |
11 | }
|
12 | |
13 | bool busy(byte i2cAdr) // ACKNOWLEDGE POLLING |
14 | {
|
15 | Wire.beginTransmission(i2cAdr); |
16 | return bool(Wire.endTransmission()); |
17 | }
|
18 | |
19 | bool ready(byte i2cAdr) // ACKNOWLEDGE POLLING |
20 | {
|
21 | Wire.beginTransmission(i2cAdr); |
22 | return 0 == Wire.endTransmission(); |
23 | }
|
24 | |
25 | bool ready(byte i2cAdr) // ACKNOWLEDGE POLLING |
26 | {
|
27 | Wire.beginTransmission(i2cAdr); |
28 | return 0 == Wire.endTransmission(); |
29 | }
|
30 | |
31 | bool ready(byte i2cAdr) // ACKNOWLEDGE POLLING |
32 | {
|
33 | Wire.beginTransmission(i2cAdr); |
34 | return not Wire.endTransmission(); |
35 | }
|
36 | |
37 | bool ready(byte i2cAdr) // ACKNOWLEDGE POLLING |
38 | {
|
39 | Wire.beginTransmission(i2cAdr); |
40 | return ! Wire.endTransmission(); |
41 | }
|
42 | |
43 | bool ready(byte i2cAdr) // ACKNOWLEDGE POLLING |
44 | {
|
45 | Wire.beginTransmission(i2cAdr); |
46 | return ! bool(Wire.endTransmission()); |
47 | }
|
48 | |
49 | bool ready(byte i2cAdr) // 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
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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. NEVER Joachim 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.
Beitrag #6360638 wurde von einem Moderator gelöscht.
Beitrag #6360654 wurde von einem Moderator gelöscht.
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!
:
Bearbeitet durch User
Beitrag #6361162 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.