Guten Abend,
Ich versuche seit längerem eine Led Matrix mit einem atmega32
anzusteuern, jedoch es hapert am programmieren.
Schaltplan:
http://www.ledstyles.de/index.php?page=Attachment&attachmentID=17002&h=a5ab3ea0cabba39a9bd960d806134c0558f194c0
PA 3,4,5 sind auch belegt sowie PD 3,4,5
Schaltung funktioniert und es klappt schon jede einzelne Led in Bascom
anzusteuern.
Code:
$regfile "m32def.dat" ' ATmega32
Config Portd = Output
Config Porta = Output
Do
Portd = 1 : Porta = &B00011001 : Waitms 1
Portd = 2 : Porta = &B00111111 : Waitms 1
Portd = 4 : Porta = &B00111111 : Waitms 1
Portd = 8 : Porta = &B00111111 : Waitms 1
Portd = 16 : Porta = &B01111111 : Waitms 1
Portd = 32 : Porta = &B01111111 : Waitms 1
Portd = 64 : Porta = &B01111111 : Waitms 1
Loop
Nun gut dies ist nicht wirklich eine gute Programmierung.
Wisst Ihr eine Lösung in Assembler oder Bascom? z.B. mit Bilddaten
Mfg Ben
Der Schlüssel zum Erfolg liegt in einer Interrupt Service Routine, die
zb jede Millisekunde aufgerufen wird.
Beim ersten Aufruf gibst du die Daten für die erste Spalte aus und
schaltest die erste Spalte ein.
Beim zweiten Aufruf wird die erste Spalte wieder ausgeschaltet (sie hat
die ganze Zeit gebrannt), die Daten für die 2. Spalte ausgegeben und die
2.te Spalte eingeschaltet.
Beim 3. Aufruf wird dann völlig analog, die 2.te Spalte ausgeschaltet,
die Daten für die 3te Spalte ausgegeben und die 3. Spalte eingeschaltet.
So geht das immer reihum. Bei jedem ISR AUfruf wird die aktuell gerade
leuchtende Spalte ausgeschaltet, die Daten für die nächste Spalte
ausgegeben und die Spalte eingeschaltet. Ist man bei der letzten Spalte
angelangt, dann beginnt alles wieder bei der ersten Spalte.
Die LED selber leuchten immer von einem ISR Aufruf bis sie dann im
nächsten ISR Aufruf wieder abgeschaltet werden.
Als Auslöser für die ISR Aufrufe eignet sich zb ein Timer, der die ISR
alle 1 Millisekunden aufruft.
Ja aber wäre es nicht Sinnvoll, ein Multiplex zu programmieren, sodass
ich nur Bilddaten eingeben muss und diese dann automatisch ausgegeben
werden?
Zurzeit flackert es ganz schön viel und das Bild wird ja auch nicht
lange angezeigt, gibt es denn programmier-Alternativen
Ben Hil schrieb:> Ja aber wäre es nicht Sinnvoll, ein Multiplex zu programmieren, sodass> ich nur Bilddaten eingeben muss und diese dann automatisch ausgegeben> werden?
Das was ich dir beschrieben habe, IST ein Multiplex.
> Zurzeit flackert es ganz schön viel und das Bild wird ja auch> nicht lange angezeigt, gibt es denn programmier-Alternativen
Lerne Programmieren. Und zwar von der Pike auf.
Mehr kann man dazu nicht sagen.
Morgen,
wenn ich mich da ein mischen darf^^ Ich würde für C tendieren.
Wenn du aber Pics programmieren willst dann is assembler auch ganz gut
(das solltest du zumidnest mal gemacht haben mit assembler, da dies
viele Grundlagen gibt zum versätndnis eines µC )
gruss
Ein Rat
Fang deine ersten Schritte in C auf dem PC an.
Auch für den PC gibt es freie Entwicklungsumgebungen UND du kannst jedes
C-Lehrbuch benutzen.
µC haben ihre Besonderheiten, die du in einem C Buch nicht finden wirst.
Dort geht es in erster Linie um C. Und genau da solltest du anfangen:
Dir ein gewisses Grundverständnis für C anzueignen. Wenn du das hast,
ist es deutlich einfacher auf einen µC überzuwechseln, weil du dann
auseinanderhalten kannst was ein C Problem ist und was ein Problem des
Anwendens von C auf dem µC ist.
Kernighan&Ritchie Programmieren in C
ist immer noch der Klassiker aller C-Bücher. Aber es gibt natürlich auch
andere.
naja also erstma grundsätzlich NEIN, weil es ist C! So lernst du die
Befehele, wie man z.B. ne Schleife macht und die Strukturierung eines
Programmes lernt man. Wenn du das dann erst einmal drauf hast, dann ist
das programmieren auf nen µC garnet mehr so schwer kommen paar neue
Befehle dazu ( das man Ports als Asugänge def. usw. )
Mfg
Ben Hil schrieb:> Also C bewehrt sich letztendlich.> Aber ist der Unterschied groß von c am pc und c am Microcontroler ?
Der Hauptunterschied besteht darin, dass du
* eine funktionierende Ein/Ausgabe einfach so zur Verfügung hast.
du schreibst printf und die Ausgabe landet im Terminalfenster
du schreibst scanf und die Eingabe von der Tastatur landet
in den Variablen im Programm.
Und alleine das ist ein nicht zu unterschätzender Vorteil bei deinen
ersten Schritten.
Auf einem µC musst du dir deine Ein/Ausgabe erst mal selber machen.
Und alleine das kann schon zu einem Abenteuer ausarten.
* du hast einen guten Debugger zur Verfügung, mit dem du deinem
Programm auf die Finger schauen kannst, während es läuft.
Für AVR gibt es zwar auch Simulatoren, die einen µC simulieren
aber wie sich herausstellt, sind die auch schon mal fehlerhaft.
* Die Datentypen sind so, dass du erst mal weniger Probleme mit
Overflows und dergleichen hast
* Die Beispiele in den Büchern kannst du 1:1 übernehmen und sie werden
laufen und funktionieren. C-Buch Beispiele sind auf einen µC nur
selten 1:1 übertragbar. Wenn man weiß was man tut, ist das kein
Problem, es sind immer wieder dieselben Anpassungen. Aber welcher
Anfänger weiß schon was er tut?
Alles in allem, ist die Situation in etwa die, wie wenn du mit einem
Handbuch für einen Golf I einen VW Passat unter die Motorhaube gehen
willst. Natürlich ist das Prinzip überall das gleiche und das was du im
Golf Handbuch liest findet sich auch im Passat Motorraum irgendwo
wieder. Aber so richtig ideal ist es nicht.
