Der Raspi mit einem SM(I2C) Bus ein Display ansteuern

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Hallo
Wer von euch kennt sich ,mit dem Raspi aus? Es geht darum, ein LCD Display 4x16 (4x20) über den I2C Bus (SM) anzusteuern. Verwende dazu einen PCF8574. Der I2C Bus (SM) funktioniert ohne Probleme. Habe bereits an einem anderen PCF8574 mit dem I2C Bus mehrere LEDs blinken lassen. Zur Kopplung verwende ich einen Pegelwandler. Auf dem Display sind leider nur die schwarzen Quadrate zu sehen.
Falls sich jemand auskennt, schicke ich gern die Programme.
achim
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Die Rechtecke weisen auf eine falsche/fehlende Initialisierung hin. Welche Software soll das Display denn auf der Himbeere ansteuern? Python?

Hast Du dasselbe Display (nebst Portexpander) erfolgreich an einem AVR testen können und eine nachweislich funktionierende Initialisierung?

Meiner Erinnerung nach gab es auch mal timingtechnische Empfindlichkeiten bei solchen Displays, wenn man irgendwelche Pausen zb nicht eingehalten hat...
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Genau so ist es, sehe ich auch so. Bei Display handelt es ich um das Modul was ich sehr oft mit dem AVR benutzt habe. Es geht auf jeden fall ist also ok. Mit Timing hat die alle Problem. Ich habe damals noch zusätzliche Pausen eingefügt. Versuche den Bus mit Python zu machen. Das soll ja sooo gut funktionieren
achim
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Mit Timing hat die alle Problem.
Aber die AVR sind halt grundsätzlich langsamer als die Himbeere, deswegen wäre es denkbar, daß irgendwo Wartezeiten fehlen. Manchmal spart man sich beim AVR dann das auslesen irgendwelcher busy-Flags, und Wartezeiten sind nicht nötig, da die in den relativ langsamen Taktraten verschwinden.

Wenn Du dasselbe Init auf AVR und Himbeere nutzt, und es hier geht und da nicht, würde ich einfach mal bei beiden 'n LogicAnalyzer drannklemmen und vergleichen...
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Habe alle Einstellungen zur Zeit und Dauer die ich in den Datein gefunden habe hochgesetzt. Leider ohne Erfolg. Das Display weigert sich beharrlich etwas darzustellen. Langsam bin ich verzweifelen. Leider scheinen sich auf der Seite von raspi auch nur wenige Leute mit dem SM(I2C) Bus auszukennen. Leider .....
Vielleicht gibt es hier ein paar Leute die auch den Raspi kennen?
achim
 

dino03

Aktives Mitglied
27 Okt 2008
6,758
18
38
Sprachen
  1. BascomAVR
  2. Assembler
Hi,

evtl passen ja die Verbindungen der PCF8574-Ports zum LCD nicht zum Programm. Das ganze wird ja per Bit-Banging umgesetzt. Es gibt aber für verschiedene Bibliotheken unterschiedliche Verbindungen zwischen den einzelnen PCF-8574-Bitleitungen und den Pins des LCDs. Das sollte man auch man kontrollieren.

Wenn auf dem LCD schwarze Blöcke zu sehen sind oder eine Zeile schwarz und die andere farblos ist, dann ist das normal. Das LCD ist dann noch nicht initialisiert, funktioniert aber grundsätzlich schon mal.

Ich hab mir das auch schonmal angesehen. Leider hab ich bei den Beiträgen zu den I2C-Displays für RasPI bis jetzt nur Links auf Amazon-Bestellungen für die I2C-Module mit dem PCF8574 gefunden aber keinerlei Beschreibung wie denn die Pins nun zwischen den Port-Bits und den Anschlüssen des LCDs verbunden sind. Die ganzen Beschreibungen sind da leider alle auf halber Strecke steckengeblieben.

