www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Unbenutztes Register im 8-Bit Atmel?


Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine mal gelesen zu haben, das es bei den Atmel 8-Bit Prozessoren 
bzw. vielleicht nur bei einigen Modellen, Register gibt, die man 
benutzen kann um dort Werte abzulegen.

Ich meine jetzt natürlich nicht die Register R0 bis R31. Die sind klar.

Ich glaube es waren auch nicht die unbenutzten I/O-Register, zu denen 
das Datenblatt sagt, das sie niemals geschrieben werden dürfen.

Hat jemand mal sowas gelesen und weiss noch wo und was dort genau steht?

Ich habe das Problem, das ich einen 16-Bit Wert ablegen muss, der zur 
Laufzeit effizient benutzbar sein soll. EEPROM oder RAM kann ich 
definitiv dafür nicht benutzen. EEPROM ist zu langsam. Und RAM geht in 
dem Zusammenhang nicht, weil ich gerade einen Zeiger speichern will, der 
in das RAM zeigt. Das würde sich in den Schwanz beissen, da ich ja die 
Adresse des Zeigers in das RAM, der im RAM abgelegt ist ja wiederum 
kennen müsste. Lege ich also den im RAM ab, müsste ich wenigstens dessen 
Adresse kennen usw. Klar?

Wäre wirklich sehr nett, wenn da jemand einen Tip hätte.

Autor: w. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na klar legst Du den ins RAM, aber eben an eine fixe Adresse und dann 
kannst du überall ins RAM damit hinzeigen. Nur auf sich selbst macht das 
keinen Sinn, geht aber auch

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ATMega 1280/1281 besitzen z.B. GPIOR0..2 als allg. nutzbare Register in 
IO-Bereich.
Was hindert dich im RAM feste Speicherstellen für den Zeiger zu 
benutzen?

Angaben zum Controller und Programmiersprache wären sehr hilfreich.

MfG Spess

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.dseg
ZEIGER:
 .byte 1
.cseg


add
subb

LDS TMP, ZEIGER ;Pointer dirket laden

cp
brne


STS ZEIGER, TMP ; Pointer wieder zurückspeichern

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@W.
>Na klar legst Du den ins RAM, aber eben an eine fixe Adresse
Gerade das will ich eben nicht. Im allgemeinen würde ich das natürlich 
so machen.

@Läubi
Dein Code ist schon klar (ist ja der normale Weg), aber dann liegt ja 
der Zeiger im RAM. Und das will ich ja nicht.

Ich schrieb: Und RAM geht in dem Zusammenhang nicht, weil ich gerade 
einen Zeiger speichern will, der in das RAM zeigt.

Das ist, wie mir Eure Antworten zeigen nur die halbe Begründung.
Es geht darum, das sämtliche im RAM abgelegten Werte verschieblich 
sein sollen. Mein ominöser Zeiger soll auf den ersten dieser Werte 
zeigen, von dem aus dann auf alle weiteren zugegriffen wird.
D.h. ich kenne keine absolute Adresse in dem RAM.
Das erstemal lade ich diese Adresse vom EEPROM, aber da ich den Zeiger 
sehr oft brauche wäre es ineffizient, den jedesmal aus dem EEPROM zu 
laden.

Das mit den GPIO ist eine Lösung, aber leider nur für einige (sogar 
ziemlich viele) Modelle. Leider aber z.B. nicht für den 162er.

Hat noch jemand eine Idee?

Autor: Ulli Vex (vex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die vom Timer 1 z.B. .... kann man hier auch im Tut. nachlesen

mfg.

Autor: Registersuche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulli K.
>Die vom Timer 1

Geht leider nicht, da die Timer benutzt werden. Auch die andere 
Peripherie wird benutzt.

Autor: Matthias Kölling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde die Startadresse immer so wählen, dass der Zeiger immer noch 
vorne dran paßt. Dann spricht auch nichts dagegen, diesen Zeiger aus dem 
EEPROM zu laden und ins RAM zu legen, wenn alle anderen Werte dahinter 
abgelegt werden.

Gruß Matthias

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias

Ich bin nicht ganz sicher ob ich Dich verstehe.
>Ich würde die Startadresse immer so wählen...

Das würde heissen, das die Startaddresse nicht beliebig sein kann,
weil ja immer wenigsten Platz für den Zeiger sein muss.
Egal ob vorne, hinten oder mittendrin.
Das aber geht nicht, bzw. ist eine Einschränkung die ich nicht will.

Der Zeiger soll garnicht RAM liegen. Der gesamte Bereich muss 
verfügbar bleiben.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist, wie mir Eure Antworten zeigen nur die halbe Begründung.
>Es geht darum, das sämtliche im RAM abgelegten Werte verschieblich
>sein sollen. Mein ominöser Zeiger soll auf den ersten dieser Werte
>zeigen, von dem aus dann auf alle weiteren zugegriffen wird.
>D.h. ich kenne keine absolute Adresse in dem RAM.

Das klingt nach dynamischen Listen mit dynamischen Längen.

Ich mache das dann so, dass ich der Liste eine Referenz voranstelle.
Beispielsweise besteht deine Liste aus x-Elementen mit mit verschiedenen 
Längen.
Liste1:  x1[0..L1]
Liste2:  x2[0..L2]
Liste3:  x3[0..L3]
...
Liste9:  x9[0..L9]   (letzte Liste. Max 9 stück möglich)
Dann lege ich eine Struktur mit folgendem Inhalt an:
- Anzahl max Listen
- Start Liste1
- Start Lsite2
- Start Liste3
- ...
Also für das Beispiel sieht das dann so aus:
9,&x1,&x2,&x3,...,&x9

Diese Referenz musst du natürlich so speichern, dass du weißt, wo diese 
Referenz beginnt.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm...gibt es einen bestimmten Grund, dass dein gesamtes RAM 
verschiebbar sein muss? Wenn nicht, dann könntest du am Anfang einen 
nicht-verschiebbaren Bereich definieren, in den du dann eben diesen Wert 
speicherst. Ansonsten solltest du darüber nachdenken, dein Konzept 
dahingehend zu ändern, dass eben ein nicht-verschiebbarer Bereich am 
Anfang irgendwie möglich wird.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Der Zeiger soll gar nicht RAM liegen. Der gesamte Bereich muss verfügbar 
>bleiben.

Und wo bleibt dein Stack? Evtl. den Stack nicht am  RAMEND 
initialisieren, sondern ein paar Bytes darunter. Die freien 
Speicherplätze oberhalb des Stacks benutzen.

MfG Spess

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias
>Das klingt nach dynamischen Listen mit dynamischen Längen.
Mit Listen hat das nichts zu tun. Aber selbst wenn, dann wäre es so, als 
wenn der Beginn der beschreibenden Struktur verschieblich sein muss.

@ mr.chip
>Hmm...gibt es einen bestimmten Grund, dass dein gesamtes RAM verschiebbar sein 
muss?

Ja, den gibt es.

@ Spess53
>Und wo bleibt dein Stack?
Der wird an einer Stelle relativ zu dem fraglichen Zeiger angelegt.

Ich möchte bitte nochmal auf die Ausgangsfrage zurückkommen:
Hat vielleicht noch jemand eine Idee, die sich auf die Frage nach einem 
Register bezieht?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht solltest du erstmal erklären, was du vorhast.
Da kommen dann vielleicht Antworten die dir weiterhelfen.
Sonst wirst du nicht mehr erwarten können, als du schon gehört hast...

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias
>Vielleicht solltest du erstmal erklären, was du vorhast.

Ich will einen Zeiger aus dem EEPROM lesen und in einem Register oder 
Ähnliches, das aber kein GPIO sein darf (weil das einige Modelle nicht 
können), ablegen. Hingegen will ich den Zeiger nicht im RAM an einer 
festen (zur Assemble-Zeit bekannten) Adresse ablegen. Sämtliche 
Peripherie muss weiter benutzbar bleiben.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und warum tut es keine normale (Pointer)Variable?
Die wird zwar im (internen) RAM abgelegt, aber, mein Gott, zwei Bytes...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann ordne dem Zeiger ein/zwei feste Register zu. Ich verstehe zwar auch 
nicht wozu das Ganze eigentlich gut sein soll und sehe keinen konkreten 
Anwendungszweck bei dem das Sinn macht.

>@ Matthias
>>Vielleicht solltest du erstmal erklären, was du vorhast.

Deine Antwort beantwortet nicht die Frage. Fürwas benötigst du den 
ganzen Aufwand ? Die Frage läuft darauf hinaus das man öfters ein Brett 
vorm Kopf hat und sich in eine viel zu komplizierte Lösung eingeschossen 
hat ohne das Offensichtliche dabei zu sehen. Ergo: erkläre dein gesamtes 
Vorhaben im kompletten Kontext.

Gruß Hagen

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber, mein Gott, zwei Bytes...

Sehe ich auch so. Pack den Zeiger doch unter den Stack, der ist ja eh 
variabel groß.

Wenn Du dann Dein gesamtes RAM adressieren musst, dann adressierst Du 
halt den Stack mit und Deinen Zeiger auch. Richtig Sinn macht das aber 
nicht.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist schwer das im Text 'rüberzubringen, aber mit allem schuldigen 
Respekt und entsprechender Höflichkeit:

Ich bin ja dankbar dafür, dass Ihr Euch Alternativen überlegt.
Aber bedenkt bitte und seid versichert, dass ich mir selbst genau 
überlegt habe, welche Frage ich stelle.

Bitte geht einfach von der Ausgangsfrage aus. Wozu ich das dann brauche 
ist eine ganz andere Frage, die ich (immer noch höflich und respektvoll 
gesagt) hier nicht diskutieren möchte.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bitte geht einfach von der Ausgangsfrage aus. Wozu ich das dann brauche
>ist eine ganz andere Frage, die ich (immer noch höflich und respektvoll
>gesagt) hier nicht diskutieren möchte.

Wir wollen deine Gedanken auch nicht in Frage stellen, sondern einfach 
wissen was du vorhast. Sonst können wir dir keine sinnvollen Antworten 
dazu geben, weil dann mehr geraten bzw in Blaue hinein geantwortet 
werden muss. Es geht auch nicht darum, das wir hier (auf Teufel komm 
raus) Alternativen suchen wollen, sondern wir verstehen einfach nicht, 
was das soll und wozu das nötig ist. Demzufolge werden wir auch keine 
weiteren Antworten geben können.

Also zwei Möglichkeiten:
1)
Du sagst nicht was du (konzeptionell) vorhast, und gibst dich mit den 
Antworten zufrieden.

2)
Du erzählt, was du konzeptionell vorhast (musst ja das Projekt nicht 
verraten), und dann können wir das nachvollziehen und Lösungsvorschläge 
bringen....


PS: Ich habe auch schon Beiträge verfasst, in denen ich Hilfe benötigt 
habe. Dort habe ich auch erklärt, was ich vorhabe, ohne zu "verraten" 
was ich genau bauen/konstruieren will...

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Der Zeiger soll garnicht RAM liegen. Der gesamte Bereich muss
>>verfügbar bleiben.
>>ist eine ganz andere Frage, die ich (immer noch höflich und respektvoll
>>gesagt) hier nicht diskutieren möchte.

Registersucher,

Kein Mensch will Dir hier in die Karten gucken, oder geistiges Eigentum 
klauen, keine Sorge!
Aber den GESAMTEN RAM zu okkupieren geht eben nicht (wie mehrfach gesagt 
wurde), weil Du dann keinen Platz für den Stack mehr hast.
Und 2-Bytes oberhalb des Stack für deine Zwecke fix zu reservieren ist 
eine sinnvolle Antwort auf Deine Frage. Tu gedanklich doch einfach so, 
als wäre Dein Stack eben 2Byte grösser, wo soll da das Problem sein?

