Ein paar Anfängerfragen zum ATmega64

[blackfield]

Ich hab mich nun auch in die Welt der µC begeben.

Dazu hät ich ein paar Fragen. Eine Menge wurde schon durch das sehr gute Wiki beantwortet aber leider nicht alle.

Ich habe vor einen Midi-Controller zu bauen. Das ganze sollte über einen ATmega64 laufen.

Kann ich problemlos Fader und Potis abfragen? (Müsste ja eigentlich gehn)

Wieviele Eingänge und Ausgänge hab ich insgesamt? DAs mit den 52 IOs (oder waren es 53?) hab ich noch nicht ganz verstanden.

Wie siehts mit einem LCD Display aus? Das es geht weiß ich aber wie siehts mit der Anzahl der Ausgänge die ich dafür brauch aus?

Wäre es möglich mehrere Controller zu kaskadieren?

Zu guter letzt: Ich hab das allbekannte Pollinboard (wird grad zusammengelötet)

Gruß Kevin

[Hubert.G]

Du hast 8 analoge Eingänge zur Verfügung
Der Chip hat 64 Pin, davon haben 11 eine feste Verwendung, der Rest sind I/O
LCD sollte kein Problem sein, ausser programmiertechnisch. Für ein Standarddisplay HD44780 brauchst du 7 I/O .
Kaskadieren ist möglich, wieder nur eine programmiertechnische Angelegenheit.
Das Pollinboard ist zum starten sehr gut, ein USB-Programmer wäre dazu noch empfehlenswert. Z.B.
http://wiki.ullihome.de/index.php/Hauptseite#USB_AVR-Lab
Für die ersten Versuchen einen ATmega8, 88, oder 16 verwenden.

[blackfield]

Vielen Dank für die Hilfe. Das heißt ich kann die anderen Pins sowohl als Eingänge als auch asl Ausgänge verwenden?

Haben die ATmega einen speziellen Bus um sie zu kaskadieren oder muss ich das über die I/Os machen?

Werde deinem Rat folgen und erstmal mit einem kleinen Controller anfangen. Kosten ja nicht die Welt. Ich denk dann ist es auch mit dem kaskadieren leichter.

[Richard]

Vielen Dank für die Hilfe. Das heißt ich kann die anderen Pins sowohl als Eingänge als auch asl Ausgänge verwenden?

Haben die ATmega einen speziellen Bus um sie zu kaskadieren oder muss ich das über die I/Os machen?

Lese Dir einmal im RN Wissen Bereich und im I-Net wikis zum I²C BUS durch. Das ist ein 3 Draht BUS mit dem bis zu 128 verschiedene Geräte verbunden werden können. Auch LCD Dispays für I²C kann man kaufen, was es da alles gibt? Sollte aber Im Netz zu finden sein.

AVR Controller haben fast alle oder sogar alle einen I²C Bus, man kann also jede Menge Pin's einsparen / b.z.w. erweitern.

Gruß Richard


Werde deinem Rat folgen und erstmal mit einem kleinen Controller anfangen. Kosten ja nicht die Welt. Ich denk dann ist es auch mit dem kaskadieren leichter.

[Hubert.G]

Das Wort kaskadieren müsste man etwas genauer definieren.
Mehrere ATmega hintereinander schalten, der erste steuert die I/O der anderen, geht zwar, ist aber nicht so einfach. Es arbeitet jeder eigenständig, aber einer schafft an was geschehen soll.
Beginne mal mit einem kleineren und versuche diese zusammen zu schalten.

[blackfield]

Ja ich dachte das ich einen extra ATmega für die Status LEDs und das LCD hernehm und den anderen die Hauptarbeit übernehmen lass.

Ich brauch eigentlich neben den ATmega Meldungen nur ein paar anzeigen wie z.B. aktiver Blackout oder Frezze.

[Besserwessi]

Den Wesentlichen Vorteil den mit einem kleineren µC wie Mega8 oder Mega16 hat,ist weniger der etwas geringere Preis, sondern vor allem das es die auch im DIP Gehäuse fürs Steckbrett oder Sockel gibt. Für die ersten Versuche ist es halt beruhigend wenn man ggf. den µC leicht auswechseln kann - was nicht heißt, dass die oft kaput gehen müssen. Ich hab z.B. noch keinen zerstört, nur einen angeschlagen mit 8 V als Versorgung, der geht nach dem Abkühlen auch noch.

