Auf dem Kriegsfuss mit AVR

[Dimitri (Gast)]

Hallo Leute,

ich muss sagen, irgendwie kann ich mich mit AVRs nicht so richtig 
anfreunden. Vielleicht bin ich zu verwöhnt vom microchip-Angebot an IDE, 
Compilern, Debuggern und Code Samples für lau bzw nix.

Ich muss aber leider bei AVR bleiben, den in einem geldbringenden 
Erzeugnis steckt eben dieser Käfer, und zwar ATMEGA644.

Ich frage mich bloss,

1. wieso für den Bootloader der Platz in der Mitte des Programmspeichers 
reserviert ist (ab 0x7000 bei 64kB)
2. wieso die Blockgrösse für das Selfprogramming ganze 512 Bytes beträgt 
(beim vergleichbaren PIC18F4620 sind das handliche 64 Bytes)
3. WAS falsch mache, dass meine ISP-Routinen (page erase, page write) 
alle ausgeführt werden, ohne das sich nur ein Byte verändert (keine 
Lockbits sind gesetzt)
4. warum das Setzen von Fuses immer so ein umständlicher Akt ist, 
während bei microchip in C18 alle Bits in #pragma-Anweisungen festgelegt 
werden.

Auch das Platzieren von Konstanten im Programmspeicher an einer 
vorgegebenen Stelle geht mit C18 mit einer einfachen #pragma-Anweisung, 
wo hingegen mit WinARV.... naja