Wenn Du mit einem Anliegen kommst, das in den Augen der meisten 
erfahrenen Programmierer erstmal absurd erscheint, dann musst Du schon 
gestatten, dass nach dem Hintergrund gefragt wird.

Jochen Müller

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.equ  mein_pointer_hi = high(RAMEND)
.equ  mein_pointer_lo = low(RAMEND)
.equ  mein_stackanfang_hi = high(RAMEND-2)
.equ  mein_stackanfang_lo = low(RAMEND-2)

So in der Art.
Dein Pointer steht dann sicher an einer fixen Adresse und der Stack 
wächst nach unten. Effektiv ist Der Stack dann eben 1 Word grösser.

Jochen Müller

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klingt nach betriebsystem.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
>klingt nach betriebsystem.

Na, das wäre z.B eine Möglichkeit.

@ Jochen
.equ geht nicht, da dann der Pointer an einer festen Stelle liegt.

>weil Du dann keinen Platz für den Stack mehr hast

Stack ist vorhanden. Er liegt nur eben nicht an einer festen Stelle.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas W. wrote:
> klingt nach betriebsystem.

Dann ist es allerdings völlig unverständlich, warum die Variablen des 
Betriebssystems nicht an konstanten Adressen liegen dürfen. Ich behaupte 
mal, bei Windows ist das so.


Peter

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum behältst du den blöden Zeiger nicht einfach in XH:XL, wenn du ihn 
nirgends abspeichern kannst?

Ansonsten: Wie schon zehnmal gesagt: Denk dir, die letzten beiden Bytes 
deines RAMs seien kaputt/nicht existent/was auch immer und leg den 
Zeiger dadrinne ab. Die restliche Programmlogik tut dann so, als obs 
diese beiden Adressen garnicht gäbe.

Autor: Thomas Mahn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ All
Also die Antworten die ich hier lese haben ja wirklih nichts mit Frage 
im ersten Post zu tun. Da muss ich dem Poster schon recht geben. Und was 
er damit anfangen will ist auch egal. Weil es nämlich definitv ausser 
den R0-R31, den GPIO und den Kontrollregistern für die UARTS und Timers 
usw. keine Möglichkeit gibt irgendwo noch was zu speichern. Die reserved 
Register können auch nicht benutzt werden. Also vergiss es.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Mahn wrote:
> Weil es nämlich definitv ausser
> den R0-R31, den GPIO und den Kontrollregistern für die UARTS und Timers
> usw. keine Möglichkeit gibt irgendwo noch was zu speichern.

Das ist uns allen ja schon lange klar.


> Also vergiss es.

Nun man wollte eben über diese Antwort hinaus behilflich sein.
Aber wenn die Hilfe nicht erwünscht ist, dann muß es bei dem:

"Also vergiss es."

bleiben und gut is.


Peter

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

nicht deswegen, sondern alles wird benutzt und ram muss dynamisch sein. 
deswegen.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht dir nur darum, den gesamten verwendeten Speicher zu 
"verschieben", oder?

Verwende einfach den Stackpointer dafür, dann kann dir der Compiler auch 
noch alle Arbeit abnehmen.

Also: Programm einfach komplett ohne Globale Variablen schreiben, alles 
auf den Stack. Vor dem Programmstart Stackpointer entsprechend 
initialisieren, und alle verwendeten Adressen sind dann relativ zu dem.

Und die ganze Adressberechnung im Hintergrund macht der Compiler.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1) Größere µC habe als Zeiger auf GOT (global offset table) etc ein 
eigenes GPR, dass dafür dient und von der Applikation nicht verwendbar 
ist.

2) Ich vermute mal es geht um Atmal AVR (Atmel hat auch 8051). Du kannst 
den Wert per Bootloader ins Flash schreiben und per LPM effizienter 
drauf zugreifen als auf EEPROM.

3) Ich verstehe immer noch nicht, warum das Ding nicht im internen RAM 
an einer fixen Adresse stehen kann. Im internen RAM kann man bei AVR 
doch eh nix drehen, was Startadresse etc. angeht. Wenn es ein 
Memory-Management sein soll, kämen die anderen Daten eh in ne andere 
Section.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Johann
Ja, es jandelt sich um die AVRs.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher,

Ich mache trotzdem nochnmal eine Anlauf, weil es trotz längerem Erwägen 
einfach schlichtweg nicht einleuchtet was Du an den bisherigen Ideen zu 
bemängeln hast. Ich argumentiere mal anders herum:

Du kaufst einen AVR für Dein Projekt und der hat z.B. 8192 Byte SRAM zu 
bieten. So. Dafür entwirfst Du nun Dein Projekt. Ok.

Wenn der AVR nun aber werkseitig nur 8190 statt 8192 Byte SRAM gehabt 
hätte, dann hätte also Dein ganzes Projekt nicht funktioniert? Und wäre 
auch niemals zum klappen zu bringen, nur wegen dieser 2 Byte???
Sorry, das kann einfach niemand glauben.

Was hindert Dich denn nun KONKRET daran, einfach zu zu tun, als hätte 
der AVR eben nur 2-Byte weniger SRAM als im Datenblatt stehen?

Viele Leute haben sich hier die Zeit genommen, für DICH Vorschläge zu 
machen, die hätten eine nachvollziehbare Antwort auf diese BERECHTIGTE 
Frage absolut verdient! Kein Mensch möchte sich gerne veralbern lassen!
Und DU bist nun mit einer venünftigen Erklärung am Zug!

Jochen Müller

Autor: Marvin M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn im Datenblatt kein Speicher für solche Zwecke ausgewiesen ist, dann 
geht sowas eben nicht.
Abgesehen davon sind die I/O-Register auch so etwas ähnliches, wie RAM - 
auch wieder mit einer festen Adresse, aber das willst Du ja nicht.
Und mit "illegalen Speicherstellen" (analog zu den "illegalen Opcodes" 
bei manchen µP) kannst Du auch nix anfangen - die könnten bei einer 
überarbeiteten Release des µC plötzlich wieder weg sein.

Mir fällt nur eine Antwort ein: Dein völlig konfuses Konzept ist auf 
einem AVR nicht realisierbar.

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht soll die Software auch auf uCs mit mehr RAM laufen ohne neu 
kompiliert zu werden? Wie auch immer.

Wenn ich es richtig verstanden habe, will der Fragensteller den Pointer 
nicht im Flash ablegen, weil der Zugriff zu lange dauert, oder? Wieviele 
Takte spart man bei einem Zugriff auf den RAM?

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen

>was Du an den bisherigen Ideen zu bemängeln hast

1. Sie beziehen sich nicht auf die ursprüngliche Frage
2. Sie setzen voraus das ich in meinem Programm eine feste Adresse für 
irgendwas habe.

Da sich die Fragen darauf fokussieren, was ich denn gegen nur zwei Byte 
im RAM habe, möchte ich noch folgendes erläutern: Die Anzahl von Bytes 
ist hier gar nicht entscheidend. Es könnten auch 10 sein und das gäbe 
kein Problem. Das Problem ist vielmehr, das überhaupt eine 
Speicherstelle fest kodiert im Programm vorhanden ist.

Wie sicherlich einsichtig ist, würde das sofort gehen, wenn ich den 
fraglichen Zeiger in zwei der Register R0 bis R31 halten könnte. Dann 
bräuchte es auch keine im RAM feststehende Adresse.

Das Problem ist nun, das ich bereits alle Register verwende. Ich kann 
zwar, wenn es darauf ankommt, mal kurz ein Registerpaar auf dem Stack 
ablegen, aber ich kann es nicht dauernd dort halten, weil ich öfter den 
eigentlichen Inhalt von R0 bis R31 brauche als diesen Zeiger.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wie sicherlich einsichtig ist, würde das sofort gehen, wenn ich den
>>fraglichen Zeiger in zwei der Register R0 bis R31 halten könnte. Dann
>>bräuchte es auch keine im RAM feststehende Adresse.

Ich kapiere es einfach nicht...
Die Register haben DOCH AUCH FESTE Adressen.
Warum soll es also in Registern gehen, an festen SRAM-Adressen aber 
nicht?


Jochen Müller

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am besten wir lassen es...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:

> Das Problem ist nun, das ich bereits alle Register verwende. Ich kann
> zwar, wenn es darauf ankommt, mal kurz ein Registerpaar auf dem Stack
> ablegen, aber ich kann es nicht dauernd dort halten, weil ich öfter den
> eigentlichen Inhalt von R0 bis R31 brauche als diesen Zeiger.

Dein Programm verwendet also einen Stack. Und wie initialisierst du den, 
wenn in deinem Programm keine fest kodierten Speicherstellen vorhanden 
sein dürfen?

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen

>...an festen SRAM-Adressen aber nicht?
Das liegt an der Forderung an das Projekt. Es soll keine festen Adressen 
geben. Sie müssen verschieblich sein, ohne das das Programm neu 
assembliert wird, indem man die fraglichen Adressen im EEPROM ablegt.

>Register haben DOCH AUCH FESTE Adressen
Mag sein, aber das Projekt verlangt ja auch nicht das Register 
verschoben werden können.

Stell Dir doch mal folgendes Szenario vor:
Ein Bereich im RAM soll beliebig verschoben werden können.
Er enthält irgendwelche Werte.
Du lädst also aus dem EEPROM dessen Adresse im RAM.
Die Werte in dem Bereich addressierst Du über einen Offset der fest im 
Programm kodiert ist, zu dem Du dann noch die Anfangsadresse addierst.

Du kannst natürlich diesen Offset auch in dem RAM, in dem 
verschieblichen Bereich speichern. Aber sobald Du die Adresse nicht mehr 
in einem der CPU-Register hast, weisst Du nicht mehr wo Du zugreifen 
musst.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan

>Dein Programm verwendet also einen Stack. Und wie initialisierst du den

Indem ich die Stack-Startadresse aus dem EEPROM lese und dann in das 
Stackpointeregister schreibe.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus dieser Erklärung entnehme ich, das du KEINERLEI Variablen (außer der 
r0..r31) verwendest? Bzw verwenden DARFST/MUSST/KANNST...

Sehe ich das richtig?

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Du kannst natürlich diesen Offset auch in dem RAM, in dem
>>verschieblichen Bereich speichern. Aber sobald Du die Adresse nicht mehr
>>in einem der CPU-Register hast, weisst Du nicht mehr wo Du zugreifen
>>musst.

Du sollst deinen Pointer ja auch in
2 RESERVIERTEN BYTES SRAM halten, DIE NICHT VERSCHOBEN WERDEN.

Du stellst Dich einfach dumm, und TUST SO, als hättest Du nicht 32 
Register, sondern 34. Die beiden zusätzlichen liegen eben einfach im 
SRAM an einer IMMER FESTEN STELLE. Lediglich die Befehle zum Zugriff 
lauten etwas anders, also LDS/STS anstatt LDI etc.

DU BASTELST DIR EINFACH ZUSÄTZLICHE REGISTER, das ist der ganze Trick.
Dem Rest der Software LÜGST DU EINFACH VOR, den nichtverschieblichen 
SRAM-Bereich (wo dein Pointer steht) GÄBE ES SCHLICHTWEG NICHT.

Jochen Müller

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias
>Aus dieser Erklärung entnehme ich, das du KEINERLEI Variablen (außer der
>r0..r31) verwendest?
>Sehe ich das richtig?

Nein, nicht ganz. Die Variablen die ich verwende sollen in meinem 
Programm als Offset zu dem fraglichen Zeiger kodiert sein.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen

>Du sollst deinen Pointer ja auch in
>2 RESERVIERTEN BYTES SRAM halten, DIE NICHT VERSCHOBEN WERDEN.