MIt den 53 IO Pins des Mega64 kann man schon recht viel anfangen. Bei LEDs und Tastern kann man ggf. über eine Matrixschaltung auch mit wenigen (z.B. 8) Pin mehr (z.B. 16) LEDs ansteuern.

[blackfield]

Das ist ein weiterer Grund dafür ATmegas zu verwenden. Kein SMD gefummel.

EDIT: Hab mir jetzt mal das I2C Kapitel zu gemüte geführt.

Versteh ich das richtig das ich über einen simplen Bus z.B. den Haupt-µC mit einem zweiten µC verbinde der sich dann lediglich um die LCD-Steuerung kümmert? Bzw das es Displays gibt die einen eingebauten Controller für den I2C Bus haben?

Entschuldigt wenn ich etwas langsam bin aber nach 48 Stunden auf den Beinen bei einem Konzert Auf- und Abbau kanns schonmal hart werden ;)

[TheDarkRose]

Ja, dass hast du richtig verstanden. Und ja es gibt auch Displays mit I2C Schnittstelle

Yeah Konzert auf und abbau ;P

[Richard]

Das ist ein weiterer Grund dafür ATmegas zu verwenden. Kein SMD gefummel.

EDIT: Hab mir jetzt mal das I2C Kapitel zu gemüte geführt.

Versteh ich das richtig das ich über einen simplen Bus z.B. den Haupt-µC mit einem zweiten µC verbinde der sich dann lediglich um die LCD-Steuerung kümmert? Bzw das es Displays gibt die einen eingebauten Controller für den I2C Bus haben?



Ja genau, aber vergesse doch bitte mehrere Prozessoren zu koppeln, das ist nicht oder nur in extremen fällen nötig. So ein Prozessor ist dermaßen schnell, der steuert auch 8 0der mehr Motore Entfernungs Sensoren, Wärme Sensoren, mehrere I²C BUSSE und und und und (quasi) gleichzeitig.

In Deinem PC ist auch nur ein Prozessor undwas kann der alles (quqsi) gleichzeitig, auf meinem PC läuft im Momen Linux, Windofs, Fernsehen, Firefox, RN Netz, Mail.....alles "Gleichzeitig":-) OK, etwas schneller als ein AVR ist der schon....

Gruß Richard


Gruß Richard

[blackfield]

Ich brauch halt eine Menge Eingänge. Hab im Wiki was über einen Portexpander gelesen allerdings werden da nur Ausgänge erweitert. Naja erstmal in BASCOM einlesen, so schwer scheint es ja nicht zu sein.

[Besserwessi]

Die Portexpander kann man so ähnlich auch für Eingänge machen. Wenn es um viele Taster geht, kann man die auch als Matrix abfragen.

Mit einem so großen Projekt würde ich nicht anfangen. Lieber erstmal was kleines, damit man auch Erfolge sieht. Dann kann man auch besser abschätzen was alles geht und weiss schon mal wie 1 Taster geht.

[Richard]

Ich brauch halt eine Menge Eingänge. Hab im Wiki was über einen Portexpander gelesen allerdings werden da nur Ausgänge erweitert. Naja erstmal in BASCOM einlesen, so schwer scheint es ja nicht zu sein.

Die I²C Pordexpander können wie jeder Port lesen und schreiben die haben eine 7 Bit Adress (darum auch nur 128 Geräte) das 1.Bit wird zum Lesen/schreiben verwendet. Gerade Adressen "schreiben" ungerade Adressen "lesen".

Dann gibt es auch noch Analog Multiplexer http://en.wikipedia.org/wiki/Multiplexer oder Schieberegister oder http://www.edv-techniker.de/klProjekt/ProjektDoku/Tastaturmatrix.htm u.s.w.

I²C kann allerdings keine lange BUS Leitungen treiben, das ist für Längen auf einer Platine gedacht......

Gruß Richard

[wkrug]

