Wo findet man Programmierer?

[Rainer Buchty]

In article <cu4sf1$5ap$1@online.de>,
Bernhard Walle <bernhard.walle@gmx.de> writes:
|> Dafür gibt es Shared Libraries. Es findet auch eine sehr starke
|> Interaktion zwischen der C-Library und dem Programm statt, deshalb linkt
|> man auch nicht bei jedem Programm die C-Library statisch hinzu.

Mit "Monolith" meinte ich nicht eine statisch gelinkte Version, sondern
die komplette Verzahnung von GUI und Anwendung in einem Programm.

|> Natürlich macht ein extra Kommandozeilenprogramm, das man aufruft und
|> mit den Daten füttert, hier keinen Sinn.

Eben, das war der Knackpunkt.

Rainer

 

[Matthias Weingart]

Oliver Bartels <spamtrap@bartels.de> wrote in
news:bi4a0157rai2mrc8g085jbpbr1ar785lnk@4ax.com:

Um beim Busfahrer zu bleiben, geht es eher darum, dass das
Gaspedal mit der linken Fuss zu bet„tigen ist und er zum Bremsen
immer den Handgriff hinter der rechten Schulter ziehen muss.
Jetzt lach bitte nicht, aber viele Rennfahrer bremsen mit dem
*linken* Fuá und bei den Rennmoppeds l„uft aus gutem Grund
(Hochschalten in der Kurve) die Schaltung auch umgekehrt wie bei
Strassenmaschinen.

Ich glaube aber, dass ein Hersteller eher Müllfahrzeuge verkauft, wenn
"nur ein normaler LKW-Führerschein erforderlich" ist, als wenn
"Rennfahrerausbildung hilfreich bzw. 6 wöchiger Lehrgang bei uns im
Hause" nötig sind.

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Oliver Bartels]

On Sun, 6 Feb 2005 13:11:39 +0000 (UTC), Matthias Weingart
<mwnews@pentax.boerde.de> wrote:

Ich glaube aber, dass ein Hersteller eher Müllfahrzeuge verkauft, wenn
"nur ein normaler LKW-Führerschein erforderlich" ist, als wenn
"Rennfahrerausbildung hilfreich bzw. 6 wöchiger Lehrgang bei uns im
Hause" nötig sind.
Das wird wohl so sein.

Nur hat einer als Hersteller von Müllfahrzeugen ein Problem, wenn
er den kompletten Fuhrpark der Firma "Joined Waste Forces" bedienen
soll, welche die Fahrer sowohl der "Roter Müllmann AG" wie auch
der "Stadtwerke Blaustein GmbH" übernommen hat, wobei die
"Roten" zum Abkippen früher bei ihren "Topmedes" einen Schiebehebel
links unten gewohnt waren, während hingegen bei den "Adlerwagen"
der "Blauen" ein Hebel dort die Freigabe der Tonnenaufnahme
bewirkt ;-)

Wobei er das Problem dann doch nicht wieder hat, weil sich
die Fahrer von Müllfahrzeugen im allgemeinen recht schnell an
ein neues Modell gewöhnen. Mir wäre z.B. nicht bekannt, dass
bei der Umstellung der S-Bahn München auf LZB dort irgendwas
an den *Fahrern* der Züge gescheitert wäre ...

Was hingegen bekannt ist, ist dass einiger Stress verursacht
wurde, weil immer mal wieder irgendein Teil des von einer bekannten
Bank mit angeschlossener Elektroabteilung gelieferten Stellwerks
herumzickt (wobei man wohl diese Bank mit Elektroabteilung
mittlerweile zu einem Vor-Ort-Präsenzdienst "herangezogen" hat).

Und damit wieder zum Thema: Mit den Fahrern klappt das
offensichtlich, aber so mancher diplomierter Akademiker
erweist sich als lernresistent und empfindet jede noch so kleine
Mausbewegung am PC und jedes Neu-Lernen und Nachdenken
als unzumutbar.

Es würde mich jetzt nicht unbedingt wundern, wenn das die
gleichen Leute sind, die dann auch nicht über ihre eigenen
Entwicklungen nachdenken wollen (unzumutbar!), was somit zu
so "perfekten" Produkten wie oben beschrieben führt ...