Neulich musste ich feststellen, dass die Daten im internen EEPROM meines 
ATMEGA644 unsicher sind. Spannung aus, Spannung ein => und schon sind 
ein paar Bits anders... :-( Und das sind ja Kalibtationsdaten für 
Sensoren!

Dann dachte ich mir, ich speichere sie einfach im Programmspeicher per 
ISP. Nach mehreren "Kopfständen" kein Erfolg. Wie gesagt, ISP-Routinen 
werden ohne Ergebnis ausgeführt. Jetzt lege ich die Daten einfach 
explizit im Programm ab. Sie werden dann mitkompiliert.

Also liebe Leute, wenn mich ein AVR-Liebhaber vom Gegenteil überzeugen 
möchte, dass mit AVR alles in Butter ist, dann lasse ich mich gerne des 
Besseren belehren. Ehrlich.

/Dimitri

[(prx) A. K. (prx)]

Dimitri wrote:

> 1. wieso für den Bootloader der Platz in der Mitte des Programmspeichers
> reserviert ist (ab 0x7000 bei 64kB)

Das Ende des Speichers liegt bei 0x8000. Nix mittendrin. Nur rechnet 
Atmel das in Codeworten. Obacht: Atmel tut das zwar, die GCC binutils 
jedoch rechnen in Bytes. Für die liegt der Bootloader also in diesem 
Fall an 0xE000.

> 2. wieso die Blockgrösse für das Selfprogramming ganze 512 Bytes beträgt
> (beim vergleichbaren PIC18F4620 sind das handliche 64 Bytes)

Hat mit der Flash-Technik zu tun. Warum auch nicht. Für Kleinkram ist 
das Flash nicht zuständig.

> 4. warum das Setzen von Fuses immer so ein umständlicher Akt ist,
> während bei microchip in C18 alle Bits in #pragma-Anweisungen festgelegt
> werden.

Geht in WinAVR auch. Nur anders. #pragma Statements sind 
Compiler-Erweiterungen, was beim GCC nicht so sinnig ist. Ist auch 
irgendwo dokumentiert.

> Auch das Platzieren von Konstanten im Programmspeicher an einer
> vorgegebenen Stelle geht mit C18 mit einer einfachen #pragma-Anweisung,
> wo hingegen mit WinARV.... naja

Und wozu braucht man das?

> Neulich musste ich feststellen, dass die Daten im internen EEPROM meines
> ATMEGA644 unsicher sind. Spannung aus, Spannung ein => und schon sind
> ein paar Bits anders... :-(

Ist mir noch nie passiert. Was freilich passiert, wenn man grad ins 
EEPROM schreibt und justament zu dem Zeitpunkt den Strom klaut. Das 
passiert den PICs aber dann garantiert auch.

Dabei nützlich: Brownout-Detector verwenden. Dann läuft er nicht Amok 
wenn Spannung zu dünne.

[(prx) A. K. (prx)]

Dimitri wrote:

> Dann dachte ich mir, ich speichere sie einfach im Programmspeicher per
> ISP. Nach mehreren "Kopfständen" kein Erfolg.

Bei den Typen mit Bootloader-Sektion kann man aus der normalen
Flash-Sektion nicht ins Flash schreiben.

[Tim (Gast)]

>Neulich musste ich feststellen, dass die Daten im internen EEPROM meines
>ATMEGA644 unsicher sind. Spannung aus, Spannung ein => und schon sind
>ein paar Bits anders... :-( Und das sind ja Kalibtationsdaten für
>Sensoren!

Passiert wenn irgendwann auf das Eeprom zugegriffen wurde 
(lesen/schreiben egal) und die Spannungsversorgung langsam 
zusammenbricht und kein Brownout-Detector eingeschaltet ist. Auch wenn 
zum zeitpunkt des Ausschaltens kein(!)
Zugriff erfolgt. Im Datenbatt wird die verwendung des Brownout-Detectors
empfohlen. Hatte seither keine Probleme mehr.

[Peter D. (peda)]

Dimitri wrote:

> 2. wieso die Blockgrösse für das Selfprogramming ganze 512 Bytes beträgt
> (beim vergleichbaren PIC18F4620 sind das handliche 64 Bytes)

Damit das Flashen schneller geht.


> 3. WAS falsch mache, dass meine ISP-Routinen (page erase, page write)
> alle ausgeführt werden, ohne das sich nur ein Byte verändert (keine
> Lockbits sind gesetzt)

Die müssen mit in den Bootsektor.
Bei meinem Bootloader habe ich deshalb einen API-Call dafür eingebaut.


> 4. warum das Setzen von Fuses immer so ein umständlicher Akt ist,
> während bei microchip in C18 alle Bits in #pragma-Anweisungen festgelegt
> werden.

Ja, das ist unschön. Andere MCs machen das besser, indem immer mit dem 
internen RC gestartet wird und dann bequem per Software die Taktquelle 
umgeschaltet werden kann. Dann brauchts auch keine Fusebits mehr, die 
man in blöde Stellungen bringen kann.


> Auch das Platzieren von Konstanten im Programmspeicher an einer
> vorgegebenen Stelle geht mit C18 mit einer einfachen #pragma-Anweisung,
> wo hingegen mit WinARV.... naja

Liegt am GCC, nicht am AVR.


> Neulich musste ich feststellen, dass die Daten im internen EEPROM meines
> ATMEGA644 unsicher sind. Spannung aus, Spannung ein => und schon sind
> ein paar Bits anders... :-( Und das sind ja Kalibtationsdaten für
> Sensoren!

Ja, bei Nutzung des EEPROM muß man beim AVR immer das Brownout-Reset 
enablen!


> Jetzt lege ich die Daten einfach
> explizit im Programm ab. Sie werden dann mitkompiliert.

Das ist ja auch die richtige Methode, wenn die Daten schon zur 
Compilezeit bekannt sind.


Peter

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> dass die Daten im internen EEPROM meines ATMEGA644 unsicher sind.
> Spannung aus, Spannung ein => und schon sind ein paar Bits anders...
Ururalter Designfehler :-/
Oft zerhagelts das Byte 0, es kann aber auch andere erwischen.
Brown-Out Detection einschalten, dann gehts.

[Dimitri (Gast)]

Hallo Lothar,

ja, tatsächlich ist es mir mehrmals mit dem Byte #0 passiert. Dann stand 
plötzlich wieder 0xFF drin. Es war aber schon so, dass zu diesem 
Zeitpunkt ausschliesslich READ-Befehle zum Einsatz kamen, keine 
WRITE-Operationen.

Es geht mir schon besser.

Ich danke allen, die mir den wertvollen Tipp über den Brown-Out gaben.

/Dmitri

[Tim (Gast)]

>ja, tatsächlich ist es mir mehrmals mit dem Byte #0 passiert. Dann stand
>plötzlich wieder 0xFF drin. Es war aber schon so, dass zu diesem
>Zeitpunkt ausschliesslich READ-Befehle zum Einsatz kamen, keine
>WRITE-Operationen.

Ja, eine einzige Read operation (z.b. nach dem reset) reicht um
bei abfallender Spannung das Eeprom zu zerlegen.

[Dimitri (Gast)]

>> Auch das Platzieren von Konstanten im Programmspeicher an einer
>> vorgegebenen Stelle geht mit C18 mit einer einfachen #pragma-Anweisung,
>> wo hingegen mit WinARV.... naja

> Und wozu braucht man das?

Ich möchte zum Beispiel einen Satz von Konstanten "auf ewig" speichern. 
ich habe einen #pragma-Block mit vordefinierten Platzhaltern im 
Programmspeicher

#define FLASH_DATA_ADDR 0x0040
#pragma romdata const_tbl = FLASH_DATA_ADDR
const rom unsigned int _Uexc[4] = {4095, 4095, 4095, 4095};
const rom unsigned int _TComp[4] = {2048, 2048, 2048, 2048};
const rom unsigned int _ZERO[4] = {2048, 2048, 2048, 2048};
const rom unsigned int _ROMSN_L;
const rom unsigned int _ROMSN_M;
const rom unsigned int _ROMSN_H;
const rom unsigned int FineZeroFlag; 
const rom unsigned char dummy[32];
#pragma romdata

und eine Struktur im RAM

struct _flashdata
{
  unsigned int Uexc[4];
  unsigned int TComp[4];
  unsigned int ZERO[4];
  unsigned int ROMSN_L;
  unsigned int ROMSN_M;
  unsigned int ROMSN_H;
  unsigned int FineZeroFlag; 
  unsigned char dummy[32];
};

struct _flashdata flash; // 64
unsigned char *pflashdata = &flash;

CODEwritePage(FLASH_DATA_ADDR, &flash);

CODEreadPage(...) ist gar nicht nötig, weil ich dann direkt auf 
Konstanten zugreifen.

Nun erfahre ich, dass so was mit AVR gar nicht möglich ist, weil die 
ISP-Routinen ausschliesslich aus dem Bootbereich agieren können. 
Richtig? Zum Nachteil für mich.

Ja, es gibt ja noch das EEPROM. Aber es gibt auch viele abgespeckten 
PIC-NibelKarossen, die keins haben.

[Michael H* (Gast)]

ich weiß nicht, ob dich ganz verstanden habe, aber vllt hilft dir das:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Vereinfachung_f.C3.BCr_Zeichenketten_.28Strings.29_im_Flash
http://www.helicron.net/avr/avrgcc/flashdata.php

[(prx) A. K. (prx)]

Fuses im Code: 
http://www.gnu.org/savannah-checkouts/non-gnu/avr-libc/user-manual/group__avr__fuse.html

[Tim (Gast)]

Bedingt durch die Architektur des AVR ist ein "direkter" ROM Zugriff
nicht möglich. Wenn du Strukturen aus dem ROM laden möchtest,
nimm memcyp_P. Beim Eeprom ist das nicht viel anders.

[Peter D. (peda)]

Dimitri wrote:

> Nun erfahre ich, dass so was mit AVR gar nicht möglich ist, weil die
> ISP-Routinen ausschliesslich aus dem Bootbereich agieren können.
> Richtig? Zum Nachteil für mich.

Nö, es ist möglich:

1. Du hast keinen Bootloader, dann kannst Du dem GCC-Linker sagen, daß 
die SPM-Routine im Bootsektor zu plazieren ist.

2. Du hast einen Bootloader, dann muß dieser eine Routine enthalten, die 
die Applikation aufrufen kann.
Diese Methode benutze ich.
Die Daten plaziere ich dann in einem Bereich, der außerhalb der 
Applikation liegt.


Peter

[Dimitri (Gast)]

> ich weiß nicht, ob dich ganz verstanden habe, aber vllt hilft dir das:
> http://www.mikrocontroller.net/articles/AVR-GCC-Tu...
> http://www.helicron.net/avr/avrgcc/flashdata.php

Hallo Michael,

ja, so mache ich es, wenn ich meine Daten explizit im Programm ablege. 
Mir ging's darum, ob und wie ich diese Werte zu Runtime überschreiben 
kann. Denn es braucht kleine Korrekturen.

Danke trotzdem
/Dimitri

[Karl H. (kbuchegg)]

Hmmm.

Man mag mich konservativ nennen.
Aber genau das war ja der ganze Hintergedanke bei einer 
Harvard-Architektur: Die strikte Trennung zwischen Code und Daten, damit 
es eben für das Programm keine Möglichkeit gibt, sich selbst zu 
beschädigen. Benutzt man nun das Flash als eine Art 'Daten-Speicher', 
dann hebelt man diesen Gedankenansatz komplett aus.
Ich kann noch verstehen, dass man Daten, die tatsächlich konstant sind 
im Flash platziert, weil woanders kein Platz dafür ist. Aber eine 
Flash-Benutzung im Sinne einer Variablen die verändert werden kann, geht 
mir gegen den Strich. Genau dafür gibt es das EEPROM.

Flash-Beschreiben sollte in meinen Augen aussschliesslich einem 
Bootloader vorbehalten sein und auch in diesem Sinne verwendet werden.

[(prx) A. K. (prx)]

Tim wrote:

> Bedingt durch die Architektur des AVR ist ein "direkter" ROM Zugriff
> nicht möglich. Wenn du Strukturen aus dem ROM laden möchtest,
> nimm memcyp_P. Beim Eeprom ist das nicht viel anders.

Das hat nur bedingt mit AVR zu tun, denn der Prozessor kann das sehr 
wohl. Und seine PICs können das genauso gut oder genauso schlecht. Wie 
einfach das aus Sicht des C-Programmierers geht ist Sache des Compilers. 
Und da ist GCC als von-Neumann-Compiler schwach. Auf 8bit Controller 
spezialisierte Compiler hingegen haben weniger Probleme, auch nicht bei 
AVR.

[Dimitri (Gast)]

>
> 1. Du hast keinen Bootloader, dann kannst Du dem GCC-Linker sagen, daß
> die SPM-Routine im Bootsektor zu plazieren ist.
>

Hallo Peter,

ja, klar geht es irgendwie. Ich will ja hier auch nicht ewig rumjammern.

Meinst du etwa diese Anweisung:

--section-start=.ISPSTUFF=BOOTLOADERRANGE

wobei ISPSTUFF für ispstuff.c und BOOTLOADERRANGE für etwas ab 0xE000 
steht.

/Dimitri

[(prx) A. K. (prx)]

Karl heinz Buchegger wrote:

> Aber genau das war ja der ganze Hintergedanke bei einer
> Harvard-Architektur: Die strikte Trennung zwischen Code und Daten

Das ist eher ein netter Nebeneffekt. Tatsächlich hat das in diesem 
Kontext weit mehr mit der praktischen Realisierung der Hardware zu tun. 
Wenn man Codezugriffe und Datenzugriffe durch getrennte Initiatoren und 
Adressräume leicht auseinander halten kann, dann lassen sich diese sehr 
einfach auf getrennten Bussen parallel abwickeln, ohne den Core unnötigt 
aufzublasen und ohne adressabhängiges Zeitverhalten in Kauf nehmen zu 
müssen.

Einen gemeinsamen Adressraum in getrennte Busse aufzuteilen ist deutlich 
aufwändiger, weshalb kleine Controller mit einem einzigen Adressraum 
sich gerne auf einen Bus beschränken und im Vergleich dementsprechend 
Zeit verlieren.

[Dimitri (Gast)]

> Man mag mich konservativ nennen.
> Aber genau das war ja der ganze Hintergedanke bei einer
> Harvard-Architektur: Die strikte Trennung zwischen Code und Daten, damit
> es eben für das Programm keine Möglichkeit gibt, sich selbst zu
> beschädigen. Benutzt man nun das Flash als eine Art 'Daten-Speicher',
> dann hebelt man diesen Gedankenansatz komplett aus.
> Ich kann noch verstehen, dass man Daten, die tatsächlich konstant sind
> im Flash platziert, weil woanders kein Platz dafür ist. Aber eine
> Flash-Benutzung im Sinne einer Variablen die verändert werden kann, geht
> mir gegen den Strich. Genau dafür gibt es das EEPROM.
>
> Flash-Beschreiben sollte in meinen Augen aussschliesslich einem
> Bootloader vorbehalten sein und auch in diesem Sinne verwendet werden.

Hallo Karl Heinz,

vielleicht sollte ich etwas ausführlicher werden, worum es mir geht.

Die EMV AKA die elektromagnetische Verträglichkeit ist so ein Ding. Wenn 
es dumm läuft, sind die Daten im RAM beschädigt. Natürlich kann man 
diese immer wieder checken. Das finde ich aber zu lästig.

Wenn die Daten aus dem fixen Speicher gelesen werden, sind sie genau so 
sicher wie das Programm selbst. Ein Reset per Watchdog, Brown-Out oder 
sonst kann ihnen nichts anhaben. Man muss diese nicht neu 
initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs, was 
bei einem EEPROM etwas anders aussieht. Man nimmt die Daten aus dem 
EEPROM und legt diese im RAM ab, wo sie EMV-mässig unsicher sind.

vielleich bin ich nur leich paranoid, was nach meiner Erfahrung mit dem 
kaputten EEPROM wohl verständlich ist.

Ja, bei mir besteht die Notwendigkeit, ein paar Werte nach der fertigen 
Kalibration unseres aus bis zu 36 Drucksensoren bestehenden Produkts 
nachzukorrigieren.

/Dmitri

[so nicht (Gast)]

EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn 
mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren 
und kann nach Hause gehen. Falls der interne Brownout nichts taugt, resp 
man dem nicht traut, sollte man einen externen verwenden. zB die MCP111 
Serie von microchip. Laeuft mit weniger als 1uA.

[Nico (Gast)]

> Ja, bei mir besteht die Notwendigkeit, ein paar Werte nach der fertigen
> Kalibration unseres aus bis zu 36 Drucksensoren bestehenden Produkts
> nachzukorrigieren.

Aber wieso legst du die Daten dann nicht einfach im EEProm ab? Wie 
gesagt, mit Brownout detection gibt es da auch keine probleme mit 
"verschwundenen" Daten. Wenn du so extrem auf Nummer sicher gehen 
willst, dann ist das Flash sowieso nicht der richtige Punkt um solche 
Daten abzulegen.

Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu 
benutzen, dann kann es dir auch nicht passieren das während eines 
Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man 
muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS 
jetzt die aktuellen Daten sind.

[Dude (Gast)]

>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>benutzen, dann kann es dir auch nicht passieren das während eines
>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>jetzt die aktuellen Daten sind.
Das ist Quatsch!

[Dimitri (Gast)]

> EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn
> mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren
> und kann nach Hause gehen.

Ja klar. Wenn mir ein kleines EMV-Labor für die Zwischentests zur 
Verfügung stünde, würde ich die Sache auch viel entspannter betrachten.

/Dimitri

[Karl H. (kbuchegg)]

Dimitri wrote:

> Wenn die Daten aus dem fixen Speicher gelesen werden, sind sie genau so
> sicher wie das Programm selbst. Ein Reset per Watchdog, Brown-Out oder
> sonst kann ihnen nichts anhaben.

Ich würd mal sagen: Im EEPROM sind sie genauso sicher.
OK. Es gibt da ein Problem aber es ist bekannt wie man das lösen kann.

> initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs,

Das du dich da mal nicht täuscht :-)

[Dimitri (Gast)]

> Aber wieso legst du die Daten dann nicht einfach im EEProm ab? Wie
> gesagt, mit Brownout detection gibt es da auch keine probleme mit
> "verschwundenen" Daten.

Hallo Nico,

also, wenn ich das Projekt neu auflegen hätte können, dann würde ich 
sowieso nur mit PIC machen. Die Makefile von avr-gcc ist mir zu 
kryptisch. Da lobe ich mir mein MPLAB mit C18 nach dem 
LPT-Port-Dongle-Ärger mit einem uralten IAR-compiler, wegen dem ich auch 
auf eine 600MHz-Rechner angewiesen war (der einzige, wo diese Krücke 
lief)

Ich habe es vergessen zu erwähnen, dass ich dieses Projekt sozusagen 
geerbt habe. Das einzig wenige, was ich darin ändern konnte, war der 
Umstieg von ATMEGA8535 (auf den Kalender guck und sich totlach) auf 
ATMEGA644.

Ich denke, wenn der Tipp mit dem Brown-Out haut, bin ich ganz zufrieden.

/Dimitri

P.S. Ich will da keinen Glaubenskrieg vom Zaun brechen. Ich gebe mich 
nur widerwillig mit AVRs ab und fühle mich bei PICs viel besser 
aufgehoben.

[Dimitri (Gast)]

>> initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs,

> Das du dich da mal nicht täuscht :-)

Wie meinen? Ich muss auf diese Konstanten keine Pointer spitzen und 
keine Functions aufrufen wie pgm_read_word(&Offset[idx]);. Für mich ist 
das ein Direktzugriff.

/Dimitri

[Peter D. (peda)]

Dimitri wrote:

> also, wenn ich das Projekt neu auflegen hätte können, dann würde ich
> sowieso nur mit PIC machen. Die Makefile von avr-gcc ist mir zu
> kryptisch.

Es geht auch ohne Make, ich haben mir dafür eine Batch geschrieben.
Man muß darin nur dem AVR-Typ festlegen, das geht leider nicht im 
C-File.
Oder man läßt sich das Make vom AVRStudio erzeugen.
Viele programmieren den AVR ohne von Make ne Ahnung zu haben.

> geerbt habe. Das einzig wenige, was ich darin ändern konnte, war der
> Umstieg von ATMEGA8535 (auf den Kalender guck und sich totlach) auf
> ATMEGA644.

Naja, man muß nicht immer gleich den größten Chip nehmen.
Wenns auf dem ATmega8535 zu eng geworden ist, dann dürfte schon der 
ATmega16 wieder ne lange Zeit reichen.

Ich bin mir sicher, daß viele den ATMega128 nehmen, ohne zu wissen 
warum. 128kB klingt halt so schön, man kann dem Chef sagen, man hätte 
was geleistet.
Kann ja keiner reingucken, wie leer der ist. Wenns hochkommt, ist der 
vielleicht zu 10% gefüllt.


> Ich gebe mich
> nur widerwillig mit AVRs ab und fühle mich bei PICs viel besser
> aufgehoben.

Das ist nur menschlich, man findet immer das besser, was man schon 
kennt.
Mir gehts genau umgekehrt, ich kann mich mit den PICs nicht anfreunden.
Ich muß glücklicher Weise auch keine PICs programmieren, ich kann mir 
die CPU selber aussuchen.


Der AVR-GCC ist nicht unbedingt optimal. Er hat allerdings den großen 
Vorteil, daß die ganze Lizensierungsgängelei kommerzieller Compiler 
wegfällt.


Peter

[(prx) A. K. (prx)]

Peter Dannegger wrote:

> Der AVR-GCC ist nicht unbedingt optimal. Er hat allerdings den großen
> Vorteil, daß die ganze Lizensierungsgängelei kommerzieller Compiler
> wegfällt.

Yep, er hat ein paar strukturelle Probleme, die bei 8-bit Zwergen wie 
AVRs und generell bei Harvard-Kisten etwas im Weg stehen. Es gibt fast 
überall bessere Compiler. Egal ob 8, 32 oder 64 Bits. Und oft auch 
besser integrierte proprietäre IDEs.

Aber er hat einen Vorteil: Man kann sich von AVRs über Microchips 
nächstgrössere Klassen (PIC30,PIC32) bis hin zu PCs und 64bit Boliden 
bewegen, ohne sich gross umgewöhnen zu müssen. Wird alles abgedeckt.

Und dann hat man die immer gleiche Struktur von Makefiles und die 
gleichen binutils in den Projekten. Und sofern man sich überhaupt gross 
mit IDEs abgibt, kann man es auch da konform halten.

[Dimitri (Gast)]

> Aber er hat einen Vorteil: Man kann sich von AVRs über Microchips
> nächstgrössere Klassen (PIC30,PIC32) bis hin zu PCs und 64bit Boliden
> bewegen, ohne sich gross umgewöhnen zu müssen. Wird alles abgedeckt.

Das hat aber auch seinen Preis. Ich liess mir sagen, dass so ein System 
von einem "Namenhaften" schnell über 5000 Euro kostet. Oder waren das 
8000?

Sind sie dann nicht auch nur auf einen Lizenzplatz eingeschränkt?

[Nico (Gast)]

>>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>>benutzen, dann kann es dir auch nicht passieren das während eines
>>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>>jetzt die aktuellen Daten sind.
>Das ist Quatsch!

Danke für deinen qualifizierten Beitrag. Möchtest Du den vielleicht auch 
noch weiter ausführen oder hast Du dich schonwieder in deiner Trollhütte 
versteckt?

[(prx) A. K. (prx)]

Das "Aber er hat einen Vorteil..." war auf GCC gemünzt. Wer bitteschön 
traut sich, 8000 für einen verwursteten und verdongelten GCC zu 
verlangen?

[Dimitri (Gast)]

> Es geht auch ohne Make, ich haben mir dafür eine Batch geschrieben.
> Man muß darin nur dem AVR-Typ festlegen, das geht leider nicht im
> C-File.
> Oder man läßt sich das Make vom AVRStudio erzeugen.
> Viele programmieren den AVR ohne von Make ne Ahnung zu haben.

das mit der batch-Datei hatte ich auch schon. Ob so oder mit dem 
Makefile, ist und bleibt es eine DOS-Welt. Ich will aber nur einen 
"Run"-Button wie in Delphi und den habe ich in MPLAB.

> Naja, man muß nicht immer gleich den größten Chip nehmen.
> Wenns auf dem ATmega8535 zu eng geworden ist, dann dürfte schon der
> ATmega16 wieder ne lange Zeit reichen.

Es war m.E. der einzige, der zum ATMEGA8535 pinkompatibel war. Wie 
gesagt, ich konnte das Layout nicht ändern. Hätte ich es können, dann 
hätte ich einen PIC reingepflanzt. :D

[STK500-Besitzer (Gast)]

>Hätte ich es können, dann hätte ich einen PIC reingepflanzt. :D
Hätte ich eine Platine, die einen PIC erfordert vor mir, würde ich über 
eine AVR-Adapterkarte nachdenken...

[(prx) A. K. (prx)]

Dimitri wrote:

> das mit der batch-Datei hatte ich auch schon. Ob so oder mit dem
> Makefile, ist und bleibt es eine DOS-Welt.

Eher Unix. Da haben die Makefiles ihren Ursprung und das wird bis heute 
innig gepflegt. Wenn auch gern mal mit Metatools wie 
Makefile-Generatoren.

> Es war m.E. der einzige, der zum ATMEGA8535 pinkompatibel war.

Hätte gedacht, die Mega16,32,644 hätten alle das gleichen Pinout.

[Dimitri (Gast)]

A.K. schrieb:

> Das "Aber er hat einen Vorteil..." war auf GCC gemünzt. Wer bitteschön
> traut sich, 8000 für einen verwursteten und verdongelten GCC zu
> verlangen?

Verdongelt? Bei dem Wort kriege ich Hautausschlag. Ich hatte einen 
verdongelten IAR. Grrrrr

[Dimitri (Gast)]

STK500-Besitzer schrieb:

> Hätte ich eine Platine, die einen PIC erfordert vor mir, würde ich über
> eine AVR-Adapterkarte nachdenken...

Danach dachte ich gestern, aber genau umgekehrt. :D

[Dimitri (Gast)]

A.K. schrieb:

> Hätte gedacht, die Mega16,32,644 hätten alle das gleichen Pinout.

So ein Mist aber auch! :D So hätte ich mir den ganzen Migrationskack 
sparen können. Nun bin ich halt der stolze Anwender des grössten Chips 
aus dieser Pinout-Familie. :D

[Gasst (Gast)]

>Die EMV AKA die elektromagnetische Verträglichkeit ist so ein Ding. Wenn
>es dumm läuft, sind die Daten im RAM beschädigt. Natürlich kann man
>diese immer wieder checken.

Am liebsten sind mir die µCs, bei denen der komplette Stack EMV 
geschützt im ROM liegt. RAM ist ja zu unsicher :-)

[Winfried (Gast)]

Genau, wenn man sich auf's Ram nicht verlassen kann, dann wird wegen 
falscher Rücksprungadressen im Stack der wildeste Code ausgeführt. Auf's 
Ram muss man sich also hundertprozent verlassen können. Es sei denn, man 
programmiert keinerlei Calls.

[so nicht (Gast)]

>> EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn
>> mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren
>> und kann nach Hause gehen.
>
>Ja klar. Wenn mir ein kleines EMV-Labor für die Zwischentests zur
>Verfügung stünde, würde ich die Sache auch viel entspannter betrachten.
>

Guter Mann,
wenn du die EMV Vertraeglichkeit nicht hinkriegst bringt nichts mehr 
was. Dann solltest du gar nichts mehr verkaufen, der Aerger ist 
vorprogrammiert. Ruecklaeufe... usw. Es ist nicht schwierig. Nimm dir 
die Zeit das zu lernen. Vielleicht ein Kurs, vielleicht eine Beratung 
beim EMV Labor, vielleicht kostet es was. Was solls. Wenn man glaubt es 
begriffen zu haben macht man einen Test mit dem naechsten Teil, und 
wenn's gut ist war's das solange man sich in der selben 
Produktekategorie aufhaelt.
Viele Leute denken die EMV Tests seien abgehobener Bullshit, laufen aber 
wie selbstverstaendlich mit dem Mobiltelephon im Sack (1Watt @ 1GHz) 
herum und sind sicher dass keine Elektronik durchdreht. Das ist eine 
pure Annahme. Denn ohne EMV Vorschriften und Tests ist das nicht so. 
Ueberlegt Euch mal was alles schiefgehen kann wenn Elektronik 
durchdreht...

[(prx) A. K. (prx)]

Stack im ROM gibt es tatsächlich!

Das Beispiel hat jeder vor der Nase. Den Initialisierungs- und 
Selbsttestcode vom PC-BIOS. Den von heute kenne ich nicht, aber im 
Original (IBM XT) konnte solange kein RAM verwendet werden, bis immerhin 
klar war, dass ein bischen davon tatsächlich funktionierte. Also zeigt 
der Stack-Pointer solange ins ROM. Man weiss ja bei nicht allzu 
komplexem Code, was da drinstehen muss.

[Dimitri (Gast)]

> Guter Mann,
> wenn du die EMV Vertraeglichkeit nicht hinkriegst

mach dir keine Sorgen, ok?

[Hannes Lux (Gast)]

Betreffs EEP-Vergesslichkeit:

Ich habe (bei älteren AVRs ohne BOD) festgestellt, dass immer nur die 
zuletzt adressierte Zelle betroffen war, also die Zelle, auf die das 
Adressregister (eearh:eearl) zeigt. Nachdem ich mir angewöhnt hatte, 
nach jedem Zugriff die Adresse auf eine unbenutzte Zelle zu setzen, 
hatte ich keine Ausfälle mehr. Das war allerdings in ASM.

...

[Karl H. (kbuchegg)]

Dimitri wrote:
>>> initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs,
>
>> Das du dich da mal nicht täuscht :-)
>
> Wie meinen? Ich muss auf diese Konstanten keine Pointer spitzen und
> keine Functions aufrufen wie pgm_read_word(&Offset[idx]);. Für mich ist
> das ein Direktzugriff.