Das habe ich schon verstanden. Aber das widerspricht eben der Forderung, 
das alles RAM frei konfigurierbar ist. Das wäre es nicht, wenn es auch 
nur eine fest kodierte Adresse gäbe. Weil dann dieser Bereich wo der 
Zeiger steht nicht verwendet werden dürfte.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Variablen die ich verwende sollen

Und wo und wie werden die abgelegt?

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias

>Und wo und wie werden die abgelegt?

Bitte verzeih', aber was an:
"Die Variablen die ich verwende sollen in meinem
Programm als Offset zu dem fraglichen Zeiger kodiert sein."

war unklar?

Sie werden im RAM per STS/LDS benutzt.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>nur eine fest kodierte Adresse gäbe. Weil dann dieser Bereich wo der
>>Zeiger steht nicht verwendet werden dürfte.

Du hast aber etwas weiter oben selbst gesagt, es käme nicht darauf an ob 
nun ein paar Byte weniger SRAM verfügbar sind oder nicht. Warum stört es 
dann, wenn 2 Bytes SRAM nicht verwendet werden dürfen?

Geht das eigentlich um eine praktische Anwendung, oder ist das eher ein 
theoretischen Konzept einer Architektur? Nur dann wären Deine 
Einschränkungen nämlich überhaupt einsehbar.

Jochen Müller

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das Problem ist nun, das ich bereits alle Register verwende. Ich kann...

Mal ehrlich, selbst bei großen Programmen ist es bei mir noch nicht 
vorgekommen, daß ich alle Register benötigt habe. AVRs sind mit 32 
Registern mehr als üppig ausgestattet. Also wenn sich da nicht 2 für 
diesen Zweck finden lassen, solltest du vielleicht mal deinen 
Programmierstil überprüfen.

MfG Spess

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebs auf...

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen

>>>nur eine fest kodierte Adresse gäbe. Weil dann dieser Bereich wo der
>>>Zeiger steht nicht verwendet werden dürfte.

>Du hast aber etwas weiter oben selbst gesagt, es käme nicht darauf an ob
>nun ein paar Byte weniger SRAM verfügbar sind oder nicht. Warum stört es
>dann, wenn 2 Bytes SRAM nicht verwendet werden dürfen?

Nun gut. Ich hätte präziser formulieren sollen:
"Weil dann irgendein Bereich, nämlich der wo
Zeiger steht, nicht verwendet werden dürfte."

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen

>Geht das eigentlich um eine praktische Anwendung

Ja.

Autor: ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da will wohl einer so ne Art Kopierschutz entwickeln...
...das wird nix!
aber man kann ja mal die Adressbereiche durchprobieren. ev. gibts ja 
noch verborgene Register. Die haben aber sicher seiteneffekte... Also 
nix was man nutzen könnte.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist mit den

EIND
RAMPZ

Registern im IO-Space?
Solange Du kein externes RAM verwendets und eicalls vermeidest, sind die 
doch ungenutzt.

Jochen Müller

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mensch, lager den Zeiger doch auf einen externen RAM-Baustein aus!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da du offenbar jede Resource jedes Microcontrollers der AVR Serie 
entweder bereits anderweitig verwendet hast oder weil nicht auf allem 
Modellen verfügbar nicht verwenden darfst, dann suchst du also nach 
einer Resource, die noch nie jemand verwendet hat und die daher 
höchstwahrscheinlich niemand kennt.

Also: Hol dir ein FPGA deiner Wahl, baue die darin den gewünschten AVR 
Controller auf und füge die fehlende Resource hinzu.

Oder stelle fest, dass, wenn alle Resourcen bereits verwendet oder per 
Vorgabe unverwendbar sind, per Definition keine mehr übrig sein können.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jochen Müller wrote:

> EIND
> RAMPZ

Gibt es beim '162 m.W. auch nicht.

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es hat leider niemand meine Frage beantwortet. Rein aus Interesse: Um 
ca. wieviele Takte ist der Zugriff auf den SRAM schneller als auf den 
Flash?

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen
>Was ist mit den EIND RAMPZ Registern im IO-Space?

Die werden leider gebraucht. Und RAMPX und RAMPY auch, falls vorhanden.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das liegt an der Forderung an das Projekt
Mich dünkt, hier geht's um ziemlichen Hack... das eigentliche Problem 
scheint die Konzeption des Projekts zu sein.

> Hingegen will ich den Zeiger nicht im RAM an einer
> festen (zur Assemble-Zeit bekannten) Adresse ablegen.

Adressen werden doch in der Regel erst zur Linkzeit vergeben, also muss 
nicht neu assembliert werden. Und wer konstante Adressen in seinem 
Programm verwendet -- ausser natürlich für SFR-Bereich etc -- ist selber 
schuld.

Hier kann es sich doch nur um Tasks in einem OS handeln oder um einen 
dynamischen Lader etc. Die dyn. Module sind ram-offsettable, aber das 
bedeutet doch nicht, dass das auf den Loader/OS zutreffen muss.

Wenn es dem Projekt gefällt, dann gehören die 2 Bytes eben per 
Definition nicht zum RAM; sondern nenn den Bereich Hasenboppes. Der 
Bereich ist ja auch nicht frei (random) zugreifbar im Sinne der 
Anwendung.

Du hast immer noch die Möglichkeit über nen Bootloader zu schreiben. Das 
dauert einmal beim Schreiben. Lesen geht ähnlich effizient wie aus dem 
RAM, aber eben nur indirekt.

Und wenn das nicht geht, musst eben in den sauren Apfel beissen und 
immer wieder aus dem EEPROM lesen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:

> Die werden leider gebraucht. Und RAMPX und RAMPY auch, falls vorhanden.

Wenn ich jetzt ein I/O-Register der '162 (oder welchem Modell auch 
immer) nach dem anderen so aufzähle: Meinst du es bleibt eines übrig, 
bei dem du nicht ebendiese Antwort lieferst?

Wenn ich damit recht habe, suchst du etwas was nicht existent oder 
zumindest nicht dokumentiert ist. Wenn ich damit nicht recht habe, 
kannst du diese Prozedur genausogut selber durchführen.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Maxim
>Mensch, lager den Zeiger doch auf einen externen RAM-Baustein aus!
Das selbe Problem. Falls externes RAM verfügbar ist, sollen darin doch 
keine festen Adressen verwendet werden.

>Es hat leider niemand meine Frage beantwortet. Rein aus Interesse: Um
>ca. wieviele Takte ist der Zugriff auf den SRAM schneller als auf den
>Flash?

Ein LPM dauert 3 Zyklen gegenüber 2 Zyklen für ein LDS.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:

> Ein LPM dauert 3 Zyklen gegenüber 2 Zyklen für ein LDS.

...und ist damit zu langsam?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:
> @ Matthias
>
>>Und wo und wie werden die abgelegt?
>
> Bitte verzeih', aber was an:
> "Die Variablen die ich verwende sollen in meinem
> Programm als Offset zu dem fraglichen Zeiger kodiert sein."
>
> war unklar?
>
> Sie werden im RAM per STS/LDS benutzt.

Das passt aber nicht ins Konzept, denn die Zugriffsadressen von STS/LDS 
lassen sich nicht verschieben, deren Zugriffsadresse ist im Programmcode 
notiert, ist also fest.

...

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, sind immerhin 50% mehr. Dürfte aber wohl nur bei extrem intensiver 
Speichernutzung eine Rolle spielen.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas
>Wenn ich jetzt ein I/O-Register der '162 (oder welchem Modell auch
>immer) nach dem anderen so aufzähle: Meinst du es bleibt eines übrig,
>bei dem du nicht ebendiese Antwort lieferst?

Es werden auch sämtliche Peripheriekontrollregister gebraucht.
Die Frage ist jedenfalls ernst gemeint.

Das sollte auch auf möglichst vielen Modellen gehen. Zumindest auf 
denen, die mehr als 8k Flash haben.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf das Risiko hin, mich zu wiederholen, mal den Kern der Sache 
zusammengefasst:

-a- Alles was sämtliche Modelle der AVRs haben ist bereits verwendet und 
kommt folglich nicht in Frage.

-b- Alles was nicht sämtliche Modelle der AVRs darf genau deshalb nicht 
verwendet werden.

-c- Die einzige noch nicht explizit ausgeschlossene Resource, das ROM, 
ist zu langsam.

=> Das Problem ist unlösbar.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube da versucht uns jemand mächtig auf die Arme zu nehmen....

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hannes

>Das passt aber nicht ins Konzept, denn die Zugriffsadressen von STS/LDS
>lassen sich nicht verschieben, deren Zugriffsadresse ist im Programmcode
>notiert, ist also fest.

Ja. Tut mir leid. Ein Flüchtigkeitsfehler. Muss natürlich ST/LD heissen.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas
>-a- Alles was sämtliche Modelle der AVRs haben ist bereits verwendet und
>kommt folglich nicht in Frage.
Das ist ja gerade die Frage, ob schon alle Möglichkeiten genutzt sind.
Auch auf die Gefahr hin, mich zu wiederholen:
1. Peripherie wird schon verwendet.
2. R0 bis R31 wird schon verwendet.

>-b- Alles was nicht sämtliche Modelle der AVRs darf genau deshalb nicht
>verwendet werden.
Das würde ich in dieser Schärfe nicht bestätigen. GPIORX ist schon eine 
gute Lösung, wenn auch ein wenig langsam, weil die erst umgeladen werden 
müssen, damit sie als Argument für ST/LD taugen.
Aber auf denen die kein GPIORX haben muesste halt ne andere Lösung her.

>-c- Die einzige noch nicht explizit ausgeschlossene Resource, das ROM,
>ist zu langsam.
Falls Du FLASH oder EEPROM meinst: Ja.

>=> Das Problem ist unlösbar.
OK. Das ist also Deine Antwort. Gibts noch andere Meinungen?

Autor: Thomas B. (yahp) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Ich glaube da versucht uns jemand mächtig auf die Arme zu nehmen....

Und das mit großem Erfolg, möchte man meinen.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

schließe mich lippy an.

Letzte Frage: Wie kann man so etwas essentielles bei der 
Programmkonzeption vergessen?

MfG Spess

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thomas & Simon

>> Ich glaube da versucht uns jemand mächtig auf die Arme zu nehmen....
>Und das mit großem Erfolg, möchte man meinen.

Ich versichere, das die Frage ernst gemeint ist. Kein Scherz. Kein 
doppelter Boden. Bitte glaubt mir das.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:

> Ich versichere, das die Frage ernst gemeint ist. Kein Scherz. Kein
> doppelter Boden. Bitte glaubt mir das.

Dann hat vielleicht jemand dich gehörig auf den Arm genommen ;-)

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soll das eigentlich ein Pentium-II Emulator für den Atmel-Mega-8 werden?
Sags ehrlich!

Jochen Müller

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ne doffe Frage aber wenn du eh das EEProm verwendest, warum liest du 
dann nicht den wert daraus? Lesen aus dem EEProm dauert doch auch nur 2 
Takte (Readbefehl + in) Oder nutz den EEPromAdresspointer als 
"hilfsregister". Oder erlaub keine Unterprogrammaufrufe und nutz den 
Stackpointer ;)

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Spess53

>Wie kann man so etwas essentielles bei der Programmkonzeption vergessen?
Das frage ich mich auch. Aber der Kunde ist halt König. Ich hätte mir 
das auch lieber erspart.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja: Eine Resource, die zwar schon erwähnt wurde, aber wohl nicht als 
Lösung: Der Stack-Pointer. Ok, CALL/RETURN kannst du dann knicken und 
Modelle bis 256 Bytes RAM auch, aber ansonsten erfüllt der alle 
Forderungen. ;-)

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Aber der Kunde ist halt König. Ich hätte mir
>>das auch lieber erspart.

Ich betrachte meine Kunden ehrlich gesagt eher als Partner und nicht als 
Monarchen, alleine schon wegen der Sinnhaftigkeit der Kommunikation...