Diese Portexpander kann man auch über Schieberegister realisieren.
Wir haben bei unserem derzeigiten Projekt ( Klimaanlagensteuerung ) einen ATMEGA 64 verbaut.
Als Schieberegister haben wir da drei 74HC165 ( parallel in , seriell out ) verwendet, um damit 24Taster einzulesen.
Die Kaskade wäre allerdings noch beliebig erweiterbar.
Das Ganze braucht 3 Ports des Controllers ( S-DATA, !EN, Clock ).
Wenn man mag kann man auch noch den INH Pin auf den Controller legen.
Der ATMEGA 64 - und auch andere AVR Controller - haben einen sog. SPI Bus in Hardware realisiert.
Mit diesem Bus kannst Du die Schieberegister, die bei uns in Reihe geschaltet sind wunderbar einlesen.
SPI Bus starten ( Library im Compiler ), 8 Bits aus dem SPI Datenregister abholen. Nächsten Block starten - Einlesen usw.

Es gibt auch Schieberegister mit Seriell in Parallel out, die man auch über SPI ansteuern kann um damit z.B. Leuchdioden zu treiben.

Man kann natürlich so eine SPI auch recht einfach in Software realisieren und somit mehrere Busse realisieren.

Ich würde an deiner Stelle die Hardware SPI für die Tastenabfrage verwenden und eine Software SPI für die Leuchtdioden Ausgabe verwenden. Ein weiterer Tipp von mir wäre Low Current LED's mit 2mA zu verwenden - die kann fast jeder Chip noch direkt treiben.
Die Tastenabfrage starte ich in unserer Anwendung alle 20ms und löse nur eine Aktion aus, wenn sich zum vorherigen Tastenbild was geändert hat. Damit ist dann auch gleich eine Tastenentprellung realisiert.
Die LED - SPI brauchst Du ja nur anzustoßen, wenn sich da was ändert.
Zur Sicherheit kann man aber auch alle 0,5...1 sek das aktuelle LED Bild senden.

I²C verwende ich persönlich nicht so gerne, weil man sich da relativ tief in die Materie einarbeiten muß um die richtigen Steuersequenzen, in der richtigen Reihenfolge zu generieren.
Von der Portanzahl her gibts aber kaum was sparsameres ( 2 Ports [ SDA, SCL ] ). Ein I²C Bus ist auch bei sehr vielen AVR Controllern in Hardware auf dem Chip und heisst dort TWI ( Two Wire Interface ) - Wohl aus lizenzrechlichen Gründen.

Um auch etwas höhere Lasten treiben zu können SSR- Relais oder kleine Motoren, verwende ich gerne ULN 2803.

Wenn Du uns sagst, welche Hardware mit welcher Anzahl Du verwenden willst, könnten wir Dir helfen einen passenden Controller zu finden.

Für mein neuestes Projekt ( MiDi Merger ) hab ich einen ATMEGA 1280 geplant, weil dieser 4 Hardware USART's hat, die ich als MiDi Eingänge verwenden will. Der ATMEGA 64 hat 2 USARTS - falls das interessiert.

Als LCD Display nehm ich gerne die 2x16 Zeichen Dotmatrix Displays von Pollin ( Best.Nr. 120 421 ), weil günstig und "schön" in Blau.
So ein Display braucht einen kompletten Port mit 7 bis 8 Leitungen.
Diese Dotmatrix Displays gibts bis 4*40 Zeichen, die dann aber schon recht teuer werden. Die meisten Compiler haben schon eine fertige Lib für diese Displays dabei.

Wenn Du dein Teil in ein 1HE 19" Gehäuse verfrachten willst, kannst Du z.B. auch ein LCD 204SW DIP von Reichelt nehmen, das aber dann schon mehr kostet.

Eine weitere Alternative wären auch noch rein grafische Displays wie das 120 424 von Pollin, die aber mehr Ports und mehr Rechenleistung vom Controller verlangen, da ja jedes einzelne Pixel des 128x64 Displays angesteuert werden muß.
Für die wirst Du Dir aber eine Library aus dem Internet holen müssen. Ausserdem wird hierbei meistens eine Zeichentabelle benötigt, in der die Form, Aussehen und Größe der Buchstaben und Zahlen festgelegt wird.
Ein einfaches Startbild benötigt da schon mal 1kB.

