Forum: Mikrocontroller und Digitale Elektronik arduino oder GCC Programmierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
'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!

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> MY_EEP_VAR.bias=SET_BIAS; // klappt nicht!

Zuweisungen funktionieren nur innerhalb von Funktionen.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von wer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dein Compiler sagt "Klappt nicht"?!

Das kann ich kaum glauben. Fehlermeldung?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
wer schrieb:
> Das kann ich kaum glauben. Fehlermeldung?

Erste Zeile seines Beitrags. Leicht zu übersehen. ;-)

von Asdf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Versuche mal Definition und Initialisierung zusammen (sitze am Tablet 
und kann das gerade nicht testen):
struct eep_var MY_EEP_VAR = {42,42,42,Hello};

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
-3 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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

von jo mei (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
jo mei schrieb:
> In Variablen benutzt man nicht durchgehend Grossbuchstaben.

Wo er das doch seit 1988 tut...

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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
von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
im h-File:
 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;


im c-File:
 struct eep_var MY_EEP_VAR={ .backlicht=42,                             
                              .contra=42,                               
                              .bias=42,                                 
                              .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:
                                                                        
void init_struct_eep(   struct eep_var* my_eep_var,                     
                        const uint8_t arg_backlicht,                    
                        const uint8_t arg_contra,                       
                        const uint8_t arg_bias,                         
                        const char* arg_str)                            
{                                                                       
   my_eep_var->backlicht=arg_backlicht;                                 
   my_eep_var->contra=arg_contra;                                       
   my_eep_var->bias=arg_bias;                                           
                                                                        
   //magic numbers, besser #define verwenden                            
   strncpy(my_eep_var->mesz_str, arg_str, 5); 
                          
   //falls mesz_str ein string-Array sein soll                   
   my_eep_var->mesz_str[4]='\0';                                        
                                                                        
}  

und dann der Aufruf:
struct eep_var MY_EEP_VAR; 
                                            
init_struct_eep(&MY_EEP_VAR, 1,2,3, "viel_zu_langer_text");  

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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!)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
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 vom Autor gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
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
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)

alles andere läuft mit schnellerem I2C clock, nur das EEPROM nicht

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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:
  // prüft, ob Baustein unter der Adresse beschäftigt ist
bool busy(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr); 
    return Wire.endTransmission();  
}

von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Ebay-Artikel Nr. 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!

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Bis jetzt sehe ich da nur borniertes Beharren!

>Ich versuche das Feuer sowieso auf mich zu ziehen.
gelingt dir gut!

von Arduino Fanboy D. (ufuf)


Bewertung
2 lesenswert
nicht lesenswert
Ja!

Ist denn mittlerweile der Groschen gefallen, welchen Bock du in deiner 
Funktion geschossen hast?

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

was von mir in der Hoffnung das es hilft, seltsame Wartezeiten habe ich 
damit nicht.
bool readOneRegister (const uint8_t i2cAdr, const uint8_t reg, uint8_t &var)
{
  Wire.beginTransmission(i2cAdr);       // Connect
  Wire.write(reg);                      // Anfrage ab/der Register Nummer
  if (Wire.endTransmission() > 0) {     // war Connect fehlerfrei?
    return false;                       // I2C Busfehler ?     
  }
  Wire.requestFrom(i2cAdr, 1);          // 1 Byte anfordern/lesen
  if (Wire.available() > 0) {           // sind Daten vorhanden?
    var = Wire.read();
  }
  return true;
}

bool writeOneRegister (const uint8_t i2cAdr, const uint8_t reg, uint8_t data)
{
  Wire.beginTransmission(i2cAdr);
  Wire.write(reg);                      // setzen auf Registeradresse ab der es losgehen soll
  Wire.write(data);                     // Daten in Register schreiben
  if (Wire.endTransmission() > 0) {     // 
    return false;                       // I2C Busfehler ? 
  }
  return true;
}

bool readTwoRegister (const uint8_t i2cAdr, const uint8_t firstReg, uint8_t &var1, uint8_t &var2)
{
  Wire.beginTransmission(i2cAdr);       // Connect
  Wire.write(firstReg);                 // Anfrage ab/der Register Nummer
  if (Wire.endTransmission() > 0) {     // war Connect fehlerfrei?
    return false;                       // I2C Busfehler ? 
  }
  Wire.requestFrom(i2cAdr, 2);          // 2 Bytes in Folge anfordern/lesen
  if (Wire.available() > 0) {           // sind Daten vorhanden?
    var1 = Wire.read();
    var2 = Wire.read();
  }
  return true;
}

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
2 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
könntet ihr euch nicht einfach mal auf ein Bier zusammensetzen und das 
lösen?