Ähm reden wir vom selben?

Wenn du aufs EEPROM zugreifst, musst du Spezialfunktionen dafür 
benutzen.
Wenn du aufs Flash zugreifst, musst du Spezialfunktionen dafür benutzen.
Wo ist also der Komfortunterschied?

Und ob du eine Datenstruktur im SRAM aus dem Flash oder aus dem EEPROM 
befüllst, ist, wie man in Österreich sagt, ghupft wie ghatscht (völlig 
Wurscht).

[Dude (Gast)]

>>>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>>>benutzen, dann kann es dir auch nicht passieren das während eines
>>>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>>>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>>>jetzt die aktuellen Daten sind.
>>Das ist Quatsch!

>Danke für deinen qualifizierten Beitrag. Möchtest Du den vielleicht auch
>noch weiter ausführen oder hast Du dich schonwieder in deiner Trollhütte
>versteckt?
Wenn du aufmerksam gelesen hättest, wüsstest du, dass bei einem 
Stromausfall nicht zwangsläufig das addressierte Byte korrupt werden 
muss. Welches Byte es erwischt, hängt (fast) ausschliesslich von der 
internen Gatterbschaltung ab!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> dass immer nur die zuletzt adressierte Zelle betroffen war, also
> die Zelle, auf die das Adressregister (eearh:eearl) zeigt.
Nur teilweise korrekt.
Was stimmt ist, dass der EPROM-Pointer zeigt, was kaputt gemacht wird. 
Umgebracht werden die Speicherzellen dann von der anlaufenden 
Lösch-Ladungspumpe (es werden also im Fehlerfall immer nur Bits auf 1 
gesetzt). Und wenn der Adresspointer dann auch so langsam absemmelt, 
kann es beliebige Bits erwischen.

