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
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 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...
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...)
