Paar Fragen zum ATmega328P

[Walter S. (Gast)]

Hallo,

es war ein Firmware Update durchzuführen und dafür stand ein GALEP-4 zur 
Verfügung. War mein erster µC, der neben dem Programmcode auch noch eine 
Seite mit Einstellungen (u.a. Fuses) hatte. Also das Ding erst mal 
ausgelesen und auch einen Screenshot der Einstellungsseite gemacht.

Das erste Problem: Obwohl es sich beim Speicher um ein Flash handelt, 
lies sich das Update nicht drüber bügeln. Bügeln schon, aber beim Verify 
wurde bereits bei 000-irgendwas gemeckert. Also musste das Flash wohl 
erst gelöscht werden (!?)

Das zweite Problem: Obwohl ich die Einstellungen (Fuses) von der 
Bearbeitung ausgenommen habe, werden die wohl beim Löschen mit gelöscht, 
bzw. verändert.
Denn die Anwendung lief danach zwar, aber mit deutlich angezogener 
Handbremse. Wohl weil man über die Einstellungen bzw. Fuses einen 
Takt-Vorteiler setzen kann. Nach dem Bearbeiten der Einstellungen (zum 
Glück hatte ich einen Screenshot gemacht) lief das Ganze wieder.

Erkenntnis: Drüber bügeln geht nicht und die Einstellungen (Fuses) 
werden beim Löschen zurück gesetzt?

Walter

[Einer K. (Gast)]

Walter S. schrieb:
> Drüber bügeln geht nicht
Vielleicht suchst du den "Chip Erase"

Walter S. schrieb:
> und die Einstellungen (Fuses)
> werden beim Löschen zurück gesetzt?
Beim "Chip Erase" werden nur die Lock Fuses verändert, keine anderen 
Fuses.

Walter S. schrieb:
> GALEP-4
Nie gesehen, so ein Dingen...

[Andreas B. (bitverdreher)]

Walter S. schrieb:
> Also musste das Flash wohl
> erst gelöscht werden (!?)
Eigentlich nicht.
Eher:
Falscher Aufbau (Speisespannung, Kondensatoren?)
Programmiertakt zu hoch

[Pandur S. (jetztnicht)]

Ein chip erase macht alles weg, auch die fuses.

[Veit D. (devil-elec)]

Hallo,

ein Chip Erase löscht keine Fuse. Es löscht je nach Einstellung der 
zuständiger Fuse den EEprom mit, aber davon ist hier keine Rede.

[S. Landolt (Gast)]

Genau!
Anders formuliert:

jetztnicht schrieb:
> Ein chip erase macht alles weg, auch die fuses.

Ein Chip-Erase löscht je nach Einstellung nicht einmal das EEPROM 
("macht das EEPROM nicht weg").

[S. Landolt (Gast)]

Wäre ja auch ein wahnschaffenes Konstrukt - nach jeder Programmänderung 
(per ISP) die Fuses wieder auf den alten Stand setzen zu müssen.

[Peter D. (peda)]

Ich meine auch der Galep5 hat diesen Bug.
Will man z.B. beim AVR nur das Hexfile neu schreiben, stimmen danach die 
Fuses nicht mehr.
Man muß sich einen Screenshot machen und dann vor dem Programmieren die 
Häckchen wieder richtig setzen.

[Wolfgang (Gast)]

Walter S. schrieb:
> Bügeln schon, aber beim Verify wurde bereits bei 000-irgendwas
> gemeckert. Also musste das Flash wohl erst gelöscht werden (!?)

Oder da ist ein Leseschutz drauf ...

[Veit D. (devil-elec)]

Hallo,

hab mir mal die Mühe gemacht, kann jedoch auch nach längerer Suche im 
Netz nichts finden was nach Fuse delete Bug klingt. Das beste was ich 
finde konnte war ein Thread aus 2009, wo ein Galep 4 irgendwelchen Mist 
machte und man das vorher löschen erst aktivieren muss.
Beitrag "ATMega8 an Galep 4"
Ein anderes Problem mit einem Galep 5.
Beitrag "Probleme mit GALEP-5D - speziell: Bauteilkennung"

Ich sage mal so. So richtig toll scheinen Galeps nicht zu sein.  :-)
Wenn ein aktueller Atmel ICE zu teuer ist, kauf dir lieber erstmal einen 
AVRISPmkII Clone. Ist auf jeden Fall zuverlässiger.

[Walter S. (Gast)]