Aber dennoch:
Wenn der Kunde auf einmal verlangt, man solle die Schwerkraft mal eben 
für das Projekt abschalten...

...dann ist der Kunde kein König, sondern ein Idiot.

Jochen Müller

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen
>Soll das eigentlich ein Pentium-II Emulator für den Atmel-Mega-8 werden?
>Sags ehrlich!

Da hast Du mich doch glatt zum Lachen gebracht. ;-)

@ Läubi

Das würde halt jedesmal 10 Zyklen brauchen (2 Bytes) und da der Wert 
doch oft gebraucht wird, geht das ganz schön auf die Geschwindigkeit.

Stackpointer wird gebraucht weil Unterprogramme vorhanden.

EEProm Register werden gebraucht.
Falls das jemand fragen will: Die Flash Lese/Schreibregister auch.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jochen Müller wrote:

> Wenn der Kunde auf einmal verlangt, man solle die Schwerkraft mal eben
> für das Projekt abschalten...

Verglichen mit diesem Problem erscheint mit das geradezu trivial. Denn 
Lösungen dafür sind hinlänglich bekannt und werden routinemässig 
genutzt.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher wrote:

> Stackpointer wird gebraucht weil Unterprogramme vorhanden.

Die kann man auch anders realisieren.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Wer ist der Programmierer? Du oder der Kunde? Wer legt die 
Registerbelegung fest? ....

Mf Spess

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ach ja: Eine Resource, die zwar schon erwähnt wurde, aber wohl nicht als
>>Lösung: Der Stack-Pointer. Ok, CALL/RETURN kannst du dann knicken und

Aber ohne Scheiss:
Möglich wäre das grundsätzlich schon.
Er könnte sich eine Art privaten Stack für rücksprungadressen bauen, und 
dann über indirekte calls arbeiten. kostet aber einigen overhead, und er 
zählt doch eh schon die takte....
der private-stackpointer liegt dann natürlich im relationalen teil des 
sram und muss erst mit der basisadr. behaftet werden...
mir wird übel...

Jochen Müller

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf die Gefahr hin, mich unbeliebt zu machen:
Bei den 8051ern hast du intern als RAM zur Verfügung:
- 128Byte direkt adressierbar (vergleichbar mit R0 bis R31, nur mehr)
- 128Byte indirekt adressierbar (können mit bes. Befehlen wie R0 bis R31 
genutzt werden)
Zusätzlich hast du bis zu 64kByte ext. RAM (meist aber schon ext.RAM im 
Chip mit drin).
Die Pointer für den ext. RAM liegen nicht wie beim AVR in den int. 
Registern R0 bis R31, sondern extra. Es gibt Derivate mit bis zu 8 
Pointern.
Wie wäre es damit? Das sollte dein Problem doch lösen, oder? Du hast 
genügend RAM für deine festen Variablen (wie du die in R0 bis R31 hast) 
und zusäztlich noch 8 Pointer für deinen dynamischen RAM, ohne dass du 
Speicherstellen im ext. RAM "verschleuderst" oder int. RAM verlierst.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Spess53
>Wer legt die Registerbelegung fest?
Ich. Aber der Kunde legt fest, das das der Speicher frei konfigurierbar 
sein soll.

@ Andreas
>Die kann man auch anders realisieren.
Das wäre im Prinzip eine Möglichkeit. PUSH/POP ist aber so eine der am 
häufigsten ausgeführten Operationen in meinem Programm. Das würde 
wahnsinnig auf die Geschwindigkeit gehen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum soll der Speicher eigentlich "frei konfigurierbar" sein? Der 
Speicher liegt doch im AVR immer an einer bestimmten Stelle und 
verschiebt sich doch nicht zwischendurch..

Oder gibts da drauf auch keine Antwort?

Autor: Moppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frage einfach Deinen Kunden, wo Du Deine zwei Bytes speichern sollst.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wer legt die Registerbelegung fest?
>Ich. Aber der ....

Dann hast du den Fehler gemacht. Lies mal meinen vorletzten Beitrag.

MfG Spess

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Kunde wirklich so einen, mal deutlich auf den Punkt gebracht, 
Blödsinn verlangt, wird das vermutlich nicht der letze Ärger sein, den 
du mit ihm hast.

Autor: Registersuche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ MC
>Auf die Gefahr hin, mich unbeliebt zu machen:...
Machst Du nicht.
>Bei den 8051ern ...
Nein. Es muss der AVR sein.

@ Simon
>Warum soll der Speicher eigentlich "frei konfigurierbar" sein?
Es ist halt nicht vorhersehbar welches Layout und welche Grösse die 
Speicherbereiche im Einsatz dann tatsächlich haben müssen. Mal ist es 
so, mal ist es anders. Mal braucht man mehr Stack. Mal für den einen 
Datenbereich weniger. Mal für den anderen Datenbereich mehr. Mal mehr 
RX-Buffer und weniger TX, mal umgekehrt.

@Spess53
>Dann hast du den Fehler gemacht.
Wer hat danach gefragt?

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@All

Wir entfernen uns nur immer mehr von der eigentlichen Frage.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wir entfernen uns nur immer mehr von der eigentlichen Frage.

Nein. Im Gegenteil. Wofür brauchst du 32 Register? Welche 
Programmiersprache benutzt du eigentlich?

MfG Spess

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Regsucher,

Ich will dir wirklich nicht zu nahe treten, aber bist du sicher dass du 
reif genug bist für so ein projekt.
Das was du da zuletzt geschildert hast ist EINE VÖLLIG NORMALE 
anforderung, aber KEIN MENSCH macht dafür so einen zirkus!

Der Stack wächst von oben nach unten,
Deine datenbereiche von unten nach oben,
so wird das GRUNDSÄTZLICH GEMACHT.

Stack und Daten können sich -bei richtiger auslegung- der controller 
nicht in die quere kommen, und um deine datenbreiche unterzubringen 
(egal wie gross die jeweils sind) muss der controller eh gross genug 
ausgelegt werden und entsprechende reserven haben. EBEN WEIL die 
datenfeldgrössen nicht 100% feststehen.-

und dann kommt es auf 2-byte oberhalb des stack NICHT MEHR AN!!
GERADE WEIL du eh immer genug speicher einplanen musst, WEIL JA die 
datengrössen veränderlich sein sollen!

Ausserdem hat deine letzte erklärung GARNICHTS mit verschieblichen 
speichern im sinne von relozierbarkeit zu tun, sondern es geht EINFACH 
NUR um eine intelligente und dynamische speicheraufteilung.
DAS IST GANZ ETWAS ANDERES!!!

War das ganz hier ein witz?
mir scheint ernsthaft, du hast dein pflichtenheft teilweise FALSCH 
INTERPRETIERT!

Jochen Müller

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wir entfernen uns nur immer mehr von der eigentlichen Frage.

>Ich meine mal gelesen zu haben, das es bei den Atmel 8-Bit Prozessoren
>bzw. vielleicht nur bei einigen Modellen, Register gibt, die man
>benutzen kann um dort Werte abzulegen.

Von dieser vermutlich.

Davon hat hier scheinbar noch niemand gehört.
Und es sind hier eine Menge erfahrener AVR User unterwegs.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konkret wird das SO gemacht, ist ein URALTER hut!
SRAM-AUFBAU:

höchste SRAM-ADRESSE
----
pointer auf datenbereich-1
pointer auf datenbereich-2
pointer auf datenbereich-3
stack
..
..
..
..
..
datenbereich-1
datenbereich-1
datenbereich-1
datenbereich-1
datenbereich-2
datenbereich-2
datenbereich-2
datenbereich-3
datenbereich-3
datenbereich-3
----
kleinste SRAM-Adresse

Wenn während der Laufzeit sich Datenbereich-Grössen ändern, wird
- der dateninhalt umgeschaufelt
- der/die pointer geändert
- fertig

Das ist ein simples Problem, eigentlich nichtmal ein Problem, sondern 
Programmier-Alltag, wozu jetzt die ganze Aufregung und anfängliche 
Verschleierung?

Jochen Müller

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das RAM des AVRs wird ja linear addressiert, beginnend mit 0x60, weil 
darunter die IO-Register liegen. Also hast du auch so nicht dein ganzes 
RAM zur Verfügung, sondern erst ab 0x60. Jetzt denkst du dir halt, dass 
die IO-Register zwei Bytes mehr brauchen und das RAM erst ab 0x62 
beginnt. Selbst bei einem furchtbaren Konzept könnte man dies wohl noch 
einplanen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ja genug Teilnehmer hier. Wenn jeder ein Bit auftreibt -- oder 
auch nur ein halbes, sind genug Leute hier --, dann haben wir 
rucki-zucki die erforderlichen 16 Bits zusammen!

Ich fang mal an:

Das T-Bit im SREG. Wird nicht gebraucht.

Rede einfach mal mit Deinem Kunden. Dass Kunden unsinnige Sachen 
verlangen ist nicht unüblich und in Ordnung. Es gehört aber zur 
Kundenpflege dazu, nicht zu allem JA und AMEN zu sagen sondern die 
Kunden gut zu beraten. Ansonsten tust Du nämlich weder Dir noch Deiner 
Firma noch dem Kunden nen Gefallen.

Ob N Bytes frei konfigurierbar sind oder N-2 ist doch Wurscht.

Da fällt mit ein... es gibt da noch die Adressen 0x0000 bis 0x001f, die 
weder zum SFR-Bereich noch zum RAM gehören. Nimm doch einfach welche 
davon.

(Die erfolgreichsten Hackerangriffe gibt's bekanntlich auf IP 127.0.0.1)

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Johann

>Da fällt mit ein... es gibt da noch die Adressen 0x0000 bis 0x001f, die
>weder zum SFR-Bereich noch zum RAM gehören. Nimm doch einfach welche
>davon.
Das hört sich interessant an.
Aber war das nicht so, das man damit die Register R0 bis R31 schreibt 
und liest?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unmögliches erledigen wir sofort, Wunder dauern etwas länger:-)
Ich habe mir nicht alles durchgelesen, aber das ist schon etwas abstrus.
Nimms mir nicht übel - aber alle Lösungen, die funktionieren, lehnst du 
ab. Auf unmögliche Lösungen wirst du lange warten müssen.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das RAM des AVRs wird ja linear addressiert, beginnend mit 0x60, weil....

Nein. Das RAM beginnt ab Adresse 0 (r0..r31), dann kommen die 
IO-Register und danach das eigentliche RAM.

MfG Spess

