Ich finde es erschütternd

Das klingt aber schon ein wenig nach Stockholm-Syndrom, so einen Murks als Feature zu verkaufen.

Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt? 


Kosmologen: Die Geheim-Vorhersage.
Reply to
Johannes Bauer
Loading thread data ...

die ALU heran- bzw. weggeschafft werden).

#define PROGMEM #define memcpy_P memcpy

ja nun auch nicht der Riesenaufwand, wenn man Code auf eine andere libc portieren will.

aber fairerweise mit anderen 8bit CPUs vergleichen. Dass hier eine 32bit

ich glaube da noch nicht so richtig dran.

AVR einfach die falsche Wahl.

umgefallenen Bits im RAM kann man damit z.B. verhindern, dass eine

Reply to
Michael Baeuerle

Man kann sich terminologisch streiten ob embedded = industrial. Oder embedded >< PC, da ist dann bald alles embedded.

Behaupten die bunten Zeitschriften.

hat sich da relativ gut gehalten.

ein Schrumpf-ARM da hinkommt weniger.

Anwendungen 32 Bit ist glaube ich nicht.

Die ARMs die ich kenne ( EFM M3 )

  • haben einen Cache der Interrupts bremst.
  • Sind ziemlich mau als Bitbanger.

langsamer als 8 Bit Controller.

  • da die CPU also kaum IO machen kann haben sie komplexe, verbuggte, schlecht dokumentierte IO-Module mit denen sich der Anwender behelfen

Befehlssatz durch beliebigen Wildwuchs an CPU-Varianten.

Gibts auch in DIL

formatting link
/ Leider sind die Register des Flashcontrollers in diesem / Chip nicht dokumentiert, weswegen das direkte Kompilieren

D.h. Vapourware/Schrottfaktor ist halt recht hoch.

MfG JRD

Reply to
Rafael Deliano

Am 18.12.2014 12:17 schrieb Michael Baeuerle:

Bei Harvard-Architekturen ist Codeinjektion um einiges schwieriger (aber

ebenfalls eine Rolle spielen.

Hanno

Reply to
Hanno Foest

Der Klassiker bei den IBM-Mainboards.

Bernd

--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen. 
P.Liedermann in defa
Reply to
Bernd Laengerich

Am 18.12.2014 um 13:47 schrieb Hanno Foest:

zB bei rechnern an die hohe sicherheitsanforderungen gestellt werden,

--
mfg hdw
Reply to
horst-d.winzler

Am 18.12.2014 um 09:49 schrieb Rafael Deliano:

Wenn ich mich jetzt nicht irre, sind die im industriellen bereich

--
mfg hdw
Reply to
horst-d.winzler

Am 18.12.2014 13:47, schrieb Hanno Foest:

liegt, statt eines Speicherbereiches im RAM. Hat eben alles Vor- und Nachteile.

Bernd

--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen. 
P.Liedermann in defa
Reply to
Bernd Laengerich

Bei den neueren AVRs gibt es das leider nicht mehr, aber PICs gibt es noch mit Hardware-Stack. Dazu gibt es Varianten die ihren Programm-

Kombination aus beidem sollte es extrem schwierig sein, dass die CPU

ROP-Angriff missbraucht wird).

Interface kann man aber per Hardware absichern.

Reply to
Michael Baeuerle

Es gibt eigentlich auch keinen Grund mehr einen 8051 zu nehmen... Ausser dem weiter unten genannten.

Designs eher nicht, es sei denn als Core.

Gerrit

Reply to
Gerrit Heitsch

Als das ROM voll war, war sie fertig. :)

Gerrit

Reply to
Gerrit Heitsch

Adressraum alle Befehle auf alle Speicherstellen anwenden kann, egal ob

Ausgabe auf einem Display ablegen, schliesslich sind das Daten.

Gerrit

Reply to
Gerrit Heitsch

ist es oft recht einfach rauszufinden wieviele Masken es brauchte.

kompatibel zu den Versionen mit Masken-ROM. Da konnte man schon brauchbar debuggen. Lief der Code dann wurde einfach das EPROM an den Hersteller geschickt und ins ROM transferiert.

Dachboden noch wird es mit aktueller Hardware nicht mehr gehen.

einen Nachbau von Petra, der lief besser als die Senseo, speziell was die Behandlung von 'Wasserstand niedrig' war.

Gerrit

Reply to
Gerrit Heitsch

Der Compiler kann nicht alles vor dir verbergen, schliesslich muss er

Hardware aus deinem eleganten Konstrukt ein Monster macht was nicht mehr ins ROM passt hast du vom Verbergen nichts.

Das kann dir bei Flash aber auch passieren. Ist schliesslich im Prinzip auch nur dynamisches RAM mit langer Refreshperiode.

Gerrit

Reply to
Gerrit Heitsch

Am 18.12.2014 um 14:15 schrieb Bernd Laengerich:

und Sun (da weiss ichs aus eigener Erfahrung, bei anderen wars wohl

MfG Rupert

Reply to
Rupert Haselbeck

Am 18.12.2014 17:25 schrieb Gerrit Heitsch:

beschriftet wurden?

Ich mein, ich hab von diesen Piggyback-Varianten noch einen 8048 rumliegen. Einen 8748 (mit eingebautem EPROM und Quarzfenster) hab ich sicher.

Elektronik und Firmware Modellpflege betrieben.

Hanno

Reply to
Hanno Foest

Eher nicht, sieht man an den nicht-ROM-Chips von MOS. Da steht die

lief. Beim NTSC-VIC war das Revision 7 (6567R7). Der PAL-VIC ging schon

Kleinigkeiten angepasst werden mussten. Der 6569R3 hatte dann auch alle

9 Helligkeitsstufen.

wurde und man per EPROM testete bis es lief. Das waren damals auch keine Hochsprachencompilate, Kleinkram von ein paar KB wurde direkt in Assembler geschrieben und ergab sehr kompakten Code. Heute hat man oft den Eindruck als wenn nach der Devise 'doesn't crash immediatly, ship it, if there are serious bugs we ship an update' gearbeitet wird. Womit der Kunde dann den Spass hat.

Das war so bei EPROMs, Frage ist, wie ist das bei dem aktuell in den Controllern verwendeten Flash? Wie ist das wenn das Teil auf dem Dachboden lagert, also im Sommer gekocht und im Winter gefroren wird?

Gerrit

Reply to
Gerrit Heitsch

Am 18.12.2014 um 18:37 schrieb Rupert Haselbeck:

--
http://www.headless-brewing.com/
Reply to
Eric Brücklmeier

Ich finde die Trennung so wie Atmel es gemacht hat praxisgerecht. Streng

Reply to
Michael Baeuerle

eignet, aber was besser geeignetes gibt es halt nicht.

Dann ersetze das Flash in Gedanken durch ein Masken-ROM. Der Punkt war

wollen oder nicht, es kommt auf den Anwendungsfall an.

Reply to
Michael Baeuerle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.