Mit Tachyonen und Gold-Chip gegen Handystrahlen...

Axel Berger wrote:
-A23731@B3

*Axel Schwenke* wrote on Tue, 07-10-16 12:50:
weil der Internet-Browser eines gewissen Software-Herstellers in
Versionen die älter als 3 Jahre sind, Probleme mit diesem Bildformat hat.

Huh? Davon weiß ich nichts. Ab Version ie 5.0 (4.x kenne ich nicht, ist
aber recht deutlich älter als drei Jahre) kenne ich keinerlei Probleme
mit PNG. Es gibt da was mit dem durchsichtiogen Hintergrund, aber
Manfred sprach ausdrücklich von Abbildungen und nicht von
Designspielereien und da ist das vollkommen irrelevant.

Ansonsten stimme ich ihm aber zu, die Arroganz jeder andere habe
ebenfalls alle fünf Minuten auf das allerneueste umzuschwenken ist
vollkommen verkehrt. Unter anderem sieht man das an den Zeichensätzen
in News und Mail, von denen meine Software nur die alt etablierten
korrekt erkennt.
Dann ziehe ich einfach weiter. Hat NXP bereits eine Stange Geld
gekostet. Sind eigentlich deren Q3 Financials schon angekuendigt oder
trauen sie sich noch nicht?

--
Gruesse, Joerg

http://www.analogconsultants.com/
 
*Christian Zietz* wrote on Sat, 07-10-20 20:28:
Gesetz? Bitte zitieren. Oder meinst Du nur genormt? Norm!=Gesetz.
Stimmt. Es ginbt ein Gestz über die Einheiten im Meßwesen und eine
Einheitenverordnung. Beide zählen ein paar kleinigkeiten auf, verweisen
aber im wesentlichen auf die Normen. Und damit werden die dann
verbindlich.
Wenn es unbedingt sein muß, krame ich sogar die Texte wieder vor, aber
ungern weil mühsam.
 
Axel Berger schrieb:

Stimmt. Es ginbt ein Gestz über die Einheiten im Meßwesen und eine
Einheitenverordnung. Beide zählen ein paar kleinigkeiten auf, verweisen
aber im wesentlichen auf die Normen. Und damit werden die dann
verbindlich.
Weder das Gesetz noch die Verordnung sagen allerdings etwas zur
Datumsdarstellung und verweisen auch nicht auf DIN ISO 8601.

Wenn es unbedingt sein muß, krame ich sogar die Texte wieder vor, aber
ungern weil mühsam.
Wenn Du den Hinweis auf die gesetzliche Vorschrift zur Datumsdarstellung
nach DIN ISO 8601 fändest, wäre das echt klasse.

CU Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
 
*Christian Zietz* wrote on Mon, 07-10-22 20:31:
Weder das Gesetz noch die Verordnung sagen allerdings etwas zur
Datumsdarstellung und verweisen auch nicht auf DIN ISO 8601.
Du hast Recht. Senil und vergeßlich wie ich werde sollte ich wirklich
besser nicht mehr ungeprüft aus dem Gedächtnis posten.
 
Rainer Weikusat schrieb:

Thomas Rachel <glglgl@expires-2007-10-31.arcornews.de> writes:

Objekte mit 'static storage duration', die nicht anderweitig
initialisert wurden, sollen auf einen geeigneten Nullwert gesetzt
werden (6.7.8|10).
Danke für die Bestätigung. Das heißt also, eigentlich sollte dort 0
stehen und nicht "irgendwas". Ich leite mal grade um in die (m.E.)
passende Gruppe für Mikrocontrollerprogrammierung. (Bin ich jetzt hier
richtig, oder wo sonst sind Mikrocontroller ontopic?)


Nochmal zusammengefaßt, es geht darum: ich habe ein Objekt mit "static
storage duration", das ich nicht explizit initialisiere. Auf
verständlich: ich habe in einem Modul beispielsweise ein "int x;"
stehen, das nach C-Standard eigentlich auf 0 initialisiert werden
sollte, d.h. äquivalent zu "int x=0;" sein sollte.

Dies geschieht jedoch nicht; ich habe einen beliebigen Wert dort stehen.


Ich verwende einen PIC18 und compiliere mit der MPLAB IDE v7.62 und dem
MCC18-Compiler. Ich erhalte auch laut Map-File ganz vorschriftsmäßig die
entsprechenden Sections. Aber offenbar werden sie nicht ausgenullt...
Habe ich irgendwo was falsch eingestellt, oder verhält sich besagtes
System von sich aus standardwidrig?

Eigentlich hätte ich auch erwartet, daß alle udata-Sections irgendwo
zusammen abgelegt werden, um sie dann auf einen Schlag ausnullen zu
können. Das ist aber auch nicht der Fall.