Nun hast Du ja wieder mal was zu Lesen und zu Recherchieren. ;)

[hardware.bas]

Dann wäre sicher auch der 40polige Atmega32 eine Alternative.
Reichlich Ports und kein SMD-Gefummele. VG Micha

[blackfield]

An allererste Stelle muss ich mal meinen Dank aussprechen!
Das war wirklich reichlich Input.

Um mal vorab zu nennen was ich umgefähr brauch:

Etwa 70 Taster. Davon gehn vier für ein Steuercross drauf, der Rest triggert diverse Funktionen.

Dazu kämen noch 5 Fader.

Das ganze soll als MIDI-Signal ausgegeben und an ein Programm namens Freestyler übertragen werden. Freestyler rechnet das ganze dann in ein DMX Signal um und sendet es an die Geräte.

Das Display soll vorallem als Feedback für den Controller dienen und einige wichtige Meldungen ausgeben. Als Beispiel wäre hier BlackOut oder FullON zu nennen. Weitere Funktionen aus Freestyler auszulesen wäre zwar möglich aber vorerst noch nicht geplant.

Als Gehäuse wird ein altes Behringer Eurodesk UB1832 Mischpult dienen(408x368mm). Da sollte genug Platz sein. Das Pult hat einen Elektronikschaden. Evtl kann ich ein paar Teile wiederverwenden wie z.B. die Fader, ein paar Potis und das Netzteil.

Eine nette Funktion wäre eine per Poti dimmbare Pultbeleuchtung. Wenn das über den Controller ginge wärs fein wenn nicht auch egal. Hierzu muss ich sagen das die Spezifikationen dieser Lampen (XLR-Anschluss, Spannung) halbwegs einheitlich sind.

Was fast schon ein muss ist, wär die Belegung der Tasten und das ausgegeben Midisignal ändern zu könnnen da ich je nach Location ein anderes Setup hab. Geht zwar über Freestyler ist da aber ein ziehmlich umständliches Geschäft

Ich würde gern einen Controller verwenden den ich mit dem Pollinboard flashen kann. Wenns dann wirklich nicht geht hab ich halt pech gehabt!

Als nächste Stufe wäre es das MIDI signal in USB zu wandeln sodass der PC ein MIDI Interface erkennt. Da werd ich vermutlich einen 5 Euro USB Midi Wandler hernehmen ist wahrscheinlich einfacher und billiger.

Erweiterbarkeit sollte dank MIDI-Protokoll auch kein Problem sein da man ein MIDI Signal theoretisch mergen kann. Probleme macht hier meistens die Midiclock.

[wkrug]

Etwa 70 Taster. Davon gehn vier für ein Steuercross drauf, der Rest triggert diverse Funktionen.
Bei so vielen Tastern würde sich eine Matrixansteuerung anbieten.
Also die Taster in Reihen und Spalten anordnen ( Schaltungstechnisch ) und die dann Abfragen.
Das dürfte Dich etwa 12Ports kosten.
4 für die Spaltenansteuerung und 8 als Feedbackleitung direkt zum Controller.
Die Schieberegister wären aber immer noch eine Option und würden die Möglichkeit eröffnen die Tastaturplatinen zu Blöcken mit jeweils 8 Tasten und einem Schieberegister aufzuteilen. Das wären dann 9 gleiche Platinen.


Dazu kämen noch 5 Fader.
Der ATMEGA 32 hat 8 A/D Wandler - geht also.


Das ganze soll als MIDI-Signal ausgegeben und an ein Programm namens Freestyler übertragen werden. Freestyler rechnet das ganze dann in ein DMX Signal um und sendet es an die Geräte.
Ich hab mir Free Styler auch mal kurz angeschaut, bin aber dann doch bei DMX Control hängen geblieben. Ob das so eine MiDi Funktion unterstützt kann ich leider nicht sagen.


Das Display soll vorallem als Feedback für den Controller dienen und einige wichtige Meldungen ausgeben. Als Beispiel wäre hier BlackOut oder FullON zu nennen. Weitere Funktionen aus Freestyler auszulesen wäre zwar möglich aber vorerst noch nicht geplant.