Ciao Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

 

[Axel Schwenke]

"MaWin" <me@private.net> wrote:

"Kurt Harders" <news@kurt-harders.de> schrieb

Ist OO an Dir vorbeigegangen? Die Datenstruktur gehört heute mit zur
Logik/Verarbeitung, weil sie Bestandteil der verwendeten Objekte ist.
....

Ein Fehler vieler heutige Programme. Nach dieser Strukturierung
ergibt sich ein kein vertikal teilbares Programm

+------+-----+------+
| | | |
|Ober- |Daten|Rechen|
|fläche| |-kern |
| | | |
+------+-----+------+

Diese Architektur ist so alt, daß es sogar schon ein Buzzword dafür
gibt: MVC - Model View Controller

Und MVC ist mit OO durchaus kompatibel. Es sagt ja keiner, daß man die
Methoden des Controllers an die Objekte aus dem Model klatschen muß.
Auch wenn das OO-Unerfahrene vielleicht im ersten Anlauf so machen.


XL

 

[Olaf Kaluza]

MaWin <me@private.net> wrote:

verzweifeln, und frage mich, welches kranke Hirn meine Handysoftware
entworfen hat.

Du GLuecklicher! An meinem Handy waren mehrere kranke Hirne beteiligt
die sich noch nichtmal miteinander absprechen konnte. SEUFZ!

das viele Kunden mehr Ahnung von der getesteten Materie haben als er,
ignorieren viele Softwareentwickler, das der Mensch, der vor dem
Computer ueber sie schimpft, RECHT hat.

Es muesste ein Gesetz geben das Programmierer maximal einen Rechner
besitzen duerfen der halb so schnell ist und halb so viel Ram hat wie
der aktuelle Rechner bei Aldi/Lidl. Ausserdem duerften sie nur
Software verkaufen die auch ihre Eltern bedienen koennen. HAHRHAR!

Olaf

 

[Axel Schwenke]

"MaWin" <me@private.net> wrote:

"Axel Schwenke" <axel.schwenke@gmx.de> schrieb

Die Entscheidung, ob eine Resource frei ist, trifft in richtigen
Betriebssystemen der Betriebssystemkern. Deswegen ist es eine
ausgesprochen blöde Idee, eben diesen Kern zu umgehen.

Bloss weil du und Microsoft nicht weiss, wie man das Problem richtig
loest, heisst das noch lange nicht, das es keine Loesung gibt.

Aber sonst gehts dir noch gut? Mich in einen Topf mit Microsoft ...
<grummel>

Warum FOLGST du nicht den extra schon gegebenen Hinweisen und liest
was schon geschrieben wurde, sondern postest in Unkenntnis ?

Die These ist einfach falsch. Da muß ich mich nicht durch Google-
Treffer wühlen um weitere falsche "Beweise" dazu zu finden.


XL

 

[Georg Acher]

Oliver Bartels <spamtrap@bartels.de> writes:

Wobei er das Problem dann doch nicht wieder hat, weil sich
die Fahrer von Müllfahrzeugen im allgemeinen recht schnell an
ein neues Modell gewöhnen. Mir wäre z.B. nicht bekannt, dass
bei der Umstellung der S-Bahn München auf LZB dort irgendwas
an den *Fahrern* der Züge gescheitert wäre ...

Die sind wohl eher froh. Sie müssen jetzt keine Vorsignale mehr bestätigen
(davon gabs viele...), können im Tunnel Vollgas/strom geben, können ohne
Sonderbefehl fast "auf Sicht" fahren und Runterbremsen geht auch von allein.

Was hingegen bekannt ist, ist dass einiger Stress verursacht
wurde, weil immer mal wieder irgendein Teil des von einer bekannten
Bank mit angeschlossener Elektroabteilung gelieferten Stellwerks
herumzickt (wobei man wohl diese Bank mit Elektroabteilung
mittlerweile zu einem Vor-Ort-Präsenzdienst "herangezogen" hat).