von jo mei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
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
mighty_opt.name=Mighty 1284p 16MHz using Optiboot
mighty_opt.upload.protocol=arduino
mighty_opt.upload.maximum_size=130048
mighty_opt.upload.speed=115200
mighty_opt.bootloader.low_fuses=0xff
mighty_opt.bootloader.high_fuses=0xde
mighty_opt.bootloader.extended_fuses=0xfd
mighty_opt.bootloader.path=optiboot
mighty_opt.bootloader.file=optiboot_atmega1284p.hex
mighty_opt.bootloader.unlock_bits=0x3F
mighty_opt.bootloader.lock_bits=0x0F
mighty_opt.build.mcu=atmega1284p
mighty_opt.build.f_cpu=16000000L
#mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

von jo mei (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> alle m1284p Arduino Clones funktionieren mit der Arduino Wire.h

Du verwechselst offenbar gerade "header file" mit "library".

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
static const uint8_t SDA = 23;
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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!
E:\Programme\arduino\portable\sketchbook\sketch_jul16d\sketch_jul16d.ino: In function 'void setup()':
sketch_jul16d:11:21: error: no matching function for call to 'TwoWire::begin(const uint8_t&, const uint8_t&)'
   Wire.begin(SCL,SDA);
                     ^
In file included from E:\Programme\arduino\portable\sketchbook\sketch_jul16d\sketch_jul16d.ino:1:0:
E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:53:10: note: candidate: void TwoWire::begin()
     void begin();
          ^~~~~
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
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)
     void begin(uint8_t);
          ^~~~~
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
E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.8.3\libraries\Wire\src/Wire.h:55:10: note: candidate: void TwoWire::begin(int)
     void begin(int);
          ^~~~~


von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Joachim, liest du auch was man dir zeigt?

Arduino Fanboy hat Testweise versucht der Wire Lib 2 Pins mitzugeben. 
Daraufhin kam folgende Meldung.
error: no matching function for call to 'TwoWire::begin(const uint8_t&, const uint8_t&)'
   Wire.begin(SCL,SDA);

Was sagt dir diese Meldung?

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von leo (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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:
$ find . -name Wire
./packages/LGT8fx Boards/hardware/avr/1.0.5/libraries/Wire
./packages/arduino/hardware/avr/1.8.2/libraries/Wire
./packages/arduino/hardware/sam/1.6.12/libraries/Wire
./packages/esp8266/hardware/esp8266/2.6.2/libraries/Wire
./packages/megaTinyCore/hardware/megaavr/1.1.2/libraries/Wire
./packages/STM32/hardware/stm32/1.5.0/libraries/Wire
./packages/MiniCore/hardware/avr/2.0.3/libraries/Wire
./packages/digistump/hardware/avr/1.6.7/libraries/Wire

So what

leo

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
aber nur ich bin nicht immer alleine ratlos
Beitrag "AVR Inline Optimierung kaputt?"

es kann jeden treffen

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.)

von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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/

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Gibt aber auch einige Libs, welche keine Klassen beinhalten.

Hast Recht, den Sonderfall habe ich außen vor gelassen.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Arduino definiert das Wort Library etwas anders.

OK

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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!
#if F_CPU < 96000000
    #if defined(__AVR_ATmega1284P__)
        #define NS(_NS) ( (_NS * ( ((long)(F_CPU*9L/10L)) / 1000000L))) / 1000
        #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (((long)(F_CPU*9L/10L)) / 1000000L)
    #else
        #define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
        #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
    #endif
#else
    #define NS(_NS) ( (_NS * (F_CPU / 2000000L))) / 1000
    #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 2000000L)
#endif

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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...

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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 ....

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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).

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
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 :)

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Johannes S. schrieb:
> brauche endlich ein Bier

Hihi, steht schon hier. :-)

OK, off-topic …

von Johannes S. (jojos)


Bewertung
3 lesenswert
nicht lesenswert
Besser Schaum aufm Bier als vorm Mund

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> einfach für den m1284p den F_CPU Takt auf 90% gesetzt!
>
>
> #if F_CPU < 96000000
>     #if defined(__AVR_ATmega1284P__)
...
> 

hast du den Stickstoff gekühlt?  :-)  :-)

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> trotzdem ist der Zugriff 10% langsamer

Welcher Zugriff wo ist 10 % langsamer? Wogegen verglichen?

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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....

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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 vom Autor gelöscht.
Beitrag #6343006 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> nicht gelesen?

Ja, nicht gelesen. Auch keine Zeit dafür, sorry.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.   :-)

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
EESAVE Fuse nicht gesetzt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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:
avrdude ... -U eeprom:w:application.elf

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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:
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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:

bool busy(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return Wire.endTransmission();
}

bool busy(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return (bool) Wire.endTransmission();
}

bool busy(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return bool(Wire.endTransmission());
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return 0 == Wire.endTransmission();
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return 0 == Wire.endTransmission();
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return not Wire.endTransmission();
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return ! Wire.endTransmission();
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return ! bool(Wire.endTransmission());
}

bool ready(byte i2cAdr)          // ACKNOWLEDGE POLLING
{
    Wire.beginTransmission(i2cAdr);
    return ! (bool)Wire.endTransmission();
}

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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Wobei dein Cast gut ist, und mein Cast böse.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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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)

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.
von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
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.
von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.