Ist da zufällig schon mal jemand drübergestolpert? Was muß ich tun, um
einen (in dieser Hinsicht) standardkonformen Compiler zu erhalten?


Thomas
 
Sebastian Waschik schrieb:

deine Variable ist aber nicht static:
|unsigned char unin[1990000];

Probiere es mal mit folgendem:
static unsigned char unin[1990000];
hm, dürfte auf die "storage duration" IMHO keinen Einfluß haben... Oder
liege ich da flhcas? Zumal es im angegebenen Fall ja so war, daß die
GCC-Version richtig gearbeitet hat - das Array oben war komplett genullt
(im Gegensatz zum "auto"-Array ui im Beispielcode, wo auch nicht-nullne
Werte drin waren, ich das aber ok finde).

static hat auf die "storage duration" nur Einfluß, wenn ich es in einer
Funktion verwende und steht da im Gegensatz zur "automatic duration".
(Siehe auch
http://osr507doc.sco.com/en/tools/clang_declar_storage_duration.html
)


Aber um wieder off-topic zu werden ;-), gebe ich auch hier (und dort)
das (vorläufige) Ergebnis meiner Recherchen bekannt[1]: offenbar gibt es
mehrere Versionen des Initialisierungscodes: gebe ich im Linkerskript
anstelle des ursprünglichen "FILES c018i.o" die Anweisung "FILES
c018iz.o", funktioniert es wir gewünscht, weil in dieser Variante vorher
der komplette Speicher ausgenullt wird und dann erst die
Initialisierungswerte aus dem ROM ins RAM geschrieben werden. Weshalb es
c018i.o überhaupt gibt... keine Ahnung. Vermutlich, um 1,3 ms beim
Einschalten zu sparen oder so...


Thomas

[1] darum auch wieder Xp+Fup2
 
Am Mon, 29 Oct 2007 17:40:09 +0100 schrieb Thomas Rachel:

Hi!

Nochmal zusammengefaßt, es geht darum: ich habe ein Objekt mit "static
storage duration", das ich nicht explizit initialisiere. Auf
verständlich: ich habe in einem Modul beispielsweise ein "int x;"
stehen, das nach C-Standard eigentlich auf 0 initialisiert werden
sollte, d.h. äquivalent zu "int x=0;" sein sollte.
Meinst du ein "static int x"?

Unter C werden Variablen doch nie nicht automatisch initalisiert wenn ich
nicht irre.

Dies geschieht jedoch nicht; ich habe einen beliebigen Wert dort stehen.
Wie gesagt, ich denke das ist standardkonform. Ich kenne aber auch nicht
alle C Dialekte.

Liene Grüße,
Thorsten
 
Thorsten Oesterlein schrieb:

Meinst du ein "static int x"?

Unter C werden Variablen doch nie nicht automatisch initalisiert wenn ich
nicht irre.
Tust du aber. Das Daten-Segment wird immer mit 0 initialisiert, wenn
nicht anders angegeben. Daten im BSS-Segment sind uninitialisiert.

Viele Grüße,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka "Makus"
aka "Kosst Amojan" aka "maqqusz" in de.sci.electronics
<45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>
 
Johannes Bauer wrote:
Thorsten Oesterlein schrieb:

Meinst du ein "static int x"?

Unter C werden Variablen doch nie nicht automatisch initalisiert wenn ich
nicht irre.

Tust du aber. Das Daten-Segment wird immer mit 0 initialisiert, wenn
nicht anders angegeben. Daten im BSS-Segment sind uninitialisiert.
Fast -- nur genau andersrum. Initialisierte Variablen stehen im
Datensegment, und Variablen, die auf 0 initialisiert werden landen im BSS.

static int x = 5; -> landet im Data-Segment.
static int y; -> landet im BSS-Segment und sollte vom C-Prolog
vor dem Aufruf von main() auf 0 gesetzt werden.

Das BSS-Segment ist eigentlich nur eine einfache Form der Komprimierung
um das Objectfile (bzw. das fertige Programm) kleiner zu bekommen. Es
wĂźrde nichts dagegen sprechen, alles im Datensegment abzulegen.

--
thomas.kindler@gmx.de,
www.bredobrothers.de, www.dohbots.de,
www.microsoft-hellhounds.de
 
Thomas Rachel wrote:

Ist da zufällig schon mal jemand drübergestolpert? Was muß ich tun, um
einen (in dieser Hinsicht) standardkonformen Compiler zu erhalten?
Egal was der Standard sagt. Es ist guter & sicherer Programmierstil alle
Variablen bei denen man einen bestimmten Wert zum Start haben will auch zu
initialisieren.
int i = 0;