Was man so hört, war wohl der Rechner, der die Telegramme der Züge auswertet
und die Sollwertvorgaben wieder an die Züge zurückschickt, etwas überlastet...
Da hat wohl jemand übersehen, dass jeder Zug 14+14 Telegramme pro Sekunde
braucht/erzeugt und die Stammstrecke eine etwas höhere Zugdichte als eine
ICE-Strecke hat... Mitsamt der ganzen Wegberechnung dürfte das einen Rechner
schon gut auslasten, und ein "normaler" PC und "normale" SW dürfte das aufgrund
der nötigen Ausfallsicherheit auch nicht sein.

Kann passieren, dass man sich da mit der Performance verschätzt, muss aber
nicht ;-) Aber nachdem alle Werke der Firma an S-Bahnhaltestellen liegen,
bekommen sie das wenigstens direkt mit...

Und damit wieder zum Thema: Mit den Fahrern klappt das
offensichtlich, aber so mancher diplomierter Akademiker
erweist sich als lernresistent und empfindet jede noch so kleine
Mausbewegung am PC und jedes Neu-Lernen und Nachdenken
als unzumutbar.

Es würde mich jetzt nicht unbedingt wundern, wenn das die
gleichen Leute sind, die dann auch nicht über ihre eigenen
Entwicklungen nachdenken wollen (unzumutbar!), was somit zu
so "perfekten" Produkten wie oben beschrieben führt ...

IMHO liegt das Hauptproblem (auch bei der Elektrobank) daran, dass Erstellung
des Pflichtenhefts/Spezifikation und Programmierung strikt getrennt sind. Wenn
die Programmierer tatsächlich mal nachdenken und feststellen, dass etwas in der
Vorgabe für den User unpraktisch ist, ist es nahezu umöglich, das zu verändern.
Erstens ist das ein Affront dem Spezifikateur gegenüber (schliesslich
spezifiziert der ja schon jahrelang und hat damit Recht) und zweitens gibt es
Unmengen an Papierarbeit. Ich habe da so Geschichten eines mitdenkenden
Chipdesigners bei Inferior gehört. Der Chip war streng nach Spezifikation
korrekt, aber so kaum sinnvoll einsetzbar...

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Markus Becker]

Moin,

Gerald Oppen wrote:

Oliver Bartels schrieb:
rechten Hand, also da, wo beim Mopped das Gas ist ... )
umsteigen, ohne dass dies zu Problemen führt.

Und ganz viele andere Menschen können das auch ...

Ob da in Prozent bei den Fahrern ausgedrückt immer noch so ganz viele
sind...

Jeder, der einen Auto- und einen Motorradfüherschein hat, kann das.

Markus

 

[Markus Becker]

Moin,

Olaf Kaluza wrote:

Du GLuecklicher! An meinem Handy waren mehrere kranke Hirne beteiligt
die sich noch nichtmal miteinander absprechen konnte. SEUFZ!

Beispiel Siemens S45i:

Mal ist 'Ok' links, 'Abbrechen' rechts. Dann wieder 'Nein' links,
und 'Ja' rechts. KrankKrankKrank.

Es muesste ein Gesetz geben das Programmierer maximal einen Rechner
besitzen duerfen der halb so schnell ist und halb so viel Ram hat wie
der aktuelle Rechner bei Aldi/Lidl. Ausserdem duerften sie nur
Software verkaufen die auch ihre Eltern bedienen koennen. HAHRHAR!

Wenn Du Software programmierst, die Deine Eltern bedienen können,
will sie niemand anders als Deine Eltern haben.

Markus

 

[Andreas Schwarz]

MaWin wrote:

Die Realitaet trennt Daten und Verarbeitung, sie arbeitet eben nicht
dokumentenzentrisch (wenn ich ein Papier habe, stehen mir eben nicht
saemtliche Werkzeuge zum Schreiben, Bemalung, Zerschneiden automatisch
zur Verfuegung, wie jeder weiss dem mal eine Offsetdruckmaschine fehlte),
sondern liefert Werkzeuge (Anwendungsprogramme) zur Bearbeitung,
ist also Applikationsorientiert.