Peter D. schrieb:
> Will man z.B. beim AVR nur das Hexfile neu schreiben, stimmen danach die
> Fuses nicht mehr.
> Man muß sich einen Screenshot machen und dann vor dem Programmieren die
> Häckchen wieder richtig setzen.

Genau so war es hier auch. Die beiden Screenshots zeigen die 
Default-Einstellungen, wenn man den ATmega328P aufruft. Obwohl ich die 
Config Bits abgewählt hatte, wurden die dann mit den 
Default-Einstellungen geschrieben. CKDIV8 setzt wohl einen Vorteiler, 
denn die Anwendung lief nach dem Update in Zeitlupe.

Dann war es noch so, dass der Programmer nach dem Laden des Hex-Files 
den Baustein vergessen hat. Nach der erneuten Zuweisung des Bausteines 
stehen die Fuses dann wieder auf default.

Veit D. schrieb:
> Ich sage mal so. So richtig toll scheinen Galeps nicht zu sein.

Ich sage mal so: Wenn man als Bastler so ein Teil hat, kann man sich 
glücklich schätzen. Das Teil liest und programmiert mir seit Jahren alle 
möglichen Bausteine.

[Peter D. (peda)]

Walter S. schrieb:
> Ich sage mal so: Wenn man als Bastler so ein Teil hat, kann man sich
> glücklich schätzen. Das Teil liest und programmiert mir seit Jahren alle
> möglichen Bausteine.

Bezogen auf die Vielfalt der programmierbaren Teile hat es schon ein 
sehr gutes Preis-Leistungs Verhältnis.

Wir hatte vorher einen super teuren Sprint-Expert. Der Hersteller hat 
den Wartungsvertrag kurz nach dem Kauf gekündigt und einen einfach im 
Regen stehen lassen. Wir haben ihn dann verschrotten müssen.

[MCUA (Gast)]

> Ich sage mal so: Wenn man als Bastler so ein Teil hat, kann man sich
> glücklich schätzen. Das Teil liest und programmiert mir seit Jahren alle
> möglichen Bausteine.
Nur, für jede MCU, auch PLDs usw. hat doch der Hersteller etwas 
passendes parat.

[Einer K. (Gast)]

Walter S. schrieb:
> Ich sage mal so: Wenn man als Bastler so ein Teil hat, kann man sich
> glücklich schätzen. Das Teil liest und programmiert mir seit Jahren alle
> möglichen Bausteine.

Vielleicht....

Mir gefällt das hier beschriebene Verhalten des Galep ganz und gar 
nicht.
Solcherart Überraschungen kann man einfach nicht brauchen.

Zudem scheint es ja wohl kein HVSP und HVPP zu können.(?)
Nicht aus IDEs nutzbar(außer der eigenen).(?)
Debuggen? Auch wohl nicht.

Dazu doch auch noch mit erheblichen Kosten verbunden.

Ok, für den trainierten Servicetechniker, welcher täglich mit anderen 
Chips zu tun hat, mag das was sein....

[Veit D. (devil-elec)]

Hallo,

sollte conitec dann nicht endlich einmal die Fehler beheben? Sind ja nun 
seit paar Jahren bekannt - zumindestens hier im Forum.  ;-)  Oder wurde 
der Fehler noch nicht gemeldet? Also mir ginge es auf den S... wenn ich 
jedesmal die Fuse etc. erneut einstellen müßte. Egal wie oft ich damit 
flashen würde. Zum Glück muss ich mich damit nicht rumärgern. Ansonsten 
mag das ja ein tolles Teil sein, aber so, ne.

[Helmut -. (dc3yc)]

Da kann ich nur die Programmer der Fa. Elnec empfehlen. Der BeeProg+ 
läuft bei mir seit fast 15 Jahren und es gibt immer noch Updates, obwohl 
der Programmer nicht mehr hergestellt wird.

[Walter S. (Gast)]

Arduino Fanboy D. schrieb:
> Mir gefällt das hier beschriebene Verhalten des Galep ganz und gar
> nicht.
> Solcherart Überraschungen kann man einfach nicht brauchen.

Stimmt schon. Wenn man sich allerdings mal die Devicelist anschaut (6067 
Devices), muss man sich nicht wundern, wenn was hakelt:
http://www.conitec.net/german/galep4device_list.htm

Hätte ich nicht sicherheitshalber ein Screenshot der Fuses gemacht, 
könnte ich die Hardware nach dem Update in die Tonne treten. Denn der 
Zustand der Fuses ist nicht veröffentlicht.

