Hallo
Habe zur Kontrolle der I2C Bus Geräte ein kleines Programm geschrieben.
Es ermittelt die Busadresse und zeigt sie auf einem 4x16 LCD Display ab.
Das Programm kann auf Grund der Grösse des LCD und des Programmes immer
nur eine Adresse anzeigen. Sind mehrere Adressen vorhanden, so kann
immer nur die letzte angezeigt werden.
Beim Raspi wird es als Tabelle angezeigt:
1 2 3 4 5 6 7
00
10
20 x x x 24
30 x 32
..
usw.
1
voidBus_checker()
2
{
3
chartext[8];
4
uint8_tiadr;
5
for(iadr=0x00;iadr<0xFE;iadr++)
6
{
7
e=i2c_start(iadr);// Abfrage I2C Bus Adresse
8
i2c_write(0x00);// Sende Inhalt 0
9
i2c_stop();// Bus Stop
10
11
lcd_printlc(1,1,"Adressen am Bus:");// Anzeige
12
lcd_printlc(2,3,"Display:");// Anzeige
13
14
lcd_putcharlc(2,12,'0');// Anzeige 0
15
lcd_putcharlc(2,13,'x');// Anzeige x
16
itoa(adr1_w,text,16);// Berechne "text"
17
lcd_printlc(2,14,text);// Anzeige Adresse Display
18
19
lcd_printlc(3,2,"Suche Nr:");// Anzeige Suche Nr
20
itoa(iadr,Buffer,10);// Berechne iadr
21
lcd_printlc(3,12,Buffer);// Ausgabe Such Nr
22
23
if(e==0)// Ausgabe Adresse
24
{// 0=Adresse vorhanden, 1=keine Adresse
25
if(iadr!=adr1_w)// adr1_w ausblenden
26
{
27
lcd_printlc(4,1,"Adr");// Anzeige "Adresse"
28
itoa(iadr,Buffer,16);// Berechne iadr in Hex
29
lcd_putcharlc(4,5,'0');// Anzeige 0
30
lcd_putcharlc(4,6,'x');// Anzeige x
31
lcd_printlc(4,7,Buffer);// Ausgabe Adresse
32
lcd_printlc(4,10,"dez");// Anzeige "dez"
33
itoa(iadr,Buffer,10);// Berechne iadr in Hex
34
lcd_printlc(4,14,Buffer);// Ausgabe Adresse
35
}
36
}
37
iadr=iadr+1;
38
_delay_ms(200);
39
}
40
}
Wie kann ich aus dieser Anzeige die Tabelle auf einem Graphikdisplay
machen?
LG Heinz
Heinz schrieb:> Wie kann ich aus dieser Anzeige die Tabelle auf einem Graphikdisplay> machen?> LG Heinz
zu fast jeder LIB gibt es auch für Grafik Displays print Ausgaben
Die Texte exestieren für das Graphikdisplay. Kann ca. 10 verschiedene
Schrifte ausgeben. Mit Angabe Zeile usw. klappt sehr gut.
Das Problem ist die Ausgabe selber. Wie kann ich die gefundenen Adressen
als Tabelle ausgeben mit korrekter Angabe von Zeile und Spalte ohne die
vorige Adresse zu löschen?
Heinz schrieb:> Mit Angabe Zeile usw. klappt sehr gut.> Das Problem ist die Ausgabe selber. Wie kann ich die gefundenen Adressen> als Tabelle ausgeben mit korrekter Angabe von Zeile und Spalte ohne die> vorige Adresse zu löschen?
??? die Worte lese ich wohl, aber mir scheint du musst programmieren
lernen, also lautet die Frage doch: "wer progrmmiert es dir?"
Es gibt viele Möglichkeiten, du legst dir ein Array an sortierst nach
deinen Wünschen und gibst es so aufs Display wie du das willst!
Ich möchte es nicht programmiert haben sondern selber machen.
Das mit dem Array ist ein guter Tip.
Da ich bereits Array programmiert habe, bleibt die Frage nach dem wie.
Es sollen doch unterschiedliche Adressen an verschiedenen Stelln geladen
und angezeigt werde.
Wenn du dir das obere Stück ansiehst bleibt eine Frage offen. Wer hat
das programmiert? Ganz so neu bin ich damit nicht. Das Stück Code ist
weder geklaut noch kopiert oder ähnliches.
Mir geht es um den Weg dabei und es relativ günstig zu machen.
den Bus_checker() in zwei Funktionen unterteilen: scan_bus() und
display_result(). scan_bus bekommt die Adresse vom Ergebnis Array und
die max. Anzahl die ins Array passen, return Wert ist die Anzahl
gefundener Devices. Bei scan reicht es in zweier Schritten hochzuzählen,
Bit0 der I2C Adressierung ist das R/W bit.
Das Ergebnis Array kann ein Array von Bytes sein, dann braucht man Platz
für die Anzahl gefundener Adressen.
Bei knappem RAM kann man auch ein Bitfeld nehmen, dann braucht man 128 /
8 = 16 Bytes für alle möglichen Adressen.
Nach dem scan ruft man display_result() mit der Arrayadresse und Anzahl
gefundener devices auf. Beim Bitfeld könnte man letzteres weglassen weil
man für die Anzeige alle Bits durchklappern muss.
Johannes S. schrieb:> Bei scan reicht es in zweier Schritten hochzuzählen,> Bit0 der I2C Adressierung ist das R/W bit.
nicht in der Arduino Zählung
Wir wissen noch nicht wo der TO programmiert, im AVR Studio, in Arduino?
oder ganz woanders?
Er hat ein 4 Zeiliges Display, er hat RAM aber da verrät er uns weder
Größe noch welcher µC es ist.
Ich würde ja, bei genug RAM, Arrays anlegen für 4 Zeilen und in das 4
Zeilen Array die gefundenen einblenden und zur Ausgabe schicken, mit
Johannes S. schrieb:> die Listeneinträge könnten nacheinander angezeigt werden, etwa für 2 s
oder mit Tastenabfrage "nächstes anzeigen"
Joachim B. schrieb:> Johannes S. schrieb:>> Bei scan reicht es in zweier Schritten hochzuzählen,>> Bit0 der I2C Adressierung ist das R/W bit.>> nicht in der Arduino Zählung
Man zählt auch nicht in 2er Schritten sondern nur bis 127. Weil es eben
eine 7 Bit Adresse ist.
Dass diese Adresse später auf dem Bus links geshifted übertragen wird,
spielt keine Rolle. Sind zwei Paar Schuhe.
Eine I2C Adresse kann zwischen 1 und 127 liegen. Ende der Geschichte.
Nur Idioten können nicht zwischen der Adresse und dem übertragenen Byte
auf dem Bus unterscheiden.
Cyblord -. schrieb:> Nur Idioten
antworten auf ungestellte Fragen?
Ich hatte mit pure AVR angefangen und mit dem Datenblatt meiner I2C
Teile also war die I2C Adresse für mich immer 8 Bit ohne
Berücksichtigung vom R/W Bit, das darfst du ruhig "idiotisch" nennen
wenns dir dann besser geht!
Ob man nun 7-Bit oder 8-Bit (mit ausklammern vom R/W Bit) auswertet ist
doch Banane, Hauptsache es funktioniert und man mixt Codes nicht wild
und bleibt bei einer Arbeitsweise.
Cyblord -. schrieb:> Man zählt auch nicht in 2er Schritten sondern nur bis 127
und berücksichtigt noch die I2C Adresserweiterung!
https://www.i2c-bus.org/addressing/10-bit-addressing/
Joachim B. schrieb:> Cyblord -. schrieb:>> Nur Idioten>> antworten auf ungestellte Fragen?
Nein, genau darum ging es.
Wenn ich alle I2C Adresse durchlaufen will, zähle ich von 1-127. Das ist
nicht nur einfach sondern auch korrekt. Und das war die Frage.
> Ich hatte mit pure AVR angefangen und mit dem Datenblatt meiner I2C> Teile also war die I2C Adresse für mich immer 8 Bit ohne> Berücksichtigung vom R/W Bit, das darfst du ruhig "idiotisch" nennen> wenns dir dann besser geht!
Ja ist es. Es ist falsch. Das ist nicht Ansichtssache, darüber kann man
nicht abstimmen. Es ist falsch. Die I2C Spec. lautet anders.
> Ob man nun 7-Bit oder 8-Bit (mit ausklammern vom R/W Bit) auswertet ist> doch Banane, Hauptsache es funktioniert und man mixt Codes nicht wild> und bleibt bei einer Arbeitsweise.
Es ist nicht "Banane" weil es teil des Verständnisses von I2C betrifft
und auch für eine API wichtig ist.
Wenn eine API die I2C Adresse möchte, muss man wissen was da erwartet
wird.
Wenn da jeder macht was er will, gibt es Konfusion. Es kann dann
Programmteile geben die mit 7 Bit Adressen rechnen und andere 8 Bit.
Chaos ist die Folge.
Dabei vermeidet man das und betrachtet die Adresse immer nur als 7 Bit.
Überall im Programm. Nur die Routine welche die Datenpakete für den
Versand über die Leitung vorbereitet, erstellt daraus die benötigten 8
Bit nach I2C Standard und fügt das RW Bit hinzu.
Das ist Clean Code. Alles andere ist Pfusch.
Joachim B. schrieb:> und das ist definitiv falsch weil es eben auch die Adresserweiterung> gibt, aber zähl du nur bis 127 ;)
Willst du dich jetzt ernsthaft daran aufhängen? Auch die
Adresserweiterung kann man sauber umsetzen. Das ist doch nicht der
Punkt.
Es handelt sich ja auch eher um eine proprietäre Erweiterung und nicht
Teil des Standards. Aber wie gesagt spielt das keine Rolle.
Würde man mit 8 Bit Adressen arbeiten dürfte man nur jede 2. Adresse
verwenden. Die Hälfte der Adresse im Adressraum wäre ungültig. Eine
entsprechende API müsste das abfangen und einen Fehler melden.
Allein daran müsste man schon sehen wie Unsinnig das ist.
> das ist DEINE Meinung, aber wie hier jeder weiss lässt du andere> Meinungen eh nicht gelten!
Welche Meinung? Du postest einen Link. Als wärst DU in der Lage
selbsttätig über saubere SW Entwicklung zu diskutieren. Vorher
diskutiert ein Lama übers fliegen.
Cyblord -. schrieb:> Willst du dich jetzt ernsthaft daran aufhängen?
warum nicht, es macht mir bei dir genauso viel Spass wie dir
offensichtlich andere zu maßregeln!
Cyblord -. schrieb:> Als wärst DU in der Lage> selbsttätig über saubere SW Entwicklung zu diskutieren
nö bin ich nicht und nun?
Eben weil es verschiedene Herangehensweisen gibt vermute ich mal das
selbst Informatikprofessoren nicht einig sind!
Ich habe aber nun keinen Bock alle Informatikscripte zu durchsuchen von
allen Unis weltweit.
Wäre das alles einfach und linear gäbe es ja kaum Softwarefehler, oder
es gibt diese Softwarefehler nur weil ein Superuser eben nicht alles
programmiert hat.
> Eine I2C Adresse kann zwischen 1 und 127 liegen. Ende der Geschichte.> Nur Idioten können nicht zwischen der Adresse und dem übertragenen Byte> auf dem Bus unterscheiden.
Na dann zeig endlich die Stelle im Standard wo du das meinst
herauszulesen. Und ich zeig dir dann die Leute die I²C erfunden haben,
I²C Teile in Chips gegossen haben, den Standard geschrieben haben und
viele I²C Chips gebaut haben. Die haben praktisch alle, mit wenigen
Ausnahmen, von 8 Bit Adressen geredet, in ihren Datenblättern
geschrieben und in ihren Testprogrammen so bezeichnet. Und
niederwertigste Bit der Adresse war/ist R/W bzw. Adresse +1 ist Slave
Transmitter.
Das diese ICs, AppNotes, Steuerprogramme und Datenblätter oft außerhalb
von Philips bzw. deren Großkunden nicht bekannt sind, tut nicht viel zur
Sache. Nur deine vehement vertretenen Behauptungen hier, solltest du
etwas überdenken. Offensichtlich kennst du nicht die ersten Jahrzehnte
von I²C beim Erfinder Philips und reimst dir deine eigene Welt zusammen.
Andi B. schrieb:> Na dann zeig endlich die Stelle im Standard wo du das meinst> herauszulesen. Und ich zeig dir dann die Leute die I²C erfunden haben,> I²C Teile in Chips gegossen haben, den Standard geschrieben haben und> viele I²C Chips gebaut haben. Die haben praktisch alle, mit wenigen> Ausnahmen, von 8 Bit Adressen geredet,
Ich kenne keine Quelle in der von 8-Bit Adressen geredet wird.
Schau mal hier rein z.B.:
I2C-bus specification and user manual
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Da ist immer nur von 7 oder 10 Bit Adressen die rede.
Hast du ein Gegenbeispiel welches näher an einer offiziellen Spec ist?
Außerdem handelt es sich nun mal DEFACTO um 7 Bit Adressen. Was gibts da
zu diskutieren. Jeder weiß es oder sollte es wissen.
Joachim B. schrieb:> Johannes S. schrieb:>> Bei scan reicht es in zweier Schritten hochzuzählen,>> Bit0 der I2C Adressierung ist das R/W bit.>> nicht in der Arduino Zählung
I2C verwendet 7-Bit Adressen - steht zumindest in der Spezifikation
(The I2c-Bus Specification Version 2.1, Kap. 10 7-Bit Addressing) und
die sollte es wissen. Fig. 14 stellt die Zusammensetzung des Startbytes
auch noch einmal bitweise dar. Alles andere ist nicht I2C.
Alle mal langsam und Luft holen. Will keinen Streit um das Thema. Mir
geht es nur um die Umsetzung des Programmes, halt was und wie ich machen
kann. Zu den Fragen: Arbeite mit Atmega 128, in C und kein Arduino.
Hatte bisher immer ein LCD Display mit 4x16 und will jetzt ein
Graphikdisplay mit 160x104 nehmen. Da darauf mehr Platz ist will ich das
mal versuchen. Beim Raspi habe die es doch auch gemacht.
Joachim B. schrieb:> nicht in der Arduino Zählung
in Arduino gibts nichtmal Programme. Wenn die Macher da etwas anders
nennen oder zählen wollen, dann sollen die das tun. Mit der Frage des TO
hat das jedenfalls nichts zu tun.
> Wir wissen noch nicht wo der TO programmiert, im AVR Studio, in Arduino?> oder ganz woanders?
Doch, ich weiss es. Dazu muss man sich nur seinen Code ansehen.
Mit der albernen Streiterei wird nur der Thread gekapert.
Heinz schrieb:> Hatte bisher immer ein LCD Display mit 4x16
Was ist ein LCD Display mit 4x16?
Wenn ich danach google, finde ich vierzeilige Textdisplays. Erzähle
jetzt nicht, dass sich da nur eine Adresse drauf anzeigen lässt!
Heinz schrieb:> und will jetzt ein Graphikdisplay mit 160x104 nehmen.
Viel Spaß mit Atmega 128 und dem für die Graphik notwendigen
Speicherbedarf.
Joachim B. schrieb:> Johannes S. schrieb:>> Bei scan reicht es in zweier Schritten hochzuzählen,>> Bit0 der I2C Adressierung ist das R/W bit.>> nicht in der Arduino Zählung
Gerade in der Arduino Zählung. Oder kennst du irgendeinen I2C Baustein,
den man nur beschreiben, aber nicht lesen kann?
Es stimmt, habe ein LCD mit 4 Zeilen verwendet. Damit kann ich 4
Adressen anzeigen lassen. Hatte aber bisher immer die letzte gefundene
Adresse angezeigt. Habe dann auch noch umgerechnet in dezi und hex.
Danke für die Angabe zum Atmega 128 und die Graphik.
Info dazu, verwende ein Display von EA, ebenfalls mit I2C Bus.
Heinz schrieb:> Es stimmt, habe ein LCD mit 4 Zeilen verwendet. Damit kann ich 4> Adressen anzeigen lassen. Hatte aber bisher immer die letzte gefundene> Adresse angezeigt. Habe dann auch noch umgerechnet in dezi und hex.
Also echt jetzt?? Ich kann auf einem LCD mit 4 Zeilen und 40 Char per
"Scrollen" locker den Roman "Krieg und Frieden" anzeigen...wo ist das
Problem?
Gruß Rainer
Heinz schrieb:> Es stimmt, habe ein LCD mit 4 Zeilen verwendet. Damit kann ich 4> Adressen anzeigen lassen. Hatte aber bisher immer die letzte gefundene> Adresse angezeigt.
Dann musst Du halt "Dein" Programm entsprechend aufbauen, Platz genug
hast Du.
> Habe dann auch noch umgerechnet in dezi und hex.
Wenn Du Dich entscheidest, entweder oder anzuzeigen, passen mehr als
vier Adressen ins Display. Wird etwas Bastelei, wenn die dezimal mal
zwei- und mal dreistellig sind und trotzdem ordentlich untereinander
stehen sollen.
> Danke für die Angabe zum Atmega 128 und die Graphik.
Ich bin mit einem OLED-Grafikdisplay und I2C auf die Nase gefallen,
Arduino-Nano 328. Das lässt sich compilieren und fliegt dann im Betrieb
weg, weil die Grafik sehr viel RAM verwendet.
> Info dazu, verwende ein Display von EA, ebenfalls mit I2C Bus.
Ich habe 2x16 (1602) und 4x20 (2004) vom Alihändler in Betrieb, die
dürften sich identisch Deinem programmieren lassen.
Habe verschiedene Displays verwendet. Unter anderem auch ein OLED.
Funktioniert super. Auch die Farb TFT Display Graphik funktionieren ohne
Probleme. Diese machen auch meisten Spass. Haben eine Reaktionszeit von
6 Mykrosekunden. Leider hat die ganze Sache mit dem Arduino riesen
Nachteile für mich. Ist halt alles kastriert.
Natürlich kann ich das alles Anzeigen. Wollte aber einfach das
Graphikdisplay mit der Anzeige wie beim Raspi machen.
Heinz schrieb:> Hatte bisher immer ein LCD Display mit 4x16 und will jetzt ein> Graphikdisplay mit 160x104 nehmen.
kann es sein das du 4x16 Zeichen! mit 160x104 Pixel verwechselst?
selbst mit den kleinsten Font wirst du 8x6 Pixel pro Zeichen benötigen,
somit schrupfen deine Pixel schon mal auf 160/8 = 20 Zeichen in eine
Richtung und 104/6 = 17 Zeichen in die andere Richtung, oder gedreht
160/6 = 26 und 104/8 = 13 sind aber je nach Displaygröße auch sehr
schlecht ablesbar.
ein Nokia 5110 LCD hat 14 Zeichen/Zeile x 6 Zeilen, mein TFT 1,8" mit
160x128 Pixel ist in der Textgröße 2 gut lesbar bietet aber weniger und
in der Textgröße 1 wirds echt schlecht ablesbar für meine Augen.
Also merke Pixel sind nicht alles, es kommt auch auf die Displaygröße an
und größere Displays mit mehr Pixel brauchen auch mehr Platz, da kann es
im AVR eng werden auch vom Tempo unter I2C.
Joachim B. schrieb:> eng werden auch vom Tempo unter I2C.
Ach komm, Tempo ist das geringste Problem. Ich musste, und vermutlich
auch Du, die Aktualisierungsrate von Displays vorsätzlich bremsen, damit
man es nicht als Flackern empfindet.
Was Heinz mit seiner I2C-Anzeige will, wäre eigentlich auch mal zu
hinterfragen. Eine Anzeige der genutzen Adressen in Echtzeit ist nicht
realistisch, so schnell kann kein Mensch lesen. Anzeige, welche
überhaupt vorhanden sind - nach ein paar Sekunden stehen alle zwei oder
drei oder fünf Adressen drin, danach ändert sich eh nichts mehr.
Heinz schrieb:> Leider hat die ganze Sache mit dem Arduino riesen> Nachteile für mich. Ist halt alles kastriert.> Natürlich kann ich das alles Anzeigen. Wollte aber einfach das> Graphikdisplay mit der Anzeige wie beim Raspi machen.
Heinz, es ist doch für niemanden klar, was Du eigentlich willst:
A) Wenn Dein Problem irgendwas mit I2C zu tun hat, dann frage zu I2C.
Anscheinend nicht.
B) Wenn Du irgendein Display eines I2C-Testers im Kopf hast, dann Link
oder Foto. Kann doch hier keiner Ahnen, wieviel Infos Du wie anzeigen
willst.
C) Wenn es irgendwie darum geht, auf einem X-Zeilen und Y-Zeichen -
Display bestimmte infos darzustellen (mit oder ohne Scrollen, Tasten,
...) dann male oder Schreibe die Dinge auf, wie Du sie Dir vorstellst.
Und beschreibe, was Du sehen möchtest.
D) Wenn es dir darum geht, wie man Zeichen in Spalten und Reihen auf ein
Grafikdisplay nagelt, dann frage dazu. Und was Du schon kennst, was
Deine Erfahrungen sind.
e) Wenn Du Probleme mit der HW des Grafik-Displays hast, dann Angabe des
Displays (link, Typ, Controller, ...). Und was schon geht und was nicht.
So wie ich das verstanden habe, hast Du einen Textbildschirm, auf dem Du
2 bis 100 Datensätze anzeigen willst. Fange einfach damit an, dass Du
alle 3 Sekunden die unterste Zeile mit der nächsten Info füllst und alle
anderen ein höher schiebst.
Manfred schrieb:> Ach komm, Tempo ist das geringste Problem.
mag sein aber 4x16 Zeichen sind was anderes als pixelweise Zeichen zu
übertragen!
Klar sind beim 4x16 LCD nur 64 Zeichen also 64 Bytes zu übertragen und
beim Grafik LCD ist das gleich als Zeichen mindesten 35x so viel und wer
da noch ein großes TFT befüllen will bekommt dann das große Flackern.
Mein 320x240 Pixeldisplay wurde dann echt unangenehm, also habe ich den
"Trick"? angewandt statt das ganze Display zu löschen (beim
Überschreiben blieben immer Restpixel stehen, vielleicht war ich im
falschen overwrite Mode?) also habe ich meinen Text gepuffert und den
alten Text lokal mit black zu überschreiben und nur an der selben
Position neu zu schreiben, somit hatten sich die Tempo- und
Flacker-probleme erledigt.
Wolfgang schrieb:> Oder kennst du irgendeinen I2C Baustein,> den man nur beschreiben, aber nicht lesen kann?
Auch solche gibt es, z.B. den DAC7571.
Aber auch der hat eine 7-Bit Adresse ;)
Thread beobachten
Seitenaufteilung abschalten