www.mikrocontroller.net

Forum: Mikrocontroller und Elektronik Frage zu AVR Transistortester - Eeprom Probleme


Autor: Stefan (Gast)
Datum:

Hallo allerseits,
ich würde gerne den hier vorgestellten Transistortester nachbauen.
Die Hex-Datei hab ich in den Atmega8 geschrieben.
Etwas über 7kb - programm passt also vollständig rein in den Controller.
Nun wollte ich das Eeprom in den Atmega schreiben und stelle fest das
das eeprom 862 Bytes groß ist. Der Atmega8 besitzt aber doch nur 512
Bytes? Also werden auch nur 512 von 862 Bytes beschrieben. Ich denke
deshalb klappt das Projekt bei mir nicht.
Wie hab ihr das hinbekommen?
Im Artikel hab ich nichts darüber finden können.
http://www.mikrocontroller.net/articles/AVR-Transistortester

Bitte um Hilfe. Ich wäre sehr dankbar!
Liebe Grüße Stefan
Autor: Uwe Nagel (ulegan)
Datum:

Das File was ich gerade unter:

http://viewvc.coremelt.net/viewvc/avr/semiconducto...

finde hat zwar 999 Byte, aber das ist das Intel-Hex Format.
Da bleiben nur 320 Byte binär übrig.
Welche Datei willst du brennen?

Uwe
Autor: Stefan (Gast)
Datum:

Uwe Nagel schrieb:
> finde hat zwar 999 Byte, aber das ist das Intel-Hex Format.
> Da bleiben nur 320 Byte binär übrig.

Ich nutze Bascom zum Übertragen. Wie füge ich die 320 Byte da ein?

Uwe Nagel schrieb:
> Welche Datei willst du brennen?

Die Eeprom-Datei für den Atmega8. Die Schaltung ohne Automatische
Abschaltung möchte ich nachbauen.

Gruß Stefan
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:
> Uwe Nagel schrieb:
>> finde hat zwar 999 Byte, aber das ist das Intel-Hex Format.
>> Da bleiben nur 320 Byte binär übrig.
>
> Ich nutze Bascom zum Übertragen. Wie füge ich die 320 Byte da ein?

Du lässt den BASCOM-Brenner einfach das Hex-File lesen (wenn der das
überhaupt kann). (*)

Du darfst nicht Dateigröße mit den tatsächlich zu brennenden Bytes
verwechseln. Hex-Files sind ungefähr um einen Faktor 2.5 größer als das,
was dann tatsächlich gebrannt wird.


(*) Wenn BASCOM mit einem *.EEP File nichts anfangen kann, dann nenne es
mal um in zb EEPROM.HEX
Eine *.HEX Datei kann BASCOM meines wissens sauber lesen und etwas
anderes ist diese EEP nicht. Sie hat nur eine andere Endung bekommen.
Autor: Stefan (Gast)
Datum:

Karl Heinz Buchegger schrieb:
> Du lässt den BASCOM-Brenner einfach das Hex-File lesen (wenn der das
> überhaupt kann). (*)

Natürlich kann das Bascom! Einfach auf "Load into Buffer". Damit lässt
sich jede Hex UND Eeprom-Datei in den Brenner laden..

Karl Heinz Buchegger schrieb:
> Du darfst nicht Dateigröße mit den tatsächlich zu brennenden Bytes
> verwechseln. Hex-Files sind ungefähr um einen Faktor 2.5 größer als das,
> was dann tatsächlich gebrannt wird.

Das weiß ich auch. Aber die "nackten" 862 Bytes an Eeprom werden in
Bascom angezeigt, obwohl sonst 1kB eeprom angezeigt wird...Also immer
noch zu viel!

Karl Heinz Buchegger schrieb:
> (*) Wenn BASCOM mit einem *.EEP File nichts anfangen kann, dann nenne es
> mal um in zb EEPROM.HEX
> Eine *.HEX Datei kann BASCOM meines wissens sauber lesen und etwas
> anderes ist diese EEP nicht. Sie hat nur eine andere Endung bekommen.