Autor: Albrecht H. (alieninside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mr.chip wrote:
> Das RAM des AVRs wird ja linear addressiert, beginnend mit 0x60, weil
> darunter die IO-Register liegen. Also hast du auch so nicht dein ganzes
> RAM zur Verfügung, sondern erst ab 0x60. Jetzt denkst du dir halt, dass
> die IO-Register zwei Bytes mehr brauchen und das RAM erst ab 0x62
> beginnt. Selbst bei einem furchtbaren Konzept könnte man dies wohl noch
> einplanen.

Fängt der (freie) SRAM-Bereich der AVRs eigentlich grundsätzlich immer 
bei 0x60 an?
Ich meine nur, weil sich ja z.B. schon die Länge der Interrupttabellen 
von Atmega88 und Atmega16 in der Länge unterscheiden und auch nicht 
jeder Atmega gleich viele I/O-Ports hat. Also wenn das sowieso bei jedem 
AVR anders ist, dann spielt es ja wohl überhaupt keine Rolle mehr, ob 
man von der "Zeropage" (C64 anyone?), noch zwei weitere Bytes für einen 
Pointer abzwackt.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albrecht H. wrote:
> Fängt der (freie) SRAM-Bereich der AVRs eigentlich grundsätzlich immer
> bei 0x60 an?

Nein.

> Ich meine nur, weil sich ja z.B. schon die Länge der Interrupttabellen
> von Atmega88 und Atmega16 in der Länge unterscheiden und auch nicht
> jeder Atmega gleich viele I/O-Ports hat.

Die Vectab steht im Flash.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albrecht H. wrote:
> Fängt der (freie) SRAM-Bereich der AVRs eigentlich grundsätzlich immer
> bei 0x60 an?

Nein, bei vielen neueren AVRs beginnt der SRAM erst bei Adresse 256, 
weil es davor noch 192 Bytes "Extended-I/O" gibt. Im Einzelfall das 
Datenblatt fragen.

> Ich meine nur, weil sich ja z.B. schon die Länge der Interrupttabellen
> von Atmega88 und Atmega16 in der Länge unterscheiden

Die Interrupt-Sprungtabelle liegt im Flash und hat nix mit dem RAM zu 
tun. Es sind dank Harvard-Architektur verschiedene Speicher.

> und auch nicht
> jeder Atmega gleich viele I/O-Ports hat. Also wenn das sowieso bei jedem
> AVR anders ist, dann spielt es ja wohl überhaupt keine Rolle mehr, ob
> man von der "Zeropage" (C64 anyone?), noch zwei weitere Bytes für einen
> Pointer abzwackt.

Zeropage gibt es beim AVR nicht, dafür 32 Register, 64 I/Os, bei einigen 
AVRs 192 Bytes Extended-I/O und dann etwas SRAM...

...

Autor: Albrecht H. (alieninside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux wrote:
> Albrecht H. wrote:
>> Fängt der (freie) SRAM-Bereich der AVRs eigentlich grundsätzlich immer
>> bei 0x60 an?
>
> Nein, bei vielen neueren AVRs beginnt der SRAM erst bei Adresse 256,
> weil es davor noch 192 Bytes "Extended-I/O" gibt.

Also für die AVRs mit den ganz vielen Pins ...?

> Im Einzelfall das
> Datenblatt fragen.
>
>> Ich meine nur, weil sich ja z.B. schon die Länge der Interrupttabellen
>> von Atmega88 und Atmega16 in der Länge unterscheiden
>
> Die Interrupt-Sprungtabelle liegt im Flash und hat nix mit dem RAM zu
> tun. Es sind dank Harvard-Architektur verschiedene Speicher.

Ok, ich gestehe, ich hab die Interruptvektoren gerade trotz Kenntnis der 
Harvard-Architektur, tatsächlich kurz vor meinem geistigen Auge im SRAM 
stehen sehen. Eigentlich waren es genau diese Unterschiede in den 
Interrupttabellen, die mich als AVR-Neuling erst vor ein paar Wochen zur 
Erkenntnis gebracht haben, dass die einzelnen AVR-Typen sich doch 
erheblich unterscheiden. Weswegen es dann auch etwas unsinnig erscheinen 
mag, verzweifelt nach zwei freien Bytes und einer möglichst für alle 
AVRs einheitlichen Lösung zu suchen, (also einer Einheitlichkeit die es 
schon technisch bedingt innerhalb der Mega-AVR Familie gar nicht gibt).

>
>> und auch nicht
>> jeder Atmega gleich viele I/O-Ports hat. Also wenn das sowieso bei jedem
>> AVR anders ist, dann spielt es ja wohl überhaupt keine Rolle mehr, ob
>> man von der "Zeropage" (C64 anyone?), noch zwei weitere Bytes für einen
>> Pointer abzwackt.
>
> Zeropage gibt es beim AVR nicht,

Lang lebe die Zeropage!

> dafür 32 Register, 64 I/Os, bei einigen
> AVRs 192 Bytes Extended-I/O
>
>und dann etwas SRAM...

na also

>
> ...

War da nicht irgendwas mit der "Zeropage" auf den AVRs, stimmt man kann 
aus der Interrupttabelle keinen "Long"-jump verwenden um zur 
Interruptroutine zu springen, aber da das auf den AVRs weder etwas mit 
C64 Zeropageadressierung noch, wie du bereits erwähntest, nicht im 
entferntesten mit dem AVR-SRAM zu tun hat ... falsche Baustelle.

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@registersuchender

ist doch ganz einfach, du legst reserfierst dir doch 2 byte RAM und zwar 
dynamisch.
und nicht gleich meckern, nach deinen Konzept geht es tatsache. Du hast 
doch im EEPROM einen pointer für die Stackinitialisierung. mit diesen 
Pointer musst du halt auf deinen RAM-Pointer zeigen und den Stack um 
2.Byte verschieben.

Wenn du jetzt das ganze zur laufzeit ändern möchtest ohne daten zu 
verlieren musst du etwas mehr aufwand treiben, aber das ist eh relativ 
aufwändig ob nun mit oder ohne pointer. in diesen Fall musst du halt den 
pointer in die Register legen.

@Maxim S.

Ja es ist gleichschnell.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber er weiß doch (da der Stackpointer irgenwo liegt) nicht wo der Stack 
"anfängt".

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albrecht H. wrote:
> Also für die AVRs mit den ganz vielen Pins ...?

Nein, mit der Pinanzahl hat das nichts zu tun. Der Maga48 (DIL28) ist 
schon so, der Mega16/32 (DIL40) aber nicht. Einfach im Datenblatt 
nachschaun und nicht voreilig versuchen zu Verallgemeinern.

> Ok, ich gestehe, ich hab die Interruptvektoren gerade trotz Kenntnis der
> Harvard-Architektur, tatsächlich kurz vor meinem geistigen Auge im SRAM
> stehen sehen.

Soll vorkommen, ist kein Problem. Auch ich hatte betreffs AVRs 
gelegendlich Irrtümer.

> Eigentlich waren es genau diese Unterschiede in den
> Interrupttabellen, die mich als AVR-Neuling erst vor ein paar Wochen zur
> Erkenntnis gebracht haben, dass die einzelnen AVR-Typen sich doch
> erheblich unterscheiden.

Der "Kern" ist immer gleich, abgesehen davon, dass einige kein HW-Mul 
haben und einige ältere kein Increment beim LPM. Ja, auch beim SPM gibt 
es Unterschiede, aber nicht Jeder nutzt grundsätzlich Bootloader.

Die großen Unterschiede kommen durch die unterschiedliche Ausstattung 
mit interner Peripherie (bei eigentlich gleichem Kern). Wenn mehr 
Timer-Features vorhanden sind, braucht man auch mehr I/O-Register. Und 
es sieht so aus, als ob die Grenze $100 zum Standard werden wird.

Das soll mir aber Wurscht sein, ich schreibe keine Universalprogramme, 
sondern spezielle Programme für einen speziellen Typ (mit geöffnetem 
Datenblatt als Referenz).

> Weswegen es dann auch etwas unsinnig erscheinen
> mag, verzweifelt nach zwei freien Bytes und einer möglichst für alle
> AVRs einheitlichen Lösung zu suchen,

Mache ich ja gar nicht.

> (also einer Einheitlichkeit die es
> schon technisch bedingt innerhalb der Mega-AVR Familie gar nicht gibt).

Ich werde aber auch nicht versuchen, das Ansinnen von 
"Registersuchender" zu bewerten. Vielleicht weiß er ja was über AVRs, 
was ich noch nicht weiß. Ob es Unsinn ist, wird sich mit der Zeit 
herausstellen. Ich werde dann aber nicht zu den Lachern gehören.

> Lang lebe die Zeropage!

Ja, 6502 (7501/8501) war nicht schlecht, kenne ich vom Plus/4. Habe aber 
bestimmt 12 Jahre nichts mehr damit gemacht. Jedes Ding hat seine Zeit, 
die Zeiten sind aber vorbei.

> War da nicht irgendwas mit der "Zeropage" auf den AVRs, stimmt man kann
> aus der Interrupttabelle keinen "Long"-jump verwenden um zur
> Interruptroutine zu springen,

Kann sein, dass Du da was verwechselst. Der Begriff "Long-Jump" lässt 
darauf schließen, dass Du den Adressabstand der Interrupt-Vektoren 
meinst. Bei kleinen AVRs (bis 8 kiB Flash, also 4 K Adressraum) reicht 
ein rjmp (Reichweite +/- 2 K) zum Sprung in die ISR, deshalb ist für 
jeden Vektor 1 Word (2 Bytes) reserviert. Ab 16 KiB Flash muss dafür ein 
jmp verwendet werden, der 32 Bit braucht, demnach sind die Vektoren 2 
Words (32 Bit) groß. Im Gegensatz zum 6502 steht am Interrupt-Vektor 
bereits der Sprungbefehl (der die Zieladresse enthält) und nicht nur die 
Zieladresse des Sprungs.

> aber da das auf den AVRs weder etwas mit
> C64 Zeropageadressierung noch, wie du bereits erwähntest, nicht im
> entferntesten mit dem AVR-SRAM zu tun hat ...

Jou, hat es nicht...

falsche Baustelle.

Soll vorkommen, kein Grund, sich zu erschießen (mit'm Strick, da wo das 
Wasser am tiefsten ist...).

Ein 6502 mit integrierten 64K SRAM, Timern, Schnittstellen, Video- und 
Sound-Baugruppen, SD-Interface und 256 KiB Flash für BASIC 3.5 und 
Anwenderprogramme wäre zwar auch nicht zu verachten, aber man kann nicht 
alles haben. Inzwischen gefällt mir AVR-ASM aber auch besser als 
6502-ASM.

...

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@läubi

klar weiß er das, er initialisiert ihn doch anhand eines im EEProm 
stehenden Wertes. Steht irgendwo in den konfusen Beiträgen oben.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ich deine Aussage irgendwo oben im Thread richtig in Erinnerung, 
das du bezüglich GPIOR zumindest keine grundsätzlichen Bedenken hattest? 
GPIOR ist wohl das, was auf deine Frage am ehesten passt, es ist weder 
im Ram, noch im Register-Satz, noch für irgendeine Peripherie benutzt. 
Ich verwende GPIO gerne als extra-Frag Register, weil man damit noch 
sbi/cbi und sbic sbis machen kann. Und sag jetzt bitte nicht das 
IO-Zugriff zu langsam wäre.

Was dein eigentliches Problem wohl eher zu sein scheint ist die von oben 
auferlegte Aufgabenstellung, die entweder von dir falsch 
verstanden/interpretiert ist, oder aufgrund sich ausschließenden 
Anforderungen logisch schlicht unmöglich zu erfüllen ist. Welchen 
Spielraum hast du überhaupt als Entwickler, laut der Aufgabenstellung? 
Wenn dir z.B. r0-r31 zur Verfügung steht, alles andere aber für die 
Anwendung frei bleiben muss, hast du hier die Möglichkeit, innerhalb 
deines Entwicklerspielraums zu optimieren, und eins der r0-31 
einzusparen. Also welches von deinen zahlreichen Einschränkungen beruht 
auf deiner eigenen (ggf. optimierbaren) Lösung, und welches ist "hart", 
also Schwarz auf Weiß im "Pflichtenheft" formuliert?

Notfalls muss man halt die Aufgabenstellung revidieren, oder Kompromisse 
eingehen, z.b. das irgendeines der IO-Register halt nicht benutzt 
wird/werdenmuss/mit höchster wahrhscheinlichkeit man immer auch ohne 
auskommen kann. Einfallen täte mir da die Output-Compare-Register, von 
denen es z.b. zwei gibt (A/B), wen man nur eine OC-Unit braucht...


Darüberhinaus spricht kein praktischer Grund dagegen, einen winzigen 
Teil des SRAMs für dein OS abzuzweigen, wie hier zahlreich 
vorgeschlagen. Es spricht offenbar nur deine Interpretation dieser 
merkwürdigen Aufgabenstellung dagegen. Da Stack verwendet wird, muss man 
immer etwas Spielraum lassen. Ob der nun 2 Byte größer ist oder nicht 
fällt kaum ins Gewicht.

Man muss auch nicht jede Aufgabe die von oben kommt als Gottesgebot 
ungefragt annehmen, wenn sich diese als nicht erfüllbar herausstellt 
hast du wohl nur die zwei Möglichkeiten A) Aufgeben oder B) nochmal über 
die Aufgabenstellung zu diskutieren (Entweder du hast sie zu hart 
interpretiert, oder der Aufgabensteller lässt sich auf einen Kompromiss 
ein)

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Warum soll der Speicher eigentlich "frei konfigurierbar" sein?
> Es ist halt nicht vorhersehbar welches Layout und welche Grösse die
> Speicherbereiche im Einsatz dann tatsächlich haben müssen. Mal ist es
> so, mal ist es anders. Mal braucht man mehr Stack. Mal für den einen
> Datenbereich weniger. Mal für den anderen Datenbereich mehr. Mal mehr
> RX-Buffer und weniger TX, mal umgekehrt.