> Zudem scheint es ja wohl kein HVSP und HVPP zu können.(?)

Dazu sollte der geneigte Bastler erst mal wissen, was HVSP und HVPP nun 
schon wieder ist.

[Einer K. (Gast)]

Walter S. schrieb:
> Hätte ich nicht sicherheitshalber ein Screenshot der Fuses gemacht,
> könnte ich die Hardware nach dem Update in die Tonne treten. Denn der
> Zustand der Fuses ist nicht veröffentlicht.
Gebranntes Kind?

Walter S. schrieb:
> Dazu sollte der geneigte Bastler erst mal wissen, was HVSP und HVPP nun
> schon wieder ist.
Ach, sich per Fuses vom µC abhängen, geht recht fix.

Spätestens dann man macht man sich kundig und findet HVSP und HVPP.
Und Zack wird der teure Galeb aus der Ecke geholt, und mit der Reparatur 
der Fuses beauftragt.

[Rainer V. (a_zip)]

Walter S. schrieb:
> es war ein Firmware Update durchzuführen und dafür stand ein GALEP-4 zur
> Verfügung.

Ich hoffe mal, man hat dich so nicht einfach zu einem Kunden geschickt! 
Ansonsten kann ich über Galeps eigentlich nichts schlechtes berichten. 
Sie haben bei uns bis zur jeweils neusten Version klaglos gearbeitet. 
Preislich natürlich ehr nicht für den Basteltisch.
Gruß Rainer

[max b. (Gast)]

Walter S. schrieb:
> Wenn man sich allerdings mal die Devicelist anschaut (6067Devices)

wie geht das eigentlich beim hersteller vor sich? 6067 programmierbare 
ics beschaffen, dann die umfangreichen datenblätter studieren, den 
algoritmus für lesen und schreiben programmieren, das ganze dann noch 
ausgiebig testen usw. wie viele leute und jahre braucht man dazu? müsste 
so eine eierlegende wollmilchsau nicht eigentlich ein vermögen kosten?

[Stefan F. (Gast)]

max b. schrieb:
> müsste so eine eierlegende wollmilchsau nicht
> eigentlich ein vermögen kosten?

Das ist ja auch der Fall. Vergleiche das mal mit einem USBASP oder 
ST-Link Klon.

[Spess53 (Gast)]

Hi

Beitrag "Re: Paar Fragen zum ATmega328P"

Wieso ist steht hier im Bild Optionen.png 'Löschen vor der 
Programmierung' abgewählt?

Ich kenne verschiedene GALEPS aus meiner alten Firma und kann eigentlich 
nichts negatives berichten. Aber wenn ich den o.g. Fehler tippe ich eher 
auf Bedienfehler.

MfG Spess

[Walter S. (Gast)]

Spess53 schrieb:
> Wieso ist steht hier im Bild Optionen.png 'Löschen vor der
> Programmierung' abgewählt?

Das ist default so gesetzt. Beide Screenshots zeigen default.

> Ich kenne verschiedene GALEPS aus meiner alten Firma und kann
> eigentlich nichts negatives berichten.

Ich kenne nur den GALEP4 und kann eigentlich auch nichts negatives 
berichten. Wobei ich anmerken möchte, dass ich noch die Software von CD 
verwende. Wie ich eben sehe, gibt es eine neuere Version.

Rainer V. schrieb:
> Ich hoffe mal, man hat dich so nicht einfach zu einem Kunden geschickt!

Da ist nichts mit Kunden, alles reine Bastelei :-)

[Spess53 (Gast)]

Hi
>Das ist default so gesetzt. Beide Screenshots zeigen default.

Also ist dir die Programmierung von AVRs mit dem Galep unbekannt?

Ich habe meiner ehemaligen Firma so etwa seit 2007 Daten für AVRs zur 
Programmierung mit Galebs für die Produktion zu erstellen. Nach Conitec 
dürfte das ein Galep4 sein.

Hast du mal die Programmiereinstellungen unter >File< in einer Datei 
gesichert?

Ich hatte mit diesen Teilen eigentlich nur alle paar Jahre etwas zu tun 
und das war für mich jedes mal ein neuer Krampf. Aber die Einstellungen 
lassen sich problemlos speichern und wieder abrufen. Deshalb auch mein 
Einwand bezüglich 'Bedienfehler'.

MfG Spess