Gruß
Dino
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Ich hatte das so verstanden, daß einerseits dieses Display bereits erfolgreich an einem AVR getestet wurde...
Bei Display handelt es ich um das Modul was ich sehr oft mit dem AVR benutzt habe
.. und folglich ein funktionierendes Init (also die via I²C gesendeten Byte-Sequenzen) bekannt ist, andererseits aber auch die Ansteuerung des I²C-Portexpanders erfolgreich gestestet wurde
Habe bereits an einem anderen PCF8574 mit dem I2C Bus mehrere LEDs blinken lassen.
Wenn also auf der Himbeere exakt dieselbe Byte-Sequenz gesendet wird, würde ich als nächsten Schritt beide Übertragungen mit einem LA mitloggen, und vergleichen...

Es gibt aber für verschiedene Bibliotheken[...]
Ich kenn mich mit den Dingern nicht aus (auch wenn ich'n 4B hierhabe), aber ich wäre jetzt von irgendwas "I2Csend"-ähnlichem ausgegangen - wenn man allerdings irgendwelche fremden (ggf auch noch nicht/schlecht dokumentierten) Bibliotheken verwendet...

Wenn ich mit irgendwelchen Bibliotheken gar nicht vorwärtskomme, versuch ich's erstmal zu Fuß...
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Guten Morgen an alle im Land und ein schönes Weinachtsfest
Ja, das Modul ist ein Teil aus meinem System und funktioniert ohne Probleme am AVR. Habe zwei verschiedne Versionen dazu. Beide basieren auf dem HD44780 (falls die schreibweise stimmt). Habe ein LCD Display mit 4x16 und ein OLED mit 4x20. Innerhalb der Datei kann ich alles einstellen, z.B. ob ich 4 oder 8 Bit nehme, welche Pins belegt werden, welches Pin RW, RS oder E ist. Habe die Adresse ausgelesen und korrekt eingestellt. Am Raspi habe ich einen anderen PCF mit 8 LEDs bereits betrieben und die LEDs blinken lassen. Damit funktioniert der I2C Bus Lib, der Pegelwandler und der Interface I2C am Raspi. Da ich auch die Anzahl der LEDs und Zeiten änder kann ist der Bus Lauffähig. Die Pin Belegung stimmt mit den verwendeten Schaltungen überein, ansonsten kann ich es ja einstellen. Per Fuss ist da nur wenig möglich, entweder geht oder geht nicht. Auch das mitloggen ist dabei nicht so einfach. übertrage nicht nur einen Satz an Bits sondern 4 verschiedene für die Zeilen.
Scheinbar kennt sich mit dem Raspi und dem Bus keiner so recht aus. Zum Beginn sind teilweise recht merkwürdige Sachen einzustellen. Die Bibliotheken ähneln sich alle. Bin gerade dabei die Unterschiede zu testen.
Mal sehen woran es liegt.
achim
 

fredred

Mitglied
1 Okt 2015
81
2
7
Hi,

evtl passen ja die Verbindungen der PCF8574-Ports zum LCD nicht zum Programm. Das ganze wird ja per Bit-Banging umgesetzt. Es gibt aber für verschiedene Bibliotheken unterschiedliche Verbindungen zwischen den einzelnen PCF-8574-Bitleitungen und den Pins des LCDs. Das sollte man auch man kontrollieren.

Wenn auf dem LCD schwarze Blöcke zu sehen sind oder eine Zeile schwarz und die andere farblos ist, dann ist das normal. Das LCD ist dann noch nicht initialisiert, funktioniert aber grundsätzlich schon mal.

Ich hab mir das auch schonmal angesehen. Leider hab ich bei den Beiträgen zu den I2C-Displays für RasPI bis jetzt nur Links auf Amazon-Bestellungen für die I2C-Module mit dem PCF8574 gefunden aber keinerlei Beschreibung wie denn die Pins nun zwischen den Port-Bits und den Anschlüssen des LCDs verbunden sind. Die ganzen Beschreibungen sind da leider alle auf halber Strecke steckengeblieben.

Gruß
Dino

Hallo,
hier mal meine Schaltung.
Display.jpg




Da ich mit Bascom programmiere benutze ich immer mit Erfolg diese Lib. Nur Pins anpaßen.

email = kent@smmab.se

comment = I2C LCD driver

libversion = 1.02

date = 31 march 2002

statement = You are free to use this code any way you like, if you are able to optimize

statement = it better, please send me an update on my e-mail.

history = No known bugs.



;define a constant named PCF8574_LCD pointing to the i2c address

;dimension _lcd_e as byte to control the E-lines (4 lines LCD:s)

;_lcd_e should have one of the following values

;128 to enable E1, 64 to enable E2, 192 to enable both E1 and E2 (cls, deflcdchar)

;Connect the following pins from PCF8574 to LCD

;

;P0 - D4

;P1 - D5

;P2 - D6

;P3 - D7

;P4 - RS

;P5 - RW (not used, set to 0 to ground for write)

;P6 - E2 (on 1 or 2 line display nc)

;P7 - E1



[_Init_LCD]

_Init_LCD:

*BASIC: waitms 50

ldi r16,&hc0 ; this is to make the initialization on both halfs of a 4-line LCD

Ldi _temp1, &h03 ; at init-time I call all routines before _lcd_e is loaded into r16

Rcall _Send_to_LCD

*BASIC: waitms 4

Rcall _Send_to_LCD

Rcall _Send_to_LCD

Ldi _temp1, &h02

Rcall _Send_to_LCD

Ldi _temp1, &h28

Rcall _Write_lcd_byte ;RS flag should to be 0, so jump directly to write byte

Ldi _temp1, &h08

Rcall _Write_lcd_byte

Ldi _temp1, &h0c

Rcall _Write_lcd_byte

Ldi _temp1, &h01

Rjmp _Write_lcd_byte

[END]

Gruß Fred
 

Anhänge

  • Display.jpg
    Display.jpg
    140.5 KB · Aufrufe: 0

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Die Belegung ist exakt die gleiche wie bei mir, Adresse ist anders bei mir eingestellt. In C wäre das schon längst erledigt. Dachte immer der Raspi ist doooooch so modern und einfach. Da habe ich wohl geirrt. Mist !!!!
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Die Adresse des PCF8574 ist:
┌───┬───┬───┬───┬───┬───┬───┬───┐
│ 0 │ 1 │ 0 │ 0 │ A2│ A1│ A0│R/W│
└───┴───┴───┴───┴───┴───┴───┴───┘


In der Schaltung von Fredred liegen die drei Adressleitungen auf Gnd, die Adresse wäre somit 0x20 (32dez) in 7-Bit Schreibweise bzw 0x41 (65dez) als Lese- und 0x40 (64dez) als Schreibadresse in 8-bit-Schreibweise.

Datenblatt PCF8574 Seite 12.

Bei Fredred wird aber auch ein PCF8574AP verwendet, und da ist die Adresse:
┌───┬───┬───┬───┬───┬───┬───┬───┐
│ 0 │ 1 │ 1 │ 1 │ A2│ A1│ A0│R/W│
└───┴───┴───┴───┴───┴───┴───┴───┘
 
Zuletzt bearbeitet:

fredred

Mitglied
1 Okt 2015
81
2
7
Die Belegung ist exakt die gleiche wie bei mir, Adresse ist anders bei mir eingestellt. In C wäre das schon längst erledigt. Dachte immer der Raspi ist doooooch so modern und einfach. Da habe ich wohl geirrt. Mist !!!!
Hallo achim,
hatte nicht die Absicht dich mit der Adressierung eines Busteilnehmers zu verwirren. Sollte nur ein Hinweis sein das die HW- Beschaltung zur SW passen muss. Mehr nicht. Schriebst ja dass es keine Probleme mit dem PCF8574 gibt. Somit die Lib mit gesendet um die Einheit zu erkennen(lcd_e = 128 ) wollte ich nicht extra erwähnen. War wohl richtig um nicht die Bascom _ Programmierung als sehr einfach und natürlich auch logisch, zu vermitteln, na ja mit „C wäre das schon längst erledigt“ .
Nun meine Bitte erkläre mal deine Erkenntnis. Musst nicht gleich in die Einzelheiten gehen, aber warum ASM – Anweisungen in C- einfacher seien sollten, nur weil es da viel mehr „Klammereien“ gibt?
Egal ob es eine „Himbeere“ oder ein 74100 oder 68000 System ist. Es sind nur Schalter……

Wort zum Abschluss:
Um in diesem kurzem Digitalzeitalter (0/1), in Saus und Braus zu leben, werden die Schalter im Moment und Reihenfolge so umgelegt, um die Menschheitswünsche zu erfüllen.
Nach meiner Meinung Blöd wie „C“ Einige Menschen bildet sich ein, die Natur/Wetter und somit Klima auf diesem Planeten und sogar das Universum so einzuklammern das es nur noch 1 = Str(Schön) Or 2 = Str(Wunderschön) ist.

Schaut doch endlich mal wieder in Header!

Dim Mensch As Bit

Dim Natur As Byte

Dim Wetter As String * (Universum)



PS. An alle die diesen Kommentar hier lesen.

Als alter und Schwerkranker Mann hatte und habe ich niemals beabsichtigt ein Forum oder eine Programmiersprache auf Qualität zu beurteilen. War immer nur auf diesem Gebiet ein Baubudenrülps, ist ja zu lesen wie ich noch so bin.

Wünsche alle hier und so wie es der Papst auch sagen würde.

Ein wunderschönes neues Jahr 2021+ 2 hoch 32 Jahre .



So:
sehr geerte Admins,
Macht es auch so wie es in anderen Foren möglich war. Löscht mich unwiderruflich als Mitglied. Hier hatte ich ja noch die Möglichkeit mich zu verabschieden.
Entdeuscht mich nicht

Vielen Dank
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Hallo Fredred,

irgendwie verstehe ich grad überhaupt nicht, worauf Du hinaus willst.
Probleme gibt's nicht beim AVR, sondern beim Raspberry, und da läuft weder Bascom drauf (denk ich), noch kannst Du ihn mit Bascom programmieren (Dein Code ist Copy&Paste aus der Bascom-IDE, um die Leerzeilen zu vermeiden mußt Du den Code in irgendeinen Texteditor zwischenkopieren; außerdem hättest Du geeignete Code-Tags verwenden können). Die Kent-Bibliothek bringt ihn nicht weiter.

Das ganze wird ja per Bit-Banging umgesetzt.
Ich war eigentlich davon ausgegangen, daß der Hardware-I²C der Himbeere genutzt wird.
Hier mal mein erster Google-Anlaufpunkt zu dem Thema...

Wie gesagt: Eine funktionierende Initialisierungssequenz ist vom AVR her bekannt. Also einfach genau dieselben Bytes durch den Raspberry ausgeben lassen (mit den entsprechenden write-Instruktionen), und das Resultat durch einen LA mit dem des AVR vergleichen.
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Da hast du voll kommen recht. Unter C laufen auf dem Atmega und Attiny die verschiedensten Programme. Manche sind einfach und andere sehr anspruchsvoll, z.B. das TFT Display und andere. Dein Tip mit dem Beitrag kenne ich und habe ihn durchgearbeitet. Habe gerade noch mal den PCF8574 getestet. Die Ansteuerung der LED klappt ohne Probleme. Auch das Auslesen und Einstellung der Adressen geht. Leider beziehen sich viel Beispiel zum Thema I2C am Raspi auf den PCF8574 oder MCP.. Zu den Displays mit dem Adapter habe ich nur ein Beispiel gefunden. Daher stammen auch meine Infos zur Einstellung am Raspi und die Programme. Da ja das Display am Bus mit C funktioniert und der eigentliche I2C Bus am Raspi einen PCF8574 ansteuert, geh ich da von aus das der Bus und das Modul funktioniert. Das Programm bringt keinerlei Fehlermeldung, ist als auch in Ordnung. Die Pausen (sleep) habe ich grosszügig verlängert, auch ohne Erfolg. Da bleibt für mich nur der Schluss, das ein Fehler in der LCDLIB vorliegt. Kann eigentlich auch nicht sein, da er ja bei den anderen funktioniert hat. Komisch, komisch .....
Ein Vergleich ist leider nur bedingt möglich, da die Unterschiede zu gross sind. Da bin ich mit meinem Latein erst mal am Ende.
achim
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Habe mal die Datei i2clib.py reingestellt. Dies funktioniert ohne Probleme

Python:
# i2c_lib
# Grunddatei für alle I2C Bus Programme

import smbus
from time import *

class i2c_device:
   def __init__(self, addr, port=1):
      self.addr = addr
      self.bus = smbus.SMBus(port)

# Write a single command
   def write_cmd(self, cmd):
      self.bus.write_byte(self.addr, cmd)
      sleep(0.001)#0.0001

# Write a command and argument
   def write_cmd_arg(self, cmd, data):
      self.bus.write_byte_data(self.addr, cmd, data)
      sleep(0.001)#0.0001

# Write a block of data
   def write_block_data(self, cmd, data):
      self.bus.write_block_data(self.addr, cmd, data)
      sleep(0.001)#0.0001

# Read a single byte
   def read(self):
      return self.bus.read_byte(self.addr)

# Read
   def read_data(self, cmd):
      return self.bus.read_byte_data(self.addr, cmd)

# Read a block of data
   def read_block_data(self, cmd):
      return self.bus.read_block_data(self.addr, cmd)

Dann fehlt noch die Datei für lcnlib.py. Mit dieser gibt es Probleme.

Python:
#lcddriver.py
#import sys
#sys.path.append("./lib")

import i2c_lib 
from time import *

# LCD Address
ADDRESS = 0x20
addr = 0x20
# commands
LCD_CLEARDISPLAY = 0x01
LCD_RETURNHOME = 0x02
LCD_ENTRYMODESET = 0x04
LCD_DISPLAYCONTROL = 0x08
LCD_CURSORSHIFT = 0x10
LCD_FUNCTIONSET = 0x20
LCD_SETCGRAMADDR = 0x40
LCD_SETDDRAMADDR = 0x80

# flags for display entry mode
LCD_ENTRYRIGHT = 0x00
LCD_ENTRYLEFT = 0x02
LCD_ENTRYSHIFTINCREMENT = 0x01
LCD_ENTRYSHIFTDECREMENT = 0x00

# flags for display on/off control
LCD_DISPLAYON = 0x04
LCD_DISPLAYOFF = 0x00
LCD_CURSORON = 0x02
LCD_CURSOROFF = 0x00
LCD_BLINKON = 0x01
LCD_BLINKOFF = 0x00

# flags for display/cursor shift
LCD_DISPLAYMOVE = 0x08
LCD_CURSORMOVE = 0x00
LCD_MOVERIGHT = 0x04
LCD_MOVELEFT = 0x00

# flags for function set
LCD_8BITMODE = 0x10
LCD_4BITMODE = 0x00
LCD_2LINE = 0x08
LCD_1LINE = 0x00
LCD_5x10DOTS = 0x04
LCD_5x8DOTS = 0x00

# flags for backlight control
LCD_BACKLIGHT = 0x08
LCD_NOBACKLIGHT = 0x00

En = 0b10000000 # Enable bit 0b0000 0100
Rw = 0b01000000 # Read/Write bit 0b0000 0010
Rs = 0b00100000 # Register select bit 0b0000 0001

class lcd:
   #initializes objects and lcd
   def __init__(self):
      self.lcd_device = i2c_lib.i2c_device(ADDRESS)
      sleep(0.1)  #zusatz
      self.lcd_write(0x03)
      self.lcd_write(0x03)
      self.lcd_write(0x03)
      self.lcd_write(0x02)

      self.lcd_write(LCD_FUNCTIONSET | LCD_2LINE | LCD_5x8DOTS | LCD_4BITMODE)
      self.lcd_write(LCD_DISPLAYCONTROL | LCD_DISPLAYON)   #LCD_DISPLAYON
      self.lcd_write(LCD_CLEARDISPLAY)
      self.lcd_write(LCD_ENTRYMODESET | LCD_ENTRYLEFT)
      sleep(0.2)

   # clocks EN to latch command
   def lcd_strobe(self, data):
      self.lcd_device.write_cmd(data | En | LCD_BACKLIGHT)
      sleep(.01)#0.0005
      self.lcd_device.write_cmd(((data & ~En) | LCD_BACKLIGHT))
      sleep(.01)#0.0001

   def lcd_write_four_bits(self, data):
      self.lcd_device.write_cmd(data | LCD_BACKLIGHT)
      self.lcd_strobe(data)

   # write a command to lcd
   def lcd_write(self, cmd, mode=0):
      self.lcd_write_four_bits(mode | (cmd & 0xF0))
      self.lcd_write_four_bits(mode | ((cmd << 4) & 0xF0))
      
   #turn on/off the lcd backlight
   def lcd_backlight(self, state):
      if state in ("on","On","ON"):
         self.lcd_device.write_cmd(LCD_BACKLIGHT)
      elif state in ("off","Off","OFF"):
         self.lcd_device.write_cmd(LCD_NOBACKLIGHT)
      else:
         print("Unknown State!")

   # put string function
   def lcd_display_string(self, string, line):
      if line == 1:
         self.lcd_write(0x00)  # 0x80
      if line == 2:
         self.lcd_write(0x40)  # 0xC0
      if line == 3:
         self.lcd_write(0x10)  # 0x94
      if line == 4:
         self.lcd_write(0x50)  # 0xD4

      for char in string:
         self.lcd_write(ord(char), Rs)

   # clear lcd and set to home
   def lcd_clear(self):
      self.lcd_write(LCD_CLEARDISPLAY)
      self.lcd_write(LCD_RETURNHOME)

Fehlt nur noch das eigentliche Programm zur Ausgabe der Zeichen:
Python:
# LCD Address
#addr = 0x20
#import smbus
import lcddriver

#import smbus  #zusatz
from time import *

# I2C-Bus Port (raspberry default = 1)
#I2C_PORT = 1  #zusatz



#from time import *
lcd = lcddriver.lcd()
sleep(0.1)
#lcd.lcd_backlight("on")
lcd.lcd_clear()
sleep(0.1)
lcd.lcd_display_string("Tutu-",1)
lcd.lcd_display_string("Zeile 2",2)
lcd.lcd_display_string("Zeile  3",3)
lcd.lcd_display_string("Zeile 4",4)

Hat da jemand eine Idee dazu?

achim

PS: Mal sehen ob die Anzeige von Python auch funktioniert
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Aus deiner angebenen Seite (netzmafia) gibt es auch ein Anleitung für ein LCD Display am I2C Bus mit dem Raspi. Habe diese Datein genomme^n und alles dazu installiert. Leider ohne Erfolg. ??????????????
 

fredred

Mitglied
1 Okt 2015
81
2
7
Hallo Achim,
Wollte eigentlich schweigen aber die Bemerkung „Habe gerade noch mal den PCF8574 getestet. Die Ansteuerung der LED klappt ohne Probleme. Auch das Auslesen und Einstellung der Adressen geht“ hat mich wieder veranlasst einen zum Besten zu geben. Bin mir sicher das du das Prinzip eines Bussystem kennst und das I²C Bus (TWI-Interface)
sehr träge ist und somit der langsamste Teilnehmer den Takt bestimmt (nicht verwechseln mit bereitstellen) Ja der Raspi ist schon ein schneller Bursche und nicht mehr vergleichbar mit den AVR. Das war auch der Grund warum ich diese nicht mag. Ich habe Zeit und wenig Geld.
So:
Kann in deinen Code nicht erkennen wie hoch der Bustakt eingestellt ist.
100kHz ist Standard bei 5V und 200pF Kapazität Pullup-Widerstande min 3mA. Na klar auch 400kHz Fast oder 3.4MHz High speed sind möglich aber nur wenn der Slave die Low-Phase bei Bedarf verlängern kann.
Somit mein Tipp, wie ich alter Kerl es mache, in jedem Projekt wo ich mit Bussysteme arbeite erstelle ich als erstes im Code eine Abfrage ob alle Teilnehmer sich melden. Somit schließe ich erstmal ein HW- Fehler aus. Erst dann füttere ich den Teilnehmer mit seinen Aufgaben. Hab es schon oft erlebt nur ein Print mehr im Code und der Master also Taktgeber ist aus dem Tritt gekommen. War meist kein Problem. Musste nur die Busaktionen an andere Stelle im Code einbinden( natürlich immer ein Problem je schneller das System ist und dann noch wie beim Raspi die Flankensteilheit mit ausgewertet wird).
Ist Keil für die Leistungsstärke. Wenn man diese benötigt sollte man auch wissen wo die Bremse ist. Ist doch nicht anders wie beim Auto. Naja alle diese Dinger haben keine Räder.
Nochmals meine Entschuldigung das ich AVR und Bascom erwähnt habe. Diese Kombination ist so einfach das sogar ich die Grundlagen in der Controllertechnik begriffen habe.

Die mich aus dieser Themenwelt kennen, wissen nun kommt noch was.

Hallo Lotdata C,
Ja. Ob Bascom- IDE direkt auf die“ Himmelbeere“ läuft habe ich nicht getestet(warum auch?) aber einige Bascom Libs als dll’s darauf genibbelt schon. Ist doch für meine alten Augen immer noch ersichtlich das Quickbasic- Instruktionen aus der Dos3.11 Version immer noch gewaltiger sind(hat wohl Bascom erkannt aber nicht erfunden). Meine installierte Variante lief fast so gut wie beim Atari 64 oder Z1013, nur etwas umständlicher und ohne App- Import. Ja der letzte Umstand war der Grund warum dieses Projekt keine Sau wollte.
Na klar der serielle Datenfluss war der Durchbruch, aber die viele Protokolle mit den wüsten CRS Prüfungen und Geschwindigkeitsabgleich der Impulse werden bald nur noch für wenige Profis und Wohlhabende von Vorteil sein. Der Rest sperrt sich selber aus.
Warum muss es ein Raspberry sein um so eine Idee umzusetzen. An den Kosten wohl kaum denn mit ein paar AVR in Parallelschaltung konnte ich immer unabhängig mit gleichem Endeffekt bleiben. Ich baute auch keine AVR- Controllermodule mehr selber. Die für ein paar Cent erhältlichen At „ aus da trüben“ fordern meist ein Bootloader für Flash. Na warum brauche ich den? War immer meine erst Aktion diesen Speicherbereich für meine Anwendungen zu nutzen. Es sei denn und gewollt ISP zu trennen.
Ist Vergleichbar mit Betriebssystem des Rasberry. Natürlich wer im Bereich der Controllertechnik, Wert auf hohe Geschwindigkeit legt oder Faul ist mitzudenken, muss sich unterordnen und sehr genau die Vorgaben der Vordenker umsetzen. War noch nie mein Ding.

Klinkt Blöd aber viele Erkenntnisse kamen mir erst nach dem letzen Schlaganfall.
Das menschliche Gehirn ist nicht die Basis um auf diesen Planeten die Herrschaft zu beanspruchen. Der Mensch ist doch so Blöd und muss sogar erstmal lernen wie er ein Schluck aus der Bulle bekommt und natürlich auch wie man dahin kommt ohne zu stürzen.
Na gut das Schreien könnte auch wie bei andere Lebewesen angeboren sein.
Finde es geil wie schell es mein Restgehirn geschafft hat wie man sich wieder wie vor ca. 65 Jahren das laufen und sogar schwimmen gelernt hat(das kacken und pinkeln am richtigem Ort war mein erster Wunsch) klappt schon sehr Gut.
Eine Forum Anfrage humorlos und nur mit akademischen Überlieferungen zu beantworten werde ich wohl nicht mehr lernen.
Ein Task rattert noch im Kopfram. Hoffe dass die Rübe nicht gleich übertaktet wird.
Frage:
Ist es nicht die Einbildung der Menschen aus der Historie gelernt zu haben. Das nur das Schnellste das Beste ist.

Mit freundlichen Grüßen und ein nicht noch schlimmeres Jahr wünsche ich alle hier für die Zukunft.
Fredred
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Hall Fredred
Danke für deine Worte. Mir geht es dabei eigentlich auch nicht um Geschwindigkeit sonder um eine Verbindung zum Internet. Dabei geht es mir unter anderem auch um eine Verbindung zu Smart Home. Es werden von ELV verschiedne Module angeboten um die verschiedenen Busse zu koppeln. Habe verschiedentlich gefragt was die Nachfolger von PIC und AVR sein könnten. Kam die die Antwort ARM. Klingt nicht schlecht. Leider ist kaum was zu finden für USB, I2S und Internet. Beim Raspi und Python sehen die Befehle sehr ähnlich in C aus. Dann kann ich meine ganze vorhanden Hardware nutzen. Gerade mit dem I2C Bus auf dem raspi scheint es wenig zu geben. Nennt sich zwar SM Bus gibt aber auch nicht mehr. Basic ist auch nicht so weit entfernt. Habe selber vor mehr als 20 Jahren damit gearbeitet. Lang ist her.
Beim PCF 8574 und den blinkenden LEDs geht es mir um das schreiben in Registern. Damit kann ich dann eine vielzahl verschiedner ICs ansprechen. Das mit den 100kHz hatte ich eingestellt. Das Display wird ja auch mit dem PCF betrieben. Licht schalten geht zwar aber leider nicht mehr. Die ganze Sache muss funktionieren. Der PCF mit LEDs geht, am Display nicht. Ist wahrscheinlich eine Frage der Einstellungen.
achim
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3,502
65
48
Marwitz
Sprachen
  1. BascomAVR
  2. Assembler
Ähm... der RaspberryPi IST ein ARM.

Um mal zum Thema zurückzukommen - wie ist das mit der Spannungsversorgung?
Beim AVR hast Du ja meistens 5V, und bei vielen Character-LCDs auch. Der Raspberry hingegen läuft mit 3V3. Der PCF scheint mit beidem klarzukommen...
 

achim S.

Mitglied
16 Jan 2010
652
9
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Hat aber mehrere Kerne und eine eingebaute Internetverbindung. Die brauche ich nicht selber programmieren (was ich nicht kann).
Der Raspi bekommt ca. 5.05V bei 8A aus dem Netzteil XL... und regelt runter auf 3,3V. Mein ganzes System wird mit 5,0 bzw 5.05V betrieben. Der Raspi wird mit Leitungen 1,5mm2 angeschlossen. Der Rest wird mit Bussteckern verbunden. Es gibt einen Pegelwandler von 3,3 auf 5V. Diesen verwende ich immer und funktioniert ohne Probleme. Die Buswiderstände sind auch dran und haben 4,7k. Habe jetzt 2 Module dran mit je PCF8574. Durch i2cdetect werden beide Adressen erkannt. Habe jetzt noch eine andere Datei ausprobiert, gleiches Ergebnis. Steh ziemlich auf dem Schlauch.
achim
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)