Das lässt sich aber auf die Software nicht so einfach übertragen. Sonst
hast du eine "Schere" die Word- und RTF-"Papiere" zerschneiden kann,
eine andere die PDF schneidet, und noch eine die HTML schneidet. Wieso
also nicht, statt lange im Werkzeugkasten zu kramen, dem Papier
beibringen wie es sich selbst zerlegen kann?

 

[Bernhard Walle]

* Olaf Kaluza [06.02.2005 16:56]:

Es muesste ein Gesetz geben das Programmierer maximal einen Rechner
besitzen duerfen der halb so schnell ist und halb so viel Ram hat wie
der aktuelle Rechner bei Aldi/Lidl.

Und Webdesigner als Internetzugang ein 56K-Modem statt *DSL haben.

Gruß,
Bernhard

 

[Markus Becker]

Moin,

MaWin wrote:

Ein klares Nein. Bedenke, das es fuer X nicht mal allgemein
akzeptierte Dialoggadgets gibt (Motif, KDE, ...)

Muss ja auch nicht. Das ist dann wieder eine Schicht drüber.

das ist durchaus das inzwischen bekannte Drama der OO-Technologie.
Denn eine auf beide Arten teilbare Programmstruktur

:

:

uebersteigt erwiesenermassen die Planungsfaehigkeit realer Programmierer.

Sagen wir's mal so: Es muss schnell fertig werden.

Die Realitaet trennt Daten und Verarbeitung, sie arbeitet eben nicht
dokumentenzentrisch (wenn ich ein Papier habe, stehen mir eben nicht
saemtliche Werkzeuge zum Schreiben, Bemalung, Zerschneiden automatisch
zur Verfuegung, wie jeder weiss dem mal eine Offsetdruckmaschine fehlte),
sondern liefert Werkzeuge (Anwendungsprogramme) zur Bearbeitung,
ist also Applikationsorientiert. Sorry, so ist die Realitaet, egal
was in OO-Buechern an modernen Maerchen drin steht.

Ein wahres Wort gelassen ausgesprochen...

Markus

 

[Oliver Bartels]

On Sun, 06 Feb 2005 19:53:17 +0100, Andreas Schwarz
<usenet@andreas-s.net> wrote:

Das lässt sich aber auf die Software nicht so einfach übertragen. Sonst
hast du eine "Schere" die Word- und RTF-"Papiere" zerschneiden kann,
eine andere die PDF schneidet, und noch eine die HTML schneidet. Wieso
also nicht, statt lange im Werkzeugkasten zu kramen, dem Papier
beibringen wie es sich selbst zerlegen kann?
Das ist richtig, zeigt aber auch gut die Grenzen der OO auf:

Wenn jetzt eine Funktion gefragt ist, die den Abstand zweier
Papierfetzen in beliebigem Format *effizient* bestimmen soll,
läuft es doch wieder auf ein Modul hinaus, das alles über jedes
Papierformat weiß. Oder kurz und knapp:
OO kann bestimmte Dinge übersichtlicher machen, mit
Templates sogar ganz viel Copy&Paste vermeiden helfen,
zeigt aber leider keine algorithmische Eigenintelligenz.

( Übrigens ein typisches Problem bei EDA Software und nicht
umsonst eine der Ecken, wo Marketingonlyware regelmäßig
den Löffel wirft, wenn es darum geht, festzustellen ob und wie
der Strom denn nun über die 1231 Leiterbahnen und 1457
Polygone mit darin enthaltenen 671 Kreisbögen fließt oder nicht,
wenn zudem noch 123 Bauteile mit eigenwilligen Padformen
im Spiel sind.
Die Funktion macht dann den Unterschied zwischen wenigen
und vielen Power-Planes und zwischen HF-Design geht bzw.
geht_nicht_wirklich. )

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

 

[Markus Becker]

Moin,

MaWin wrote:

Haeh ? Lebst du in einer Parallelwelt ?

Warum kriege ich staendig irgendwelche Word oder PowerPoint oder
Excel-Dateien zugeschickt, die nur das allerneueste Word, Excel
oder PowerPoint lesen kann, obwohl nur plattester Inhalt drin
ist, den schon Version 1.0 konnte ?

Es ging ja nicht darum, ob Prog-V2.0 noch die Daten von Prog-V1.0
lesen kann, sondern darum, daß Prog-V1.0 noch auf Win-V2.0 läuft.

