Servus Leute, hab heut feststellen müssen, dass die Welt von der alten 8051 MC`s und die der AVR`s doch grosse Unterschiede hat. Ich hatte damals zum programmieren meines 8051ers Bascom verwendet mit einem selbst gebauten Brenner von Batronix glaub ich. Hat gut funktioniert. Leider musste ich nun feststellen, das ich mit Bascom AVR keine Fusebits oder der gleichen ändern kann mit meinem vorhanden Brenner. Den Brenner hab ich von myAVR gekauft und läuft über USB. Programmtechnisch kann ich zwar Pins und der gleichen High Low setzen, aber schon das ansteuern eines Displays haut nicht hin. Mittlerweilen bin ich der festen Meinung das es an den Fusebits liegt oder halt einfach Bascom nicht 100%tig mit dem Brenner hamoniert. Deshalb hab ich mir heute die Software von myAVR.de gekauft. Ist nicht mehr auf Basic-Basis sondern nun auf C-Basis. Vorallem kann ich die Fusebits setzen und das schon in der Demoversion. Genau hier setzt meine erste Frage an. Und zwar welche muss ich nun setzen damit ich meinen externen Quarz ansteuern kann. Es ist ein 14,7456MHz Quarz um eine korrekte Baudrate für meine spätere Anwendung hinzukriegen. Der MC ist ein Atmega16. Soweit ichs verstanden habe muss ich die CSEL alle auf 1 setzen, blos wie ich die STUD setzen muss... da drehen sich bei mir 3 Fragezeichen. Den CKOPT soweits ich überrissen hab muss auch von Null auf Eins. (CKOPT = 1 für MHZ > 8MHz laut Datenblatt Atmel). Die andere Sache nebenbei ist das JTAG wohl auf disable also auf 1 muss um den C-Port freizuschalten da er wohl momentan für den In-System-Debuger reserviert ist. Die andere Frage die mich brennend interessiert ist, welcher Kondi ist nötig für meinen 14,7456MHz. Momentan hab ich nen 22 pF drin wies im Atmel Datenblatt steht. Aber beim Reichelt wo ich den Quarz gekauft hab, steht im Katalog drin das 32pF dazugehören. Hab auch im Internet schon einige gefunden, aber da sinds mal die mal die. Ich hab das ganze mal mitn Oszi gemessen und er geht jetzt wo die Fusebits bei CCEL auf 1 stehen schon mal von 0V auf so 0,6-0,7 Volt hoch, aber schwingen tut er meiner Meinung nach nicht. Eben wegen den Fusebits und dem fehlenden Quarz stimmten wohl die Flanken fürs Display nicht. Pegel gibt er aus (sichtbar aufn Oszi) aber halt kaum messbar das kein Speicheroszi ist. Das Display geht, da ichs an einem alten 8051 getestet hab. Naja ich hoffe einer von euch kann mir helfen, den langsam Verzweifle ich an dem ganzen... MfG Matthias
Hier kannst du die Fusebit kontrollieren: http://palmavr.sourceforge.net/cgi-bin/fc.cgi Aufpassen mit den 0 und 1 Die Kondensatoren beim Quarz passen schon so.
Danke mal soweit. Die Seite kannte ich schon, blos stellt sich für mich die Frage sind die 14,xxx MHz schon ein High Frequ. Oszilator oder nicht? Hab da leider keinen Plan von und ich will nicht einfach alle Einstellungen durchtesten, nicht das noch was hobs geht am MC. MfG Matthias
Hallo Matthias, laut Datenblatt von Atmel ist alles was über 8MHz rennt "High Speed". Wenn der Brenner mit Bascom nicht will, versuche doch mal ob du mittels AVRstudio mit dem Brenner eine richtige Kommunikation hinbekommst, die Fusebits ändert man ja nicht jeden Tag. :) Geht das Programmieren des Programmcode mit Bascom und diesem Brennen? Je nach dem würde ich Anfänglich die Fuses (wenn der Brenner mitspielt) aus AVR-Studio heraus setzen das ist am Anfang übersichtlicher. MfG Roland
Hallo Roland, danke für die Info, ich wurd aus dem Datenwust im Datenblatt nicht mehr schlau. Also ist der schon Highspeed. Programmcode lässt sich mit Bascom brennen, aber halt Fusebits nicht ändern. Ich hab mir jetzt die C-Umgebung schon bestellt, da sie auch richtig zum Brenner gehört und in der Demo die High Fusebits nicht änderbar sind. Das AVR Studio hab ich schon probiert das kriegt garkeine Komunikation zu stande. Und bei Bascom bin ich mir ehrlich gesagt auch nicht mehr ganz so sicher ob das so passt wie ers schreibt. Und wie ichs ausm Datenblatt etc. verstanden hab müssen dann die CSELs alle auf 1 und die CKOPT auch auf 1. Die SUT sind für die Startverzögerung vom Reset zu Power up zuständig. Wie die stehen sollte dann egal sein oder damit er mit dem externen Oszi läuft. Langsam glaub ich das der 22pF Kondi am Quarz net passt...ich glaub ich löt mal den 32pF ran wies im Reichelt Katalog steht. Denn egal welche Einstellung ich momentan mach, kommt am Display maximal irgend ein Mist wie 3 Balken an, wenn überhaupt. Ich danke euch allen nochmal...bin froh das so ein Forum gibt sonst wäre ich aufgeschmissen. MfG Matthias
Hmmm meinst du mit drei Balken auf dem LCD nur Schwarze Balken wie wenn es nicht richtig initialisiert ist? Oder buchstaben und Zahlenmüll? Beschreibe das Problem mal genauer, insbesondere was für ein Displaycontroller das Display hat, dann kann ich mehr sagen. Brenn doch mal nen Demoprogramm mit Bascom rein, einfache Pin einschalten, 1sec warten, pin ausschalten. Das ganze in einer Endlosschleife rennen lassen. Wenn sich am Pin was tut weißt du das der Quarz nicht schuld ist, vorausgesetzt du hast den Mega vorher in den Fusebits auf externen Takt eingestellt. Roland
Also das Display hat den HD44780 drauf den selben Controller wie ich schon auf meinen anderen Displays hab. Es ist bisher nur auf einer Fusebiteinstellung bisher geglückt das auf dem Display wenistens in der ersten Zeile und im ersten Buchstaben 3 Balken zu sehen waren. Ansonsten ist tote Hose. Pins High Low schalten hab ich schon gemacht, aber leider kann ich nicht 100 Pro sagen obs eine Sekunde ist. An meinem alten Board mit dem 8051 geht das Display perfekt. Die Befehle sind genau die selben wie damals. Mehr gibts nicht fürs Display bei Bascom. Hier mal den Quellcode... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ $crystal = 1474560 $regfile = "m16def.dat" Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.3 , Db6 = Porta.1 , Db7 = Porta.0 , E = Portc.5 , Rs = Portc.6 Config Lcd = 20 * 4 Config Lcdbus = 4 Wait 1 Upperline Lcd "Dies ist die 1" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Naja ich zweifle eben noch daran, dass der Quarz wirklich so schwingt wie er sollte. Am Oszi ist jedenfalls nix zu sehen ausser konstant 0.7 V. MfG Matthias
Hallo, probiers mal mit diesem Code für Bascom. $crystal = 1474560 $regfile = "m16def.dat" Config Lcd = 20 * 4 Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.3 , Db6 = Porta.1 , Db7 = Porta.0 , E = Portc.5 , Rs = Portc.6 wait 1 initlcd cls Wait 1 Upperline Lcd "Dies ist die 1" Kompiliere den Code mal und braten den rein und gib mir bitte rückmeldung. :) Roland
ähm, blöde Frage (kenne mich mit bascom gar nicht aus): Sollte $crystal nicht mit 14745600 initialisiert werden? Mit fehlt da oben im Code eine null. Ansonsten haben wir vor kurzem auch einen Mega16 problemlos am besagten 14,... Quarz betrieben. Als Kondensator hatten wir irgendwas zwischen 15 pF und 22 pF... auf keinen Fall höher (funktioniert wahrscheinlich auch, ist aber nicht spezifiziert). Die Evaluations-Boards von Pollin verwenden auch 22 pF - wird schon stimmen. Ich habe jetzt leider nicht die Fuses von unserem Aufbau da. Folgende Fuses habe ich für unser Folgeprojekt seinerzeit evaliert. Bin mir nicht sicher, ob wir die schon so getestet haben:
1 | 0 BOOTRST (1) = 1 (unprogrammed) ; set reset interrupt vector to 0x0000 |
2 | 1 BOOTST0 (0) = 1 (unprogrammed) ; reduce boot flash size to 128 words ($1f80-$1fff) |
3 | 2 BOOTSZ1 (0) = 1 (unprogrammed) ; reduce boot flash size to 128 words ($1f80-$1fff) |
4 | 3 EESAVE (1) = 1 (unprogrammed) ; do not preserve EEPROM on chip erase |
5 | 4 CKOPT (1) = 0 (programmed) ; Oscillator: full rail-to-rail swing, very noisy environment, wide frequency range, max 16 MHz (Seite 25, Abschnitt: "Crystal Oscillator") |
6 | 5 SPIEN (0) = 0 (programmed) ; enable SPI programming |
7 | 6 JTAGEN (0) = 1 (unprogrammed) ; disable JTAG interface |
8 | 7 OCDEN (1) = 1 (unprogrammed) ; disable on chip debugger |
9 | |
10 | 0 CKSEL0 (1) = 1 (unprogrammed) ; Crystal Oscillator, BOD enabled |
11 | 1 CKSEL1 (0) = 1 (unprogrammed) ; 1 - 16 MHz? |
12 | 2 CKSEL2 (0) = 1 (unprogrammed) ; 1 - 16 MHz? |
13 | 3 CKSEL3 (0) = 1 (unprogrammed) ; 1 - 16 MHz? |
14 | 4 SUT0 (0) = 1 (unprogrammed) ; Crystal Oscillator, BOD enabled |
15 | 5 SUT1 (1) = 0 (programmed) ; Crystal Oscillator, BOD enabled |
16 | 6 BODEN (1) = 0 (programmed) ; enable Brown Out Detector |
17 | 7 BODLEVEL(1) = 0 (programmed) ; 4.0 V Grenzwert |
Wir hatten seinerzeit auch Probleme die Quarz-Schwingung auf das Oszi zu kriegen... der Controller ist dabei immer aus dem Takt gekommen (undefinierte Zustände). Vielleicht eine zu geringe Leitungsimpedanz gewählt - ist nicht gnz mein Fachgebiet ;) Wir messen immer mit folgendem Programm:
1 | .MACRO debugOutput |
2 | out PORTD, r16 |
3 | out PORTD, r17 |
4 | out PORTD, r18 |
5 | out PORTD, r19 |
6 | out PORTD, r20 |
7 | out PORTD, r21 |
8 | out PORTD, r22 |
9 | out PORTD, r23 |
10 | out PORTD, r24 |
11 | out PORTD, r25 |
12 | out PORTD, r26 |
13 | out PORTD, r27 |
14 | out PORTD, r28 |
15 | out PORTD, r29 |
16 | out PORTD, r30 |
17 | out PORTD, r31 |
18 | .ENDMACRO |
19 | |
20 | ldi r16, 0x0 |
21 | ldi r17, 0x1 |
22 | ldi r18, 0x2 |
23 | ldi r19, 0x3 |
24 | ldi r20, 0x4 |
25 | ldi r21, 0x5 |
26 | ldi r22, 0x6 |
27 | ldi r23, 0x7 |
28 | ldi r24, 0x8 |
29 | ldi r25, 0x9 |
30 | ldi r26, 0xa |
31 | ldi r27, 0xb |
32 | ldi r28, 0xc |
33 | ldi r29, 0xd |
34 | ldi r30, 0xe |
35 | ldi r31, 0xf |
36 | |
37 | loop: |
38 | debugOutput |
39 | debugOutput |
40 | debugOutput |
41 | . |
42 | . |
43 | . |
44 | . ; einfach ein paar hundert mal untereinander |
45 | . ; das verhindert, dass der Rücksprung unten ins Gewicht fällt |
46 | jmp loop |
Auf die Weise ist auf - PD0 eine Frequenz von 14,.../2 zu messen - PD1 eine Frequenz von 14,.../4 zu messen - PD2 eine Frequenz von 14,.../8 zu messen - PD3 eine Frequenz von 14,.../16 zu messen Die Pins müssen natürlich als Output konfiguriert sein. Einer guten Oszi-Messung steht dann nichts mehr im Wege - wenn ich mich nicht vertippt habe... Vielleicht hilft's ja ein wenig. Gruß Kai
@Kai Gibeler, stimmt du hast recht, das habe ich ganz übersehen, es muß $crystal = 14745600 heißen, sonst ist die Frequenz viel zu klein und der Compiler macht den Displayinit viel zu schnell. Deshalb wird das Vermutlich auch nicht gehen und das LCD zeigt nur Müll an.... :) Roland
Also so wies aussschaut hats ein MC nicht überlebt die ersten Fuseversuche. Er ist mit nix mehr erreichbar wobeis am WE noch ging. Wahrscheinlich war die letzte Einstellung mist oder der Brenner hats verhunst, wobei er am WE noch auszulesen war...naja seis drum. Hab nun meinen 2ten und letzten in Betrieb. Ich hab die Fusebits soweit eingestellt wie Kai, ABER LEIDER LÄSST SICH DAS CKOPT NICHT ÄNDERN!!! Langsam könnt ich kotzen. Der CKOPT steht immernoch auf 0 also geht meiner Meinung nach der Quarz nicht, da er laut Atmel Datenblatt auf 1 muss wenn ein Quarz >1 Mhz installiert ist. Das mit dem Crystal hab ich selber gesehen, aber es ist nur etwa der Quellcode der drauf ist, der liegt nämlich auf einen anderen Rechner. Gut habs aber soweit geändert und auch mal das INITLCD reingeschrieben. Blieb aber ohne Erfolg. Ich hab heut meine Vollversion vom AVR Workpad gekriegt und selbst da lassen sich die High Fuses nicht ändern. Was ich nicht zu gedacht hätte ist, der C-Code ist um Ecken komplexer als von Bascom. Danke Euch trotzdem...
Also der eine Controller geht doch noch war blos nicht richtig im Sockel.
Servus Roland, Code hab ich reingebraten so wie du ihn geschrieben hast...leider nix passiert. Omann...
Hallo Matthias, hast du im $crystal-Statement die frequenz korrigiert? Kontrolliere mal die Anschlüsse des LCDs, sind die wirklich alle korrekt angeschlossen, miß die mal sicherheitshalber durch. Ich hatte schon mal Stiftleisten wo ein Kontakt intern unterbrechung hatte. Hat mich 4 Stunden suchen gekostet... Wie hast du die restlichen Pins des LCD beschaltet? Ist der RW-Pin fest auf GND gezogen? Roland :)
Servus Roland, Crystal hab ich korrigiert. Die Leitungen sind schon x-mal durchgemessen worden. Ach ja ich hab mal den Schaltplan Hochgeladen. Da sind die E und die RS getauscht, welches ich auch im Programmcode getauscht hab. Wie gesagt war nur schnell ausm Kopf hingeschrieben. Hier der aktuelle Code. $crystal = 14745600 $regfile = "m16def.dat" Config Lcd = 20 * 4 Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.3 , Db6 = Porta.1 , Db7 = Porta.0 , E = Portc.6 , Rs = Portc.5 Wait 1 Initlcd Wait 1 Cls Upperline Lcd "Dies ist die 1"
Hallo, füge bitte im Quellcode unter dem $crystal-Statement noch folgende Befehle hinzu (nur um ganz sicher zu gehen)... $hwstack = 32 $swstack = 10 $framesize = 40 lass das upperline-statement und das "wait 1" vor initlcd mal weg für den Anfang zum testen der Sache. Setze unter lcd noch das folgende: Cursor On Blink Laut Schaltplan ist Pin5 am LCD das RW-Pin und das ist ja Fest auf GND gelegt, das sollte also klar sein. Was für nen Display verwendest du, also welcher Typ, eines von diesen gierigen Blauen von www.lcd-module.de? Was ich mal versuchen würde die restlichen nicht belegten Datenleitungen (du betreibst das LCD ja im 4-Bit mode) auf definiertes Potential zu legen (GND) nicht das die in der gegend rumfloaten das gibt sonst massive probleme. Einige LCDs haben aber meistens schon "Ziehwiderstände" an diesen Pins, muß aber nicht. Sonst mal messen mit dem Multimeter ob sich das Spannungen ändern im Betrieb. Blöde Frage: Kontrastspannung stimmt oder, also du siehst beim aufdrehen schwarze balken des uninitialisierten Displays? Welche Version von Bascom verwendest du? Die Demo oder die Full? Auslesen der Fusebits klappt? wenn ja bitte mal hier posten. Probier das bitte mal. Den einen MC der sich nicht mehr ansprechen läßt, ich vermute daß du oder der brenner durch einen zufall die Fusebits der takteinstellung geändert hast. Das äußert sich darin daß der mega nun einen externen Takt haben möchte, der quarz kann somit nicht mehr funktionieren. Lege einen externen Takt an und du kannst das ding wieder richtig fusen. Als taktquelle kannst du einen 2. mega verwenden, brate nen programm rein daß immer einen Pin toggelt und schon hast du nen taktgenerator. Alternativ kannst du mir den Chip auch schicken und ich fuse dir den wieder richtig. Kostenlos versteht sich. Wenn das alles nicht geht bleibt nur noch eine sache als Fehlerquelle übrig. Entweder hat das LCD nen schuss weg oder die Fuses des Chips stimmen nicht. An Bascom kanns eigentlich nicht liegen, ich hab das ganze Programm (okok Programm ist für die paar Zeilen Code etwas übertrieben*g*) mal eben Compiliert (ich hab die Full) und in mein Testboard gebraten. Funktioniert einwandfrei. Ich hab nen 20*4 von LCD-Module.de das hier noch so rumlag verwendet gibts bei reichelt. Bascom ist meiner meinung nach sehr zuverlässig vom programmergebnis her. Ich Progge selbst in Bascom und in C, je nach komplexität der Problemstellung, alle Fehler haben sich bis jetzt immer als ein Versehen meinerseits oder als Hardwarefehler rausgestellt. MfG Roland
Hallo Roland, also hab den Code mal so geänder geholfen hat es nix. Kontrast passt, die Balken seh ich. Das Display ist vom Reichelt und zwar: http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=A5212;GROUPID=3006;ARTICLE=53952;START=0;SORT=preis;OFFSET=1000;SID=30QdSJ2awQAR4AAFVwB90ad5507c9a2b1c8f7461af5264668569d Einen Schuss hat es sicher nicht weg, da ich es am Wochenden an einem Baord hatte welches auch ein 4 mal 20er verwendet HD44780 und dort hats einwandfrei funktioniert, war im endeffekt die selbe Belegung. Also denke ich kann ich das Ausschliessen. Das Auslesen der Fusebits unter Bascom unterstützt mein Brenner leider nicht, dafür aber in der C Software die als Demo dabei war und die ich mir jetzt auch original besorgt hab. Hier mal was eingestellt ist: -------------------------------------------------- FUSEBITS: Brown-out detection level at VCC=2.7 V; [BODLEVEL=1] Brown-out detection enabled; [BODEN=0] Ext. Crystal/Resonator High Freq.; Start-up time: 16K CK + 4 ms; [CKSEL=1111 SUT=10] -------------------------------------------------- High- Fusebits: siehe Anhang. -------------------------------------------------- Lock-Bits: Mode 1: No memory lock features enabled Application Protection Mode 1: No lock on SPM and LPM in Application Section Boot Loader Protection Mode 1: No lock on SPM and LPM in Boot Loader Section -------------------------------------------------- Momentan kann ich leider die High-Fusebits nicht ändern. Warum weis ich nicht, also werd ich morgen mal bei dennen ihrem Support auf den Putz haun. Genauso wie das Brennen eines ihrer Beispiele auch nicht hinhaut...traumhaft. BASCOM AVR Compiler Version 1.11.7.7 Soweit ich weis die Full. Den andern Controller hab ich wieder hinbekommen, der hat sich im Eifer des Gefechtes wohl ausm Sockel vom Brenner geschlichen, sprich er läuft wieder einwandfrei. Auch wenn die Pins langsam aber sicher nicht mehr die neuesten sind. Aber danke fürs Angebot! Weis ich zu schätzen, genauso wie die hilfe von dir und den anderen. Also eins weis ich die 8051er waren simpler als die AVR`s :-) MfG und Danke nochmals Matthias P.S. Welchen C-Compiler nimmst du eigentlich dann her, hab mir grad as AVR-Studio und WinAVR gezogen, aber die können mit meinem Brenner nix anfangen.
Leute, Leute - immer wieder das selbe: da wird gespart, koste es was es wolle. Warum besorgt ihr euch nicht ein vom Hersteller unterstütztes, und per Firmware-Update aktuell gehaltenes Programmiertool wie den AVRISP oder ggf. auch den Dragon? Also mir wäre meine spärliche Freizeit zu viel Wert als sie mit untauglichen Tools zu vertun...
Hmm, wenn ich das so lese muß ich Stefan Wimmer zumindest in teilen zustimmen. Mein erster Programmer war der nachbau von AVR910 (die Variante von Herrn Leidinger). Wenn ich da so lese wie einige sich mit Ponyprog o.ä. abmühen, bin ich froh daß ich die 2 Stunden in den Aufbau des AVR910 Proggers gesteckt habe. Jetzt hab ich nen STK500 Clone, von mir erweitert um USB-Schnittstelle, dort bekomme ich auch die Versorgungsspannung her (bei bedarf). Das Teil hat nen Schaltregler verpasst bekommen und kann somit auch den HV-Modus. Da das ganze auf einer Applikation von Atmel basiert hält mir die Firma Atmel die Firmware auch noch aktuell. Danke Atmel ggg Schön ist auch das das Ding sowohl mit den gängigen Programmertools rennt wie avrdude usw., und auch mit Bascom direkt. Also was will ich mehr? :D @Michael, was für einen Brenner und was für Steuersoftware verwendest du (außer Bascom)? Als Alternative, ich habe in deiner Schaltung gesehen daß du die RS232 schnittstelle verwendest, Brenne doch einmal nen Bootloader in den Mega und flashe bequem über die serielle, geht auch einwandfrei aus Bascom raus, Stichwort "MCS Bootloader". Einen einfachen Bootloader findest du in Bascom ist in dem ordner Samples dabei heißt Bootloader.bas. Chip auswählen, compilieren braten und sich freuen. Wenn du natürlich nichts an den Fuses machen kannst ist das problematisch da du da was ändern mußt das der Bootloader rennt. Übrigends deine Bascom-Version ist nicht aktuell, momentan ist 1.11.8.9 die aktuellste. Mach mal nen Onlineupdate über MCS. So den rest schau ich mir morgen an wenn ich in der Firma bin :D EDIT: Schalt mal das JTAG-Interface aus es sei den du brauchst das, das kann störungen geben insbesondere auf Port C! Wie das genaue Pinmapping ist weiß ich auswendig nicht aber wenn du das nicht brauchst weg damit. Falls gar nix Klappt, wie währe es mit einem AVR910 Progger, z.B. von Herrn Leidinger, ist schnell aufgebaut und funktioniert garantiert mit AVR-Studio ohne Probleme! Oder einen der vielen AVRISP-Clones mit USB, Stichwort das Ding von Benedikt Sauter, schön klein einfach und rennt zuverlässig. War letztlich sogar in der Elektor zu finden wenn ich mich richtig erinnere. MfG Roland
Also, habs etz hinbekommen unter AVR Studio auf meinen Brenner zuzugreifen und auch die Fusebits zu ändern. Jtag is aus und Ckopt auf 1. Hilft alles kein gramm was... Langsam aber sicher bin ihc mit meinem Latein am Ende. Ich werd nochmals alle Datenleitungen etc. Durchmessen...vll find ich da trotz schon x-maliger Messung noch was. Ansonsten kanns vll sein das er mit dem Splitten der Leitungen auf verschiedene Pins nicht klarkommt? MfG Matthias
STRIKE STRIKE STRIKE!!! ES LEBT ES LEBT!!! ICH HAB ANZEIGE AUFN DISPLAY!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! OLEOLEOLEOLE!!! Den Grund werdet ihr wohl auch gerne Wissen wohlen, also ich hab beim durchmessen keine Fehler festgestellt, ABER IM QUELLCODE. Da war statt Port a Port c für RS und E drin. Hab wohl ich wohl im Halbschlaf nicht richtig gelesen...kein Wunder wenn man Nachts schon vom MC-Programmieren träumt und auch so beschissen geschlafen hat. Es ist nun eine Kompi aus unseren beiden Codes, mehr deiner als meiner Roland. ____________________________________________________ $crystal = 14745600 $hwstack = 32 $swstack = 10 $framesize = 40 $regfile = "m16def.dat" Config Portc.0 = Output Config Lcd = 20 * 4 Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.3 , Db6 = Porta.1 , Db7 = Porta.0 , E = Porta.5 , Rs = Porta.6 Config Lcdbus = 4 Initlcd Wait 1 Cls Upperline Lcd "Dies ist die 1" Cursor On Blink Do Reset Portc.0 Wait 5 Set Portc.0 Wait 5 Loop _________________________________________________________-- Ohne Upperline zeigt er nämlich garnix an... :-) wer weis worans liegt...mir is jedenfalls Rille es geht nun entlich. Jetzt wo die FUSEBITS also JTAG off und CKOPT auf 1 steht läuft der MC entlich in seiner ordentlichen Taktrate... ALSO NOCHMALS EIN DICKES DICKES DANKE AN ALLE DIE MIR GEHOLFEN HABEN!!! MfG Matthias P.S.: Sorry für die viele Großschreiberrei...ich freu mich grad wie ein Kleinkind vor der Weihnachtsbescherung!
"Upperline" oder "LOCATE 1,1" sagt dem Displaykontroller, wohin er Deinen Text "schreiben" soll. Ja, das ist manchmal schon eine große Freude, wenn der AVR den Bediener verstanden hat. ;-) Anders herum ist es aber auch nicht schlecht. MfG Paul
Hallo, das höre ich gerne wenn klappt, freut mich immer wieder wenn die Hilfe zum gewünschten Endresultat führt :D Das mit der Vertauschung der Ports ist mir auch schon mal passiert, allerdings nicht ganz so wie bei dir. Bei mir war es so: Ich hatte nen Mega64 mit angeschlossenem HC595 Schieberegister daß auf einen DAC (DAC0800) ging. Das Schieberegister wird logischerweise mit dem Shiftout-Befehl in Bascom "befüllt" Das ganze programm ging, nur hat der DAC permanent müll ausgegeben egal was ich gemacht habe. Ich habe mehrere Stunden daran verbracht den vermeintlichen Hardwarefehler oder Softwarefehler zu finden. Schlußendlich hat man mir auch in einem Forum weitergeholfen (sorry wo weiß ich nicht mehr ist schon längers her) der Shiftout befehl mußte mit "PortX.X" parametriert werden der Shiftin-Befehl mit "PinX.X". Nun ratet mal was bei mir daneben gegangen ist... Ich hab auf dem gleichen uC auch noch zwei Routinen die seriell Daten entgegen nehmen und habe aus Versehen (ok zugegeben es war auch schon sehr spät :D) das Shiftout-Command ebenfalls mit PinX.X versucht anzusprechen. Das wurde natürlich nix. Mit der neuen Version von Bascom wurde das vom Rulecheck auch als Fehler entdeckt (habs irgendwann später mal spaßeshalber ausprobiert) mit der "älteren" Version wurde das beim Compilerlauf nicht moniert... :D MfG Roland (der nach einem 16 Stunden-Tag total erledigt ist...)
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.