Da hab ich Dir schon ein paar Möglichkeiten aufgezählt, es kommt halt auf die Menge der auszugebenden Daten an.


Eine nette Funktion wäre eine per Poti dimmbare Pultbeleuchtung. Wenn das über den Controller ginge wärs fein wenn nicht auch egal. Hierzu muss ich sagen das die Spezifikationen dieser Lampen (XLR-Anschluss, Spannung) halbwegs einheitlich sind.
Dafür würde sich eine PWM anbieten. Fast jeder Timer eines ATMEGA Controllers kann als Hardware PWM genutzt werden. Ein passender Treiber MOS FET sollte auch nicht wirklich ein Problem sein.


Was fast schon ein muss ist, wär die Belegung der Tasten und das ausgegeben Midisignal ändern zu könnnen da ich je nach Location ein anderes Setup hab. Geht zwar über Freestyler ist da aber ein ziehmlich umständliches Geschäft
Das denk ich mal könnte über eine Zuordnungstabelle geschehen.
Ein geeigneter Speicherort dafür wäre das EEPROM des Controllers, da dies auch die Werte ohne Strom beibehält.
Ein mögliches Speicherformat wäre:
1. Anzahl der MiDi Bytes
2. 1.Byte ( Status )
3. 2.Byte ( Parameter 1 )
4. 3.Byte ( Parameter 2 )
Das Ganze mal 70 ( Tasten ) wären 280 Bytes pro Setup.
MiDi Befehle mit mehr als 2 Parametern gibts eigentlich nur bei System Exclusive Befehlen, aber die würde ich für dein Projekt nicht nutzen wollen.
Wenn Du dich für einen Controller entscheidest solltest Du, falls Du das so machen willst, auch die EEPROM Größe im Auge behalten. Ein Externes EEPROM über I²C wäre aber auch möglich, ebenso eine Speicherung auf einer SD Karte. Allerdings schluckt eine FAT für die SD Karte ziemliche Controller Resourcen und ausserdem läuft so eine Karte nur mit 3,3V. Die meisten Displays hingegen brauchen 5V - Siehst Du das Problem ?


Als nächste Stufe wäre es das MIDI signal in USB zu wandeln sodass der PC ein MIDI Interface erkennt. Da werd ich vermutlich einen 5 Euro USB Midi Wandler hernehmen ist wahrscheinlich einfacher und billiger.
Gut das MiDi Signal in eine USB Schnittstelle zu packen ist eigentlich kein Problem. Das geht mit einem FT232R. Das der PC das aber auch als MiDi Schnittstelle erkennt dürfte schwieriger werden.
Im Zweifelsfall würd ich da, wie Du vorgeschlagen hast, ein fertiges MiDi USB Kabel verwenden.

Wenn ich mir den Umfang deines Projekts so anschaue würde ich persönlich zu einem ATMEGA 64 tendieren.
Wenn Dir bei MEGA 32 die Ports ausgehen kannst Du da schon wieder einiges umstricken. Immerhin 5* A/D, 12*Tasten, 8*Display, 4*LED, 2*SPI.
Damit hast Du dann schon 32 I/O Ports verbraten. Damit dürfte ein MEGA 32 schon voll sein!
Beim MEGA 64 hast Du immer noch die Möglichkeit auf einen MEGA 128 oder gleich einen MEGA 256 umzurüsten, wenn der Speicher nicht reicht.

Ich würd mir für den MEGA 64 ein Adapterboard basteln auf dem auch gleich eine ISP Schnittstelle sitzt. Wenn Du dich dann auf eine Rastergröße eines Steckbretts festlegst kannst Du damit schon sehr viel probieren.

Wenn dann die Ports immer noch nicht reichen, kannst Du auch gleich auf einen ATMEGA 2580 ( TFQP100 ) hochrüsten ;) ;) ;)

[blackfield]

Bei so vielen Tastern würde sich eine Matrixansteuerung anbieten.
Also die Taster in Reihen und Spalten anordnen ( Schaltungstechnisch ) und die dann Abfragen.
Das dürfte Dich etwa 12Ports kosten.
4 für die Spaltenansteuerung und 8 als Feedbackleitung direkt zum Controller.
Die Schieberegister wären aber immer noch eine Option und würden die Möglichkeit eröffnen die Tastaturplatinen zu Blöcken mit jeweils 8 Tasten und einem Schieberegister aufzuteilen. Das wären dann 9 gleiche Platinen.