Ein ueberwiegender Teil ehemals gut funktionierender Software
laeuft unter meinem XP nicht mehr, ob TombRaider3, CDRWin oder
meine Programmiergeraetesoftware.

Wowereit.

parallel installiert, damit alte Software noch benutzbar ist,
aber nur so lange Microsoft diese alte Software haben will.

Bzw. braucht. Hast Du mal Quelltext von MS-Office gesehen?

Markus

 

[Martin]

Am Sun, 6 Feb 2005 20:42:59 -0500 schrieb Olaf Kaluza
<olaf@criseis.ruhr.de>:

Markus Becker <yetispamb@web.de> wrote:

Beispiel Siemens S45i:

Mal ist 'Ok' links, 'Abbrechen' rechts. Dann wieder 'Nein' links,
und 'Ja' rechts. KrankKrankKrank.

NEC N341i:

Loeschen einer Email verlangt eine Bestaetigung. Sagt man ja wird sie
geloescht.
Eine SMS wird dagegen ohne Rueckfrage geloescht, landet dafuer aber im
Papierkorb der extra zu loeschen ist.
[100 andere Probleme spare ich mir]

Man sollte doch meinen wenn mehr als ein Programmierer an einem
Projekt beteiligt sind, das sie sich auch mal ueber ihre Arbeit
unterhalten. Wenigstens beim Mittagessen. [seufz]

Wenn ich nicht dringend imode brauchte (wegen Email) so wuerde ich mir
ein Nokia 2110 auf Lithiumakku umbauen. :-]

War das nicht ein Waffenscheinpflichtiger "stumpfer Gegenstand"? Ein

bisschen kleiner darf es heute schon sein.
--
Martin

 

[Matthias Weingart]

Olaf Kaluza <olaf@criseis.ruhr.de> wrote in
news:33h6uc.cs4.ln@criseis.ruhr.de:

Nokia

Ihmo einer der wenigen Hersteller, wo sich die Leute Gedanken um die
Bedienung gemacht haben. Bei neueren Modellen liegen z.B. liegen häufig
benutze Funktionen zwar in Untermenüs. Man erreicht sie aber einfach
dadurch das man mehrmals die Menü-Taste drückt (ohne Scrollen zu
müssen).

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[Olaf Kaluza]

Markus Becker <yetispamb@web.de> wrote:

Beispiel Siemens S45i:

Mal ist 'Ok' links, 'Abbrechen' rechts. Dann wieder 'Nein' links,
und 'Ja' rechts. KrankKrankKrank.

NEC N341i:

Loeschen einer Email verlangt eine Bestaetigung. Sagt man ja wird sie
geloescht.
Eine SMS wird dagegen ohne Rueckfrage geloescht, landet dafuer aber im
Papierkorb der extra zu loeschen ist.
[100 andere Probleme spare ich mir]

Man sollte doch meinen wenn mehr als ein Programmierer an einem
Projekt beteiligt sind, das sie sich auch mal ueber ihre Arbeit
unterhalten. Wenigstens beim Mittagessen. [seufz]

Wenn ich nicht dringend imode brauchte (wegen Email) so wuerde ich mir
ein Nokia 2110 auf Lithiumakku umbauen. :-]


Olaf

 

[Vinzent 'Gadget' Hoefler]

Dirk Ruth wrote:

Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das
macht man nur in C/C++.

Falsch.


Vinzent.

--
worst case: The wrong assumption there actually is one.

 

[Matthias Weißer]

Vinzent 'Gadget' Hoefler schrieb:

Dirk Ruth wrote:

Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das
macht man nur in C/C++.

Falsch.

Welch wohldurchdachte und in sich schlüssige Argumentationskette.

SCNR

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

 

[Vinzent 'Gadget' Hoefler]

Matthias Weißer wrote:

Vinzent 'Gadget' Hoefler schrieb:
Dirk Ruth wrote:

Hardwarenahe Programmierung heist Kernel-Treiber schreiben und das
macht man nur in C/C++.

Falsch.

Welch wohldurchdachte und in sich schlüssige Argumentationskette.

Man nennt das Wissen und Erfahrung.