Guter Tipp! Aber EEP und HEX Files kann er lesen.

Aber damit ist das Problem noch nicht behoben.
Meine Frage wäre jetzt wie die, die den Transistortester nachgebaut
haben müssen das ja irgentwie hinbekommen haben.
Uwe schrieb ja das bei ihm 320 Bytes übrig bleiben. Bei mir sinds aber
ganze 862 Bytes an binärem Zeugs.
Würde mich sehr freuen wenn ihr mir weiterhin helfen könnt.
Gruß Stefan
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:

> Uwe schrieb ja das bei ihm 320 Bytes übrig bleiben. Bei mir sinds aber
> ganze 862 Bytes an binärem Zeugs.
> Würde mich sehr freuen wenn ihr mir weiterhin helfen könnt.


Welches EEP File ist es genau? UNd wo genau hast du es her?
Lade das doch mal hier hoch.
Ich hab mir auf deinem Link wieder eine Weiterverlinkung verfolgt und
bin tatäsächlich bei einem EEP File gelandet. Aber wenn ich da rein
schaue, dann sind da sicher keine 890 Bytes drinnen.
Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Hallo Karl Heinz,
Das Eeprom-File befindet sich nun im Anhang.
Bei dem Link, den ich gepostet habe, befindet sich unten ein Punkt :
"Firmware inkl. Schaltplan und Sourcecode".
Das hab ich heruntergeladen und davon die Eeprom-Datei in Bascom
eingefügt.
Gruß Stefan
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:
> Hallo Karl Heinz,
> Das Eeprom-File befindet sich nun im Anhang.
> Bei dem Link, den ich gepostet habe, befindet sich unten ein Punkt :
> "Firmware inkl. Schaltplan und Sourcecode".
> Das hab ich heruntergeladen und davon die Eeprom-Datei in Bascom
> eingefügt.


Das ist genau das, wovon wir geredet haben.
Die Filegröße ist 862 Bytes.

Das entspricht aber nicht dem Inhalt. Der tatsächliche Inhalt wird so um
die 320 Bytes sein (862 / 2.5)

Dein BASCOM kann die Datei nicht richtig lesen. D.h. lesen schon, aber
es interpretiert den Inhalt falsch.

So fängt die Datei an

:1000000054657374206CE17566742E2E2E00426167


und das bedeutet:

:     so fängt jede Zeile an
10    Anzahl der Bytes in der Zeile, als Hex-Zahl. Also 16 Bytes
0000  dorthin sind die Bytes zu programmieren, also ab Adresse 0
00    Typ des Datensatzes. 00 steht für Daten
54    und erst dann kommt das erste Datenbyte
65    das nächste Datenbyte
etc. etc.

so ist der Aufbau der Datei.
http://de.wikipedia.org/wiki/Intel_HEX

Wenn dir BASCOM das zu brennende anzeigt, und dieses beginnt nicht mit
54 65 73 74 ...  dann hat es das File falsch gelesen.

Und du siehst auch wieviele Zeichen in einer Zeile (und damit Bytes am
File) notwendig sind, um läppische 16 Bytes Nutzdaten zu beschreiben.

Daraus folgt: Dateigröße ist nicht gleich der Anzahl der Bytes, die dann
tatsächlich zu brennen sind.
Autor: Werner (Gast)
Datum:
Angehängte Dateien:

Nimm' dies, das passt :-)
Autor: Stefan (Gast)
Datum:

Karl Heinz Buchegger schrieb:
> Das ist genau das, wovon wir geredet haben.
> Die Filegröße ist 862 Bytes.
>
> Das entspricht aber nicht dem Inhalt. Der tatsächliche Inhalt wird so um
> die 320 Bytes sein (862 / 2.5)

Stimmt! Jetzt verstehe ich das mit den 320 Bytes. ;-)

