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
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 )
langsamer als 8 Bit Controller.
Befehlssatz durch beliebigen Wildwuchs an CPU-Varianten.
Gibts auch in DIL
D.h. Vapourware/Schrottfaktor ist halt recht hoch.
MfG JRD
Am 18.12.2014 12:17 schrieb Michael Baeuerle:
Bei Harvard-Architekturen ist Codeinjektion um einiges schwieriger (aber
ebenfalls eine Rolle spielen.
Hanno
Der Klassiker bei den IBM-Mainboards.
Bernd
Am 18.12.2014 um 13:47 schrieb Hanno Foest:
zB bei rechnern an die hohe sicherheitsanforderungen gestellt werden,
Am 18.12.2014 um 09:49 schrieb Rafael Deliano:
Wenn ich mich jetzt nicht irre, sind die im industriellen bereich
Am 18.12.2014 13:47, schrieb Hanno Foest:
liegt, statt eines Speicherbereiches im RAM. Hat eben alles Vor- und Nachteile.
Bernd
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.
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
Als das ROM voll war, war sie fertig. :)
Gerrit
Adressraum alle Befehle auf alle Speicherstellen anwenden kann, egal ob
Ausgabe auf einem Display ablegen, schliesslich sind das Daten.
Gerrit
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
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
Am 18.12.2014 um 14:15 schrieb Bernd Laengerich:
und Sun (da weiss ichs aus eigener Erfahrung, bei anderen wars wohl
MfG Rupert
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
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
Am 18.12.2014 um 18:37 schrieb Rupert Haselbeck:
Ich finde die Trennung so wie Atmel es gemacht hat praxisgerecht. Streng
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.
On 18 Dec 14 at group /de/sci/electronics in article snipped-for-privacy@mid.individual.net
Ich kenne beides. Firmen die noch WireWrap kannten (IBM, DEC, hp ...) nahmen eben diesen.
Wolfgang
Have something to add? Share your thoughts — no account required.
Ask the community — no account required