Das hätte noch den Vorteil das man zwei drei Reserveplatinen löten könnte und ein schneller wechsel möglich wäre --> modularer Aufbau


Freestyler hat MIDI, das ist nicht das Problem. Ich kann jede Note frei einer Funktion zuweisen.

Auf das Matrixprinzip werde ich auf jeden Fall zurückgreifen, sonst wird das ein haufen Ports verbraten.

Als Display wird maximal ein 4x20 Dotmatrix reinkommen, eher kleiner. Da wird natürlich auf den Preis geschaut und cool aussehn sollte es natürlich auch ein bissl ;)


Dann werd ich wohl doch auf einen ATmega 64 umsteigen. Dadurch wird auch das Display weniger kritisch. Das Pollinboard hat einen ISP Anschluss damit bräuchte ich nur einen Pinadapter. Ich denk der ATmega wirds mir danken wenn ich da einen LIF Sockel nehm. Alledings sind die größeren ATmegas nicht im DIL Gehäuse erhältlich was das löten wieder sehr interessant machen dürfte.

Ich seh schon ich hab mir da einiges vorgenommen baer man wächst ja bekanntlich mit seinen Aufgaben.

[wkrug]

Alledings sind die größeren ATmegas nicht im DIL Gehäuse erhältlich was das löten wieder sehr interessant machen dürfte.
...das dachte ich anfangs auch immer.
Lötstation, dünnes Lot ( 0,3...0,5 ) Flussmitteldispensor, Platine mit Lötstoplack, Lötsauglitze und SMD Pinzette heissen hier die Zauberworte.
So ein IC ist in 5 bis 10 min einzulöten.
Am längsten dauert da noch das genaue Positionieren der Pins.
Flussmittel drauf geben.
An 2 gegenüber liegenden Ecken anlöten.
Mit dem Lötkolben unter stetiger Zugabe von etwas Lötzinn an den 4 Seiten des IC mit dem Lötkolben entlangziehen.
Das Überschüssige Lot und die Brücken ( die dabei zwangsläufig entstehen ) mit Lötsauglitze absaugen. Mit der Lupe kontrollieren fertig.
Es ist mit geignetem Werkzeug wirklich so einfach!

[blackfield]

Wird schon gehn irgendwie. Zur Not find ich bestimmt auch jemanden der mir sowas macht.
Betreibt hier jemand nen Platinenservice der bezahlbar ist?

Was den MiDi Merger angeht würde das die Erweiterung natürlich ziehmlich vereinfachen. Wenn ich viel konventionelles Licht hab brauch ich mehr Fader. Bei bewegtem Licht und LEDs sind wieder mehr Taster am Start.

[wkrug]

Ich lass meine Platinen meistens bei Bilex http://www.bilex-lp.com machen.
Die Qualität ist soweit OK und er fertigt auch Einzelstücke und der Preis passt auch.
Lediglich Fräsungen und Langlöcher werden nicht ausgeführt.

[blackfield]

Hab mich mittlerweile etwas mit BASCOM auseinandergesetzt.

Ich stolpper jedoch immer wieder über das selbe Problem: den WAIT-Befehl.

Egal was ich für einen Wert eingebe, das Programm bleibt immer dort stehn. Dazu muss ich sagen das ich nur simuliere meine AVRs kommen erst morgen.

Ist das ein Fehler von BASCOM oder überseh ich etwas? Der waitms Befehl funktioniert mehr oder weniger.

[hardware.bas]

Da ich grundsätzlich echt, also mit Hardware oder Hardwarersatz simuliere,
um Peripherie und Peripherieantworten mit einzubeziehen, kann ich zwar
zum Simulator nicht viel sagen. Ich hatte jedoch mal vergessen, die
Taktfrequenz des AVR zu aktualisieren, so dass alles VIIIEEEEL langsamer
lief, als normal. Dadurch war der Wait-Befehl so lang, dass ich einen
Aufhänger vermutete. Also mein Vorschlag, mal die Taktfrequenz
kontrollieren. Schaumal, ob die Waitms-Befehle auch langsamer sind.
VG Micha
Taktfrequenz

