Anfängerfrage: ROM beschreiben

[Barbara (Gast)]

hallo Forum,

ich fange gerade an mich mit dem internen ROM meines at90s8515 zu
beschäftigen.
im Moment stecke ich aber leider ziemlich fest und bevor ich
weiterprobiere
wollt ich mir einen Tip geben lassen ob ich auf der richtigen Spur bin,
oder
ob ich grundsätzlich was falsch verstehe.

1. meines wissens ist mit ROM das interne EEPROM gemeint.
2. wenn ich es bei der programmierung meines uC mit Konstanten
bespielen
will dann muss ich doch den befehl progmem benutzen, und nach diesem
beispiel
( http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array)
vorgehen.
3. ich benutze das programmers notepad mit winavr und habe das avrsize
plugin eingebunden. wenn ich jetzt
das beispiel von 2. compiliere, dann wird mir bei eeprom size eine null
angezeigt.
4.zum programmieren verwende ich ponyprog und habe bis jetzt immer nur
das hex file auf den uC
aufgespielt - wenn ich auch das eeprom beschreiben will, muss ich dann
auch noch ein anderes file aufspielen?
oder sind noch anderweitige Einstellungen an den verwendeten Programmen
erforderlich?

vielen Dank
und Grüße
Barbara

p.s.:auch noch mal das erwähnte beispiel an dieser stelle


#include <avr/pgmspace.h>

const char foo[] PROGMEM = "Foo";
const char bar[] PROGMEM = "Bar";

PGM_P array[2] PROGMEM = {
    foo,
    bar
};

int main (void)
{
    char buf[32];
    PGM_P p;
    int i;

    memcpy_P(&p, &array[i], sizeof(PGM_P));
    strcpy_P(buf, p);
    return 0;
}

[Rufus T. Firefly (Gast)]

"1. meines wissens ist mit ROM das interne EEPROM gemeint."

Du irrst. Gemeint ist das interne Flash-ROM, das ist was anderes als
das interne EEPROM.

Unter der Prämisse dürften einige der weiteren Fragen sich komplett
erübrigen, oder?

[Barbara (Gast)]

danke dir Rufus

das erspart mir dann wohl nen haufen suchen in die falsche Richtung.

dankbar wäre ich dir noch für jeweils ein stichwort (sprich befehl) zu
eeprom bzw. internem flash ROM. Für letztgenanntes lautet es progmem,
lieg ich da richtig ?

danke
Barbara

[Rufus T. Firefly (Gast)]

Ja, progmem ist zu verwenden, um Datenzugriffe auf das Flash-ROM
durchzuführen. Das liegt an der verkorksten Harvard-Architektur der
AVRs.

Wie auf das EEPROM zuzugreifen ist, verrät Dir unter anderem dieser
Link hier http://www.mikrocontroller.net/wiki/AVR-GCC-Tutorial#EEPROM

[Barbara (Gast)]

danke dir
Babs

[Matthias (Gast)]

Hi

was bitte ist an der Harvard-Architektur des AVR "verkorksten"?

Wir hätten heute weit weniger Software-Sicherheitsprobleme wenn Intel
anno dazumal bei ihrem 8086 Design auf eine Harvard-Architektur gesetzt
hätten.

Matthias

[Rufus T. Firefly (Gast)]

Du verwechselst 8086 und 4004.

Auch andere Hersteller haben erfolgreich die Harvard-Architektur
vermieden: MOS/Rockwell, Zilog, Motorola ... um nur einige Vorväter aus
der 8-Bit-Zeit zu nennen.

Nein, die Software-Sicherheitsprobleme haben nichts mit der
Harvard-Architektur zu tun. Sonst hätte der Mac sie ja auch schon immer
haben können, oder der beliebte VC Amiga ...

[Matthias (Gast)]

Hi

90% der heutigen Softwarebugs die das Einschleusen von fremden Code
ermöglichen haben ihre Ursache im Überschreiben des Stacks und
anschließedem Ausführen von Code der in irgendeinen Buffer geschrieben
wurde.

In erster Näherung ist das ein Programmierfehler. In zweiter aber auch
eine Unzulänglichkeit der Hardware. Daten sollen ja schließlich nicht
ausgeführt werden. Nicht umsonst haben AMD und auch andere Hersteller
(AFAIK auch IBM beim PowerPC) mitlerweile ein spezielles Bit in ihre
Seitentabellen aufgenommen die das ausführen von (Daten- und Stack-)
Seiten verhindert.

Zusätzlich ermöglicht die Harvard-Architektur einen schnellere
Ausführung von Programmen da beim Zurückschreiben von Daten bereits der
nächste Befehl geholt werden kann. Nicht umsonst ist der L1-Cache
moderner Prozessoren in Harvard-Architektur ausgelegt.

BTW:
Auch der Mac (bzw. dessen Nachfolger) hat die selben Probleme mit der
vN-Architektur wie x86. Nur gibt es wesentlich weniger Angriffsziele
und damit auch weniger Angriffe.

Matthias

[T.Stütz (Gast)]

[ironie on] softwareschutz per hardware ... [ironie off]

Das größte Problem bei den "Pufferüberläufen" ist meines
erachtens die Unfähigkeit der Programmierer bei einem
mem/strcpy zu prüfen wieviel bytes kopiert werden sollen und ob der
Platz reicht.

'tschuldigung mußte mal gesagt werden ...

Gruss

PS: Ich nehme mich da NICHT aus.

[Thomas X. (Gast)]

der hauptgrund für harvard-architekturen sind auch nicht irgendwelche
sicherheitsaspekte. die idee ist viel mehr die, dass daten und
codezugriffe parallel ablaufen können, da zwei verschiedene speicher
mit eigenem bus verwendet werden.

so könnte ein harvard-prozessor bereits einen neuen befehl aus dem
programmspeicher lesen, während zur gleichen zeit ein ergebnis in den
datenspeicher zurück geschrieben wird.

[thkais (Gast)]

Übrigens ist auch der MCS-51 ein "Harvard"-Controller. Er wird nur
meistens mit einem schaltungstechnischen Trick (&-Gatter) zu einer von
Neumman-Maschine modifiziert (vergewaltigt?).

[Jürgen (Gast)]

Vergewaltigt?
Hat wohl eher den Grund, die Anzahl externer Bauteile zu verringern.

Und um es mit Andrew S. Tanenbaum zu sagen: Software und Hardware eines
Rechners sind logisch äquivalent. Wieso also darüber streiten?
Alles ist relativ ;)

[Gunter (Gast)]

>Alles ist relativ ;)
wenn Alles relativ wäre, gäbe es nichts, zu dem es
relativ sein könnte !!!

[Oliver (Gast)]

@ Gunter,

diese Aussage ist ganz klar falsch falsch!