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.
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
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
@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?
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
@ 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.
>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.
1
Liste1:x1[0..L1]
2
Liste2:x2[0..L2]
3
Liste3:x3[0..L3]
4
...
5
Liste9:x9[0..L9](letzteListe.Max9stückmöglich)
Dann lege ich eine Struktur mit folgendem Inhalt an:
1
-AnzahlmaxListen
2
-StartListe1
3
-StartLsite2
4
-StartListe3
5
-...
Also für das Beispiel sieht das dann so aus:
1
9,&x1,&x2,&x3,...,&x9
Diese Referenz musst du natürlich so speichern, dass du weißt, wo diese
Referenz beginnt.
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.
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
@ 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?
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...
@ 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.
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
> 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.
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.
>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...
>>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
.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
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.
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
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.
@ 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.
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
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.
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.
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
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.
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?
@ 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.
>>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
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?
@ 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.
@ 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.
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?
>>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
@ 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.
@ 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.
@ 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.
>>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
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
@ 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."
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.
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
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.
> 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.
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.
@ 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.
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.
...
@ 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.
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.
@ 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.
@ 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?
@ 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.
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 ;-)
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 ;)
@ 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.
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. ;-)
>>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
@ 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.
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.
>>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
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.
@ 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.
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?
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.
@ 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?
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
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
>>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.
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
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.
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)
@ 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?
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.
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
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.
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.
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...
...
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.
@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.
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.
...
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)
>>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
...
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 jedemAVR laufen
soll.
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.>> ...
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
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..
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!
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.
...
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".
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
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.
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.
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.
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
>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
@ 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.
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.
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.
@ 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?
>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
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...
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.
> 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
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
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
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
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
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.
;-)))