Karl Heinz Buchegger schrieb:
> Dein BASCOM kann die Datei nicht richtig lesen. D.h. lesen schon, aber
> es interpretiert den Inhalt falsch.

Was heißt das nun genau? Anderes Programm benutzen?
In Bascom werden nähmlich immer noch die 862 Bytes angezeigt. Also ist
dieser Wert immer noch nicht der wahre Bytewert?
Gruß Stefan
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:
> Karl Heinz Buchegger schrieb:
>> Das ist genau das, wovon wir geredet haben.
>> Die Filegröße ist 862 Bytes.
>>
>> Das entspricht aber nicht dem Inhalt. Der tatsächliche Inhalt wird so um
>> die 320 Bytes sein (862 / 2.5)
>
> Stimmt! Jetzt verstehe ich das mit den 320 Bytes. ;-)
>
> Karl Heinz Buchegger schrieb:
>> Dein BASCOM kann die Datei nicht richtig lesen. D.h. lesen schon, aber
>> es interpretiert den Inhalt falsch.
>
> Was heißt das nun genau? Anderes Programm benutzen?
> In Bascom werden nähmlich immer noch die 862 Bytes angezeigt. Also ist
> dieser Wert immer noch nicht der wahre Bytewert?

Nein, der stimmt nicht.

Wenn du die Datei öffnest, sieh nach welche Dateiformate dir das
Brennprogramm beim Öffnen anbietet. Du brauchst "Intel Hex"
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:
> Karl Heinz Buchegger schrieb:
>> Das ist genau das, wovon wir geredet haben.
>> Die Filegröße ist 862 Bytes.
>>
>> Das entspricht aber nicht dem Inhalt. Der tatsächliche Inhalt wird so um
>> die 320 Bytes sein (862 / 2.5)
>
> Stimmt! Jetzt verstehe ich das mit den 320 Bytes. ;-)

So fängt die Datei an (die kann man mit jedem Texteditor öffnen)

:1000000054657374206CE17566742E2E2E00426167


und das bedeutet:

:     so fängt jede Zeile an
10    Anzahl der Bytes in der Zeile, als Hex-Zahl. Also 16 Bytes
0000  dorthin sind die Bytes zu programmieren, also ab Adresse 0
00    Typ des Datensatzes. 00 steht für Daten
54    und erst dann kommt das erste Datenbyte, hier mit dem Wert 54
65    das nächste Datenbyte
etc. etc.

so ist der Aufbau der Datei.
http://de.wikipedia.org/wiki/Intel_HEX

Wenn dir BASCOM das zu brennende anzeigt, und dieses beginnt nicht mit
54 65 73 74 ...  dann hat es das File falsch gelesen.

Und du siehst auch wieviele Zeichen in einer Zeile (und damit Bytes am
File) notwendig sind, um läppische 16 Bytes Nutzdaten zu beschreiben.

Daraus folgt: Dateigröße ist nicht gleich der Anzahl der Bytes, die dann
tatsächlich zu brennen sind.
Autor: Stefan (Gast)
Datum:

In der ersten Zeile steht:
:100000005465737
also wird die EEP-Datei doch richtig von Bascom gelesen oder?
Es werden aber trotzdem wie oben geschrieben die 862 Bytes angezeigt.
Wenn man nun das Epprom-File in den Controller schreibt steht dort:
"512 Bytes written to EEPROM"
und was ist dann mit den anderen 350 Bytes? Die passen doch dann nicht
mehr in den Controller?
Wie habt ihr denn das Eeprom übertragen? Mit welchem Programm?

Werner schrieb:
> Nimm' dies, das passt :-)

Nein, leider nicht. Zumindest nicht in Bascom. Es werden dort ebenfalls
komischerweise 862 Bytes angezeigt.

Gruß Stefan
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Stefan schrieb:
> In der ersten Zeile steht:
> :100000005465737
> also wird die EEP-Datei doch richtig von Bascom gelesen oder?

Und was wird dir vom BASCOM Brenner angezeigt, was er ins EEPROM brennen
möchte?