[Walter S. (Gast)]

Spess53 schrieb:
> Hast du mal die Programmiereinstellungen unter >File< in einer Datei
> gesichert?

Ich hatte keine Programmiereinstellungen übermittelt bekommen. Für ein 
Update hatte ich ein HEX-File übermittelt bekommen und wollte das drüber 
bügeln. Damit die Fuses nicht verändert werden, habe ich selbige 
abgewählt. Selbige Abwahl hat aber nichts geholfen.

Irgendwie ungut, wenn man für die Programmierung eines µC außer dem Code 
noch weitere Informationen benötigt, die nicht im Code verankert sind. 
Wenn die weiteren Informationen verloren gehen, kann das Teil in die 
Tonne.

[Stefan F. (Gast)]

Walter S. schrieb:
> Irgendwie ungut, wenn man für die Programmierung eines µC außer dem Code
> noch weitere Informationen benötigt, die nicht im Code verankert sind.

Die Fuses kann man durchaus in den C Quelltext schreiben, sie landen 
dann auch im elf File. Aber da man HEX Dateien nur in den Flash laden 
kann, werden die Fuses da dann eben nicht mehr drin stehen.

[Spess53 (Gast)]

Hi

>Irgendwie ungut, wenn man für die Programmierung eines µC außer dem Code
>noch weitere Informationen benötigt, die nicht im Code verankert sind.
>Wenn die weiteren Informationen verloren gehen, kann das Teil in die
>Tonne.

Hast du eigentlich einmal getestet unter 'Datei->Speichern unter...' 
deine Einstellunge zu Speichern? Wir haben in meiner ehemaligen Firma 
mehr als 50 verschieden Dateien mit unterschiedliche Einstellung zur 
Verfügung (die nichts Vergessen).

Dafür hatte ich auch nur ein Hex-File zur Verfügung. Na ja, die 
Fuse-Bits habe ich im Kopf. Dann gespeichert und die Kollegen konnten 
programmieren.

MfG Spess

[Walter S. (Gast)]

Spess53 schrieb:
> Hast du eigentlich einmal getestet unter 'Datei->Speichern unter...'
> deine Einstellunge zu Speichern?

Da stellt sich zuerst die Frage nach dem Format:

- Binär-Datei
- Intel Hex
- Motorola Hex
- Jedec Fuse <- was ist das denn?
- Galep-Projektdatei

Das ist aber nicht wirklich die Lösung. Wenn ich z.B. einen neuen µC 
bekomme und eine Hex-Datei drauf laden soll, woher kommt die Information 
für die Fuses?

[Spess53 (Gast)]

H

Deine Fragen verstehe ich langsam nicht mehr. Du hast geschrieben:

>Wenn man als Bastler so ein Teil hat, kann man sich
>glücklich schätzen. Das Teil liest und programmiert mir seit Jahren alle
>möglichen Bausteine.

Andererseits

>Da stellt sich zuerst die Frage nach dem Format:

>- Binär-Datei
>- Intel Hex
>- Motorola Hex
>- Jedec Fuse <- was ist das denn?
>- Galep-Projektdatei

Dann öffne doch mal deine 'Hex-Datei' in einem Editor. Wenn jede Zeile 
mit einem ':' beginnt hast du Intel-Hex. Bei Motorola beginnt jede Zeile 
mit einem 'S'.

Jedec Fuse-> wird für GALs, PALs und Konsorten benötigt.

MfG Spess

[MCUA (Gast)]

Fuses sep. speichern, das kann doch nicht so schwer sein.

[Spess53 (Gast)]

Hi

>Fuses sep. speichern, das kann doch nicht so schwer sein.

Die Galep-Dateien enthalten eh die Flash- und ggf. die EEPROM-Inhalte. 
Da kommt es auf ein paar Bytes für Fuses-/ Security-Bits und ähnliches 
nicht mehr an.

MfG Spess

[Rainer V. (a_zip)]

Walter S. schrieb:
> Wenn ich z.B. einen neuen µC
> bekomme und eine Hex-Datei drauf laden soll, woher kommt die Information
> für die Fuses?

Das ist doch höchstens eine "akademische" Frage. Wann jemals 
materialisiert ein Controller samt Hex-Datei auf meinem Tisch?? Die 
nötigen Infos habe ich doch entweder selbst oder sie werden irgendwie 
dazu gegeben. Immerhin weiß ich ja auch, was ich mit dem Controller 
machen will.
Gruß Rainer