Guten morgen
Hoffe bin hier richtig, Habe mich nicht richtig mit mikrocontr..
flashbausteine ect.. beschäftigt . Auf jeden fall ich will was nachbauen
was ich im internet gefunden habe. Auf der bauteil liste steht ein
Atmega8l 8Au , die Hex datei hat aber eine größe von 294 kb.
Passt das , hab versucht mich im internet durch zu lesen und hab das so
verstanden das der besagte atmega aber nur 8 Kb hat oder bringe ich da
was durch einnander ?
Welchen atmega müßte ich den nehmen für das hex file?
Danke schon mal im vorraus.
Christian wrote:
> was ich im internet gefunden habe. Auf der bauteil liste steht ein> Atmega8l 8Au , die Hex datei hat aber eine größe von 294 kb.
Dann kann es nicht für den ATmega8 sein.
Ein Hexfile ist etwa 2,8 * BIN groß, also max 22kB darf es sein.
> Welchen atmega müßte ich den nehmen für das hex file?
Genau den, der als Target beim Generieren des Hexfile spezifiziert
wurde.
Die Größe des Hexfiles ist schnurz, das Target muß stimmen.
Peter
Hex-Files sind immer grösser als das darin enthaltene Programm.
Zum einen werden für jedes Datenbyte im Controller 2 Bytes in der .hex
benötigt (Darstellung als lesbarer Hex-Wert); zum anderen sind da noch
Adressangaben und Prüfsummen dabei, die auch noch mal ihren Senf
dazuwerfen.
Wobei mir der Grössenunterschied von 8 <-> 294 kB auch etwas gross
vorkommt.
Das passt ganz sicher nicht. Oder sind das vielleicht die ASM/C Sourcen?
Die können schon mal beachtlich größer sein - wobei bei > 200 k Code auf
8 k Flash schon seeehr viele Kommentare drin sein müssen ;-)
Gib doch einfach mal einen Link zu dem Projekt, dann wird man dir
sicherlich sagen, welchen Controller du benötigst.
Matthias
>Wie finde ich die target größe raus ?
Beim Kompilieren spuckt der Compiler die Speicherbelegung aus (RAM, ROM
etc). Vergiss auch nicht die Optimierung anzuschalten (-02 oder -Os)
ich habe nur noch die hex datei , dann in einer world pad datei welche
pins ich wo anlöten muss. den page wie quell code ect.. gibs nicht mehr
. Hab das jetzt seid knapp 2 jahre auf dem rechner liegen und wollte es
jetzt mal ausprobieren .
Achso! Du hast irgendein Programm aus dem Internet, bei dem es die Seite
nicht mehr gibt.(dann sag das doch)
Was macht das Programm?
Wenn es für nen ATMEGA8 kompiliert wurde müsste es aber auch in einen
solchen reinpassen.
Die Größe ist tatsächlich sehr ungewöhnlich. Abgesehen davon ist die
höchste Speicheradresse in der Datei 41FF, der Speicher des ATMega8 geht
aber nur bis 1FFF (Byte-Adressen). Also kann es schonmal nicht für einen
ATMega8 sein.
bin mir jetzt nicht sicher, aber das hex file Sieht mich überhaupt nicht
nach einem Programm aus. Es sind ständig wiederhohlende Blöcke drin.
Sieht für mich mehr wie daten für EPROM/Flash aus als wie ein Programm.
z.b. irgendwelche Kennlinien usw.
Habe hier kein Atmel Hex File um zu vergleichen.
Benedikt K. wrote:
> Das ist keine Hex Datei. Keine Ahnung was das ist, aber das Muster da> drin sieht über die ganze Datei verteilt recht konstant aus.
Das stimmt allerdings, da ist irgendwie ein Muster drin. Ich hatte es im
Hex-Editor offen, da sieht man es zwar nicht auf den ersten Blick, aber
es ist schon irgendwie komisch...
Außerdem müsste, wenn es tatsächlich eine AVR-Hex-Datei sein sollte, der
erste Befehl ein Sprungbefehl sein. "5A70" entspricht aber keinem
AVR-Sprungbefehl-Opcode...
Der Wert 0x7F kommt überdurchschnittlich oft vor (11,6% aller Werte).
Wenn man sich das ganze grafisch betrachtet, sieht man auch mehrere
linear ansteigende Sequenzen.
Entweder ist das also irgendeine große Bin Datei mit Daten für ein
EEPROM, oder es ist irgendeine proprietäre Projekt/Objektdatei von
irgendeinem Compiler.
Das "Muster" in der Datei erkennt man am besten mit nem Hex-Editor, 13
Spalten (Also 13 Bytes pro Zeile).
Das Erste Byte scheint dabei eine Art Zähler zu sein...
Autsch. Da ist mehr falsch als richtig:
- AVcc und AGND sind nicht angeschlossen, Reset auch nicht.
- Bildformate
- Die Hex Datei ist keine und passt erst recht nicht in den mega8.
-> Sinnlos zu versuchen das jemals zum Laufen zu bekommen, wenn mehr
falsch als richtig ist und es keine weiteren Infos dazu gibt.
Peter wrote:
> Ach hier schon eine etwas kleinere Firmware zu sein.
Die scheint ja stark nachgefragt zu sein: Immerhin 16x in 2 Jahren
runtergeladen, und vermutlich kein einziges mal nachgebaut.
Mal ne andere frage , was kann man den noch so tolles mit so nen Atmega
anstellen ? Bin ab nächste woche Di Arbeitssuchend und suche auch direkt
ein neues hobby.
Christian wrote:
> Mal ne andere frage , was kann man den noch so tolles mit so nen Atmega> anstellen ?
Mal ne andere Frage: Wie kann man in diesem Forum, in dem es an
Beispielen für Anwendungen nur so wimmelt, diese Frage stellen...?
Vom Blinklicht bis zur Atomraketenabschussrampensteuerung so ziemlich
alles.
Ich würde aber an deiner Stelle mal mit dem Blinklicht anfangen, direkt
nach dem nächsten Bewerbugsgespräch.
Gute idee fragt sich woher man uran bekommt das waffenfähig ist !
Trozdem allem danke , muss mein patenkind von der schule abholen ,
danach schaue ich mal ob ich hier in der suche ein gutes buch finde für
den anfang .
> > Der Mega8 hat 64 kb (oder anders ausgedrückt 8 kB).
Nö. Es sind 8 KB
Hast ja recht....
Also nochmal:
Der Mega8 hat 64 Kb (oder anders ausgedrückt 8 KB).
Peter wrote:
>> Nö. Es sind 8 KB> Warum ein grossen K, kilo ist ist doch eine kleines
Auweia, da hat wieder jemand in der Schule nicht aufgepasst... Speicher
werden praktisch immer binär adressiert und ihre Größe ist deshalb auch
i.d.R. eine Potenz von 2. Der Speicher eines ATMega8 hat 8192 Bytes, das
sind nicht 8*10^3 (8000) sondern 8*2^10 Bytes. Und 2^10 ist entweder ein
großes K oder (nach IEC60027) ein Ki (für KiBi, Kilo Binary).
das mit den 1024 war mir klar, Aber das bis jetzt die unterscheidung mit
k und K gemacht wurden nicht. Ich dachte es macht jeder so wie er denkt.
Das Ki ist auch bekannt gewesen.
> Ich dachte es macht jeder so wie er denkt.
Das Denken sollte man den Pferden überlassen, die haben den grosseren
Kopf....
Das geht zu oft in die Hose, wenn man bei solchen Definitionen nicht
sich exakt an die Standards hält. Versuch mal ne Marslandung zu
berechnen und verwechsle dann 1000 und 1024. Sowas ähnliches hat die
NASA ja schon geschafft.
Peter wrote:
> Ich dachte es macht jeder so wie er denkt.
Tja, es machen tatsächlich viele alles so, wie sie es denken...
Deshalb gibt es hier im Forum auch zig Beiträge von Leuten, die ihre
Controller angeblich mit 16 mHz betreiben. Ungefähr ein Befehl pro
Minute ist doch auch was, gell?
Ich bin davon ausgegangen wenn es schon eine Definition von k(1000) und
K(1024) gibt, das man ja gar nicht Ki hätte einführen müssen. Bei die
SI-Prefixen habe ich das grosse K auch noch nicht gefunden.
Peter wrote:
> Ich bin davon ausgegangen wenn es schon eine Definition von k(1000) und> K(1024) gibt, das man ja gar nicht Ki hätte einführen müssen.
Doch. Früher, als Speicher noch klein und niedlich waren, brauchte man
nur ein "kilo" um alles verfügbare zu beschreiben. Deshalb hat man zur
Unterscheidung das K groß geschrieben, um darauf hinzuweisen, dass es
eben kein dekadisches kilo, sondern ein binäres sein soll. Aber dann
wurden die Speicher größer und es gab erhebliche Diskussionen wegen den
Präfixen Mega (M) und Giga (G), die nunmal schon in der dekadischen
Schreibweise Großbuchstaben sind. Und genau auf dieser Problematik setzt
die IEC60027-2 auf, die ein einheitliches Präfix-System für alle
Größenordnungen vorschlägt.
> Bei die SI-Prefixen habe ich das grosse K auch noch nicht gefunden.
Es ist auch afaik nie genormt gewesen, sondern war immer ein
inoffizieller Standard, der sich aber weitgehend durchgesetzt hatte. Die
IEC60027-2 enthält auch keine verbindlichen Festlegungen, sondern ist
auch im Prinzip nur ein Vorschlag.
SI-Standards beziehen sich auch im Großen und Ganzen auf physikalische
Größen, und afaik sind weder Bit noch Byte (also praktisch die einzigen
Anwendungsfälle für die binären Präfixe) genormt, weshalb logischerweise
auch die Präfixe nicht durch entsprechende Standards festgelegt sind...
