Hallo zusammen! Nachdem ich schon längere Zeit hier im Forum mitlese, kommt hier jetzt das erste Thema von mir. Vorgeschichte Wie im Titel erwähnt geht es um eine LED-Matrix. Genauer um eine Anzeigetafel von 1,40m x 1,40m Größe mit 128x128 LED's, davon sind vor kurzem zwei in meinen Besitz übergegangen. Eigentlich sind die auch voll funktionstüchtig, wurden aber früher (immerhin Baujahr '89) von einem Atari angesteuert. Das Problem ist, der Atari sowie sämtliche Dokumentationen oder Schaltpläne existieren nicht mehr. Aktueller Stand Nachdem ich alles einigermaßen "durchschaut" habe, (ich hab im Anhang noch ein Bild von der Rückseite ;-) ) bin ich zu dem Schluss gekommen, dass es wohl einfacher ist, etwas neues zu machen, als das alte Signal herauszufinden. Glücklicherweise besteht die Tafel aus 8 Segmenten mit jeweils 128x16LEDs und eigener Zeilen-/Spaltensteuerung sowie Stromversorgung. Schaltpläne und Funktion der Steuerung für die Zeilen und Spalten habe ich rekonstruiert und sind für Interessierte auch im Anhang zu finden! Mein Vorhaben Ich möchte jetzt mit einem Mikrocontroller, zum Beispiel dem Atmega16, die Steuerung der gesamten Tafel realisieren. Dazu sollen dann 2048Byte vom PC an den µc gesendet werden, in denen das komplette Bild für die Tafel steht. Der µc sollte das dann speichern und dann die jeweils ersten Zeilen der Module mit den Daten füllen, die erste Zeile für 500µs einschalten, dann das gleiche Spiel für die restlichen 15 Zeilen und das mit 100Hz. Mein Problem Auch wenn ihr mich bei dem Vorhaben eventuell steinigen wollt, ich habe noch nie mit einem Mikrocontroller gearbeitet! Allerdings habe ich mir gerade von Pollin das Eva-Board mit einem Atmega16 geholt und werde dann mit Tutorials für LED-Blinkschaltungen, Texten per Terminal etc anfangen und wenn ich soweit bin versuche ich zuerst eins der Module anzusteuern. Allerdings würde ich gerne wissen, ob der ATmega16 später auch leisten kann was ich möchte. Mit der vorhandenen Technik müsste das wie folgt aussehen: * erstes Byte der ersten Zeile an Ausgang A * eine 0 an vier Pins von Ausgang B * eine 1 an einen Pin, damit der Spaltentreiber das Byte übernimmt, dann wieder eine 0 -> also clock * zweites Byte der ersten Zeile an Ausgang A * eine 1 an vier Pins von Ausgang B * eine 1 an einen Pin, damit der Spaltentreiber das Byte übernimmt, dann wieder eine 0 .. das ganze 16mal für ein Modul, dann noch für die anderen Module, also 128mal diese 3 Punkte. Schafft der Mikrocontroller das in 125µs? Ich hab überschlagen, dass etwa soviel Zeit zum setzen der Spalten für das Multiplexing bleibt, wenn jede Zeile 100mal für 0,5ms eingeschaltet wird. Ich weiß nicht, wie dann noch Zeit bleiben soll, neue Daten zu empfangen... Sonst müsste in der Zeit die Anzeige dunkel bleiben, das wäre erstmal auch nicht so schlimm. Ausgänge bräuchte ich 26 oder 21, wenn ich noch ein Demultiplexer verwende. Könnt ihr mir sagen, ob das mit einem Atmega16 mit einfachen Mitteln möglich ist, oder ob das ein extrem aufwändiges Projekt ist? Ich hab zwar schon viel hier im Forum über LED-Matrix Schaltungen gelesen, aber auch über andere interessante Links oder sonstige Ideen bin ich immer dankbar! Und tut mir leid, dass das hier in einem Roman ausgeartet ist... Grüße vom "neuen", müs-lee
@ Sebastian R. (mues-lee) >Auch wenn ihr mich bei dem Vorhaben eventuell steinigen wollt, Warum? >ich habe >noch nie mit einem Mikrocontroller gearbeitet! Naja, jeder muss mal anfangen. > Allerdings habe ich mir >gerade von Pollin das Eva-Board mit einem Atmega16 geholt und werde dann >mit Tutorials für LED-Blinkschaltungen, Texten per Terminal etc anfangen >und wenn ich soweit bin versuche ich zuerst eins der Module anzusteuern. Schon mal guter Ansatz. >.. das ganze 16mal für ein Modul, dann noch für die anderen Module, also >128mal diese 3 Punkte. Schafft der Mikrocontroller das in 125µs? Ja. >Ich hab überschlagen, dass etwa soviel Zeit zum setzen der Spalten für >das Multiplexing bleibt, wenn jede Zeile 100mal für 0,5ms eingeschaltet >wird. Ich weiß nicht, wie dann noch Zeit bleiben soll, neue Daten zu >empfangen... Ein AVR mit 16 MHz hat mehr Power als du denkst. Ist vor allem eine Frage des richtigen Hardware- und Softwarekonzepts. > Sonst müsste in der Zeit die Anzeige dunkel bleiben, Nö. Lies was zum Thema LED-Matrix. >Könnt ihr mir sagen, ob das mit einem Atmega16 mit einfachen Mitteln >möglich ist, Ja. > oder ob das ein extrem aufwändiges Projekt ist? eher nicht, wenn gleich sportlich für einen Anfänger. MFG Falk
Hast Du noch mehr Fotos? Was für ein Atari war das?
@Falk: Danke für deine Antworten, das macht mir auf jeden Fall schonmal Mut, dass das was werden könnte! Zum Thema LED-Matrix, das habe ich zwar schon durchgelesen, allerdings dachte ich eher, dass der AVR einige ms braucht um 2kb zu empfangen und dass er in der Zeit dann vielleicht keine Daten an die Spalten schicken kann. Aber vermutlich unterschätze ich da die AVR's schon wieder oder kenne die technischen Möglichkeiten (noch) nicht. @matthiask: Ich hab hier im Anhang noch ein paar Fotos reingestellt, oder was interessiert dich davon speziell? Zum Atari kann ich dir nichts weiter sagen. Ich habe die Anzeige noch nie in Aktion erlebt und der Vorbesitzer konnte mir nur sagen, dass am Monitorausgang von einem Atari noch ein Konverter oder ähnliches angeschlossen wurde (den ich nicht zur Hand habe) und der dann zur Tafel ging.
@Sebastian R. (mues-lee) >dachte ich eher, dass der AVR einige ms braucht um 2kb zu empfangen und Die Anzeige/Multiplexen und das Empfangen neuer Daten erfolgt quasi parallel durch Nutzung von Interrupts und Multitasking. Ausserdem muss man na nicht immer ein komplett neues Bild übertragen, wenn sich nur ein paar Zeichen ändern. >kann. Aber vermutlich unterschätze ich da die AVR's schon wieder Ja. 128x128 einfarbige LEDs sind gerade mal 16384 Bit oder wie schon richtig bemerkt 2kByte. Die müssen mit 100 Hz ausgegeben werden, macht 200kB/s. Ist schon ganz ordentlich, aber machbar. MFG Falk
Sebastian R. schrieb: > @matthiask: Ich hab hier im Anhang noch ein paar Fotos reingestellt, > oder was interessiert dich davon speziell? Einfach nur das Interesse an solchen älteren Bauwerken. Mit einen 8 Bit Atari habe ich auch mal angefangen und das war eine tolle Zeit... Die Anzeige sieht schon in großen Teilen ganz ordentlich gemacht aus. Lässt sich bestimmt wieder zum leben erwecken. Viel Erfolg!
Intressantes Projekt. Aber ich würde zu nen größerem AVR raten, da der AtMega16 nur 1kb RAam hat. Ein AtMega 644 ist da pinkombatibel und hat 4kb RAM und ist somit besser geeignet die 2kb für die einzelnen LEDs im Speicher zu halten. Von der Geschwindigkeit her nehmen sich die beiden AVRs nichts MfG Turbotoni
Frank: Alles klar! Ich habe mir jetzt nochmal die beiden Seiten zu Interrupts und Multitasking durchgelesen; Technik, die begeistert! matthiask: Ordentlich gemacht sollte das auch aussehen, der Vorbesitzer hat mir nämlich den Neupreis verraten... Damals hat eine der verwendeten LED's 1DM gekostet. Wenn man das für zwei 128x128 Anzeigen zusammenrechnet und nochmal die Hälfte drauflegt, das ist schon ne stolze Summe! @tobi: Danke für den Tip, über sowas habe ich mir noch garkeine Gedanken gemacht. Klingt auf jeden Fall sinnvoll!
@ Sebastian R. (mues-lee) >Frank: Alles klar! Der hat hier noch nicht geschrieben. > Ich habe mir jetzt nochmal die beiden Seiten zu > Interrupts und Multitasking durchgelesen; Technik, die begeistert! Yo. >hat mir nämlich den Neupreis verraten... Damals hat eine der verwendeten >LED's 1DM gekostet. Wenn man das für zwei 128x128 Anzeigen >zusammenrechnet und nochmal die Hälfte drauflegt, das ist schon ne >stolze Summe! 32000 DM für so ne LED-Wand? Meine Herrn! MFg Falk
@Falk > Der hat hier noch nicht geschrieben. Autsch, mein Fehler.. > 32000 DM für so ne LED-Wand? Meine Herrn! Nicht ganz richtig, soviel haben nur die LED's gekostet. Wie gesagt da kommt nochmal gut die Hälfte drauf. ;-)
> ich habe noch nie mit einem Mikrocontroller gearbeitet! Dann sorg auf jeden Fall dafür, daß die LEDs nicht kaputtgehen, wenn sie mal nicht 1/16 der Zeit an sind, sondern eine Zeile dauernd an ist und sie den 16-fachen Strom bekommen. Reduziere also erst mal den Strom auf 1/16tel zu Ungunsten der Helligkeit, relevante Widerstandswerte ver16fachen. Dann schliesse den AVR an die gezeichneten Stecker der Platine an, sind 21 Pins (4 Zeilenselect, 8 Datenbits (alle 8 Platinen parallel), 4 Registerselect (alle 8 Platinen parallel) und 3 für 1/8 Platinerndecoder 74LS138, könnte man auch durch 8 Einzelleitungen machen also 26 gesamt), kein Problem. Der AVR schafft es locker, die 4kByte an das Display mit 100Hz zu übertragen, aber nur wenige AVR Modelle schaffen es, die 4k Byte in RAM zu speichern :-(( Wenn du also nicht alphanumerisch ansteuern möchtest (Character ROM und pro 8x14 Feld nur das Byte des Buchstabens speichern, braucht nur 288 Bytes) dann brauchst du einen AVR mit 8k Bytes RAM (2 Bilder, eines angezeigt, das andere wird gerade geladen). Nimm einen Renesas M16C :-)) da gibt es auch Eval Boards für, von Glyn, die haben genug RAM. Es wäre sogar möglich, dabei Graustufen anzuzeigen, aber dann braucht man 64kByte RAM, Programmierung ist dann zwangsweise in hochoptimiertem Assembler wo die innerste Schleife nur die Daten rausschiebt (sozusagen REP STOSB, das sagt dir nichts aber einigen anderen Lesern sagt es was) und alles andere vorher berechnet wurde. An einen AVR externes RAM dranzustricken und in Software zu bedienen wird übrigens zu langsam, das RAM sollte im Adressraum liegen. Die 8 Ringkerntrafos könnten es übrigens notwendig machen, sie sequentuell, der Reihe nach zeitlich getimt, einzuschalten, damit nicht die Haussicherung rausfliegt. Bei 3300 Watt reicht auch ein PC-Netzteil nicht mehr wirklich.
MaWin schrieb: > Dann sorg auf jeden Fall dafür, daß die LEDs nicht kaputtgehen, wenn sie > mal nicht 1/16 der Zeit an sind, sondern eine Zeile dauernd an ist und > sie den 16-fachen Strom bekommen. Das kam mir auch schon in den Sinn, deswegen wollte ich auch erstmal nur mit einem Modul mit 128x16 anfangen, weil extrem viel umlöten wollte ich nicht unbedingt. > Der AVR schafft es locker, die 4kByte an das Display mit 100Hz zu > übertragen, aber nur wenige AVR Modelle schaffen es, die 4k Byte in RAM > zu speichern :-(( Würde da nicht schon der Atmega644 reichen, den turbotoni empfohlen hat? Nach meiner Rechnung sind es ja nur 128x128/8->2kB. Und kann man mit dem Bild, das man gerade bekommt nicht auch direkt das alte im RAM überschreiben? Alphanumerische Ansteuerung wollte ich eigentlich nicht, da eventuell auch zwischendurch Grafiken angezeigt werden sollen. > Die 8 Ringkerntrafos könnten es übrigens notwendig machen, sie > sequentuell, der Reihe nach zeitlich getimt, einzuschalten, damit nicht > die Haussicherung rausfliegt. Bei 3300 Watt reicht auch ein PC-Netzteil > nicht mehr wirklich. Das stimmt, alle 8 zusammen töten die Sicherung gnadenlos. 4 und 4 gehen noch. Wäre auch hilfreich wenn irgendjemand weiß, wo man Trafoschaltrelais herbekommen kann?
Wo bekommt man solch tolle Dinger her? Will auch haben! Musst unbedingt Zeigen wenn das "Ding" läuft.
@ Sebastian R. (mues-lee) >Würde da nicht schon der Atmega644 reichen, den turbotoni empfohlen hat? Ja. Der Mawin hat sich vertan, es sind nur 2kB, nicht 4kB. >Bild, das man gerade bekommt nicht auch direkt das alte im RAM >überschreiben? Kann man, ist hier auch ausreichend. Ein Doppelpufferung ist reiner Luxus. MFG Falk
ich würde das größte nehmen, was es in DIP gibt: ATMEGA1284P. 128k Flash 16k SRam 4k EEPROM Gerade als Anfänger schreibt man nicht den optimalsten Code. und gerade sowviel Ram, wie Bildspeicher gebraucht wird ist zuwenig. Man sollte daran denken, dass eventuell auch vom Steuerrechner noch Eingaben gepuffert werden müssen, ganz zu schweigen von tatsächlichem Arbeitsspeicher. Außerdem würden hier auch noch ein paar Standalone-Programme reinpassen Der Preisunterschied ist auch nicht so groß
@Michael: Man muss nur im richtigen Moment bei eBay vorbeischauen. ;-) Und wenn das Teil läuft werd ich hier auf jeden Fall ein Bild reinstellen und schreiben, mit welchem AVR und welchem Code das dann letztendlich geklappt hat! @Falk und Vlad: Ah okay, dann wird der Atmega644 ja auch nicht ausreichen. Aber der Atmega1284P hat ja mehr als genügend RAM und dazu dann auch noch den großen Flashspeicher. Da könnte ich dann ja noch eine kurze Bildsequenz reinschreiben, die angezeigt wird, wenn man die Tafel einschaltet. Ich habe den 1284p jetzt bei Ebay für 7,95€ +2€ Versand gefunden, das ist ja tatsächlich noch recht günstig. Gibt es eigentlich sowas wie "den Shop" für Atmel µc's oder muss man einfach schauen, wo es den gewünschten gerade am günstigsten gibt? Ansonsten warte ich momentan nur darauf, dass meine Pollin Bestellung ankommt, damit ich meine ersten Versuche wagen kann. Angelesen habe ich mir dazu inzwischen schon eine Menge.
Sebastian R. schrieb: > Ich habe den 1284p jetzt bei Ebay für 7,95€ +2€ Versand gefunden, das > ist ja tatsächlich noch recht günstig. Aber hoffendlich nicht nur einen bestellt :-) Am besten gleich mehrere ATMegas bestellen, falls man bei den eigenen Bastelversuchen mal einen oder den anderen schrottet. Einen speziellen Shop gibt es nicht, man mus selber suchen, wo man die AVRs herbekommt.
Sebastian R. schrieb: > Ich habe den 1284p jetzt bei Ebay für 7,95€ +2€ Versand gefunden, das > ist ja tatsächlich noch recht günstig. > Gibt es eigentlich sowas wie "den Shop" für Atmel µc's oder muss man > einfach schauen, wo es den gewünschten gerade am günstigsten gibt? csd hat eine recht vernünftige Auswahl. Da kostet er auch 8€, man kann aber (wenn man sich durch den grottigen shop gekämpft hat - immer dran denken, der warenkorb hat eine äußerst kurze Halbwertszeit) den Rest an Elektronik mitbestellen. Turbo Toni schrieb: > Aber hoffendlich nicht nur einen bestellt :-) > > Am besten gleich mehrere ATMegas bestellen, falls man bei den eigenen > Bastelversuchen mal einen oder den anderen schrottet. > > Einen speziellen Shop gibt es nicht, man mus selber suchen, wo man die > AVRs herbekommt. man muss das ganze ja nicht gleich mit dem teuersten Controller probieren für die kleine Variante kann man das zuerst ja einen günstigeren nehmen.
> Nach meiner Rechnung sind es ja nur 128x128/8->2kB Du hast doch angeblich 2 Displays a 128 x 128, so komme ich auf 4k. Es kann natürlich sein, daß du jedem einen AVR spendieren willst, das weiss ich nicht. > Ja. Der Mawin hat sich vertan, es sind nur 2kB, nicht 4kB. Na klar Falk. Immerhin habe ich vor dem Schreiben nachgedacht. > Und kann man mit dem Bild, das man gerade bekommt nicht > auch direkt das alte im RAM überschreiben? Können schon, aber wenn wir mit 9600bd senden, dauert das 2 Sekunden bis das neue Bild steht, und alle Betrachter sehen das langsame umklappen der Bits. Find ich nicht professionell. Natürlich könnte man auch 115000bd haben... Rein softwaretechnisch kann der uC natürlich empfangen (UART Interrupt) und dennoch (Programmhauptschleife) simultan das Display mit 100Hz refreshen. > wo man Trafoschaltrelais herbekommen kann? Nimm normale Netzspannungsrelais. Meine Zeiten mit LED-Displays sind lange vorbei, es muß so die Zeit gewesen sein aus der dein Modell stammt, damals gab es noch keine AVR, aber die Mikros hatten jede Menge RAM weil es noch kleine Platinen mit RAM+ROM waren. Der 68HC11 hatte leider kein 8088 mässiges REP MOVSB, mit dem Z80 hatte man es dank OTIR einfacher.
@MaWin: Danke für deine ausführlichen Antworten! > Du hast doch angeblich 2 Displays a 128 x 128, > so komme ich auf 4k. > Es kann natürlich sein, daß du jedem einen AVR spendieren > willst, das weiss ich nicht. Sorry, da hättest du natürlich recht, ich glaub das habe ich noch nicht erwähnt. Ich wollte beide als einzelne Anzeigen benutzen und falls doch mal beide gebraucht werden, schickt die Software das über beide seriellen Ports raus! > Können schon, aber wenn wir mit 9600bd senden, > dauert das 2 Sekunden bis das neue Bild steht, > und alle Betrachter sehen das langsame umklappen > der Bits. Find ich nicht professionell. Natürlich > könnte man auch 115000bd haben... Das Problem ist ja nun auch behoben! Bei 16kb RAM sollte ein zweites Bild kein Problem sein. Spricht denn sonst etwas dagegen, eine Baudrate von 115000 oder noch höher zu verwenden? Mit einem passenden Quarz sollte das doch fehlerarm machbar sein oder? > Nimm normale Netzspannungsrelais. Ich dachte eher an die Schaltungen, die die Trafos erst vormagnetisieren und dann bei entsprechender Remanenz zum passenden Zeitpunkt einschalten. (http://de.wikipedia.org/wiki/Transformatorschaltrelais) Das wäre zwar die eleganteste Lösung, aber ich glaube, zwei Schalter tuns auch.
> Spricht denn sonst etwas dagegen, eine Baudrate > von 115000 oder noch höher zu verwenden Die Länge der Zuleitungskabel. > http://de.wikipedia.org/wiki/Transformatorschaltrelais) Überflüssig. Sicherungen haben nicht ohne Grund B und C Characteristik.
>Ausgänge bräuchte ich 26 oder 21, wenn ich noch ein Demultiplexer verwende. Ich würde das an das ExtIF der CPU hängen (nat. so'ne CPU auch auswählen), das geht am schnellsten. (Daran auch probl.los weiteres SRAM dran hängbar, kostet nur 1..2 Waits) Für 2kB werden dann 11 Adr-Ltgs benötigt. (Vielleicht ein paar mehr vorsehen, für Reserve, als 'Display-Bus'). Eine halbwegs schnelle MCU kann, evtl mit DMA, die 2kB in 40960ns rausschicken, und die CPU würde es nichtmal mitbekommen. (wären nur 0,4% von 10ms). Wenn man beim AVR je übertragenes Byte 4 Clks rechnet, wären es bei 20MHz auch nur ca 410 us, was (nur) ca 4,1% CPU-Auslastung wäre.
@MCUA: Danke für die Antwort, aber als Anfänger kann ich damit noch nicht so sehr viel anfangen.. Aber wenn man vom PC Daten direkt per DMA in den RAM speichern kann, wäre das natürlich nicht schlecht. Ich habe jetzt gerade meine ersten Versuche mit blinkenden LED's etc gemacht und habe anschließend noch ein 128x16 Feld zum Leuchten gebracht. Das hat auch gut funktioniert, jede Reihe war für 0,5ms eingeschaltet mit 100Hz. Jetzt mache ich erst einmal eine Woche Urlaub und nehme mir ein wenig Lektüre mit. Momentan bin ich zumindest ganz optimistisch, dass ich in absehbarer Zeit "sinnvolle" Dinge mit der Anzeigetafel anstellen kann. Eine Frage habe ich noch, ich habe bisher alles in Assembler gemacht, habe aber schon Erfahrung mit C#. Die Steuerung für die Tafel wollte ich auch in Assembler schreiben. Würdet ihr mir eher raten, dafür C zu verwenden?
Da dein AVR ziemlich am Limit läuft, solltest du das direkte Ansprechen der Tafel in Assembler machen. Aber schon für die nicht zeitkritischen Sachen kannst du auf C auweichen.
Nach längere Abwesenheit melde ich mich wieder zurück. Inzwischen habe ich alle nötige Hardware fertiggestellt, eine Platine für den ATmega1284P und zwei die jeweils als Anschlussplatine für die Spalten und Zeilentreiber dienen. Nach vielen Versuchen in Assembler und auch vielen Fehlschlägen habe ich es aber geschafft, ein Programm zu schreiben, dass zuerst ein vorgefertigtes Bild aus dem EEPROM in das SRAM überträgt und anschließend das Bild aus dem SRAM mit 100Hz anzeigt. Das funktioniert auch wunderbar, ein Foto davon und alle Schaltpläne + Assembler Code habe ich mit hochgeladen. (Fuse Bits: Low 0xFF, High 0xD7, Extended 0xFF) Jetzt wollte ich natürlich auch die Übertragung der Daten vom PC über Seriellen Port an die Tafel realisieren. Da ich die Anzeige am kommenden Samstag das erste mal einsetzen wollte, möchte ich das Ganze zuerst so machen, dass er am Ende von einem angezeigten Bild prüft, ob Daten am UART angekommen sind und wenn ja, direkt alle 2048 Byte in den SRAM schreibt und dann erst das Bild wieder anzeigt. Das die Anzeige solange dunkel bleibt, stört nicht weiter. Um das hinzubekommen habe ich das UART-Tutorial hier von µc-net angesehen und wollte zuerst ausprobieren, ob ich Zeichen senden kann und im Terminal dann empfange. Das hat dann doch etwas mehr Zeit als gedacht in Anspruch genommen, da die UART Status und Control Register nicht per in/out/cbi/sbi angesprochen werden können sondern nur per lds/sts. Zumindest hat AVR-Studio 4 das gesagt, im Datenblatt ist das Beispiel mit out Befehlen. Auch wenn AVR Studio das Programm dann Problemlos assembliert hat, bekomme ich am Seriellen Port immernoch keine Daten geliefert. Könnte jemand von euch kurz über den Quelltext von "UART-Test.asm" drübersehen und mir sagen, obs am Programm oder der Hardware liegt?
@ Sebastian R. (mues-lee) >Nach vielen Versuchen in Assembler und auch vielen Fehlschlägen habe ich >es aber geschafft, ein Programm zu schreiben, dass zuerst ein >vorgefertigtes Bild aus dem EEPROM in das SRAM überträgt und >anschließend das Bild aus dem SRAM mit 100Hz anzeigt. Das funktioniert >auch wunderbar, Herzlichen Glückwunsch! > ein Foto davon und alle Schaltpläne + Assembler Code Für den Anfang OK. Aber nach dem ersten Einsatz solltest du dich mal mit dem Thema Timer beschäftigen. Dann wird das deutlich besser und der Datenempfang per UART auch kein allzugroßes Problem. >in Anspruch genommen, da die UART Status und Control Register nicht per >in/out/cbi/sbi angesprochen werden können Das kommt auf den AVR-Typ an. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART MfG Falk
@Falk Brunner > Herzlichen Glückwunsch! Danke! > Für den Anfang OK. Aber nach dem ersten Einsatz solltest du dich mal mit > dem Thema Timer beschäftigen. Dann wird das deutlich besser und der > Datenempfang per UART auch kein allzugroßes Problem. Ja ich denke auch, dass da noch großer Optimierungsbedarf besteht. Die Timer wollte ich mir ansehen, sobald die Datenübertragung eines kompletten Bildes mit einfachen Mitteln funktioniert. Das Problem, dass ich keine Daten über die serielle Schnittstelle bekomme hat sich übrigens erledigt... Ich habe im AVR Studio beim Flashen nicht die Hex Datei von meinem UART-Test angegeben sondern noch das Anzeigeprogramm. Da ich die Stromversorgung für die LED's nicht an hatte und die ganzen letzten Tage immer nur auf "Program" drücken musste ist mir der Fehler tatsächlich nicht aufgefallen - ich denke aber, so etwas passiert einem nur ein Mal. ;-)
@ Sebastian R. (mues-lee) >Timer wollte ich mir ansehen, sobald die Datenübertragung eines >kompletten Bildes mit einfachen Mitteln funktioniert. Falscher Ansatz. Genau anders herum wird ein Schuh draus. Erst Timer, dann UART. Trust me! ;-) MFG Falk
Falk Brunner schrieb: > Falscher Ansatz. Genau anders herum wird ein Schuh draus. > Erst Timer, dann UART. Trust me! ;-) Okay, du hast definitiv mehr Ahnung von der Materie. Da werde ich dir mal lieber glauben und mich heute Abend erstmal mit Timern auseinandersetzen! Gruß, Basti
@Falk: Ich habe mich an deinen Rat gehalten und bis Donnerstag noch auf Timer umgebaut. Danke für den Hinweis, so kompliziert sind Timer dann ja auch wieder nicht! Das Programm habe ich mal im Anhang hochgeladen. Ich bin sehr zufrieden, am Samstag hat die Anzeige 8 Stunden ohne Probleme gearbeitet und etwa alle 10min ein neues Bild bekommen. Jetzt wollte ich nur noch einige Features schreiben, damit ich vom Rechner aus die Helligkeit ändern und ins EEPROM schreiben kann, aber das sollte kein Problem sein. Meine Überlegungen sind jetzt nur, welche Schnittstelle ich am besten wählen sollte. Momentan über Seriell muss ja immer ein Rechner in der Nähe stehen. Mein Favorit wäre per Netzwerk. Beide Tafeln könnten dann an einen WLAN Router angeschlossen und von einem entfernten Rechner separat oder zusammen angesteuert werden. Könnte ich dafür den NET-IO Bausatz von Pollin verwenden? Oder habt ihr Ideen für eine bessere Schnittstelle oder Umsetzung?
Sebastian R. schrieb: > Könnte ich dafür den NET-IO > Bausatz von Pollin verwenden? Ja defintiv. Sebastian R. schrieb: > Oder habt ihr Ideen für eine bessere > Schnittstelle oder Umsetzung? USB?
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.