Wenn da an der BASCOM Oberfläche irgendwo :100000005465737 auftaucht,
dann hat es die Datei falsch interpretiert. Denn mehr als die Hälfte
dieses :100000005465737 sind die Anweisungen an den Leseteil, wie der
Rest der Zeile zu lesen ist.


Wenn das File korrekt gelesen wird, dann bleibt als zu brennender Inhalt

54 65 73 74  ..... übrig.
Autor: Karl Heinz Buchegger (kbuchegg) (Moderator)
Datum:

Autor: be-cool (Gast)
Datum:

Hallo, ich hatte mit Bascom des gleiche Problem. Nach dem Umbenennen des
eep.files in .hex hat Bascom das aber anstandslos gebrannt.
Autor: Rudi D. (rulixa)
Datum:

be-cool schrieb:
> Hallo, ich hatte mit Bascom des gleiche Problem. Nach dem Umbenennen des
> eep.files in .hex hat Bascom das aber anstandslos gebrannt.

Mit PonyProg, umsonst erhältlich hier:
http://www.lancos.com/prog.html

kann man die *.eep Dateien brennen ohne Tricks.

Habe übrigens heute den Transistortester, handverdrahtet, gebaut.
Hat sofort funktioniert. Der Kontrast ist bei 0V etwas hoch , man sieht
die Punkte im Hintergrund. 0,4V ist besser.

Einen ganz vorzügliches Produkt! Gratulation Markus Frejek!!

LG Rudi
Autor: Laser_Maus (Gast)
Datum:

Hallo,

ein Super-Gerät, dass ich schon seit langem vermisse.
Auch nachbausicher Dank sehr guter Dokumentation .
Bei einigen Displays hatte ich Probleme mit dem Kontrast, da wäre
anstelle des 1 k Widerstands ein Trimmpoti (oder 2 Widerstände , die man
ausmisst, ) wohl etwas flexibler.

Hab einige (< 100) meist 3-polige Bauteile durchgemessen mit z.T.
fehlender Beschriftung oder fehlenden Daten.

Probleme gab es bei speziellen npn-Transistoren, die ähnlch wie
D-Mos-FET - eine Diode parallel zur C-E-Strecke haben (z.B. BUL38). Auch
wurden ein paar Bauteile als npn Transistor mit Stromverstärkung 0
ausgewiesen (was wohl keinen besonderen Sinn macht)ohne Ube Angabe. Auch
haben einige Bautiele ein U be von über 4V (vermutlich eher eine Art
Zenerdiode). Vielleicht kann man auch einen Hinweis ausgeben, bei Ube >
1V (Darlington?) bzw > 2V (unerkanntes Bauteil).
Aber bei 98% der getesteten Transistoren (Junction/Mos)keine Probleme,
nur scheint mir die Stromverstärkung etwas hoch. Ich weiss nicht, wie
sie intern berechnet wird und ob z.B. das Ube berücksichtigt wird.

Widerstände wurden sehr genau ermittelt (in den meisten Bereichen mit ca
1%), Kondensatoren hatten bei mir einen um ca 1/3 zu hohen Wert ( ich
hab aber nur zwischen 1 nF und 20nF gemessen, mag aber auch an meinem
Aufbau liegen.

Bei Diodenmessungen wäre eventuell ein Hinweis bei Ud < 0,25 V
Shottky/Germanium sinnvoll, bei U d > 0,75 V Verdacht auf Zenerdiode
(die haben meist eine geringfügig höhere Flussspannung).

Gruss Laser_Maus
Autor: Hubert G. (hubertg)
Datum:

ATmega8 neuerer Fertigung und ATmega8A benötigen andere Werte in der
main.c
Ich komme mit den nachfolgenden Werten ganz gut hin.
unsigned int H_CAPACITY_FACTOR EEMEM = 262;     //  Standardwerte für
M8A
unsigned int L_CAPACITY_FACTOR EEMEM = 177;     //  Standardwerte für
M8A

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net