Controller mit statischem RAM

Thomas 'Tom' Malkus schrieb:

Hallo, jeder µC mit Powerdown Modi? Wenn natürlich an der Spannung keine anderen Verbraucher hängen. Einige AVR brauchen dann 1µA und weniger. Also, Brown Out detektieren -> dann Powerdownmode fertich.....

Andreas

Man kann alle üblichen modernen Controller in standby schalten, also z.B. Controller abschalten oder auch Clock abschalten. Letzteres wäre hier nötig. Für "Stunden" ist Pufferung über Goldcap aber eventuell riskant.

Langsamer Zugriff, aber wenn der Controller I2C hat gäbe es eventuell auch noch "ferroelektrische" 24C02-Varianten für hohe Zahl von Schreibzyklen.

In DIL40: 68HC908GP32 Den gäbs auch (kostenpflichtig) mit FORTH drauf:

Das ist aufbohrter 68HC05 nicht 68HC11, Befehlssatz aber sehr ähnlich.

MfG JRD

Rafael Deliano schrieb:

Welchen Vorteil das gegenüber der Programmierung in gängigeren Sprachen haben sollte, konnte mir noch keiner zufriedenstellend erklären.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Rafael Deliano meinte:

Ja, ist auch die einzige Alternative, die mir bisher einfiel.

Es kommt nicht so genau auf die Zeit an, die Geräte laufen nur in einer Umgebung wo permanente Spannungsschwankungen an der Tages- ordnung sind und ein paar Byte müssen das überleben. Der 68HC711 mit dem 2,2F GoldCap hat noch nach Tagen die Daten.

Und ein extra Chip. Wollte ich vermeiden.

Ich hatte eher an einen aufgebohrten 8051er gedacht, da ist man bei einigen Typen nicht vom Hersteller abhängig.

Aber mal schauen...

Danke!

73 de Tom

--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43PC * DL-QRP-AG #1186 * AGCW-DL #2737 DARC OV I19

Für allgemeine Erklärungen ( mit ideologischer Schlagseite ) gäbs newsgroups:

de.comp.lang.forth ( wenig belebt, gutes S/N-Verhältnis ) comp.lang.forth ( sehr belebt, entsprechendes S/N-Verhältnis )

oder Webseiten. Hier nur die der FORTH e.V.:

Deren Zeitschrift ist überigens dort kostenlos als pdf verfügbar:

Enthält sporadisch Vorabdrucke von meiner Zeitschrift ( an die man jetzt nichtmehr so gut rankommt ).

Bezogen auf Controller: FORTH macht wenig Sinn wenn es nur als Crosscompiler existiert. Im GP32 läuft es aber im Controller. D.h. man tippt am Terminalprogramm das über V24 am Controller hängt rum, der "Computer" der tut ist aber der Controller. Man hat sowas wie simples Betriebsystem ( a la MS-DOS, nur weniger ) integriert mit interpretierender Programmiersprache vor sich. Grafische Benutzeroberfläche is nicht.

Von "gängigeren Sprachen" ist C zwar hardwarenah und genau-so-gut-lesbar aber es ist schwieriger zu erlernen ( weil umfangreicher ). C erzeugt als Crosscompiler effizienteren Code, aber unterstützt Modularität ( d.h. konsequente Zerlegung in Unterprogramme ) und Debugging weniger ( es gibt für FORTH keinen separaten "Debugger", die Sprache macht das ). D.h. man kriegt in FORTH bestimmt kein schnelleres Programm, aber man kriegt das Programm schneller. Aus dem Grund ist im GP32 auch Assembler/Disassembler für den 68HC08 integriert, sodaß man die Unterprogramme die Geschwindigkeit brauchen in Assembler einbinden kann. BASIC wäre zwar nominell auch Interpreter, aber weniger hardwarenah. Es auch weniger konsequent als FORTH für interaktives Arbeiten ausgelegt. Eben nur humanere Form von Algol, keine radikal andere Sprache. Praktische Erfahrung bezogen auf Controller:

• Leute die vorher Assembler programmiert haben, haben minimale Probleme FORTH zu erlernen. Leute die sich gut mit C auskennen haben endlose Probleme ( "Wo sind hier die Pointer?" ).