Nick
--
The lowcost-DRO:
<http://www.yadro.de>
 
Nick Mueller schrieb:

Egal was der Standard sagt. Es ist guter & sicherer Programmierstil alle
Variablen bei denen man einen bestimmten Wert zum Start haben will auch zu
initialisieren.
int i = 0;
Grundsätzlich stimme ich Dir zu. Allerdings ist das einiges an Zeugs,
und ich vermute stark, daß die explizit initialisierten Variablen dann
auch entsprechend Platz im ROM-Image belegen, und davon hab ich leider
auch nur 4k...


Thomas
 
Thomas Rachel wrote:

... daß die explizit initialisierten Variablen dann
auch entsprechend Platz im ROM-Image belegen, und davon hab ich leider
auch nur 4k...
Hmm. Nachdem die Variablen ja im RAM liegen (<G>), muss der Compiler sie
entweder laut Standard (IIRC sagt er das zumindest fĂźr static) mit 0
initialisieren (was code braucht) oder du machst es (was code braucht).
Die Frage ist, wie clever/dumm der Compiler ist. Wird der Wert bei statics
mit 0 initialisiert, dann sollte er für deine (Über-)Initialisierung mit 0
keinen zusätzlichen code generieren. Ausprobieren.
Initialisiert er nicht mit 0, dann kann man mit einem charfill() sehr
kompakt mit 0 initialisieren wenn man eben diese Variablen hintereinander
deklariert.
Start = @ErsteVariable
length = @LetzteVariable - @ErsteVariable + sizeof(LetzteVariable).
Die Berechnung mit einem assert absichern. :)


Nick
--
The lowcost-DRO:
<http://www.yadro.de>
 
Nick Muellerschrieb:
"
Thomas Rachel wrote:

... daß die explizit initialisierten Variablen dann
auch entsprechend Platz im ROM-Image belegen, und davon hab ich leider
auch nur 4k...

Hmm. Nachdem die Variablen ja im RAM liegen (<G>), muss der Compiler sie
entweder laut Standard (IIRC sagt er das zumindest für static) mit 0
initialisieren (was code braucht) oder du machst es (was code braucht).
Die Frage ist, wie clever/dumm der Compiler ist. Wird der Wert bei statics
mit 0 initialisiert, dann sollte er für deine (Über-)Initialisierung mit 0
keinen zusätzlichen code generieren. Ausprobieren.
Initialisiert er nicht mit 0, dann kann man mit einem charfill() sehr
kompakt mit 0 initialisieren wenn man eben diese Variablen hintereinander
deklariert.
Start = @ErsteVariable
length = @LetzteVariable - @ErsteVariable + sizeof(LetzteVariable).
Die Berechnung mit einem assert absichern. :)

Das steht doch alles in der "startup".
Entweder kopiert der Controller Nullen in den Block, bei
Initialisierung auf 0, oder er kopiert einen Block aus dem ROM in den
RAM, um die Variablen zu initialisieren.

MfG
Dirk
 
Thomas Rachel <glglgl@expires-2007-10-31.arcornews.de> schrieb:

Weshalb es c018i.o überhaupt gibt... keine Ahnung. Vermutlich, um
1,3 ms beim Einschalten zu sparen oder so...
....und 20 Bytes. Ist aber in der Tat 'ne böse Falle.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
 
Harald Wilhelms schrieb:
On 14 Okt., 13:47, Rolf_Bombach <rolfnospambomb...@bluewin.ch> wrote:

Ich denke, den Durchschnittsverbrauch von reichlich 20 kW
kriegt er auch mit konsequenten Umstellen auf Energiespar-
lampen nicht so schnell weg :-[.

Könnte man den Pool nicht auch mit Energiesparlampen heizen?
Sicher, auch wenn ich hier eher zu normalen Glühlampen geraten
hätte. Energiesparlampen braucht man dann fünf mal mehr, was
konstruktive und investitionsmässige Probleme aufwirft. Auch
wird das dann so hell, dass das noch mehr in den Augen brennt
wie das elende Chlor. Auch darf man sich dann nicht wundern,
wenn sich aufgebrachte Astronomen anschleichen und schwarze
Tinte in den Pool kippen.

--
mfg Rolf Bombach
 
Thomas Meier schrieb:
Weiss ich auch nicht. Aber wieviel Energie wird eigentlich für die
Herstellung eine Glühlampe verbraucht? Wie gesagt, die Durotest
Lampen halten locker 8-10mal solange, wie die normalen.

Wird sich nicht viel von der Energiemenge zur Herstellung
einer Bierflasche unterscheiden. Und die schmeisst man
auch in die Tonne ohne gross drüber nachzudenken.

Gibts das in der Schweiz? Aus D kenne ich Bier nur in Pfandflaschen(0),
da tauscht man im Getränkemarkt leer gegen voll(1), v.a. wenn es sich um
die alten bauchigen Flaschen handelt, an denen eingie fränkische
Brauereien festhalten. Die kann man nur da zurückgeben wo sie angeboten
werden.
Ja. Viele Traditionsplörren werden in 0.33 l oder 0.5 l Einwegflaschen
angeboten. Die sind recht dünnwandig. Die haben meist einen Kronkorken
Verschluss mit Gewinde, sodass auch der grobmotorisch ungeübte diese
Flaschen ohne Werk- oder sonstiges Zeug aufkriegt. Jedenfalls wenn
er sozusagen den Dreh raus hat.
(1) Keine Ahnung wieviel Energie das rumfahren und ausspülen kostet. Und
seit dem mal ein Stück Orangenschale im Bier war alle Kiddies
verfluchend und beschimpfend die ich auf Parties die Flaschen als
Aschenbecher oder Abfalleimer missbrauchend sehe.
Das schlimmste sind die Deppen, welche die Flaschen zwischendurch
zum Aufbewahren von Öl, womöglich noch Motoren-Altöl, benutzen. Das
gibt extrem Ärger bei der Reinigung.
Energetisch ungünstig sind sehr dickwandige Flaschen mit schlechter
Volumenausnutzung drin und drumrum, welche dann noch gekühlt
transportiert werden müssen. Kurzum Milchflaschen. Das grosse
Totvolumen braucht zu viel Kühlraum.

--
mfg Rolf Bombach
 
Matthias Kern schrieb:
Rolf_Bombach <rolfnospambombach@bluewin.ch> schrieb:

Wird sich nicht viel von der Energiemenge zur Herstellung
einer Bierflasche unterscheiden. Und die schmeisst man
auch in die Tonne ohne gross drüber nachzudenken.
(Sie soll ja nicht in den Restmüll. Ein Teil des
eingesammelten Glases wird dann in der Müllverbrennungs-
anlage wieder beigemischt, als Schlackebildner).

Ja, ja, Schlackebildener, wohl ein wenig bekloppt!

Ich weiß noch ganzgenau, als man in München die Glascontainer
einführte, nicht etwa um Glas zu sammeln und energie zu sparen, nein
genau darum um in der Müllverbrennungsanlage, eben keine Schlacke zu
haben, die sich an den Ofenwänden festsetzt.
Ja, das ist richtig. Nur ist man hier, wie so oft bei diesen
Hau-Ruck-Entschlüssen, über das Ziel hinausgeschossen. Gleich-
zeitig wurden ja auch Einweg-Glasgebinde en masse vom Markt
genommen. Resultat, die günstige Glasmenge im Abfall von
IIRC ungefähr einem Gurkenglas pro 50 l Hausmüll, wurde
unterschritten.

Es ist schon klar, es ist technisch viel einfacher, diese
geringe Glasmenge als Granulat nachher genau zuzudosieren
als irgend was rauszufischen. Auch ist es letztendlich
einfacher dem Konsumenten zu "verkaufen", er solle kein
Glas in den Abfall tun, als etwa eine Empfehlung abzugeben,
so ungefähr ein Glas pro Abfalltüte beizugeben.

War nur als Beispiel für heute typische Überreaktionen gedacht.

--
mfg Rolf Bombach
 
Rolf Bredemeier wrote:
Hallo,

ich habe einen Haufen Mignon-Akkus, deren Kapazitär ich
mal messen möchte.

8 Stück zugleich soll der zu verbauende AVR handeln.

Und ich habe noch einen Haufen Darlington-Arrays Type SLA4070:
http://www.nur-solutions.de/tmp/sla4070.pdf

Ich weiss jedoch nicht, wie ich aus den ICs eine
passende Stromsenke (1 Ampere) bauen könnte, da die Durchfluss-
spannung ja bei 1,2V liegen wird, die Entladeschluss-
spannung der Akkus aber deutlich darunter liegt.

Geht nicht, oder doch?
Vcesat ueber 0.7V ist nicht so der Hit, wuerde arg eng.

Es macht natürlich auch keinen Sinn, jede Menge Aufwand
zu betreiben, nur, damit die Dinger auch verwendet werden.

Da muss ich dann zur Not doch in ein paar BUZ11 investieren.

Wollte aber vorher einmal fragen.
Hast Du nicht noch ein paar FETs aus Audioendstufen rumliegen?

--
Gruesse, Joerg

http://www.analogconsultants.com/
 

Welcome to EDABoard.com

Sponsor

Back
Top