[Karl H. (kbuchegg)]

Dimitri wrote:

>> Oder man läßt sich das Make vom AVRStudio erzeugen.
>> Viele programmieren den AVR ohne von Make ne Ahnung zu haben.
>
> das mit der batch-Datei hatte ich auch schon. Ob so oder mit dem
> Makefile, ist und bleibt es eine DOS-Welt. Ich will aber nur einen
> "Run"-Button wie in Delphi und den habe ich in MPLAB.

AVR-Studio + WinAVR

Du drückst auf einen Button, und den Rest erledigt AVR-Studio.
So what?

Gut, 'brennen' musst du noch selber anstossen :-)

[Skua (Gast)]

Grober EMV Test, einfach ein 230V Relais als Wagnerschen Hammer 
beschaltet an die Zuleitung.

[Nico (Gast)]

>Wenn du aufmerksam gelesen hättest, wüsstest du, dass bei einem
>Stromausfall nicht zwangsläufig das addressierte Byte korrupt werden
>muss. Welches Byte es erwischt, hängt (fast) ausschliesslich von der
>internen Gatterbschaltung ab!

Und deswegen schrieb ich vorher das er Brownout detection verwenden 
soll. Nicht aufmerksam genug gelesen, oder?
Der Ringbuffer dient eher als "transaktionsorientierte Datenbank" um 
dafür zu sorgen das man sich sicher sein kann das die letzte 
Modifikation der Daten komplett durchgeführt wurde. Halt, ganz oder 
garnicht.

