Mega16, Fusebits und Quarz Probleme.

[Matthias (Gast)]

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

[Hubert G. (hubertg)]

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.

[Matthias (Gast)]

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

[Canbastler (Gast)]

> 14,xxx MHz schon ein High Frequ. Oszilator

Ja

[Roland Z. (r-zimmermann)]

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

[Matthias (Gast)]

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

[Roland Z. (r-zimmermann)]

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

[Matthias (Gast)]

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

[Roland Z. (r-zimmermann)]

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

[Kai G. (runtimeterror)]

ä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:

0 BOOTRST (1) = 1 (unprogrammed) ; set reset interrupt vector to 0x0000
1 BOOTST0 (0) = 1 (unprogrammed) ; reduce boot flash size to 128 words ($1f80-$1fff)
2 BOOTSZ1 (0) = 1 (unprogrammed) ; reduce boot flash size to 128 words ($1f80-$1fff)
3 EESAVE  (1) = 1 (unprogrammed) ; do not preserve EEPROM on chip erase
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")
5 SPIEN   (0) = 0 (programmed)   ; enable SPI programming
6 JTAGEN  (0) = 1 (unprogrammed) ; disable JTAG interface
7 OCDEN   (1) = 1 (unprogrammed) ; disable on chip debugger

0 CKSEL0  (1) = 1 (unprogrammed) ; Crystal Oscillator, BOD enabled
1 CKSEL1  (0) = 1 (unprogrammed) ; 1 - 16 MHz?
2 CKSEL2  (0) = 1 (unprogrammed) ; 1 - 16 MHz?
3 CKSEL3  (0) = 1 (unprogrammed) ; 1 - 16 MHz?
4 SUT0    (0) = 1 (unprogrammed) ; Crystal Oscillator, BOD enabled
5 SUT1    (1) = 0 (programmed)   ; Crystal Oscillator, BOD enabled
6 BODEN   (1) = 0 (programmed)   ; enable Brown Out Detector
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:

.MACRO debugOutput
  out PORTD, r16
  out PORTD, r17
  out PORTD, r18
  out PORTD, r19
  out PORTD, r20
  out PORTD, r21
  out PORTD, r22
  out PORTD, r23
  out PORTD, r24
  out PORTD, r25
  out PORTD, r26
  out PORTD, r27
  out PORTD, r28
  out PORTD, r29
  out PORTD, r30
  out PORTD, r31
.ENDMACRO

ldi r16, 0x0
ldi r17, 0x1
ldi r18, 0x2
ldi r19, 0x3
ldi r20, 0x4
ldi r21, 0x5
ldi r22, 0x6
ldi r23, 0x7
ldi r24, 0x8
ldi r25, 0x9
ldi r26, 0xa
ldi r27, 0xb
ldi r28, 0xc
ldi r29, 0xd
ldi r30, 0xe
ldi r31, 0xf

loop:
  debugOutput
  debugOutput
  debugOutput
  .
  .
  .
  . ; einfach ein paar hundert mal untereinander
  . ; das verhindert, dass der Rücksprung unten ins Gewicht fällt
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

[Roland Z. (r-zimmermann)]

@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

[Matthias (Gast)]

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

[Matthias (Gast)]

Also der eine Controller geht doch noch war blos nicht richtig im 
Sockel.

[Matthias (Gast)]

Servus Roland,

Code hab ich reingebraten so wie du ihn geschrieben hast...leider nix 
passiert.

Omann...

[Roland Z. (r-zimmermann)]

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

[Matthias (Gast)]

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"

[Roland Z. (r-zimmermann)]

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

[Matthias (Gast)]

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.

[Stefan W. (wswbln)]

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

[Roland Z. (r-zimmermann)]

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

[Matthias (Gast)]

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

[Matthias (Gast)]

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!

[Paul Baumann (Gast)]

"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

[Roland Z. (r-zimmermann)]

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