• Leute die Windows, Java, grafische Benutzeroberflächen usw. mögen brauchen keinen Gedanken an FORTH verschwenden.

• an FORTH kommt man nicht durch Lesen von Büchern ran ( selbst wenn der Brodie recht nett ist ), sondern man muß sich vor laufendes System setzen um rumtippen anfangen. Für das Elektor R8C-Board gibts überigens eine ziemlich kostenlose Implementierung von Paysan.

MfG JRD

Thomas 'Tom' Malkus schrieb:

Wirst du durch die spezielle Forderung dann wohl doch. Aber frag doch mal im Forum auf

Gruß Dieter

Würde mir der Befehlssatz nicht gefallen. Jenseits des 8051 DIL40-Oldtimers dens wohl auf ewig und billig geben wird: second-source gibts dort heute auch nichtmehr. Man ist dann von genau einem Hersteller abhängig und bei Freescale bedeutete langfristige Verfügbarkeit bisher genau das. Die 68HC11 ( entwickelt in den 80ern ) sind teilweise immer noch verfügbar:

Hilft aber nur bei Boards mit herausgeführtem Bus, die 68HC711 OTPs hats bereits weitgehend erwischt. 68HC705 OTPs gibts aber immer noch.

MfG JRD

Dieter Wiedmann meinte:

Warum? Spezielle Forderung auf das statische RAM bezogen?

Ich hatte mir das, wie ich andeutete, schon fast gedacht, das Controller so kaum noch auf dem Markt sind und die Lösung im Bereich der PowerDown und StandBy Modi liegt. Es hätte aber auch anders sein können. Ich möchte aber nicht den totalen Exoten einsetzen und wenn es etwas bei den gängigen Controllern geben würde, hätte hier schon jemand geantwortet. Das ist ja das Schöne am Usenet ;-).

Also werde ich es mal mit den StandBy-Modi testen.

Gruss, Thomas

--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43PC * DL-QRP-AG #1186 * AGCW-DL #2737 DARC OV I19

Rafael Deliano meinte:

Ist mir eigentlich egal, 98% Code ist sowieso C. Damit habe ich aber Erfahrung und die Entwicklungstools (PK51).

Wenn ich das jetzt auf die Schnelle richtig gesehen habe, habe ich die freie Wahl bezüglich Pin-Kompabilität zwischen Atmel,NXP,Dallas und Intel, z.B. AT89C51RD2 o.ä.

Ich weiß, dass ist wirklich langfristig bei denen...

Ich setze seit über 10 Jahren den 68HC711E9CFN2 ein, für den muss so langsam mal ein Ersatz bei dem Produkt her.

Gruss, Thomas

--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43PC * DL-QRP-AG #1186 * AGCW-DL #2737 DARC OV I19

Das ist, weiß Gott, kein Alleinstellungsmerkmal. Wer Assembler wirklich beherrscht (und nicht nur irgendeinen der Tausende von Dialekten benutzt), der kann sich in _jede_ prozedurale Sprache ziemlich problemlos einarbeiten. Schlimmstenfalls läßt er sich das Disassemblat des binaries anzeigen, um zu gucken, was der jeweilige Compiler da eigentlich jeweils verzapft hat. Auf diese Art kann man sich sozusagen "bottom-up" sogar die abstrakten Prinzipien objektorientierter Programmierung aneignen.

Und erst wenn man weiß, was hinter den Kulissen passiert, wird der Sinn (und teilweise Unsinn) manches Sprachfeatures von Hochsprachen wirklich verständlich. Das trifft besonders auf die zu, bei denen OO eher nur ein notdürftig drangestrickter modischer Aufsatz ist, namentlich: C++.

Auf jeden Fall helfen gute Assemblerkenntnisse unwahrscheinlich bei der Entzifferung der völlig unleserlichen Ergüssen mancher grenzdebiler C-Freaks, die scheinbar ernsthaft glauben, extrem kurzer Quelltext wäre gleichbedeutend mit einem laufzeiteffizienten Programm oder vielleicht sogar eine Art "Kopierschutz". Und noch viel nützlicher sind sie, wenn die angebliche "Portabilität" von C mal wieder doch nicht so ganz portabel ist und der erzeugte Code im Zielsystem nur Mist macht.