[Dimitri (Gast)]

Karl Hinz schrieb:

> Ähm reden wir vom selben?

Nö :-)

denn ich schrieb

Wenn die Daten aus dem fixen Speicher gelesen werden, sind sie genau so
sicher wie das Programm selbst. Ein Reset per Watchdog, Brown-Out oder
sonst kann ihnen nichts anhaben. Man muss diese nicht neu
initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs, was
bei einem EEPROM etwas anders aussieht.

Beim Direktzugriff meinte ich ausschliesslich den Zugriff auf die Datem 
im Programmspeicher. :-)

[Dimitri (Gast)]

> Wenn du aufs Flash zugreifst, musst du Spezialfunktionen dafür benutzen.
> Wo ist also der Komfortunterschied?

Nicht beim MPLAB C18 :-)

Siehe meinen Code bei 26.02.2009 14:47

[(prx) A. K. (prx)]

Auch nicht bei anderen AVR Compilern. Nur GCC tut sich mit 
Adressraumklassifizierung von Pointern schwer.

[Karl H. (kbuchegg)]

Dimitri wrote:
>> Wenn du aufs Flash zugreifst, musst du Spezialfunktionen dafür benutzen.
>> Wo ist also der Komfortunterschied?
>
> Nicht beim MPLAB C18 :-)

