Hallo AVR Anfänger sucht Know-How oder Schaltung wie man ein 2 Zeiliges Display ueber I2C Bus ansteuert. Meine Idee ist folgende: Für ein sehr hochwertiges Brettspiel möchte ich eine Count-Down-Uhr entwickeln. Bevor ich das mechanisch löse oder Rhasberry nutze, dachte ich an 8 Bit MC s. Nun möchte ich das Rad nicht neu erfinden. Hat schon jemand eine Schaltung , in der ein ATtiny über ein I2C Bus ein Display ansteuert? Danke für eure Hilfe
Vergiss den Tiny und nimm gleich mal einen Mega. Preislich ist der Unterschied irrelevant. Für I2C gibt es zb beim P.Fleury fertige I2C Funktionen. Der Rest ist dann Datenblatt des Displays lesen, wie es auf der Basis I2C angesteuert werden will. Um das erlernen der Grundlagen wirst du allerdings nicht herumkommen. So gesehen macht du gerade den 85-ten Schritt vor dem ersten.
Karl H. schrieb: > Vergiss den Tiny und nimm gleich mal einen Mega. Hi, TWI (I2C) kann beim ATtiny2313 im Bedarfsfalle über die USI-Schnittstelle konfiguriert werden. Die Adresse ist beim Portadapter mit PCF8574A zusammen mit dem ersten String mit 0x70 einzugeben. A0,A1,A2 auf GND verdrahtet. Nach jedem Stop muss vor dem Neustart die Slaveadresse neu eingegeben werden. Bei der LCD-Initialisierung hapert es aber noch, vor allem, da der Enable-Impuls nicht wie gewohnt durch einfaches Portbit-Setzen sondern anderweitig generiert werden muss, wofür ich (hoffentlich) bald eine passable Lösung gefunden habe. Bis bald ciao gustav
Karl B. schrieb: > Bei der LCD-Initialisierung hapert es aber noch, vor allem, da der > Enable-Impuls nicht wie gewohnt durch einfaches Portbit-Setzen sondern > anderweitig generiert werden muss, wofür ich (hoffentlich) bald eine > passable Lösung gefunden habe. OK, Lösung gefunden. Man kann auch durch den Ladebefehl die Ports maskieren. Für heute soll's das gewesen sein. Nur den entscheidende Codeschnipsel noch. Die LCDs haben auch noch verschiedene Adressen. der PCF8574 hat die hex 0x40 für das TWI-Interface. Morgen der auskommentierte Code für den ATtiny2313. Versprochen! enable: nop ori temp, 0b00000100 rcall twiout nop nop nop nop nop nop nop nop andi temp, 0b11111011 rcall twiout nop ret ciao gustav
Und fertig! ciao gustav P.S.: SCNR: Die momentan im Netz kursierenden Libs. (von SainSmart) haben mir leider nicht weitergeholfen. Dafür aber Beitrag "TWI-Master mit USI am ATtiny2313 (Assembler)" Danke!
:
Bearbeitet durch User
Ich denke mal, daß es Sebastian mit der P.Fleury-Lib vor 4 Jahren gelöst haben wird.
Peter D. schrieb: > Ich denke mal, daß es Sebastian mit der P.Fleury-Lib vor 4 Jahren gelöst > haben wird. Hi, so wie ich das sehe, ist in der besagten Lib. die Verwendung der USI-Schnittstelle nicht vorgesehen. Das war hier aber die eigentliche Aufgabenstellung. "...This I2c library is implemented as a compact assembler software implementation of the I2C protocol which runs on any AVR (i2cmaster.S) and as a TWI hardware interface for all AVR with built-in TWI hardware (twimaster.c)...." Geht nicht - gibt's nicht. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > so wie ich das sehe, ist in der besagten Lib. > die Verwendung der USI-Schnittstelle nicht vorgesehen. Weil das USI ne Krücke ist. Es taugt bestenfalls als I2C-Slave (Start-, Stop-Erkennung, Clock Stretching, externer Schiebetakt). Als I2C-Master bringt es keinen Nutzen. Hier mal ein einfacher I2C-Master mit Bit-Banging: Beitrag "Re: I2C Eeprom AT24C512 Lib für Pagewrite in C"
Sebastian G. schrieb: > Nun möchte ich das Rad nicht neu erfinden. > Hat schon jemand eine Schaltung , in der ein ATtiny über ein I2C Bus ein > Display ansteuert? Karl H. schrieb: > Der Rest ist > dann Datenblatt des Displays lesen, wie es auf der Basis I2C angesteuert > werden will. Hi, es sind also genau genommen zwei Fragestellungen. Einmal, wie die Kommunikation über das I2C-, alias TWI-"Protokoll" funktioniert und realisiert werden kann. - Ja, es gibt da nicht nur eine dogmatische Lösung. Zumindest für Minimalanforderungen mit gewissen Einschränkungen anzutesten, auf die auch auf Seite 142 ff des Manuals hingewiesen wird: "...The USI Two-wire mode does not incorporate slew rate limiting on outputs and input noise filtering..." Soll heißen, nur auf kürzeste Strecken störungsfrei und als Bustreiber für mehrere Master/Slaves ohne weiteres kaum zu empfehlen. Aber es ging hier in meinem Beispiel nur um die Ansteuermöglichkeit einer LC-Anzeige mit einem Master und einem Slave unter Verwendung eines Huckepack-Portadapters PCF8574. Und der andere Teil der Fragestellung besteht darin, wie die Ansteuerung eines LCD ohne die externe Zugänglichkeit der Steuereingänge RS, R/W, Enable nun softwaremäßig erfolgen kann. Die LCD-Initialisierung im Tutorial hier funktioniert da nämlich nicht. https://www.mikrocontroller.net/articles/AVR-Tutorial:_LCD Man kann nämlich nicht ein oder mehrere Portbits direkt setzen in I2C, weil ja kein Port in dem Sinne vorhanden ist, sondern nur zwei Leitungen. Die Steuerbits müssen demzufolge in die Steuerwort-Bytes integiert werden. Von daher muss die LCD-Routine angepasst werden. Für beide Fragestellungen gibt es hier eine Antwort: https://www.avrfreaks.net/forum/lcd-sainsmart2004-connecting-attiny2313-usi ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Die Steuerbits müssen demzufolge in die Steuerwort-Bytes integiert > werden. Wenn man die Hardwarezugriffe geschickt kapselt, ist es egal, ob man direkt auf IO-Pins schreibt oder auf virtuelle IO-Pins im SRAM und diese dann über I2C, SPI usw. ausgibt. Karl B. schrieb: > Von daher muss die LCD-Routine angepasst werden. Die Anpassungen sind minimal (3 I2C-Aufrufe in lcd_nibble):
1 | void lcd_i2c_out( void ); |
2 | |
3 | static uint8_t virtual_lcd_port; |
4 | |
5 | #define LCD_D4 SBIT( virtual_lcd_port, 0 )
|
6 | #define LCD_D5 SBIT( virtual_lcd_port, 4 )
|
7 | #define LCD_D6 SBIT( virtual_lcd_port, 3 )
|
8 | #define LCD_D7 SBIT( virtual_lcd_port, 5 )
|
9 | #define LCD_RS SBIT( virtual_lcd_port, 2 )
|
10 | #define LCD_E0 SBIT( virtual_lcd_port, 1 )
|
11 | |
12 | static void lcd_nibble( uint8_t d ) |
13 | {
|
14 | LCD_D7 = 0; if( d & 1<<7 ) LCD_D7 = 1; |
15 | LCD_D6 = 0; if( d & 1<<6 ) LCD_D6 = 1; |
16 | LCD_D5 = 0; if( d & 1<<5 ) LCD_D5 = 1; |
17 | LCD_D4 = 0; if( d & 1<<4 ) LCD_D4 = 1; |
18 | lcd_i2c_out(); |
19 | LCD_E0 = 1; |
20 | lcd_i2c_out(); |
21 | _delay_us( 1 ); // 1us |
22 | LCD_E0 = 0; |
23 | lcd_i2c_out(); |
24 | }
|
Das Setzen der Pindirection in "lcd_init" fällt natürlich weg. Hier noch die LCD-Lib dazu: https://www.avrfreaks.net/forum/tutc-lcd-tutorial-1001
:
Bearbeitet durch User
Karl B. schrieb: > "...The USI Two-wire mode does not incorporate slew rate limiting on > outputs and input noise filtering..." Als Bit-Banging I2C-Master braucht man kein "input noise filtering" und das "slew rate limiting" geht gut mit 47..100R in Reihe.
Hi @P. Danke für Update! Karl B. schrieb: > Bei der LCD-Initialisierung hapert es aber noch, vor allem, da der > Enable-Impuls nicht wie gewohnt durch einfaches Portbit-Setzen sondern > anderweitig generiert werden muss, wofür ich (hoffentlich) bald eine > passable Lösung gefunden habe. ciao gustav
Peter D. schrieb: > Weil das USI ne Krücke ist. Ähem, ja. Leider ist das so. Ein wenig mehr Eigenintelligenz hätte dieser Baugruppe sicher nicht geschadet und hätte sie tatsächlich zu dem machen können, was der doch etwas hochtrabende Name verspricht... > Es taugt bestenfalls als I2C-Slave (Start-, > Stop-Erkennung, Clock Stretching, externer Schiebetakt). > Als I2C-Master bringt es keinen Nutzen. So weit würde ich dann allerdings doch nicht gehen. > Hier mal ein einfacher I2C-Master mit Bit-Banging: Bit-Banging hat halt den Nachteil, dass man ohne komplizierte Code-Schachtelung kein Möglichkeit hat, Code quasi-parallel laufen zu lassen. Dazu kommt, dass I2C mit so geringen Frequenzen läuft, bei denen es schon ziemlich wenig weh' tun kann, das System für eine komplette Byte-Zeit praktisch stumm und taub für alles andere zu machen. Bei SPI ist das weniger kritisch, das kann man mit erheblich höheren Taktraten betreiben, so dass die "Auszeiten" für's Bitbanging weitaus weniger störend sind. Es kommt halt auf's Gesamtwerk an, ob diese Auszeiten den Unterschied zwischen "geht" und "geht nicht" ausmachen. Sprich: man muss das von Fall zu Fall jedes mal neu analysieren. Nach meiner Erfahrung ist aber sehr oft das USI das ultimative Mittel, eine Sache zum Laufen zu bringen, die sonst auf Tinys einfach nicht laufen kann oder zumindest nur mit sehr hohem Programmieraufwand. Also mit "geschachteltem" Code, d.h.: man muß in die ungenutzten Takte des Bitbanging Code einer Routine einstreuen, die mit der Bitbanging-Ausgabe eigentlich rein garnix zu schaffen hat. Das ist zwar durchaus machbar, aber sehr fehlerträchtig und ganz sicher völlig unportabel. Wenn man sowas durch den Einsatz des USI vermeiden kann, wird man es natürlich tun.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.