Hah! Hab ich doch richtig geraten. Das Programm soll auf uCs mit 
unterschiedlichem Speicherausbau laufen.
In diesem Fall geht es ja nicht, dass man den Pointer auf RAMEND legt, 
weil ein anderer uC einen anderen RAMEND hat. Dafür müsste das Programm 
neu kompiliert werden.

Ist es möglich, dass das Programm zur laufzeit erkennt, auf welchem uC 
es läuft? Ansonsten könnte man eine Routine bauen, die nach dem Reset 
die Speichergröße erkennt und den Zeiger auf die letzten zwei Byte im 
RAM über dem Stack legt. Oder die Software bietet eine Option, mit der 
man die Speichergröße manuell einstellen kan (DIP-Schalter oder so).

Oder du verwendest den Flash-Speicher für den Zeiger und nimmst eine 
höher getaktete Version des Megas, sofern der Kunde nichts dagegen hat 
...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moritz E. wrote:
> Habe ich deine Aussage irgendwo oben im Thread richtig in Erinnerung,
> das du bezüglich GPIOR zumindest keine grundsätzlichen Bedenken hattest?
> GPIOR ist wohl das, was auf deine Frage am ehesten passt, es ist weder
> im Ram, noch im Register-Satz, noch für irgendeine Peripherie benutzt.
> Ich verwende GPIO gerne als extra-Frag Register, weil man damit noch
> sbi/cbi und sbic sbis machen kann. Und sag jetzt bitte nicht das
> IO-Zugriff zu langsam wäre.
Das mit den GPIOR ist oben schon erledigt worden, weil nur eine Handvoll 
AVRs die überhaupt haben (der weiter oben erwähnte Mega162 hat z.B. kein 
GPIOR), das ganze aber offensichtlich auf praktisch jedem AVR laufen 
soll.

Autor: Albrecht H. (alieninside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux wrote:
> jede Menge wissenswertes ... ;-)
>...
>
>> War da nicht irgendwas mit der "Zeropage" auf den AVRs, stimmt man kann
>> aus der Interrupttabelle keinen "Long"-jump verwenden um zur
>> Interruptroutine zu springen,
>
> Kann sein, dass Du da was verwechselst. Der Begriff "Long-Jump" lässt
> darauf schließen, dass Du den Adressabstand der Interrupt-Vektoren
> meinst. Bei kleinen AVRs (bis 8 kiB Flash, also 4 K Adressraum) reicht
> ein rjmp (Reichweite +/- 2 K) zum Sprung in die ISR, deshalb ist für
> jeden Vektor 1 Word (2 Bytes) reserviert.

Ja so steht es auch im Datenblatt, wobei ich jetzt gerade mal auf dem 
mega88 (von weit weg) einen rjmp zu $1f00 probiert habe, das macht er 
nicht, (Relative branch out of reach), wie ist das denn nun, sind die 
Sprungziele als Words oder als Bytes organisiert? Eigentlich schon als 
Bytes, denn von 3 hintereinander liegenden NOPs kann ich jedes einzelne 
NOP als rjmp-Sprungziel angeben, ...?


> Ab 16 KiB Flash muss dafür ein
> jmp verwendet werden, der 32 Bit braucht, demnach sind die Vektoren 2
> Words (32 Bit) groß.

Also jetzt z.B. beim Atmega16 mit 16KB Flash? Aber da sind laut 
Datenblatt zwischen zwei Interruptvektoren doch auch nur 2 Bytes Platz 
oder hab ich da was übersehen?

> Im Gegensatz zum 6502 steht am Interrupt-Vektor
> bereits der Sprungbefehl (der die Zieladresse enthält) und nicht nur die
> Zieladresse des Sprungs.
>
>> aber da das auf den AVRs weder etwas mit
>> C64 Zeropageadressierung noch, wie du bereits erwähntest, nicht im
>> entferntesten mit dem AVR-SRAM zu tun hat ...
>
> Jou, hat es nicht...
>
> falsche Baustelle.
>
> Soll vorkommen, kein Grund, sich zu erschießen (mit'm Strick, da wo das
> Wasser am tiefsten ist...).
>

Na ja, peinlich ist es schon ein bisschen, nicht unbedingt das Unwissen, 
mehr die eigene Arroganz, wenn man meint nach mehreren Jahren 
Programmierpraxis auf dem PCs ALLES zu wissen, zumal die AVRs ja sooo 
viel kleiner sind wie ein Pentium ...

> Ein 6502 mit integrierten 64K SRAM, Timern, Schnittstellen, Video- und
> Sound-Baugruppen, SD-Interface und 256 KiB Flash für BASIC 3.5 und
> Anwenderprogramme wäre zwar auch nicht zu verachten, aber man kann nicht
> alles haben.

Da gabs doch mal bei Pearl für 20 EUR diesen C64-"Joystick" mit 
eingebautem "Singlechip-C64", mit TV-Ausgang und ca. 30 Spielen auf ROM.

>Inzwischen gefällt mir AVR-ASM aber auch besser als
> 6502-ASM.
>
> ...

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim S. wrote:

> Hah! Hab ich doch richtig geraten. Das Programm soll auf uCs mit
> unterschiedlichem Speicherausbau laufen.
> In diesem Fall geht es ja nicht, dass man den Pointer auf RAMEND legt,
> weil ein anderer uC einen anderen RAMEND hat. Dafür müsste das Programm
> neu kompiliert werden.

Dann verstehe ich aber immer noch nicht seine Bedenken, Rambereiche zu 
benutzen, die selbst auf dem minimalsystem vorhanden wären, z.b. RAM 
START, oder RAMEND der kleinsten möglichen variante mit SRAM. Wenn er 
den Stack so und so per EEPROM Zeiger umschiebt muss er auch irgendwie 
einen Zeiger beim Reset bekommen, und den selben Zeiger kann er neben 
Stack auch für seine Systemdaten verwenden? Aber wenn er wirklich sowas 
vorhat hätte man sich 70% der Raterei sparen können wenn er mal endlich 
rausrücken würde mit näheren Infos zum Kontext

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albrecht H. wrote:

> Ja so steht es auch im Datenblatt, wobei ich jetzt gerade mal auf dem
> mega88 (von weit weg) einen rjmp zu $1f00 probiert habe, das macht er
> nicht, (Relative branch out of reach), wie ist das denn nun, sind die
> Sprungziele als Words oder als Bytes organisiert? Eigentlich schon als
> Bytes, denn von 3 hintereinander liegenden NOPs kann ich jedes einzelne
> NOP als rjmp-Sprungziel angeben, ...?

Adressen im CSEG als Word, auch ein NOP ist 16 bit, demnach müsstest du 
mit $0F80 erfolg haben, wobei dort 2er-Komplement erwartet wird..