Mein Fehler.
Irgendwie geh ich immer davon aus, dass WinAvr, also gcc, benutzt wird.

[MWS (Gast)]

Und um auch was Qualifiziertes & Philosophisches beizusteuern:

Es ist dem AVR so was von wurscht ob der Dimitri nun mit ihm klarkommt 
oder nicht.

Dieser ganze µC Kram basiert darauf, daß man irgendwelche Hürden 
überspringt, umgeht oder Probleme löst die ohne µC gar nicht da wären. 
Jeder hat da so seine Vorliebe.

Aber da dies hier ein nettes Forum, mit netten AVR Benutzern ist, 
bekommt auch jemand der Atmel nicht mag passende Hilfe.

Und da sich der OP das Project ans Bein hat binden lassen, bleibt ihm 
auch gar nix anderes übrig, als da sich mit den Eigenheiten der AVR's 
auseinanderzusetzen, da mag er soviel schimpfen, wie er will ;-)

[Dimitri M. (dimitri)]

Karl heinz Buchegger wrote:
> Dimitri wrote:
>
>>> Oder man läßt sich das Make vom AVRStudio erzeugen.
>>> Viele programmieren den AVR ohne von Make ne Ahnung zu haben.
>>
>> das mit der batch-Datei hatte ich auch schon. Ob so oder mit dem
>> Makefile, ist und bleibt es eine DOS-Welt. Ich will aber nur einen
>> "Run"-Button wie in Delphi und den habe ich in MPLAB.
>
> AVR-Studio + WinAVR
>
> Du drückst auf einen Button, und den Rest erledigt AVR-Studio.
> So what?
>
> Gut, 'brennen' musst du noch selber anstossen :-)

Ja, das kenne ich und habe es bereits im Einsatz gehabt. Dann musste ich 
feststellen, dass eine und dieselbe Installation (AVRStudio + WinAVR) an 
einem PC problemlos lief, während sich das Programm am anderen PC beim 
Compilieren anhängte. Das fand ich zu doof und verzichtete auf AVRStudio 
als IDE. Zum Brennen ist es ganz OK.

Zurzeit bin ich mit der Portable-Version am Werken.  AVRDUDE ist auch 
dabei. "Programmer Notpad" als IDE ist auch ganz OK. Ich konnte die 
Einträge im Tools-Menü entsprechend anpassen.

[Dimitri M. (dimitri)]

Skua wrote:
> Grober EMV Test, einfach ein 230V Relais als Wagnerschen Hammer
> beschaltet an die Zuleitung.

Danke für den Tipp.