[blackfield]

Ja ist der. Wie aktualisier ich die Taktfrequenz? Das läuft doch über den Baud und crystal Befehl.

Ein Freund hat mir dazu geraten direkt mit Assembler zu programmieren. Lohnt es sich oder soll ich erstmal mit BASCOM anfangen?

[Richard]

Hab mich mittlerweile etwas mit BASCOM auseinandergesetzt.

Ich stolpper jedoch immer wieder über das selbe Problem: den WAIT-Befehl.

Egal was ich für einen Wert eingebe, das Programm bleibt immer dort stehn. Dazu muss ich sagen das ich nur simuliere meine AVRs kommen erst morgen.

Ist das ein Fehler von BASCOM oder überseh ich etwas? Der waitms Befehl funktioniert mehr oder weniger.

Im Simulator klappt das (Zeitlich) nicht, der Simulator brauch dafür zu viel Zeit. Um trotzdem Simulieren zu können, muss am Anfang vom Programm ein $Sim eingefügt werden und neu Compiliert werden. Dann läuft das Programm durch. :-)

Im realen Programm muss das $Sim natürlich wieder raus.

Gruß Richard

Gruß Richard

[hardware.bas]

Klar, geht die Taktmanipulation in BASCOM. Der crystal-Befehl ist richtig,
jedoch muss der AVR wissen, ob er seinen Quarzoszillator, den internen
freilaufenden Oszillator oder einen externen Takt benutzen soll.
Dies kann man mit den Fuse-Bits festlegen. Ist auch im BASCOM
möglich. Viele AVRs sind im Auslieferzustand auf Freilaufoszillator
eingestellt mit 1000000 Hz (siehe crystal-Befehl). Damit passen dann
auch wieder die Zeiten, WENN es sich WIRKLICH so verhält, jedoch
ca. 1-2 Prozent Ungenauigkeit. VG Micha
Osz

[blackfield]

Jetzt macht es Sinn da ich im Simulator ja keine Fusebits setzen kann.

[hardware.bas]

Wie gesagt, ich kenn mich mit dem Simulator nicht aus. Fusebits gehen
ziemlich ins Eingemachte der AVRs. Vielleicht kann jedoch im Simulator
die Taktfrequenz verändert werden? Oder vielleicht noch eine Idee:
Den AVR auf 1000000 Hz setzen und in dem Falle, dass es ein neuer ist,
zumindest beim Atmega8 ist das so, müsste er das annehmen und
dann kann man ja testen, ob z.B Wait 60 auch (ca.) 1 Minute ist.
Oder noch was, mal testen on Waitms 60000 auch 1 Minute ist oder so
ähnlich. Bei diesen Test kann man zumindest nix zerschiessen.
VG Micha

[wkrug]

So ein Wait befehl mit einer Sekunde kann im Simulator durchaus ne viertelstunde laufen. Hast Du da auch so lange gewartet?

Gerade bei den großen AVR Controllern läuft die Simulation mit AVR Studio extrem langsam ( je nach PC ).

Bei meinen Simulationen kann ich bei Wartezyklen um oder größer 1 sek locker mal auf die Toilette gehen.

Wen auch der Timer zu wenig anzeigt kanns natürlich auch an der Taktfrequenz liegen.
Wenn das Fil gebuilt ed ist kann man unter DEBUG bei AVR Simulator Options die Taktfrequenz einstellen.

Pass bei der Verkabelung der ISP auf, die ist bei den 64, 128 und 256 Controllern nicht auf den gleichen Pins ( MISO, MOSI und SCK ) wie bei den kleineren Controllern.
Des weiteren solltest Du die ATMEGA103 Compatibility Fuse abwählen und das JTAG Fuse abschalten. Beide sind bei einem neuen Controller ein!
Das sind die Probleme, die die meisten Anfänger haben.

Ich schreib meine Programme aber in "C".

[blackfield]

So lange hab ich noch nicht gewartet.

Ich denk mal es liegt am Simulator, ein i7 dürfte da ja keine Probleme haben.

Ich werd mich mal umsehn ob ich einen Fix für das Problem find.