Autor: Albrecht H. (alieninside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moritz E. wrote:
> Albrecht H. wrote:
>
>> ...
>> Bytes, denn von 3 hintereinander liegenden NOPs kann ich jedes einzelne
>> NOP als rjmp-Sprungziel angeben, ...?
>
> Adressen im CSEG als Word, auch ein NOP ist 16 bit, demnach müsstest du
> mit $0F80 erfolg haben, wobei dort 2er-Komplement erwartet wird..

Ach du meine Güte, die sind ja ALLE -> min. 16-bit Opcode, jetzt wirds 
Tag, da programmiert man einmal nicht mehr mit Lochkarten und schon 
übersieht man sowas!

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albrecht H. wrote:
> Also jetzt z.B. beim Atmega16 mit 16KB Flash? Aber da sind laut
> Datenblatt zwischen zwei Interruptvektoren doch auch nur 2 Bytes Platz
> oder hab ich da was übersehen?

Ja, hast Du. Vergleiche mit einem kleineren AVR. Beachte, dass die 
Adressen im Flash wordweise sind.

Achja, RJMP geht vorwärts und rückwärts, wenn es über das Speicherende 
(als Ring gesehen) hinaus gehen soll, dann muss man das im AVR-Studio 
einstellen. Habe es gerade nicht vor mir, musst halt selber mal suchen.

> Da gabs doch mal bei Pearl für 20 EUR diesen C64-"Joystick" mit
> eingebautem "Singlechip-C64", mit TV-Ausgang und ca. 30 Spielen auf ROM.

Möglich, hat mich aber nicht interessiert, bin kein Gamer, hatte deshalb 
auch keinen C64 sondern den Plus/4. Und den habe ich auch drastisch 
erweitert.

Ehe Du weitere Fragen in diesem Thread (in dem es eigentlich um Anderes 
geht, wir also nur stören) stellst, lies und vergleiche die 
Datenblätter, lies und verstehe das Tutorial, lies und verstehe den 
Befehlssatz, lies auch in der Hilfe zum AVR-Studio.

...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim S. wrote:
>>>Warum soll der Speicher eigentlich "frei konfigurierbar" sein?
>> Es ist halt nicht vorhersehbar welches Layout und welche Grösse die
>> Speicherbereiche im Einsatz dann tatsächlich haben müssen. Mal ist es
>> so, mal ist es anders. Mal braucht man mehr Stack. Mal für den einen
>> Datenbereich weniger. Mal für den anderen Datenbereich mehr. Mal mehr
>> RX-Buffer und weniger TX, mal umgekehrt.
>
> Hah! Hab ich doch richtig geraten. Das Programm soll auf uCs mit
> unterschiedlichem Speicherausbau laufen.

Sieht wohl so aus ja..

Ich weiß nicht was das werden soll, schließlich haben AVRs, die einen 
verschiedenen Speicherausbau haben auch nicht zwangsläufig den gleichen 
Umfang an Peripherie, Instruction Set und zudem kann es sein, dass die 
symbolischen Namen für Register (wie TCCR1A) dann auf die völlig falsche 
Adresse zeigen.
Hast du dir diesbezüglich schon was ausgedacht? Oder verwendest du nur 
bestimmte AVRs, die garantiert nur Differenzen in der Speichergröße 
haben?
Warum nicht einfach für jeden Chip neu kompilieren? RAMEND ist zur 
Kompilierzeit ja ausreichend um das Speicherlayout zu "erstellen".

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Warum nicht einfach für jeden Chip neu kompilieren? RAMEND ist zur
> Kompilierzeit ja ausreichend um das Speicherlayout zu "erstellen".

Es wäre mir neu, daß AVR-Programme ohne neu compilieren auf nem anderen 
Typ laufen.
Selbst ATmega8 und ATmega88 sind sich zwar ähnlich aber im Binärcode 
völlig inkompatibel.
ATmega16 und ATmega164 auch usw.

Ohne für den richtigen Typ zu compilieren läuft bei den AVRs garnichts!

Und daher kann es nie den Fall geben, daß RAMEND nicht bekannt ist.


Peter

Autor: Maxim S. (maxim) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
/offtopic

Ich glaube, das ist ein neuer Rekord: 119 Beiträge in weniger als 24 
Stunden!

/offtopic

Autor: Albrecht H. (alieninside)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux wrote:
> Albrecht H. wrote:
>> Also jetzt z.B. beim Atmega16 mit 16KB Flash? Aber da sind laut
>> Datenblatt zwischen zwei Interruptvektoren doch auch nur 2 Bytes Platz
>> oder hab ich da was übersehen?
>
> Ja, hast Du. Vergleiche mit einem kleineren AVR. Beachte, dass die
> Adressen im Flash wordweise sind.

Schon gemerkt.

>
> Achja, RJMP geht vorwärts und rückwärts, wenn es über das Speicherende
> (als Ring gesehen) hinaus gehen soll, dann muss man das im AVR-Studio
> einstellen. Habe es gerade nicht vor mir, musst halt selber mal suchen.

Yep.

>
>> Da gabs doch mal bei Pearl für 20 EUR diesen C64-"Joystick" mit
>> eingebautem "Singlechip-C64", mit TV-Ausgang und ca. 30 Spielen auf ROM.
>
> Möglich, hat mich aber nicht interessiert, bin kein Gamer, hatte deshalb
> auch keinen C64 sondern den Plus/4. Und den habe ich auch drastisch
> erweitert.

Kein Problem, die Betonung lag auch mehr auf "Singlechip mit Peripherie" 
als auf Spiele.

>
> Ehe Du weitere Fragen in diesem Thread (in dem es eigentlich um Anderes
> geht, wir also nur stören) stellst,

Schon klar, schon klar, ist ja auch alles geklärt soweit, die ATmegas 
sind  8-Bitter deren Opcodes immer min. 16 Bits lang sind, (sogar die 
NOPs), weshalb auch die Word-weise Adressierung Sinn macht. Wenn man mit 
einer gewissen Vorstellung von 8-Bittern, (basierend auf 6502, Z80, 
8051), an die 8-Bit AVRs rangeht kann man halt schon mal in so eine 
"Falle" tappen. Ist jetzt aber bei mir angekommen, gespeichert und wird 
sicher nicht mehr das Thema weiterer Kommentare von mir sein, es sei 
denn, ich kann mal jemand anderem damit helfen, der das ebenfalls 
übersehen hat.

Ok, das war jetzt eben ein kleiner Exkurs der das Ursprungsthema 
verlassen hat, kommt vor, sorry. Aber anfangs gings mir ja nur um die 
Unterschiede zwischen den einzelnen AVR-Typen, (also die, die sogar mir 
als AVR-Neuling sofort aufgefallen sind), und es deswegen möglicherweise 
überhaupt keinen Sinn macht, nach dem mysteriösen 33.ten Register zu 
suchen, weil man das "Problem" sowieso auf jedem AVR anders lösen 
müsste, bzw. stattdessen auch gleich zu einer der vielen vorgeschlagenen 
Standardlösungen greifen und irgendwo aus dem SRAM, (z.B. ganz am 
Anfang), zwei Bytes abzwacken kann.



> lies und vergleiche die
> Datenblätter, lies und verstehe das Tutorial, lies und verstehe den
> Befehlssatz, lies auch in der Hilfe zum AVR-Studio.
>
> ...

Sag das bitte nicht immer, ich bin ein echter Datenblatt-Fan, manchmal 
braucht es eben solche kleinen Schlüsselerlebnisse, damit man 
Datenblätter die man sich schon ein Dutzend mal durchgesehen hat und 
glaubt sie verstanden zu haben, noch einmal aus einem anderen 
Blickwinkel etwas genauer betrachtet.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erlaube mir noch einmal an die Ausgangsfrage zu erinnern und die 
bisherigen Lösungen zusammenzufassen:

Gibt es, mit Ausnahme der Peripheriekontrollregister und der Register R0 
bis R31 eine Möglichkeit CPU intern einen 16-Bit bzw. zwei 8-Bit Werte 
zu speichern?

Bisherige Antworten:
1. Nein, gibt es nicht
2. GPIORX

Ich weise auch höflich darauf hin, das die Ausgangsfrage die nach einer 
Information ist. Nicht, wie mir viele Antworten voraussetzen scheinen, 
die Frage nach einem Rat wie denn vorzugehen ist, wenn es nur die 
Antwort 1. gibt.

Wenn Ihr gestattet, würde ich Euch gerne eine Kritik über Eure Beiträge 
hier und einen Rat geben. Dies frage ich vor allem Spess53, Matthias 
Kölling und Jochen Müller.

Autor: PapaNappa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwartest du ehrlich jetzt noch eine neue Antwort? Hier wurden schon so 
gut wie alle Möglichkeiten durchgesprochen.

Angenommen, es würde ein Hinweis auf deine Frage im Datenblatt stehen, 
dann wäre hier schon eine Antwort gefallen.
Da eine eventuelle Lösung also nicht im Datenblatt steht, kannst du dir 
nie sicher sein, dass diese Lösung in späteren Revisionen der Controller 
auch noch funktioniert.

Also selbst wenn es funktionieren würde, hättest du keine volle 
Flexibilität - die dein Kunde ja offensichtlich so hoch schätzt.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher,

Ein Problem löst man dadurch, dass man versucht dessen Ursache und 
dessen Wesen zu ergründen.

Nicht durch stochern im Nebel.

Genau aus diesem Grund wollten hier soviele Leute die Hintergründe zu 
Deiner Frage erfahren. Das ist übliche und sinnvolle Methodik.

Wärst Du bei Deinem Kunden ebenso vorgegangen, hättest Du vielleicht das 
Problem garnicht, Deine bisherigen Info-Häppchen zu den Hintergründen 
rechtfertigen jedenfalls Deine angedachte Programm-Architektur auf 
keinen Fall. Das musst Dir Dir halt schon anhören, wenn Du öffentlich 
fragst...

Jochen Müller

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@reistersuch

Woher weist du wo du den Stack initialisieren musst?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein Problem löst man dadurch, dass man versucht dessen Ursache und
>dessen Wesen zu ergründen.

>Nicht durch stochern im Nebel.

>Genau aus diesem Grund wollten hier soviele Leute die Hintergründe zu
>Deiner Frage erfahren. Das ist übliche und sinnvolle Methodik.

Ich würde behaupten das dies die einzig gangbare Methodik bei der 
Umsetzung einer Problemstellung ist. Das ist ja der Grund warum ich 
Programmierer geworden bin, weil man zwar konkrete Probleme per HW/SW zu 
lösen versucht aber dabei eben die Gründe warum es ein Problem ist/gibt 
viel weitgefasster analysieren muß. Ohne diese Arbeit, bei der man die 
Umweltbedingungen umfassender analysiert, wäre Programmierung ziemlich 
langweilig.

Das was Registersuchender macht halte ich für grund verkehrt, und 
eigentlich auch für Zeitverschwendung darauf zu antworten. In der 
normalen Praxis versucht man durch Festlegungen von wichtigen Parametern 
die Software die entwickelt wird stabli und wartbar lauffähig zu 
bekommen. Jede Forderung im Pflichtenheft die logisch gegen die 
ausgewählten Instrumente (Compiler, Physik, Mathematik, Hardware) 
verstößt kann nicht logisch in Sofwtare umgesetzt werden. Die Forderung 
nach "abstrakter Universal-Flexibilität" indem man beliebigst den SRAM 
ausnutzen kann widerspricht der Programmierpraxis auf AVRs, aus 
abstrakten unlogischen Forderungen baut man auch nur auf abstrakten, 
unlogischen AVRs eine abstrakt unlogische Software. Man baut in eine 
normalerweise stark zielorientierte und relativ einfach gestrickte 
Software für den AVR ein Feature ein (alles dynamisch im SRAM 
verschiebbar) das kontraproduktiv ist, für diese ausgewählten Mittel. 
Dieses Faeture wird aus dem Projekt ein unwartbares, bzw. ohne 
zusätzliche Vorteile wartbares, und instabiles, fehleranfälliges System 
machen. Wemm dann müsstes du jetzt auf die Suche nach einer besser 
geeigneten Plattform für das Projekt gehen, zb. auf CPUs für PC mit 
richtig fetten Betriebsystemen mit virtuellem Memorymanagement wird man 
mit dynamischer Relokation der Speicherresourcen konfrontiert. Nur das 
dort zwei wichtige Bedingungen erfüllt sind, die HW unterstützt es und 
hat Power und das zu lösende Problem, Multitasking und quasiparallele 
Bedienung von Software wird benötigt.

Oder in kurz: eine dynamische Relokation des SRAMs auf AVRs ist unsinnig 
und praxisfern da man sowieso für jeden weiteren AVR Typ die Software 
erneut anpassen und recompilieren muß. Die einzige Außnahme ist es das 
uns wichtige Informationen über das eigentliche Projekt fehlen und daher 
immer eine Fehlinterpretation unsererseits stattfindet.

Die Antworter hier versuchen also nicht nur auf eine konkrete Frage zu 
antworten, sondern sie versuchen dir, Registersuchender, auch 
beizubiegen das es unter Umständen auch viel bessere Lösungen, die sich 
in der Praxis bewährt haben, zu verklickern. Dazu benötigt man aber 
Informationen die wir nicht haben. Und das machen sie weil sie 
verstanden haben das nicht nur die Lösung eines Problemes mit 
irgendeiner Lösung wichtig ist sondern ein Problem nur dann korrekt 
gelösst ist wenn man es mit der bestmöglich angepassten Lösung angeht.

Gruß Hagen

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jochen Müller
Ich habe Dich nicht aufgefordert mich zu kritisieren und ich habe Dich 
höflich gefragt habe ob Du Kritik von mir hören willst.

Soll ich nun annehmen das Du nicht in der Lage bist zu verstehen oder 
nicht willens?
Und, egal welche Annahme nun zutrifft: Soll ich nun, angesichts dessen, 
weiter annehmen das Du in der Lage bist mein Problem zu lösen?

Am Anfang stand klar und deutlich die Frage nach einer Information. 
Nicht die Bitte um die Lösung eines Problems. Wo steht, das ich jemanden 
auffordere mein Problem zu lösen?

Soll ich nun annehmen das Du nicht in der Lage warst den Unterschied zu 
erkennen oder nicht willens?
Und soll ich das wiederrum als Hinweis auf Deine Fähigkeit annehmen Text 
zu verstehen oder nicht?
Und soll ich nun, wiederrum angesichts dessen, annehmen das Du in der 
Lage bist mein Problem zu lösen?

Du hast hier meine Fähigkeiten in Frage gestellt, obwohl ich Dich dazu 
nicht aufgefordert habe. Mich sogar mit groß geschriebenen Worten 
angeschrieen.
Abgesehen von der Unhöflichkeit die darin liegt, was soll ich nun 
annehmen? Das ich Deine Eigenliebe verletzt habe, weil ich partout Deine 
Benühungen mein Problem zu lösen nicht anerkennen wollte oder das Du, 
indem Du mich kritisiert hast, verdecken wolltest das Du die eigentliche 
Frage nicht beantworten kannst, aber doch Aufmerksamkeit wolltest, die 
ich Dir verweigert habe, indem ich Deine Lösungen als nicht akzeptabel 
kennzeichnete?

Nur eins weiss ich sicher: Meine Frage hast Du nicht beantwortet.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
> Oder in kurz: eine dynamische Relokation des SRAMs auf AVRs ist unsinnig
> und praxisfern da man sowieso für jeden weiteren AVR Typ die Software
> erneut anpassen und recompilieren muß. Die einzige Außnahme ist es das
> uns wichtige Informationen über das eigentliche Projekt fehlen und daher
> immer eine Fehlinterpretation unsererseits stattfindet.

Punkt aus Schluss. Thread beendet.

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
>
> Punkt aus Schluss. Thread beendet.

Warum? Jeder blamiert sich eben so gut er kann.

MfG, der Trollige

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1.) die in neueren AVRs vorhandenen GPIOR benutzen
2.) Prozessorregister wie XH:XL global reservieren und dort deinen 
Zeiger rein
3.) bischen, 2 bytes SRAM abknapsen und statisch global reservieren für 
deinen zeiger
4.) ein transparentes Latch an 2 Ports des AVRs anschließen und dort 
deinen Zeiger abspeichern, über die 2 Ports hast du Zugriff auf dieses 
Latch
5.) externen Speicher benutzen, oder besser noch, externen Speihcer mit 
externen SPeihcer mit externen Speicher in dem schlußendlich dein zeiger 
steht
6.) SPH:SPL als zeiger mißbrauchen, statt nur als Stackpointer zu 
benutzen diesen so umbauen das dieser dein Relokationzeiger darstellt, 
somit inklusive Stackmanagement und als Quintessenz darfst du deinen 
eigenen Compiler bauen der deine Sonderregeln auch umsetzt