SCNR

-- 8< -- elan520-sdram_controller_registers.ads - snip --

------------------------------------------------------------------------
-- AMD Élan(tm) SC 520 embedded microprocessor --
-- MMCR -> SDRAM Controller Registers --
-- --
-- Johnny L. Fencey aka. Vinzent Hoefler (<ada.rocks@jlfencey.com> --
-- --
-- pragma License (GPL); --
------------------------------------------------------------------------

with Elan520.Basic_Types;

package Elan520.SDRAM_Controller_Registers is

---------------------------------------------------------------------
-- SDRAM Control (DRCCTL) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 10h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- sub types for SDRAM_Control
type Operation_Mode_Select is (Normal,
NOP_Command,
All_Banks_Precharge,
Load_Mode_Register,
Auto_Refresh);
for Operation_Mode_Select use (Normal => 2#000#,
NOP_Command => 2#001#,
All_Banks_Precharge => 2#010#,
Load_Mode_Register => 2#100#,
Auto_Refresh => 2#101#);
for Operation_Mode_Select'Size use 3;

DEFAULT_OPERATION_MODE_SELECT :
constant Operation_Mode_Select := Normal;

-- unit is 7.8 microseconds
type Refresh_Request_Speed is range 1 .. 4;
for Refresh_Request_Speed'Size use 2;

DEFAULT_REFRESH_REQUEST_SPEED : constant Refresh_Request_Speed := 2;

---------------------------------------------------------------------
-- SDRAM Control at MMCR offset 16#10#
---------------------------------------------------------------------
MMCR_OFFSET_SDRAM_CONTROL : constant := 16#10#;
SDRAM_CONTROL_SIZE : constant := 8;

type SDRAM_Control is
record
Op_Mode_Sel : Operation_Mode_Select;
Rfsh : Basic_Types.Positive_Bit;
Rfsh_Spd : Refresh_Request_Speed;
Wb_Tst : Basic_Types.Positive_Bit;
end record;

for SDRAM_Control use
record
Op_Mode_Sel at 0 range 0 .. 2;
Rfsh at 0 range 3 .. 3;
Rfsh_Spd at 0 range 4 .. 5;
-- bit 6 is reserved
Wb_Tst at 0 range 7 .. 7;
end record;

for SDRAM_Control'Size use SDRAM_CONTROL_SIZE;

---------------------------------------------------------------------
-- SDRAM Timing Control (DRCTMCTL) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 12h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- subtypes for SDRAM Timing Contol
type RAS_CAS_Delay is range 2 .. 4;
for RAS_CAS_Delay'Size use 2;
DEFAULT_RAS_CAS_DELAY : constant RAS_CAS_Delay := 4;

type RAS_Precharge_Delay is (Two_Cycles, Three_Cycles,
Four_Cycles, Six_Cycles);
for RAS_Precharge_Delay use (Two_Cycles => 2#00#,
Three_Cycles => 2#01#,
Four_Cycles => 2#10#,
Six_Cycles => 2#11#);
for RAS_Precharge_Delay'Size use 2;
DEFAULT_RAS_PRECHARGE_DELAY :
constant RAS_Precharge_Delay := Four_Cycles;

type CAS_Latency is range 2 .. 3;
for CAS_Latency'Size use 1;
DEFAULT_CAS_LATENCY : constant CAS_Latency := 3;

---------------------------------------------------------------------
-- SDRAM Timing Control at MMCR offset 16#12#
---------------------------------------------------------------------
MMCR_OFFSET_SDRAM_TIMING_CONTROL : constant := 16#12#;
SDRAM_TIMING_CONTROL_SIZE : constant := 8;

type SDRAM_Timing_Control is
record
Ras_Cas_Dly : RAS_CAS_Delay;
Ras_Pchg_Dly : RAS_Precharge_Delay;
Cas_Lat : CAS_Latency;
end record;

for SDRAM_Timing_Control use
record
Ras_Cas_Dly at 0 range 0 .. 1;
Ras_Pchg_Dly at 0 range 2 .. 3;
Cas_Lat at 0 range 4 .. 4;
-- bits 5-7 are reserved
end record;
for SDRAM_Timing_Control'Size use SDRAM_TIMING_CONTROL_SIZE;

---------------------------------------------------------------------
-- SDRAM Bank Configuration (DRCCFG) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 14h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- subtypes for SDRAM Bank Configuration
type Bank_Count is (Two_Bank_Device, Four_Bank_Device);
for Bank_Count use (Two_Bank_Device => 0,
Four_Bank_Device => 1);
for Bank_Count'Size use 1;

type Column_Address_Width is range 8 .. 11;
for Column_Address_Width'Size use 2;

type Bank_Descriptor is
record
Col_Width : Column_Address_Width;
Bnk_Cnt : Bank_Count;
end record;
for Bank_Descriptor use
record
Col_Width at 0 range 0 .. 1;
-- bit 2 is reserved
Bnk_Cnt at 0 range 3 .. 3;
end record;
for Bank_Descriptor'Size use 4;

---------------------------------------------------------------------
-- SDRAM Bank Configuration at MMCR offset 16#14#
---------------------------------------------------------------------
MMCR_OFFSET_SDRAM_BANK_CONFIGURATION : constant := 16#14#;
SDRAM_BANK_CONFIGURATION_SIZE : constant := 16;

type SDRAM_Bank_Configuration is
record
Bnk0 : Bank_Descriptor;
Bnk1 : Bank_Descriptor;
Bnk2 : Bank_Descriptor;
Bnk3 : Bank_Descriptor;
end record;

for SDRAM_Bank_Configuration use
record
Bnk0 at 0 range 0 .. 3;
Bnk1 at 0 range 4 .. 7;
Bnk2 at 0 range 8 .. 11;
Bnk3 at 0 range 12 .. 15;
end record;

for SDRAM_Bank_Configuration'Size use SDRAM_BANK_CONFIGURATION_SIZE;

---------------------------------------------------------------------
-- SDRAM Bank 0 - 3 Ending Address (DRCBENDADR) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 18h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- subtypes for SDRAM Bank Ending Address
type Ending_Address is range 0 .. 2**7 - 1;

type Ending_Address_Descriptor is
record
End_Address : Ending_Address;
Bnk : Basic_Types.Positive_Bit;
end record;

for Ending_Address_Descriptor use
record
End_Address at 0 range 0 .. 6;
Bnk at 0 range 7 .. 7;
end record;
for Ending_Address_Descriptor'Size use 8;

---------------------------------------------------------------------
-- SDRAM Bank Ending Address at MMCR offset 16#18#
---------------------------------------------------------------------
MMCR_OFFSET_SDRAM_BANK_ENDING_ADDRESS : constant := 16#18#;
SDRAM_BANK_ENDING_ADDRESS_SIZE : constant := 32;

type SDRAM_Bank_Ending_Address is
record
Bnk0 : Ending_Address_Descriptor;
Bnk1 : Ending_Address_Descriptor;
Bnk2 : Ending_Address_Descriptor;
Bnk3 : Ending_Address_Descriptor;
end record;

for SDRAM_Bank_Ending_Address use
record
Bnk0 at 0 range 0 .. 7;
Bnk1 at 0 range 8 .. 15;
Bnk2 at 0 range 16 .. 23;
Bnk3 at 0 range 24 .. 31;
end record;

for SDRAM_Bank_Ending_Address'Size use
SDRAM_BANK_ENDING_ADDRESS_SIZE;

---------------------------------------------------------------------
-- ECC Control (ECCCTL) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 20h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- ECC Control at MMCR offset 16#20#
---------------------------------------------------------------------
MMCR_OFFSET_ECC_CONTROL : constant := 16#20#;
ECC_CONTROL_SIZE : constant := 8;

type ECC_Control is
record
ECC_All : Basic_Types.Positive_Bit;
Single_Bit_Interrupt : Basic_Types.Positive_Bit;
Multi_Bit_Interrupt : Basic_Types.Positive_Bit;
end record;

for ECC_Control use
record
ECC_All at 0 range 0 .. 0;
Single_Bit_Interrupt at 0 range 1 .. 1;
Multi_Bit_Interrupt at 0 range 2 .. 2;
-- bits 3 to 7 are reserved
end record;

for ECC_Control'Size use ECC_CONTROL_SIZE;

---------------------------------------------------------------------
-- ECC Status (ECCSTA) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 21h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- ECC Status at MMCR offset 16#21#
---------------------------------------------------------------------
MMCR_OFFSET_ECC_STATUS : constant := 16#21#;
ECC_STATUS_SIZE : constant := 8;

type ECC_Status is
record
Single_Bit_Error : Basic_Types.Positive_Bit;
Multi_Bit_Error : Basic_Types.Positive_Bit;
end record;

for ECC_Status use
record
Single_Bit_Error at 0 range 0 .. 0;
Multi_Bit_Error at 0 range 1 .. 1;
-- bits 2 to 7 are reserved
end record;

for ECC_Status'Size use ECC_STATUS_SIZE;

---------------------------------------------------------------------
-- ECC Check Bit Position (ECCCKBPOS) --
-- Memory Mapped, Read Only --
-- MMCR Offset 22h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- ECC Status at MMCR offset 16#22#
---------------------------------------------------------------------
MMCR_OFFSET_ECC_CHECK_BIT_POSITION : constant := 16#22#;
ECC_CHECK_BIT_POSITION_SIZE : constant := 8;

type ECC_Check_Bit_Position is range 0 .. 38;
for ECC_Check_Bit_Position'Size use ECC_CHECK_BIT_POSITION_SIZE;

---------------------------------------------------------------------
-- ECC Check Code Test (ECCCKTEST) --
-- Memory Mapped, Read/Write --
-- MMCR Offset 23h --
---------------------------------------------------------------------

---------------------------------------------------------------------
-- subtypes for ECC Check Code Test
type Forced_ECC_Check_Bits is range 0 .. 2**7 - 1;

---------------------------------------------------------------------
-- ECC Check Code Test at MMCR offset 16#23#
---------------------------------------------------------------------
MMCR_OFFSET_ECC_CHECK_CODE_TEST : constant := 16#23#;
ECC_CHECK_CODE_TEST_SIZE : constant := 8;

type ECC_Check_Code_Test is
record
Force_Bad_ECC_Check_Bits : Forced_ECC_Check_Bits;
Bad_Check : Basic_Types.Positive_Bit;
end record;

for ECC_Check_Code_Test use
record
Force_Bad_ECC_Check_Bits at 0 range 0 .. 6;
Bad_Check at 0 range 7 .. 7;
end record;

for ECC_Check_Code_Test'Size use ECC_CHECK_CODE_TEST_SIZE;

---------------------------------------------------------------------
-- subtypes for error addresses (single & multi-bit)
type Error_Address is range 0 .. 2**26 - 1;

---------------------------------------------------------------------
-- ECC Single-Bit Error Address (ECCSBADD) --
-- Memory Mapped, Read Only --
-- MMCR Offset 24h --
---------------------------------------------------------------------
MMCR_OFFSET_ECC_SINGLE_BIT_ERROR_ADDRESS : constant := 16#24#;
ECC_SINGLE_BIT_ERROR_ADDRESS_SIZE : constant := 32;

type ECC_Single_Bit_Error_Address is
record
SB_Addr : Error_Address;
end record;

for ECC_Single_Bit_Error_Address use
record
SB_Addr at 0 range 2 .. 27;
end record;

---------------------------------------------------------------------
-- ECC Multi-Bit Error Address (ECCMBADD) --
-- Memory Mapped, Read Only --
-- MMCR Offset 28h --
---------------------------------------------------------------------
MMCR_OFFSET_ECC_MULTI_BIT_ERROR_ADDRESS : constant := 16#28#;
ECC_MULTI_BIT_ERROR_ADDRESS_SIZE : constant := 32;

type ECC_Multi_Bit_Error_Address is
record
MB_Addr : Error_Address;
end record;

for ECC_Multi_Bit_Error_Address use
record
MB_Addr at 0 range 2 .. 27;
end record;

end Elan520.SDRAM_Controller_Registers;

-- 8< -- snip --

0% C, 0% C++, 100% Hardware.


SCNRE,

Vinzent.

--
worst case: The wrong assumption there actually is one.