Verbleiben die Probleme:
1.) die Software muß auf jeden AVR Typ denoch zugechnitten werden
2.) die Problematik des Stacks ist noch zu lösen, dieser muß an 
igendeiner Stelle, und diese sollte am besten sehr frühzeitig im 
Programmablauf stehen, mit festen nicht reallozierbaren Addressen 
gefüllt werden

Gruß Hagen

PS: Neugier ist eine der besten Eigenschaften der Menschen, und auch 
eine der Eigenschaften die am leichtesten von jedem Menschen 
nachvollziehbar sein sollte.
Ein Programmierer ist ein Problemlöser, er sollte die Eigenschaft haben 
das er das Lösen eine Problemes als intgeressant und befriedigend an 
sieht.
Du stösst hier also im Thread auf exakt solche Menschen die diese beiden 
Eigenschaften besitzen.

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hagen & Simon
>> Oder in kurz: eine dynamische Relokation des SRAMs auf AVRs ist unsinnig

Setzt Ihr die allgemeingültigen Maßstäbe was sinnvoll ist und was nicht?

Im übrigen, wiegesagt, habe ich nicht um Rat gefragt. Sondern nach einer 
Information.

Kennt Ihr den Unterschied?

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und, egal welche Annahme nun zutrifft: Soll ich nun, angesichts dessen,
>weiter annehmen das Du in der Lage bist mein Problem zu lösen?

ich glaube dass könne etliche hier! aber nicht so, so nicht :-)

Fred

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe den thread nicht komplett gelesen, aber ich denke ich habe die 
antwort für das problem ohne der schon oft geforderten hintergrundinfos:

42

@registersucher:
Registersucher wrote:
> Aber der Kunde ist halt König.

manchmal muss man dem kunden verklickern, dass etwas nicht in der form 
möglich ist, wie er es sich einbildet...

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol, du verhältst dich echt lächerlich! Kommst hier mit so einem 
Schwachsinn an, lehnst alle Informationen ab die du geboten bekommst, 
wiederholst immer wieder die Frage nach einer nicht existenten 
Information und beschimpfst die Leute dafür dass sie versuchen dir zu 
helfen.

Ich glaube, du solltest die Finger vom Programmieren lassen.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kennt Ihr den Unterschied?

Sicher doch. Besser ist es du kaufst dir par Bücher die sind nicht 
neugierieg, haben nicht das Bedürfniss nach der Suche von Lösungen weil 
es ihnen Spaß macht.

Dein Fehler ist Unhöflichkeit. Keiner möchte dich im ersten Moment hier 
auslachen oder fertig machen, die meisten versuchen sich in DEIN (ja ich 
schreie mal) Problem reinzudenken und eine Lösung vorzuschlagen.

>Setzt Ihr die allgemeingültigen Maßstäbe was sinnvoll ist und was nicht?

Korrekt das machen wir und es ist sinnvoll. Wir nehmen allgemeingültige 
Maßstäbe, quasi Standardprogramme in unseren Hirnen die durch langjähige 
Erfahrungen bei der Entwicklung mit AVRs so entstanden sind, aus Büchern 
angelesen, aus anderer Software abgeschaut oder einfach hier im Forum 
diskutiert wurden und benutzen sie als Mittel um einen Zweck zu 
erfüllen. Nämlich deine Frage zu beantworten.

Gruß Hagen

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Registersucher,

Kein Mensch hat Dich angeschrien, GROSS geschrieben bedeutet für mich 
nur die Betonung wichtiger Teile.
Dass Dein problem so wie Du es fragtest nicht lösbar ist, müsste Dir 
schon vor mindestens 50 Beiträgen klar geworden seion.

Solange Du aber keine klaren Hintergünde nennst, und auch berechtigte 
Einwände ignorierst (nicht nur von mir, sondern zahlreichen Schreibern)
hilft das nicht weiter.

ALSO:
1) Möglicherweise ist Dein Problem mit einem gänzlich anderen Ansatz 
lösbar.
2) Für DEINEN Ansatz sieht hier niemand eine Lösung.
3) Viele Wege führen nach Rom, man darf die nur nicht einfach 
ingnorieren.
4) Ein Problem ist NUR DANN lösbar, wenn man die kompletten Hintergründe 
kennt.

Ich bin sicher, dass, wenn Du Du unter einem neuen Trhread das Problem 
mal mit allen Hintergründen schilderst, auch eine Lösung gefunden wird.

Und das ist nichts persönliches, das sind GANZ berechtigte Einwände, wie 
ich sie auch bei jedem Kundengespräch aufgebracht hätte.

Jochen Müller

Autor: Registersucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja. Ich glaub', ich lass Euch allein mit Euren Gewissheiten.
Die müssen Euch sehr viel Trost geben.

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe einen funktionierenden hinweis gegeben. wenn du es nicht nehmen 
möchtest pech gehabt.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Naja. Ich glaub', ich lass Euch allein mit Euren Gewissheiten.
>Die müssen Euch sehr viel Trost geben.

Wetten das der noch mal ne Frage hat!

Fred

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fangfrage im Pflichtenheft, Auftraggeber erwartet das der Programmierer 
auf die Unsinnigkeit der Aufgabe hinweist ;)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Registersuchender!

Du hast bei der letzten Zusammenfassung einen Post übersehen, der 
garnicht schlecht aussieht. Witer oben kam nämlich die Idee das ganze 
anders herum zu lösen:

Wenn Du keinen festen Register-Satz hast und alles dynamisieren musst, 
dann dynamisiere doch auch den 'Register-Satz'. Um das Fazit aus dem 
Post zu wiederholen:
Lege einen Pointer auf die RAM-Adresse des 'Register-Satz' im FLASH ab 
und danach legst Du den eigentlichen Pointer ins FLASH dazu. Beim Start 
lädst DU also zuerst einen Pointer auf den 'Register-Satz' und danach 
seinen Inhalt.

Ich kann mir nicht vorstellen, dass Du die dynamischen Codes ohne ein 
gewisses Framework, also Software, präparierst und auf den Controller 
überträgst. Es muss bei der Übertragung ja klar sein, welche Code-Teile 
wo hin sollen und wie viel RAM sie benötigen. Damit hat das Framework 
auch die Information den Pointer dynmisch irgendwo unter zu bringen und 
seinen Startwert zu berechnen. Letzteres, also das Berechnen des 
Startwertes für das dynmische RAM, muss Du ja ohnehin schon machen. Da 
das (hoffentlich) in Bezug auf genutzten und vorhandenen Speicher bezug 
nimmt, sollte auch ein Platz für die Speicherung des nun dynmisierten 
'Register-Satz' möglich sein.

Damit bist Du nur beim Reset auf zwei FLASH/EEPROM Reads angewiesen und 
kannst zur Laufzeit mit 'Full-Speed' auf den Pointer und seinen Inhalt 
zugreifen. Das Muster erlaubt es zudem, auch zur Laufzeit den Pointer zu 
verschieben, also alles ganz gemäß Deinem Konzept.

Sollte der Kunde also den Wunsch hegen, zur Laufzeit Datenbereiche zu 
verschieben, kann Dein Kernel den Pointer in relokieren. Baut der Kunde 
neue Software mit einem anderen Speicher-Layout, dann sorgt Dein 
Framework für die automatisch passende Verlagerung des Pointers.

Damit hättest Du das Lastenheft erfüllt und bist kompatibel zu allen 
AVR. Denn Deine Ursprüngliche Fragestellung ist schon ein Paradoxon, Du 
wünschst eine Kompatibilität zu möglichst allen AVR, fragst aber nach 
Registern, die eventuell nur teilweise in einigen Modellen existieren. 
Da waren die weit gestreuten Antworten vorprogrammiert.

Gruß, Ulrich

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja aber wo ist der Vorteil ?

Das was er jetzt per Hand machen möchte macht der Compiler automatisch 
und vollständig transparent. Und da man eh in der AVR-Szene die Software 
für andere AVrs immer neu kompilieren muß stellt sich die Frage nach dem 
Sinn des Unterfangens. Besonders auch in Bezug darauf das zu 99.99% 
aller Fälle bei AVR Software keine Relokation der SRAM Daten notwendig 
ist, bzw. sogar unerwünscht ist. Die wenigsten Projekte benutzen gar 
einen dynamischen Heap und das wäre die Vorstufe für ein komplett 
dynamisch relokierbares Memory Management.

Gruß Hagen

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt folgende Sorten von Kunden:

1) Der, der den Controller als BlackBox ansieht, der das-und-das machen 
soll.
DEM IST ES PIEP-EGAL WO WELCHE DATENBEREICHE LIEGEN.

2) Der Kunde mit exakten Background.
MIT DEM KANN MAN DAS PROBLEM GANZ OFFEN BEREDEN UND AUF UNMÖGLICHKEITEN 
HINWEISEN, OHNE MURREN.

3) Der Kunde der nicht weiss was er will, Luftschlösser baut, und aus 
Unsicherheit unmögliche Dinge erwartet, weil er schlicht Angst hat 
irgendwelche Weichen falsch zu stellen.
DIESEN TYPEN NIMMT MAN AN DIE HAND, SCHULT IHN UND DER KUNDE GEWINNT 
VERTRAUEN UND LÄSST AM ENDE DEN PROGRAMMIERER MACHEN.

Ich gehe davon aus, das dem Registersucher einfach die Erfahrung fehlt, 
mit diesen Kundentypen entsprechend umzugehen. Da ist ja auch keine 
Schande, ging mir vor 20Jahren ebenso. Aber die zahlreichen helfenden 
Hände hier für dumm verkaufen zu wollen und als unfähig zu bezeichnen, 
nur weil sie ohne Hintergründe keine Lösung nennen können, das geht 
definitiv nicht!

Jochen Müller

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, Leute, woher nehmt ihr bloss dermassen viel Freizeit?!?

Autor: w. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur gut das ich sie nicht hatte.

Puh was ein harter Kanten (Quadratur des Kreises in euklidscher Ebene)
ich kan seine frust verstehen. aber seine Beschwerden sollte er an Atmel 
richten, die Haben sein 16 Bitregister einfach nicht im Plan, weil sie 
es für überflüssig hielten neben einer vielzahl von univerasal und 
spezialregistern eines für nichtvorhergesehen und Anwendungen in alle 
Chipvarianten zu brutzeln. Und noch dazu auf das ohnehin spärlich 
vorhandene RAM.


Als alter Zzweckentfremder kann ich nur sagen: " Bevor ich etwas 
zweckentfremde analysire ich dessen Möglichkeiten." Ein Weg findet sich 
dann fast immer. Aber ein Problem welches nur aus Unbestimmbarkeiten 
besteht seiner selbst.

;-)))

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
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.