mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Frage zu MSP430 Dokumentation für Einstieg


Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein nächstes Firmenprojekt wird höchstwahrscheinlich auf einem MSP430 
für ein 4-20mA/HART gespeistes industrielles Steuergerät beruhen. Ich 
habe mich gestern interessehalber schon ein wenig mit einem MSP430 
Launchpad bewaffnet und mit ein paar uC Peripherien wie GPIO und UART, 
Timer erfolgreich befaßt.

Als zu unterstützende Dokumentation holte ich mir bis jetzt neben dem 
MSP430 User Manual und uC Datenblatt vom Netz zwei Standardwerke die 
hier im Forum schon erwähnt wurden. ("MSP430 Family Architecture Guide 
and Module Library" und "Analog und Mixed Signal Application Reports").

Lohnt es sich anhand dieser Vorhandenen Dokus noch irgendwelche Bücher 
zu besorgen? Auf Amazon gibt es ja Einiges. An sich komme ich aber mit 
den erwähnten klar geschriebenen Dokus und Datenblätter schon ganz gut 
klar und es ist alles Pertinente gut beschrieben. Deshalb bin ich mir 
unsicher ob sich das wirklich lohnen würde. Der uC Variant ist eine 
MSP430FR5998 Launchpad Bord mit CCS V8.1.


Wie habt ihr Euch mit dem MSP430 vertraut gemacht?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Lohnt es sich anhand dieser Vorhandenen Dokus noch irgendwelche Bücher
> zu besorgen?

Vergiss nicht die Device Errata Sheet … :-o  Einige Dinge da sind schon 
recht abschreckend.  Habe vor paar Jahren mal damit zu tun gehabt, kam 
dann allerdings doch nicht zum Kundenprojekt.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Gerhard O. schrieb:
>> Lohnt es sich anhand dieser Vorhandenen Dokus noch irgendwelche Bücher
>> zu besorgen?
>
> Vergiss nicht die Device Errata Sheet … :-o  Einige Dinge da sind schon
> recht abschreckend.  Habe vor paar Jahren mal damit zu tun gehabt, kam
> dann allerdings doch nicht zum Kundenprojekt.

Hi Jörg,

Danke für den "Reminder";-) da habe ich auch schon Einiges erlebt. Hoffe 
aber schon, dass es da keine wirkliche "Show stopper" gibt. Ist aber 
sonst ein interessantes Teil.

Gruß,
Gerhard

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Hoffe aber schon, dass es da keine wirkliche "Show stopper" gibt.

Beinahe-show-stopper für uns war damals, dass man einen Zählerwert nicht 
zuverlässig auslesen kann, während der Zähler läuft. Offizieller 
Würgaround ist es, den Zähler beim Auslesen anzuhalten … Der Rest war 
zumindest erträglich, wenngleich die Tatsache, dass vieles über viele 
Revisions nicht repariert worden ist, schon einen schalen Beigeschmack 
hinterlässt.

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
https://forum.43oh.com/ ist ein Anlaufpunkt den ich Dir empfehlen kann 
Gerhard. Der MSP430 ist nicht schlechter oder besser als andere 
Prozessoren seiner Klasse und interessante Errata gibts auch bei den 
AtXmegas.
In so fern im Westen nichts Neues.
Ich programmiere in C mit gcc und es ist nicht wirklich relevant ob man 
einen Atmel oder einen TI am Wickel hat.


@Jörg: das mit dem Zähler ist ca. genauso lustig wie der Fakt das man 
den internen EEPROM nicht beschreiben kann so lange der Prozessor läuft 
..wie gehabt beim AtXmega128A3.
Gruß,

Holm

: Bearbeitet durch User
Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Wie habt ihr Euch mit dem MSP430 vertraut gemacht?

Datenblatt, Errata, Familiy Ref, Adapter PCB + Lochraster (kein 
sinnvolles Eval Board für den Typ verfügbar) und los gehst.
Dann im Kreis kotzen was die Timer-A vom MSP430I2041 alles NICHT können 
(selten so sinnfrei kastrierte Timer gesehen), dafür sind die 24bit ADC 
recht nett. Irgendwas ist ja immer.

Ein Kollege hat mir ein MSP430 Buch mitgebracht, in dem wunderschön 
beschreiben war wie man ein völlig anderes Uralt Modell betütert das 
ganz andere Peripherie hat. Nett aber nicht hilfreich.

Vergiss Bücher, lese die Dokus der Hersteller.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Ich programmiere in C mit gcc und es ist nicht wirklich relevant ob man
> einen Atmel oder einen TI am Wickel hat.

… oder einen ARM. :) Das wird immer erst interessant, wenn's in die 
tieferen Regionen geht.

Was mir noch einfällt: wimre ist bei 32 (oder 48?) KiB erstmal das Ende 
der Flash-Fahnenstange erreicht, danach werden andere Dinge 
eingeblendet, IO-Register, RAM etc. Wenn man ein Device mit mehr Flash 
hat, gibt's dann weiter hinten (jenseits 64 KiB) ein zweites 
Flash-Segment. Um die Zuordnung, welche Funktion in welchem Bereich 
landet, muss(te?) man sich zumindest beim GCC selbst kümmern.

Für kleinere Devices ist das natürlich kein Thema, vorteilhaft ist dann 
dort, dass man alles in einem Adressraum hat und keine gesonderten 
Befehle für den Flash-Daten-Zugriff braucht wie beim AVR.

: Bearbeitet durch Moderator
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Lohnt es sich anhand dieser Vorhandenen Dokus noch irgendwelche Bücher
> zu besorgen?

Kaum. Das wenige, was es an tatsächlicher Literatur zu MSP430 gibt, ist 
hoffnungslos veraltet, zumindest das, was ich gesehen habe.

Da werden nur die fossilen MSP430-Varianten beschrieben, die es vor der 
Einführung von SBW gab, d.h. so etwas wie der 'F161, der 'F149 und 
andere arthritische Familienmitglieder.

Zwar kann man die alle auch heute noch kaufen, sie sind aber massiv 
überteuert und mit keinem Launchpad zu programmieren.

Vor allem, und das ist der entscheidenste Nachteil, entspricht deren 
Peripherie nicht der, die in aktuellen Modellen zu finden ist.

Bereits die Peripherie eines so einfachen Controller wie dem 'G2553 hat 
kaum noch etwas mit der eines 'F161 zu tun.


Zur Entwickung und zum Verständnis wichtig ist neben dem Datenblatt und 
dem jeweiligen "Family User's Guide" die passenden 
Sourcecode-Beispiele, die TI zur Verfügung stellt.

Die kann man nicht oder nur mit Aufwand zwischen mehreren Familien 
austauschen; auch wenn die Peripheriemodule gleich sein mögen, kann die 
Gestaltung der Interruptvektoren komplett anders aussehen.

Wer beispielsweise mit dem 'G2553 I2C und eine UART ansteuern möchte, 
kann mit Code für einen 'F5438 praktisch nichts anfangen.

> Der uC Variant ist eine MSP430FR5998 Launchpad Bord mit CCS V8.1.

Du meinst einen 'FR5994. Für den sind die Codebeispiele hier zu finden:

http://www.ti.com/lit/zip/slac710

Zusätzlich sind die Codebeispiele Deines Launchpads von Interesse:

http://software-dl.ti.com/msp430/msp430_public_sw/...



Viel Erfolg!

Autor: infoman (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Family User Guide ist perfekt für Selbststudium.

Und wenn es unbedingt ein nicht TI- Buch sein soll: Mikrocontroller 
Basics von Davis.

Und lass dir keinen falschen Floh ins Ohr setzen. Der MSP ist ein super 
Controller. Da kommt der AVR Quatsch nicht mit.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
infoman schrieb:
> Da kommt der AVR Quatsch nicht mit.

Kannst du einfach die billige Polemik stecken lassen?

Danke.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerade zurück vom Einkaufen:-)

Vielen Dank für Eure hilfreichen und interessanten Kommentare. Dann hat 
sich das Thema Bücher kaufen praktisch schon erledigt. Die Unterlagen 
die ich mir bis jetzt durchgesehen habe sind anscheinend gut genug 
dokumentiert. Die Links von Euch möchte ich mir noch ansehen. Der Wert 
einer Dokumentation kommt erst dann ans Licht wenn man damit arbeitet:-)

Die FR Typen finde ich übrigens sehr cool.

Das Konzept der Launchpads gefällt mir. Die sind nicht so überladen und 
der Debugteil ist auch noch off-board verwendbar.

Die Programmierung des Baudratengenerators mit dem Modulator ist etwas 
"Quirky". Das ist wahrscheinlich beim STM32 besser gelöst. Zum Glück 
brauche ich nur 1200 Baud für den HART Teil.

Ob noch andere uC Familien in Frage kommen wird sich noch herausstellen. 
Die stromsparenden Eigenschaften der MSP430 sind eher 
Programmierstrategie und sinnvoller Einsatz der Fähigkeiten des uC. Ob 
da noch Microchip in Frage kommt wird erst später ans Licht kommen. 
Einige derer uC haben auch sehr niedrigen Stromverbrauch bei niedrigen 
Spannungen und Takt Frequenzen. Meine Stromversorgung ist jedenfalls 
sehr begrenzt und alles muss mit unter 3.5mA zuverläßig laufen. 
Energiespeicherung über einen bestimmten Grad ist wegen Einsatz in 
gefährlichen, explosiven Umgebungen nicht erlaubt.

Naja, bald wird der Stein wohl ins Rollen kommen...

Schönes Wochenende noch,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
infoman schrieb:
> Family User Guide ist perfekt für Selbststudium.
>
> Und wenn es unbedingt ein nicht TI- Buch sein soll: Mikrocontroller
> Basics von Davis.

Danke für den Hinweis.
>
> Und lass dir keinen falschen Floh ins Ohr setzen. Der MSP ist ein super
> Controller. Da kommt der AVR Quatsch nicht mit.

Das ist gut zu wissen. Sprichst Du von Arbeitsprojekten oder rein 
privaten Erfahrungen?

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Gerade zurück vom Einkaufen:-)
>
> Vielen Dank für Eure hilfreichen und interessanten Kommentare. Dann hat
> sich das Thema Bücher kaufen praktisch schon erledigt. Die Unterlagen
> die ich mir bis jetzt durchgesehen habe sind anscheinend gut genug
> dokumentiert. Die Links von Euch möchte ich mir noch ansehen. Der Wert
> einer Dokumentation kommt erst dann ans Licht wenn man damit arbeitet:-)
>
> Die FR Typen finde ich übrigens sehr cool.
>
> Das Konzept der Launchpads gefällt mir. Die sind nicht so überladen und
> der Debugteil ist auch noch off-board verwendbar.

Das gibts bei anderen Leuten auch, STM z.B..
>
> Die Programmierung des Baudratengenerators mit dem Modulator ist etwas
> "Quirky". Das ist wahrscheinlich beim STM32 besser gelöst. Zum Glück
> brauche ich nur 1200 Baud für den HART Teil.

I.A. gibts in der Doku Tabellen in denen das für "vernünftige" Taktraten 
und Baudraten bereits ausgerechnet und dokumentiert ist.

>
> Ob noch andere uC Familien in Frage kommen wird sich noch herausstellen.
> Die stromsparenden Eigenschaften der MSP430 sind eher
> Programmierstrategie und sinnvoller Einsatz der Fähigkeiten des uC.

Die sind zwar stromsparend, aber ein AVR hantiert auf dem selben Level.
Nicht blenden lassen von der Werbung...

> Ob
> da noch Microchip in Frage kommt wird erst später ans Licht kommen.
> Einige derer uC haben auch sehr niedrigen Stromverbrauch bei niedrigen
> Spannungen und Takt Frequenzen. Meine Stromversorgung ist jedenfalls
> sehr begrenzt und alles muss mit unter 3.5mA zuverläßig laufen.
> Energiespeicherung über einen bestimmten Grad ist wegen Einsatz in
> gefährlichen, explosiven Umgebungen nicht erlaubt.

Ich hatte einen G2553 im LPM3 laufen und angesichts der 800nA 
Stromverbrauch entschieden den Einschalter (zur Lithum-Primärzelle)
weg zu lassen.
>
> Naja, bald wird der Stein wohl ins Rollen kommen...
>
> Schönes Wochenende noch,
> Gerhard

Viel Spaß Gerhard. Die Dinger gehen genauso wie andere Controller auch.
Sicher gibts ältere Modelle und welche wo die Peripherie nicht so tut 
wie man sich das wünscht, gibts woanders aber auch. Selbst die Tatsache 
ob ein Controller "arthritisch" ist oder nicht, spielt nur sehr selten 
eine wirkliche Rolle. MSP gibts ca. genauso viele wie PICs und PIC16 
habe ich ein mal für Geld programmiert, muß ich nicht unbedingt nochmal 
haben.

Gruß,

Holm

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, dann bin ich mal vorerst voller Zuversicht. Jedenfalls ist es 
beruhigend von Euren Erfahrungen zu wissen. Bis der uC festgelegt wird 
vergeht bestimmt noch einige Zeit und es hängt ja nicht von mir aleine 
ab. Da hat der Projektmanager auch noch ein kleines Wörtchen mitzureden. 
Aber meine Neugier ist mal auf alle Fälle geweckt und da Werkzeug und 
Bord in greifbarer Nähe sind werde ich mal erste Erfahrungen sammeln. 
Ich habe einen Bekannnten in D der schon viel mit MSP430 gemacht hat und 
über die Jahre eigentlich nie was Negatives gehört. Man kann auch 
teilweise vermuten, daß Probleme der älteren MSP Generation vielleicht 
zum Teil behoben worden sind. Ich muß mir auf alle Fälle die Errata 
vorknöpfen.

Die FR Versionen kann man eigentlich nicht unbedingt als "arthritisch" 
benennen:-) Beim FR5994 ist ja allerhand Nettes unter der Motorhaube 
eingebaut.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Die FR Versionen kann man eigentlich nicht unbedingt als "arthritisch"
> benennen:

Sind sie ja auch nicht, die können SBW, und es gibt sie auch noch nicht 
ansatzweise so lange wie 'F14x und Co.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> und alles muss mit unter 3.5mA zuverläßig laufen

Wenn du keine Geschwindigkeit brauchst, ist das doch heutzutage bereits 
ein überwältigend großes Power-Budget. :)

Autor: infoman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Kannst du einfach die billige Polemik stecken lassen?

Was gesagt - besser geschrieben - werden muss, muss gesagt werden!

Gerhard O. schrieb:
> prichst Du von Arbeitsprojekten

Ja.

Hab damit die AVRs abgelöst, weil besser.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
infoman schrieb:
> Jörg W. schrieb:
>> Kannst du einfach die billige Polemik stecken lassen?
>
> Was gesagt - besser geschrieben - werden muss, muss gesagt werden!
>
> Gerhard O. schrieb:
>> prichst Du von Arbeitsprojekten
>
> Ja.
>
> Hab damit die AVRs abgelöst, weil besser.

...Rädermacher, Viereckige..

Schlecht sind sie sicher nicht, ganz im Gegensatz zu Deiner 
tiefgreifenden Argumentation.

Gruß,

Holm

Autor: infoman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> ...Rädermacher, Viereckige..
>
> Schlecht sind sie sicher nicht, ganz im Gegensatz zu Deiner
> tiefgreifenden Argumentation.

Und was steckt in deinen Worten hier? Du bist nur auf eine Schiene 
eingefahren und was der Bauer (der Holm) nicht kennz, ...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
infoman schrieb:
> Du bist nur auf eine Schiene eingefahren und was der Bauer (der Holm)
> nicht kennz, ...

Mensch, du kannst ja nichtmal lesen, sondern nur Polemik.

Holm schrieb weiter oben, dass er sie benutzt.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..wohl ein besonders dümmliches Exemplar von Troll..

Gruß,
Holm

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Die Programmierung des Baudratengenerators mit dem Modulator ist etwas
> "Quirky". Das ist wahrscheinlich beim STM32 besser gelöst. Zum Glück
> brauche ich nur 1200 Baud für den HART Teil.

Das Wunderbare an der TI-Unterstützung ist, dass es zu allen möglichen 
Dingen bereits Beispiel-Code gibt, den man eins zu eins kopieren und 
verwenden kann ... muss man nicht, würde aber Zeit und Schmerzen 
einsparen.


Rufus Τ. F. schrieb:
> Gerhard O. schrieb:
>> Lohnt es sich anhand dieser Vorhandenen Dokus noch irgendwelche Bücher
>> zu besorgen?
>
> Kaum. Das wenige, was es an tatsächlicher Literatur zu MSP430 gibt, ist
> hoffnungslos veraltet, zumindest das, was ich gesehen habe.

Daumen hoch! : Vergleich man die Autoren der Literatur in den 
Buchhandlungen, stellt man fest, dass es die Autoren sind, die die 
App-Notes schreiben - TI-Mitarbeiter. .. und somit ist der Text von der 
TI-Internetseite immer frisch und knackig.

Happy coding!

Bernd

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit "Literatur" bezog ich mich bei meiner Antwort auf Gerhard auf die 
von ihm angefragten Bücher, nicht auf die Dokumentation, die TI zur 
Verfügung stellt.

Das sollte aus dem Kontext meiner Antwort heraus eigentlich auch klar 
sein.

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Es ist evtl. noch erwähnenswert das es da dieses "Energia" Zeugs gibt, 
analog der Arduino Geschichte..bin da aber nicht auf dem Laufenden, ich 
verwende werde die Arduino noch die Energia Software, ich verwende auch 
die Hersteller-IDEs nicht, baue mir meine eigene Umgebung.

(Energia ist für mich eigentlich ne Rakete..)

Gruß,

Holm

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Energia ist für einige wenige MSP430-Varianten verwendbar.

Unterstützt werden folgende Modelle:

MSP430F5529,
MSP430FR2311,
MSP430FR2433,
MSP430FR5739,
MSP430FR5969,
MSP430FR5994

die allesamt auf gleichnamigen Launchpads zu finden sind.

Und der MSP430G2553, der auf dem MSP430G2 und dem neuen 
MSP430G2ET-Launchpad verwendet wird.

Recht wahrscheinlich sollten sich auch die unmittelbar verwandten 
Familienmitglieder nutzen lassen, natürlich nur, wenn die jeweilige 
Anwendung nicht auf nicht verfügbare Peripherie zugreifen will und RAM & 
Flash-ROM ausreichen.


Insofern ist Energia für einfache Fingerübungen brauchbar, und für ein 
erstes "Hineinschmecken".

Was Energia aber ebensowenig unterstützt wie die Arduino-Umgebung ist 
echtes Debuggen, obwohl alle MSP430-Launchpads entsprechende 
Hardwareunterstützung in Form des SBW-Debuginterfaces enthalten.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Mit "Literatur" bezog ich mich bei meiner Antwort auf Gerhard auf die
> von ihm angefragten Bücher, nicht auf die Dokumentation, die TI zur
> Verfügung stellt.

Bernd B. schrieb:
> Daumen hoch! : Vergleich man die Autoren der Literatur in den
> Buchhandlungen, stellt man fest, dass es die Autoren sind, die die
> App-Notes schreiben - TI-Mitarbeiter. .. und somit ist der Text von der
> TI-Internetseite immer frisch und knackig.

Dung Dang - TI -> Getting Started with the MSP430 Launchpad
Lutz Bierl - TI -> Das große MSP430 Praxisbuch

... man könnte das fortsetzen, würde sicher noch ein paar Treffer 
landen. Meine Aussage ist eindeutig in die Richtung: Codebeispiele von 
TI zu den jeweiligen Prozessortypen ansehen und die Family Guides lesen. 
Man spart nicht nur viel Geld, sondern erhält alles superaktuell und als 
PDF. ... aber das ist ja bekannt.

siehe hier: Beitrag "MSP430 Praxisbuch"

Gruß

Bernd

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frage am Rande: wie gut funktioniert mittlerweile eigentlich der 
MSP-GCC? Als ich das vor Jahren für die Firma gemacht habe, war es noch 
ein ziemliches Gebastel, weil TI den Code völlig separat von GCC 
gepflegt hat. Ich habe gehört, dass sich das in letzter Zeit geändert 
hat. Dann müsste man sich ja eigentlich einen Compiler „aus der Dose 
raus“ mit
configure --target=msp430

bauen können, oder?

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guck mal in den Port..

/usr/ports/devel/gcc-msp430-ti-toolchain

Gruß,
Holm

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, tnx!  Wenn ich mal wieder Zeit habe, mit dem Launchpad rumzuspielen, 
welches noch in der Ecke liegt …

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
..jetzt schreibe ich den Mist nochmal weil Du zu schnell warst für den 
Edit..
(was soll das eigentlich?)

Ich kann gar nicht böse sein wenn Jemand (Ti in dem Falle) seinen Kram 
selber macht und das dann veröffentlicht. Wwil ich 40 Stück H8 da habe 
und auch RAMs und Flashroms habe ich mich in den letzten Tagen damit 
befaßt eine H8 Toolchain zu bauen...da bekommt man Pickel. Der H8 wurde 
irgendwann obsolete, versuche mal anhand der gcc Doku heraus zu bekommen 
wann das genau passiert ist und was der letzte funktionsfähige Compiler 
für H8300 ist. Das heutige gcc und LLVM schon kräftige Probleme haben 
den alten gcc Sourcecode überhaupt vernünftig zu übersetzen steht auf 
einem anderen Blatt. Das ist indessen einfach eine grauenhafte 
Bloatware, kein Unterschied zwischen LLVM und gcc.
Die Binutils und die Newlib haben seltsamerweise damit keine Probleme, 
das spricht Bände.

Ich habe jetzt einen gcc-3.4.6 für H8 der plausiblen Code erzeugt und 
keinen Bock darauf festzustellen was gcc-4.xx flasch macht weil er die 
Byteorder verdreht...

Ich habe noch 2 Launchpades mit LM4F120H5QR, da hat man heute schon 
Sorgen herauszufinden das TI die mal gemacht hat.. TM4C123GH6PM ist der 
Nachfolger und soll weitestgehend kompatibel sein....hmm...toll.


Gruß,

Holm

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Lutz Bierl - TI -> Das große MSP430 Praxisbuch

Das ist komplett veraltet, da es den technischen Stand von vor 14 Jahren 
wiedergibt.

> Dung Dang - TI -> Getting Started with the MSP430 Launchpad

Das ist zwar neuer, aber wirklich nur ein sehr elementarer Einstieg.

Wenn überhaupt, dann dieses Buch verwenden.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
... ich meine: KEINE Bücher verwenden, nur TI-Seiten und die PDFs 
runterziehen!

Gruß

Bernd

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, dann wird ja langsam alles besser.

Gut so.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Hardware sieht sehr low-level-programmier-freundlich aus (so ähnlich 
wie DOS Assemblerprogrammierfreundlich war) d.h.

Man kann also einen die "Spreu-vom-Weizen-Trenneffekt" erwarten. -> Wer 
gut Lowlevel kann und gute Ideen hat - hat wohl etwas mehr von den 
bereitgestellten Möglichkeiten..

Auf dieser Internetseite kann man sich zumindest mal das 
Inhaltsverzeichnis von dem Buch "Das MSP430 Mikrocontroller Buch" von 
Stefan Tappertzhofen und Marian Walter ansehen:
https://de.book-info.com/isbn/3-89576-236-9.htm

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Vielen Dank für Eure weiteren Gedanken zum Thema. Ich bin mir ziemlich 
sicher, dass ich mit den offiziellen T.I. Unterlagen neben diversen Web 
Beiträgen/Ressourcen gut zurecht kommen werde. Ich habe übers Wochenende 
noch etwas mit der Bord gespielt und habe keine großen oder unerwarteten 
Probleme gehabt um mich mit der Materie weiter vertraut zu machen. Bis 
jetzt finde ich den MSP430 ziemlich gutmütig. Allerdings bin ich mir 
ziemlich sicher ab und zu meine Haare ausreißen zu müssen oder das Teil 
in die Ecke werfen zu wollen:-) Eigentlich auch nicht viel anders wie 
andere uC mit den ich bisher zu tun hatte. Beim STM32 war ich damals 
innerhalb von zwei Wochen vertraut genug um richtig damit arbeiten zu 
können.

Da bin ich nun auch der Ansicht, dass angesichts der guten Firmen 
Unterlagen sich vorerst (veraltete) Bücher nicht so recht lohnen würden.

Ich wusste übrigens gar nicht am Anfang, dass die MSP430 Familie eine 
rein deutsche Entwicklung ist.

Ich suche übrigens noch ähnlich wie die STM32 "ST-Link Utility nach 
"Standalone" Programmer Software Utilities für den MSP430. Bis jetzt 
fand ich eigentlich nur die Sachen von Elpotronics die in Frage kommen 
würden,  Z.B. wie das hier:

https://www.elprotronic.com/products?show&id=35
(Frei und die Pro Version)

Gibt es für Windows noch irgendwelche gute Alternativen? An sich sollte 
diese Software den Zweck gut erfüllen, den uC in der Produktion und 
sonst direkt zu programmieren und sichern.


Gerhard

Nachtrag:

Ich testete gerade die Freeware Version von Elpotronics mit dem 
Launchpad und es funktioniert alles zufriedenstellend was ich damit 
machen will.
Es nervt nur jedes mal bei Gebrauch ein bisschen einen Firmware Update 
machen zu wollen, was es dann allerdings selber nicht empfehlt um den 
Launchpad nicht zu "bricken".

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Mein nächstes Firmenprojekt wird höchstwahrscheinlich auf einem MSP430
> für ein 4-20mA/HART gespeistes industrielles Steuergerät beruhen.

Hallo Gerhard,

es ist hier echt manchmal schwierig Informationen rüber zu bringen: 
Mehrfach der Anlauf, dass die Autoren der Codebeispiele auch selbst 
einmal ein Buch geschrieben haben und dass im Buch sicher nichts mehr 
drin steht, als sie für Ihren Arbeitgeber schreiben und dass bis ein 
Buch gedruckt wird es neue Codebeispiele gibt, usw. und es somit 
sicherlich ein guter Ratschlag ist direkt auf den Internetseiten des 
Herstellers zu lesen und mehr.

Also, wenn Du einsteigen willst, suche nach den SLACs, z.B. für den 
MSP430FR5969 ... und zwar hier:

http://www.ti.com/general/docs/lit/getliterature.t...

So frisch und knackig kannst Du kein Buch finden!!!

Gerhard O. schrieb:
> Der uC Variant ist eine
> MSP430FR5998 Launchpad Bord mit CCS V8.1.

Den FR5998 habe ich leider nicht gefunden.

Wenn Du diesen "großen" Prozessor benötigst, gut. Dann kannst Du sicher 
Deinen Hart-Baustein anklemmen, z.B. den hier:

http://www.hart-expert.co.uk/wp-content/uploads/HA...

Die Schnittstelle nutzt RX // TX // Carrier Detect.

Im Prinzip lässt sich die gesamte Schaltung bereits auf einem Steckbrett 
aufbauen.

Bitte, wenn du ernsthaft mit dem MSP430 arbeiten willst, lass die 
Quervergleiche zu anderen Prozessoren weg! Es ist aus meiner kleinen 
eingeschränkten Sicht nicht klug immer Parallelsysteme analysieren und 
vergleichen zu lassen. Schreibe, was Du willst und wo es hakt.

Meine bescheidene Empfehlung an dieser Stelle ist noch, nur mit dem 
Assembler zu arbeiten. Du erzeugst Dir einen sehr schlanken Code, der 
gleichzeitig sehr übersichtlich sein kann. Aber das ist Geschmackssache, 
ob man so verfährt.

Noch etwas, Haare brauchst Du Dir nicht ausreißen, sondern "nur" 
versuchen modular zu programmieren. Jede kleine Funktion testest Du und 
setzt die "Bausteine" anschließend zusammen. Dass die C-Experten nicht 
immer diesen Weg gehen, dürfte klar sein. Die benötigten Assembler 
"Befehle" findest Du in jedem Family User's Guide SLAUxx im Kapitel zur 
CPU, vielleicht Kapitel 4. Das sind nicht viele, und alle ursprünglichen 
stammen aus Paderborn oder Freising.

Ich selbst schreibe meine Software mit IAR und habe noch nie und kein 
Lauch-Pad oder Traget "gebrickt". Beim Assembler gibt es keine 
Codesize-Limitation !!!

So, wenn die Begeisterung anhält, hast Du in Nullkommanix Dein System 
fertig. Ich drücke Dir die Daumen.

Happy Coding!

Bernd

@Rufus, stimmt Deine E-Mail im System für die private E-Mail nicht mehr?

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

vielen Dank fuer die vielen Punkte zum berücksichtigen und die Links.
Die sind schon mal ein guter Anfang.

Bernd B. schrieb:
> Gerhard O. schrieb:
>> Mein nächstes Firmenprojekt wird höchstwahrscheinlich auf einem MSP430
>> für ein 4-20mA/HART gespeistes industrielles Steuergerät beruhen.
>
> Hallo Gerhard,
>
> es ist hier echt manchmal schwierig Informationen rüber zu bringen:
> Mehrfach der Anlauf, dass die Autoren der Codebeispiele auch selbst
> einmal ein Buch geschrieben haben und dass im Buch sicher nichts mehr
> drin steht, als sie für Ihren Arbeitgeber schreiben und dass bis ein
> Buch gedruckt wird es neue Codebeispiele gibt, usw. und es somit
> sicherlich ein guter Ratschlag ist direkt auf den Internetseiten des
> Herstellers zu lesen und mehr.
>
> Also, wenn Du einsteigen willst, suche nach den SLACs, z.B. für den
> MSP430FR5969 ... und zwar hier:
>
> http://www.ti.com/general/docs/lit/getliterature.t...
>
> So frisch und knackig kannst Du kein Buch finden!!!
>
> Gerhard O. schrieb:
>> Der uC Variant ist eine
>> MSP430FR5998 Launchpad Bord mit CCS V8.1.
>
> Den FR5998 habe ich leider nicht gefunden.
War ein Fehler von mir. Ich meinte natuerlich den MSP430FR5994.
>
> Wenn Du diesen "großen" Prozessor benötigst, gut. Dann kannst Du sicher
> Deinen Hart-Baustein anklemmen, z.B. den hier:
>
> http://www.hart-expert.co.uk/wp-content/uploads/HA...
Danke für den Link. Das muss ich mir noch genau durchlesen und das 
Datenblatt. Ich habe vor ein paar Wochen nach Hart Modems gesucht und 
ein paar in Frage kommende ICs. Den HT2015 kannte ich noch nicht. Ob der 
uC zu groß ist weiß ich noch nicht, aber der FR5994 schien mir zum 
Anfang groß genug um alle Möglichkeiten abstecken zu können. Später 
lässt sich dann besser entscheiden welcher Typ aktuell Sinn hat.
>
> Die Schnittstelle nutzt RX // TX // Carrier Detect.
>
> Im Prinzip lässt sich die gesamte Schaltung bereits auf einem Steckbrett
> aufbauen.
Das dachte ich mir auch. Obwohl da noch einige HW dazukommen wird. Aber 
man könnte die LaunchPAD Baugruppe anfänglich als Aufsteckplatine 
vorsehen.
>
> Bitte, wenn du ernsthaft mit dem MSP430 arbeiten willst, lass die
> Quervergleiche zu anderen Prozessoren weg! Es ist aus meiner kleinen
> eingeschränkten Sicht nicht klug immer Parallelsysteme analysieren und
> vergleichen zu lassen. Schreibe, was Du willst und wo es hakt.
OK. Gut. Das war auch nicht wirklich meine Absicht.
>
> Meine bescheidene Empfehlung an dieser Stelle ist noch, nur mit dem
> Assembler zu arbeiten. Du erzeugst Dir einen sehr schlanken Code, der
> gleichzeitig sehr übersichtlich sein kann. Aber das ist Geschmackssache,
> ob man so verfährt.
Ich bin mit C ziemlich gut bewandt. Assembler liegt mir da weniger. Aber 
es wäre ganz interessant und potenziell nützlich zeitkritische Sachen 
auch in  mixed Assembler programmieren zu können.
>
> Noch etwas, Haare brauchst Du Dir nicht ausreißen, sondern "nur"
> versuchen modular zu programmieren. Jede kleine Funktion testest Du und
> setzt die "Bausteine" anschließend zusammen. Dass die C-Experten nicht
> immer diesen Weg gehen, dürfte klar sein. Die benötigten Assembler
> "Befehle" findest Du in jedem Family User's Guide SLAUxx im Kapitel zur
> CPU, vielleicht Kapitel 4. Das sind nicht viele, und alle ursprünglichen
> stammen aus Paderborn oder Freising.
Ja. Das ist guter Ratschlag. Mir liegt modulare Organisation sowieso 
weil ich gerne meine Sourcen auf andere uC portiere.
>
> Ich selbst schreibe meine Software mit IAR und habe noch nie und kein
> Lauch-Pad oder Traget "gebrickt". Beim Assembler gibt es keine
> Codesize-Limitation !!!
Die CCS V8.1 Version ist jetzt unbegrenzt.

Das mögliche Bricken wurde mir von der Elpotronic Software angesagt. Als 
ich das Programm startete wurde mir mitgeteilt, dass meine ISP V1.00 war 
und die jetzige V3.... Trotzdem warnte mich die SW es nicht auf den 
neuesten Stand zu bringen weil es möglicherweise den ISP bricken könnte. 
So war das gemeint. Das muss ich mir noch näher anschauen.

In der Firma arbeiten wir eigentlich hauptsächlich mit IAR. Es ist 
möglich, dass die SW Entwicklung hier auch in IAR gemacht werden soll. 
Das habe ich aber nicht alleine zu entscheiden und ist für mich auch 
unwichtig da ich mit IAR jahrelang mit ARM7 gearbeitet habe. Aber wenn 
CCS gut genug ist, dann wäre das auch eine Möglichkeit. Bis jetzt 
funktionierte CCS vorzüglich.
>
> So, wenn die Begeisterung anhält, hast Du in Nullkommanix Dein System
> fertig. Ich drücke Dir die Daumen.
Die ist da:-) Auch privat habe ich jetzt vor mich damit Hobby maessig zu 
befassen. War in der Vergangenheit nur zu sehr mit PIC, AVR und STM32 
belastet und da sieht man weniger über den Zaun. Dieses mal ist aber die 
niedrige Stromaufnahme wichtig und dachte der MSP430 wäre dazu gut 
geeignet. In der Vergangenheit war Leistungsaufnahme meiner Projekte 
kaum von Bedeutung. Es ist möglich, dass auch andere uC richtig sparsam 
verwendet werden können, aber das müsste ich erst recherchieren. Beim 
MSP430 sollten ja rund 12MIPS/mA (83uA/MIPS) möglich sein. Inwieweit die 
einzelnen Peripherien das verschlechtern muss ich erst recherchieren 
sobald ich genau weiß was verwendet werden muss.

Privat habe ich auch einige Projekte mit Langzeit Batteriebetrieb im 
Auge und da werden mir die Erfahrungen mit dem MSP430 bestimmt nützlich 
sein.
>
> Happy Coding!
Danke!

Gerhard
>
> Bernd
>
> @Rufus, stimmt Deine E-Mail im System für die private E-Mail nicht mehr?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Privat habe ich auch einige Projekte mit Langzeit Batteriebetrieb im
> Auge

Kritischer Punkt bei sowas war bei mir bislang stets irgendwelcher Dreck 
auf der Platine: Flussmittelreste + Feuchtigkeit ist da völlig tödlich 
(zumal das auch ganz schnell dann Leiterzüge hinweg korrodiert). Wenn du 
keine Feuchtigkeit befürchten musst, ist es einfacher. Ansonsten 
natürlich die Frage, ob deine CPU tatsächlich durchlaufen muss oder du 
viel schlafen kannst. Bei meinen Funkthermometern ist im Laufe von 4 
Jahren die Batteriespannung von 3,3 V auf gerade mal 2,85 V abgesunken, 
aber die müssen halt nur aller 5 min mal eine Messung durchführen und 
ein Datenpaket senden (allerdings wachen sie jede Sekunde auf, um die 
Uhr „ticken“ zu lassen).

Autor: LPM4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jahrelang (mangels LowPower Alternativen) Produkte mit dem 
MSP430 entwickelt. Heute bin ich glücklich nicht mehr auf den MSP430 
angewiesen zu sein.
Wenn es Dir um LowPower und energiesparen geht, dann schau Dir doch mal 
die SiliconLabs EFM32 Gecko Controller an. Wenn Energie keine Rolle 
spielt, dann wüßte ich nicht, warum man überhaupt noch einen MSP430 
einsetzen sollte..

Die Lektüre der Erratas ist, wie von den Kollegen oben schon bemmerkt, 
äußerst wichtig.

IAR IDE? Der Compiler ist super, aber die IDE ist betagt. Oder ist die 
mittlerweile Eclipse-basierend...?

Autor: LPM4 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> ob deine CPU tatsächlich durchlaufen muss oder du
> viel schlafen kannst.

Bein MSP430 ist ja gerade der Trick das Teil immer im Schlaf zu halten 
und nur per Timer aufzuwecken. Einmal in der Main ein paar Aktionen 
abarbeiten und dann wieder schlafen legen. Der letzte Aufruf in der Main 
ist bei mir immer LPM3/LPM4.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LPM4 schrieb:
> Bein MSP430 ist ja gerade der Trick das Teil immer im Schlaf zu halten
> und nur per Timer aufzuwecken.

Naja, nicht nur dort. :)

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Kritischer Punkt bei sowas war bei mir bislang stets irgendwelcher Dreck
> auf der Platine: Flussmittelreste + Feuchtigkeit ist da völlig tödlich

Ja. Das kenne ich auch. Speziell das wasserlösliche Flussmittel ist da 
sehr anspruchsvoll auf perfekte Reinigung nach dem Löten.

Obwohl die Anwendung auf 4-20mA Steuerung und Versorgung ausgelegt sein 
wird, ist es vielleicht möglich LPMs auszunützen. Allerdings darf der 
Gesamt Stromverbrauch nie größer als 3.5mA werden.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

bitte nenne doch einmal Deine CPU, die Du nutzen willst. Ich hatte ja 
geschrieben, dass ich den Typ FR5998 nicht gefunden  habe.

Dann wäre es günstig zu erfahren, ob Du ein Pflichtenheft hast. Was soll 
Deine Applikation denn alles machen?

Ich hatte einmal mit einem F2011 eine serielle Ansteuerung für einen 
Sennheiser Telefonkopfhörer mit Lifter für den normalen Hörer aufgebaut. 
Das lief über RS232. mehr kann ich nicht verraten, da ich eine 
Stillschweigevereinbarung unterschrieben hatte. Die serielle 
Schnittstelle hatte ich über die I/O-Pins von Port2 realisiert. Als 
Zeitnormal diente ein Uhrenquarz mit 32kHz und der im MSP realisierten 
Frequenzaufbereitung. Sofern also nur ein "Umsetzer" geplant ist, kannst 
Du einen wirklich kleinen Prozessor verwenden.

Ich verstehe auch nicht, warum immer alle gegen den MSP430 
argumentieren. Auch verstehe ich nicht, warum immer alle in C 
programmieren. Wenn ich z.B. die Register setze, sehe ich keinen 
Unterschied zw. den beiden Dialekten, ausgenommen der Reihenfolge der 
Buchstaben und der kleineren Dateien beim Assembler. Ich könnte noch 
viel mehr ausholen...

Bei mir zuhause habe ich übrigens eine KNX-Steuerung realisiert mit dem 
F2011, F2012 und F2013 - komplett mit allem Pipapo und in Assembler. 
Aber bitte, man kann auch in C, wenn man will. Bei den Geräten ist die 
Stromaufnahme so gering, dass ein 100uF Kondensator schon viele Minuten 
braucht, bis der Prozessor diesen entladen hat und nicht mehr läuft.

Ob der Hart-Baustein richtig ist, weiß ich nicht, denn die benötigte 
Zeitbasis ist etwas unüblich, wie das Internet schreibt. Vielleicht gibt 
sich ja bei der Taktrate etwas in Übereinstimmung mit der 
RS232-Schnittstelle, so dass Du den Takt vom Prozessor aus erzeugen 
könntest.

Aber zu allem wird benötigt: Prozessortyp und Pflichtenheft.

Zu dem "Bricken" mache Dir erst einmal keine Gedanken, davon habe ich 
beim MSP430 noch nie etwas gehört... bei Android Mobiltelefonen schon. 
Wie schon an andere Stelle geschrieben, nutze ich den MSP430 seit etwa 
1998 oder noch früher? - Ich kann mich schon gar nicht mehr dran 
erinnern und Telefone hatten schon Drucktasten. Aber Mobiltelefone 
blockierten den Platz im Kofferraum oder liefen nur in einem Band D-Netz 
oder E-Plus.

Wenn Du mit mehr Informationen kommst, kann ich vielleicht noch ein paar 
Vorschläge unterbreiten, aber die Katze lasse ich noch nicht aus dem 
Sack...
...
 Ich hab Rollen gespielt der verschiedensten Art
 Hatte siebzig und mehr Monologe parat
 Konnte improvisieren mit Witz und Geschmack
 Und lies niemals die Katze zu früh aus dem Sack
 Ich traf instinktiv stets den richtigen Ton
 und brauchte kaum Proben, nur Intuition
...

Happy coding!

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LPM4 schrieb:
> Ich habe jahrelang (mangels LowPower Alternativen) Produkte mit
> dem
> MSP430 entwickelt. Heute bin ich glücklich nicht mehr auf den MSP430
> angewiesen zu sein.
> Wenn es Dir um LowPower und energiesparen geht, dann schau Dir doch mal
> die SiliconLabs EFM32 Gecko Controller an. Wenn Energie keine Rolle
> spielt, dann wüßte ich nicht, warum man überhaupt noch einen MSP430
> einsetzen sollte..
Mir scheint zwischen den Zeilen es gibt doch ein paar graue (Gewitter) 
Wolken am Himmel des MSP430:-) Welche Aspekte/Probleme störten Dich da 
besonders?
>
> Die Lektüre der Erratas ist, wie von den Kollegen oben schon bemmerkt,
> äußerst wichtig.
Ja. Das ist klar.
>
> IAR IDE? Der Compiler ist super, aber die IDE ist betagt. Oder ist die
> mittlerweile Eclipse-basierend...?
Die neueste IAR Generation von IDE ist jetzt in Eclipse. Ich arbeite 
gern mit IAR. Nicht lachen: Ich arbeitete früher gerne auch mit dem 8051 
Keil uV.

Autor: so so (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Mir scheint zwischen den Zeilen es gibt doch ein paar graue (Gewitter)
> Wolken am Himmel des MSP430

Alles Blödsinn. Die Jungs kennen nur ihren ersten uC und jetzt wird 
rumgeweint.

Der MSP430 ist top. Du kommst schnell mit ihm zurecht, die Doku ist top 
und es gibt keine Fallstricke.
IAR C passt gut zu dem uC.

Also alles ganu easy, mach dir keinen Kopf.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bernd B. schrieb:
> Hallo Gerhard,
>
> bitte nenne doch einmal Deine CPU, die Du nutzen willst. Ich hatte ja
> geschrieben, dass ich den Typ FR5998 nicht gefunden  habe.
Der uC ist ein MSP430FR5994 für den Anfang.
>
> Dann wäre es günstig zu erfahren, ob Du ein Pflichtenheft hast. Was soll
> Deine Applikation denn alles machen?
Soweit ist es noch nicht weil das Projekt im Augenblick noch in der 
Bewilligungsphase ist und ich aus persönlichem Interesse den "Feind" 
kennenlernen wollte:-) Allerdings darf ich nur grobe Andeutungen machen. 
Die Anwendung ist eine pneumatische Ventilsteuerung die sich mit nur 
Pressluft als Arbeitskraft und dem 4-20mA Steuer- und Versorgungssignal 
begnügen muss. Die Ventile werden piezoelektrisch getriggert und haben 
ein kapazitives Lastverhalten, so dass nur C-Umladungen den 
Stromverbrauch kurz beeinflussen. Dazu kommt, dass ich schon immer ein 
persönliches Interesse an der MSP430 Familie hatte und jetzt eine gute 
Gelegenheit ist mich mit den Einzelheiten dieses uC-Universums vertraut 
zu machen. Ich habe da auch einige private Hobbyprojekte vor.
>
> Ich hatte einmal mit einem F2011 eine serielle Ansteuerung für einen
> Sennheiser Telefonkopfhörer mit Lifter für den normalen Hörer aufgebaut.
> Das lief über RS232. mehr kann ich nicht verraten, da ich eine
> Stillschweigevereinbarung unterschrieben hatte. Die serielle
> Schnittstelle hatte ich über die I/O-Pins von Port2 realisiert. Als
> Zeitnormal diente ein Uhrenquarz mit 32kHz und der im MSP realisierten
> Frequenzaufbereitung. Sofern also nur ein "Umsetzer" geplant ist, kannst
> Du einen wirklich kleinen Prozessor verwenden.
Hört sich trotzdem sehr interessant an. Kann mir vorstellen, dass es da 
einige Herausforderungen gegeben hat.
>
> Ich verstehe auch nicht, warum immer alle gegen den MSP430
> argumentieren. Auch verstehe ich nicht, warum immer alle in C
> programmieren. Wenn ich z.B. die Register setze, sehe ich keinen
> Unterschied zw. den beiden Dialekten, ausgenommen der Reihenfolge der
> Buchstaben und der kleineren Dateien beim Assembler. Ich könnte noch
> viel mehr ausholen...
Das war mir eigentlich nicht so wirklich bewusst. Ich glaube nicht, dass 
genug Zeit da ist um Assembler so zu beherrschen, so dass ich das 
Projekt zeitgemäß durchziehen könnte.
>
> Bei mir zuhause habe ich übrigens eine KNX-Steuerung realisiert mit dem
> F2011, F2012 und F2013 - komplett mit allem Pipapo und in Assembler.
> Aber bitte, man kann auch in C, wenn man will. Bei den Geräten ist die
> Stromaufnahme so gering, dass ein 100uF Kondensator schon viele Minuten
> braucht, bis der Prozessor diesen entladen hat und nicht mehr läuft.
Ja. Die Launchpad hat ja auch einen Supercap drauf und das möchte ich 
mal ausprobieren. Ich machte mal was mit einem AVR und DS1302 RTC. Die 
RTC wird über einen 0.2F Supercap versorgt. Bei aufgeladenen C läuft die 
RTC fast ein Jahr lang nur mit dem Supercap, Allerdings lässt dann die 
Genauigkeit viel zu wünschen übrig. Aber dann wollte ich ja nur 14 Tage 
Laufzeit. Aber es war interessant wie lange die RTC das durchhält.
>
> Ob der Hart-Baustein richtig ist, weiß ich nicht, denn die benötigte
> Zeitbasis ist etwas unüblich, wie das Internet schreibt. Vielleicht gibt
> sich ja bei der Taktrate etwas in Übereinstimmung mit der
> RS232-Schnittstelle, so dass Du den Takt vom Prozessor aus erzeugen
> könntest.
Ja. Zur Zeit ist dieser Aspekt noch verfrüht. ich werde mir alles 
ansehen was es da gibt. Ich bin hoffnungsvoll, dass es mit der Wahl 
nicht zu viele Hürden geben wird.
>
> Aber zu allem wird benötigt: Prozessortyp und Pflichtenheft.
100% ACK. Ich bin ziemlich sicher, dass der FR5994 wahrscheinlich 
Overkill ist. Aber Anfangs möchte ich mir keine Brücken sprengen. Man 
wird ja spaeter sehen welches Familienmitglied die vernünftige Wahl ist. 
Kosten spielen weniger eine Rolle da die Produktion nicht in den 
Millionen gehen muss und man um jeden Cent knausern muss der sich aufs 
Millionenfache multipliziert. In dieser Industrie sind Tausende schon 
ein guter Umsatz. Komplettes Pflichtenheft ist bei uns ueblich und 
Pflicht.
>
> Zu dem "Bricken" mache Dir erst einmal keine Gedanken, davon habe ich
> beim MSP430 noch nie etwas gehört... bei Android Mobiltelefonen schon.
> Wie schon an andere Stelle geschrieben, nutze ich den MSP430 seit etwa
> 1998 oder noch früher? - Ich kann mich schon gar nicht mehr dran
> erinnern und Telefone hatten schon Drucktasten. Aber Mobiltelefone
> blockierten den Platz im Kofferraum oder liefen nur in einem Band D-Netz
> oder E-Plus.
Das Bricken bezog sich eigentlich nur auf die Warnung von der Elpotron 
SW in Verbindung mit der Launchpad ISP Hardware. Das hatte nichts mit 
dem MSP430 zu tun. Die SW sagte nur aus dass die SW Version um drei 
Versionen hinten ist. Trotzdem warnte sie dann, dass die V3 
möglicherweise mit dem LP nicht kompatibel sein könnte und es riskant 
ist. So ließ ich es bleiben. Nur nervt die SW jedes mal wenn man auf den 
MSP430 zugreift. Vielleicht lässt sich das abschalten. Sonst scheint ja 
alles zu funktionieren. Ich habe alles getestet bis auf die Security 
Fuse. Das traue ich mich nicht solange ich nicht 100% die Folgen des 
Setzens verstehe. Da muss ich erst mal diesbezüglich das 
Datenblatt/Manual lesen.
>
> Wenn Du mit mehr Informationen kommst, kann ich vielleicht noch ein paar
> Vorschläge unterbreiten, aber die Katze lasse ich noch nicht aus dem
> Sack...
Das wäre nett. Obwohl ich eigentlich hier nicht viel mehr mitteilen 
möchte(darf)...
> ...
>  Ich hab Rollen gespielt der verschiedensten Art
>  Hatte siebzig und mehr Monologe parat
>  Konnte improvisieren mit Witz und Geschmack
>  Und lies niemals die Katze zu früh aus dem Sack
>  Ich traf instinktiv stets den richtigen Ton
>  und brauchte kaum Proben, nur Intuition
> ...
>
> Happy coding!
Danke!
Gerhard
>
> Bernd

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

danke für die Ausführungen! Ich meinte eher eine Black-Box-Beschreibung.

Also HART<-->UART<-->und dann?

Der MSP430 wurde schon einmal am M-Bus eingesetzt. Die Code Beispiele 
finden sich sicherlich noch auf den TI-Seiten.

Wenn Du mir mein altes MikroVision von Keil abkaufst (mit Dongle für 
C166) entwickle ich Dir das (Smiley).

Also, wenn nur seriell, dann ist das schon fast fertig! (NochnSmiley)

Aber, was die Kollegen oben schreiben: Schreibe Dir alle Buchstaben vom 
Gehäuse des MSP430 auf ein Blatt Papier und gehe ins Errata. Auch wenn 
du die MSP nachkaufst, Du musst unbedingt die neuen Codes auf dem 
Gehäuse aufnehmen und ins nächste Errata Sheet, usw.

Gruß

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Hallo Gerhard,
>
> danke für die Ausführungen! Ich meinte eher eine Black-Box-Beschreibung.
>
> Also HART<-->UART<-->und dann?
Das Hart Modem ist nur für die Parametrisierung notwendig. Die primäre 
Steuerung ist analog über die 4-20mA Loop.
>
> Der MSP430 wurde schon einmal am M-Bus eingesetzt. Die Code Beispiele
> finden sich sicherlich noch auf den TI-Seiten.
M-Bus kannte ich noch nicht weil ich noch nie etwas damit zu tun hatte. 
Musste das Googeln:-)
>
> Wenn Du mir mein altes MikroVision von Keil abkaufst (mit Dongle für
> C166) entwickle ich Dir das (Smiley).
Danke vielmals; aber da muss ich passen. Einfach deshalb, weil ich uV 
anno 2002 für 8051 und C166 schon habe. (Ich nehme an Deine Version ist 
viel neuer.) Allerdings sind in Kanada C166 nicht sehr ueblich und mein 
Interesse galt bis jetzt lediglich den 8051ern und auch da  nur aus 
nostalgischen Interesse mit den Atmel FLASH Versionen wie der 
AT89LP51ED2 u.ae. und früher mit einer EPROM Version mit Fenster. Ich 
finde sie aber nett zum Spielen wenn wahrscheinlich auch hoffnungslos 
veraltet außer in ASICs wo sie noch millionenfach im Umlauf sind.
>
> Also, wenn nur seriell, dann ist das schon fast fertig! (NochnSmiley)
Das glaube ich Dir aufs Wort:-)

>
> Aber, was die Kollegen oben schreiben: Schreibe Dir alle Buchstaben vom
> Gehäuse des MSP430 auf ein Blatt Papier und gehe ins Errata. Auch wenn
> du die MSP nachkaufst, Du musst unbedingt die neuen Codes auf dem
> Gehäuse aufnehmen und ins nächste Errata Sheet, usw.
Ja. Das werde ich machen. Danke für diesen Rat. Mein L.P. uC ist 
übrigens Rev. C.

Gruesse,
Gerhard
>
> Gruß
>
> Bernd

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> (Ich nehme an Deine Version ist
> viel neuer.)

... 1996 !

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Ich verstehe auch nicht, warum immer alle gegen den MSP430
> argumentieren.

Es diskutieren doch gar nicht „alle dagegen“.

Allerdings sollte man eben auch nicht übersehen, dass die Architektur 
des MSP430 nun doch schon allmählich in die Jahre gekommen ist *). Das, 
womit er mal glänzen konnte (geringer Stromverbrauch) können 
mittlerweile so fast alle.

*) Damit du mich recht verstehst: die des AVR natürlich auch. Nicht 
umsonst konzentriert Microchip dort die Weiterentwicklung auf den 
Bereich neuer ATtinys, also sehr kleiner Controller – im oberen Bereich 
braucht man gegen die Parade der ARMs von …zig Herstellern 
(einschließlich Atmel/Microchip selbst) sowieso nicht mehr anzustinken.

> Auch verstehe ich nicht, warum immer alle in C
> programmieren.

Weil's sehr viel effizienter ist, wenn man mehr als ein paar Seiten an 
Code schreiben muss. „Effizienz“ meint hierbei nicht die sich 
ergebende Codegröße, sondern den Aufwand, den man braucht, den Kram zu 
schreiben und zu pflegen.

: Bearbeitet durch Moderator
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Gerhard O. schrieb:
>> (Ich nehme an Deine Version ist
>> viel neuer.)
>
> ... 1996 !

Oh! Really?

Mal Spaß beiseite. Ich sah mir mal gerade die Errata an. Da versteckt 
sich ja ein sehr, sehr übler Geselle darinnen. Er hört auf den wenig 
ehrenvollen Namen USCI42. Im Augenblick ist mir unklar wie man diesen 
umschiffen kann. Dieser Bug macht zuverlässige, automatische 
Puffersendung nicht gerade leicht oder sogar unmoeglich. Workaround gibt 
es anscheinend dafür keinen (guten).

Ich muss mir mal die Assembler Listing ansehen um herauszufinden wie der 
Compiler damit fertig wurde. Mein Sende Test Code funktionierte ja. Ich 
frage mich nur ob es möglich ist gepufferten Sende Code in C zu 
schreiben und der dann auch so funktioniert wie man es gewöhnt ist. Wie 
soll man da feststellen wenn die Sendung aus dem TX Register heraus ist, 
außer nur das TXEPT Bit zu berücksichtigen?

Im Internet wird anscheinend auch sehr geschimpft.

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn ich das recht verstehe besteht der Bug darin, das das das 
UCTXCPTIFG Flag nach jedem gesendeten Zeichen gesetzt wird und nicht 
wenn der Puffer leer ist wie es sein sollte. Damit kann man das Flag 
aber immer noch benutzen um über die Anzahl der gesendeten Zeichen 
informiert zu werden. Man muß halt extern mit zählen was den Sender 
verlassen hat oder sich auf einzelne Bytes beschränken. Klar ist das 
ätzend.

Gruß,
Holm

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich sah mir mal gerade die Errata an. Da versteckt sich ja ein sehr, sehr
> übler Geselle darinnen. Er hört auf den wenig ehrenvollen Namen USCI42.
> Im Augenblick ist mir unklar wie man diesen umschiffen kann. Dieser Bug
> macht zuverlässige, automatische Puffersendung nicht gerade leicht oder
> sogar unmoeglich.

UCTXCPTIFG ist nicht UCTXIFG.

Der von der Software aus sichtbare Sendepuffer ist das TXBUF-Register. 
Wenn dieses leer ist (wenn der Wert von TXBUF ins interne 
Schieberegister kopiert wurde), dann wird UCTXIFG gesetzt. Dieses Flag 
ist für das Senden von Daten (ob Pollen, Interrupt, oder DMA) 
notwending, und hat immer schon funktioniert.

UCTXCPTIFG ("transmit complete") zeigt an, dass das interne 
Schieberegister leer ist, und dass keine weiteren Daten folgen (dass 
TXBUF auch leer ist). Die zweite Bedingung wird durch das Erratum nicht 
beachtet. Dieses Flag wäre nützlich, um festzustellen, wann das 
TXD-Signal nicht mehr aktiv ist, ist aber normalerweise nicht notwendig.

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Allerdings sollte man eben auch nicht übersehen, dass die Architektur
> des MSP430 nun doch schon allmählich in die Jahre gekommen ist *).

Was soll denn noch groß geändert werden? Eine Erweiterung der CPU auf 32 
Bits ist sinnlos, weil es schon ARM gibt ("MSP432"). Und es gibt immer 
noch neue Modelle: 
http://www.ti.com/general/docs/newproducts.tsp?&co... 
(in diesem Fall mit neuer Peripherie namens "smart analog combo")

> Das, womit er mal glänzen konnte (geringer Stromverbrauch) können
> mittlerweile so fast alle.

Heutzutage ist TIs Alleinstellungsmerkmal integriertes FRAM.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

das ist absolut KEIN knock-out Kriterium!

Wie Holm beschrieben hat, zählst Du einfach mit.

Du deklarierst Dir eine RAM-Zelle und addierst oder dekrementierst. 
Sobald der Interrupt (nun falsch bei jedem Zeichen) ausgelöst wird, 
springst Du in eine ISR und dekrementierst. Bei Null setzt Du irgendwo 
eine Flagge.

Sobald Du wieder Zeichen in den Puffer schreibst, inkrementierst Du mit 
jedem Zeichen oder addierst die Zeichenzahl zu der Speicherzelle. Die 
maximale Zahl in der RAM-Zelle kannst Du ausmaskieren und erzeugst so 
keinen Datensalat oder Endlosschlaufen.

Immer wenn Du im Errata-Sheet den Hinweis zur Fehlerbehebung "None" 
findest, kannst Du Dich entspannt zurücklehnen und die Lösung selbst 
finden oder im TI-Forum nachfragen. (Fragen im AVR-Forum verwirren und 
verunsichern nur!)

Also, das ist ein echt harmloser Fehler. Ich hatte einmal eine fehlende 
Drahtverbindung zwischen den Clock-Modulen, intern auf dem Chip 
(Metallisierung fehlte). Da musste man extern eine Verbindung herstellen 
und hat I/O-Pins verbraten. Das war aus meiner Sicht schon etwas 
sophisticated, auch um den Fehler erst einmal zu finden.

Egal, was hier so geschrieben wird, gewöhne Dir an, so wenig wie möglich 
innerhalb der ISR zu verweilen!!! Rein, kurzer Code und raus, keine 
Schleifen!!!

Von außen kannst Du entspannt Deine Flags und Register betrachten und 
den notwendigen Code abarbeiten, von außen.

Eben fällt mir ein, statt zu Zählen, könnte man auch mit Pointern 
(Zeigern) arbeiten. Du wirst für RX und TX sowieso irgendwo einen 
zyklischen Puffer mit Anfang- und Ende-Pointer haben. Genauso kannst Du 
einen dritten Pointer durch den Speicher schieben. Dann hast Du sogar 
noch Zugriff auf das aktuelle Zeichen, das Zeichen davor und dahinter 
und so weiter.

Bei Fragen, einfach fragen!

Happy coding!

Bernd

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Meines Wissens nach lesen Compiler und Assembler keine 
Errata-Sheets. Somit sollten die Programmierer die Lösung finden und den 
"Workaround" selbst programmieren.

Abba wer weiß?

B. (Smiley)

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
[..]
>
> Allerdings sollte man eben auch nicht übersehen, dass die Architektur
> des MSP430 nun doch schon allmählich in die Jahre gekommen ist *).
[..]

You have to get the Job done.

..und das ist das was ich oben schon schrieb: es ist in den allermeisetn 
Fällen egal ob die Chips "arthritisch" sind.

Der Maschinenbefehlssatz der MSP430 lädt zum Assembler programmieren 
ein, eine schöne Architektur, inspiriert von der PDP11 mit einem 
weitestgehend orthogonalen Befehlssatz. Ich jedenfalls bin Einer dem 
CISC ala Intel auf den Wecker fällt, man räumt ständig Daten in der CPU 
umher, das ist hier nicht notwendig.

Gruß,

Holm

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> es ist in den allermeisetn Fällen egal ob die Chips "arthritisch" sind.

Als derjenige, der den Begriff in die Diskussion einbrachte: Das war 
nicht auf alle MSP430 allgemein gemünzt, sondern nur auf sehr alte 
Familienmitglieder wie 'F14x, 'F15x etc., letztlich alle Varianten, die 
aus der Vor-SBW-Zeit stammen und nur mit 4-Draht-JTAG angesprochen 
werden können.

Sie sind im Vergleich zu den neueren Modellen deutlich teurer* und haben 
deutlich weniger leistungsfähige Peripherie.

Das ist der Grund, warum ich vom Gebrauch dieser Generation in 
Neuentwicklungen abrate.

*) Auf dem G2-Launchpad war ein 'F1611 (oder -12) verbaut, der alleine 
mehr kostet, als TI für das komplette Launchpad verlangte.

Im wesentlichen entsprach dieses SBW-Interface den Innereien des alten 
MSP-FET430UIF, der essentielle Unterschied neben anderer Firmware war 
das Fehlen der für 4-Draht-JTAG nötigen Treiberbausteine.

Vor dem G2-Launchpad war diese Hardware schon auf dem "USB-Stick" für 
den 'F2013 zu finden, afaik der ersten SBW-fähigen MSP430-Familie.

Mittlerweile gibt es eine neue Hardware des G2-Launchpads, die mit dem 
Ez-Fet-Debuginterface arbeitet; TI wird die auch aus Kostengründen 
entwickelt haben. Obendrein hat TI die Sourcen und das Protokoll zur 
Ansteuerung dieses Debuginterfaces veröffentlicht, was weder beim 
MSP-FET430UIF noch dessen Frickelportvorgänger MSP-FET430PIF der Fall 
war.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clemens L. schrieb:
> Heutzutage ist TIs Alleinstellungsmerkmal integriertes FRAM.

Das ist natürlich ein Argument – für den, der das braucht. Sah mir bei 
Gerhard erstmal nicht so aus (Device hängt ständig an der Versorgung, 
darf halt nur weniger als 4 mA brauchen).

Holm T. schrieb:
> Der Maschinenbefehlssatz der MSP430 lädt zum Assembler programmieren
> ein, eine schöne Architektur, inspiriert von der PDP11 mit einem
> weitestgehend orthogonalen Befehlssatz.

Ja, allerdings ist das eher fürs Hobby nett. Wenn ich Produktionscode 
schreiben muss (wo es auf die Entwicklungs- und Wartungszeit ankommt), 
dann schreibe ich in aller Regel nicht auf Assemblerniveau. Unser 
kompletter Produktionscode in der Firma hat keine einzige Zeile 
Assemblercode, die wir selbst beigesteuert hätten, also jenseits von 
dem, was die Systembibliotheken sowieso mitbringen. Dabei haben wir 
einiges an zeitkritischen Dingen darin, aber das eigentliche Timing 
macht sowieso ein Timer (egal, auf welcher Hardware), alles andere wäre 
unsinnig.

: Bearbeitet durch Moderator
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> aber das eigentliche Timing
> macht sowieso ein Timer (egal, auf welcher Hardware), alles andere wäre
> unsinnig.

Hallo Jörg, man sollte nur über das urteilen, was man kennt. Es gibt 
durchaus zeitkritische Vorgänge, die nicht timer-gesteuert, sondern 
ereignisgesteuert mit fester (wirklich fester) Latenzzeit ablaufen 
sollen -> kein Jitter, keine halben Op-Code-Zeiten.

@Holm: Das Leben ist so vielfältig! Unsere Produkte ebenfalls und die 
evolutionären Prozesse greifen auch in der Ingenieurwissenschaft.

Gruß in die Runde!

Bernd

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Es gibt durchaus zeitkritische Vorgänge, die nicht timer-gesteuert,
> sondern ereignisgesteuert mit fester (wirklich fester) Latenzzeit
> ablaufen sollen

Klar kannste das so machen. Aber dann isses eben … – den Spruch kennst 
du sicherlich. ;-)

Wir haben hier ein Softwareprojekt, das wir nicht auf eine einzelne 
Architektur auf diese Weise festnageln können oder wollen. Schon deshalb 
verbietet sich derartiger Code darin. Davon abgesehen, auf jedem 
halbwegs modernen Prozessor mit Cache kannst du ein Timing auf so einer 
Basis komplett in die Tonne kloppen, denn das ist beim ersten Durchlauf 
viel langsamer als danach. Nur deshalb auf den Cache verzichten, damit 
man solche Krücken bauen kann? Wer's mag, wir nicht. :)

Das ist natürlich jetzt überhaupt nicht MSP430-spezifisch (Timer hat der 
ja auch), aber das Argument für einen Prozessor, weil er doch so einen 
schönen Assemblerbefehlssatz hat, zieht heutzutage kaum noch in der 
realen Welt außerhalb des Hobbys.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> aber das Argument für einen Prozessor, weil er doch so einen schönen
> Assemblerbefehlssatz hat, zieht heutzutage kaum noch in der realen Welt
> außerhalb des Hobbys.

Wäre das das primäre Argument, ich würde versuchen, mir einen µC auf 
Basis des 6309 von Hitachi zu schnitzen ...

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Meines Wissens nach lesen Compiler und Assembler keine Errata-Sheets.

Compiler tun das sehr wohl, wenn es um Codegenerierung geht (siehe 
CPUxx): http://www.ti.com/lit/pdf/slaz681 Ein Assembler kann natürlich 
kaum was machen.

Ansonsten könnte man Workarounds in einer Bibliothek verstecken, aber 
bei Mikrocontrollern werden sie kaum benutzt.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clemens L. schrieb:
> Compiler tun das sehr wohl, wenn es um Codegenerierung geht (siehe
> CPUxx): http://www.ti.com/lit/pdf/slaz681 Ein Assembler kann natürlich
> kaum was machen.

Das meinte ich nicht, aber ich schreibe da nix mehr zu.

Sorry Clemens, aber trotzdem...

Gruß

Bernd

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Hallo Jörg, man sollte nur über das urteilen, was man kennt. Es gibt
> durchaus zeitkritische Vorgänge, die nicht timer-gesteuert, sondern
> ereignisgesteuert mit fester (wirklich fester) Latenzzeit ablaufen
> sollen -> kein Jitter, keine halben Op-Code-Zeiten.

Jörg W. schrieb:
> Klar kannste das so machen. Aber dann isses eben … – den Spruch kennst
> du sicherlich. ;-)

Auch das hier kommentiere ich nicht weiter.

Gruß

Bernd

Autor: holm (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ja, allerdings ist das eher fürs Hobby nett. Wenn ich Produktionscode
> schreiben muss (wo es auf die Entwicklungs- und Wartungszeit ankommt),
> dann schreibe ich in aller Regel nicht auf Assemblerniveau. Unser
> kompletter Produktionscode in der Firma hat keine einzige Zeile
> Assemblercode, die wir selbst beigesteuert hätten, also jenseits von
> dem, was die Systembibliotheken sowieso mitbringen. Dabei haben wir
> einiges an zeitkritischen Dingen darin, aber das eigentliche Timing
> macht sowieso ein Timer (egal, auf welcher Hardware), alles andere wäre
> unsinnig.

..ja aber das ist auch kein Argument gegen diese Architektur, sondern 
nur ein positiver Nebeneffekt den sie hat. Die Tatsache das sich das 
Ding gut in Assembler programmieren läßt schließt doch nicht aus das man 
einen Compiler oder von mir aus Interpreter verwendet..

Gruß,
Holm

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
holm schrieb:
> Die Tatsache das sich das Ding gut in Assembler programmieren läßt
> schließt doch nicht aus das man einen Compiler oder von mir aus
> Interpreter verwendet.

Das hat ja auch nirgends jemand behauptet. ;-)

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Bernd B. schrieb:
>> Es gibt durchaus zeitkritische Vorgänge, die nicht timer-gesteuert,
>> sondern ereignisgesteuert mit fester (wirklich fester) Latenzzeit
>> ablaufen sollen
>
> Klar kannste das so machen. Aber dann isses eben … – den Spruch kennst
> du sicherlich. ;-)
>
> Wir haben hier ein Softwareprojekt, das wir nicht auf eine einzelne
> Architektur auf diese Weise festnageln können oder wollen. Schon deshalb
> verbietet sich derartiger Code darin. Davon abgesehen, auf jedem
> halbwegs modernen Prozessor mit Cache kannst du ein Timing auf so einer
> Basis komplett in die Tonne kloppen, denn das ist beim ersten Durchlauf
> viel langsamer als danach. Nur deshalb auf den Cache verzichten, damit
> man solche Krücken bauen kann? Wer's mag, wir nicht. :)
>
> Das ist natürlich jetzt überhaupt nicht MSP430-spezifisch (Timer hat der
> ja auch), aber das Argument für einen Prozessor, weil er doch so einen
> schönen Assemblerbefehlssatz hat, zieht heutzutage kaum noch in der
> realen Welt außerhalb des Hobbys.

..da liegst Du aber definitv falsch. Natürlich entwickle ich für Geld 
auch auf PIC12C508 ..aber das wird teurer als auf anderen 
Maschinen...wegen seiner Architektur und seinem Befehlssatz.

Drehe doch mal Deine Argument herum: Du brauchst eine CPU mit Cache die 
schnell genug ist das mit Timer zu erreichen was anderswo mit Assembler 
geht :-)

Komm einfach wieder zurück.. Was Ihr da in Eurer Firma macht und wie Ihr 
die Möglichkeiten einer HW/SW Architektur und ihrer Tools beurteilt ist 
evtl. naheliegend, aber keine allgemeingültige Aussage. Anderer Leute 
können das durchaus anders sehen. Du hast Cache angeführt, keine der 
vergleichbaren Architekturen im Thread hat das. Ich erinnere mal an den 
ATtiny 2313 den ich mit einer Assembler ISR vergewaltigen mußte um 2 
China Meßschieber auf einmal auszulesen und nebenbei noch eine 
gemultiplexte 7Seg Anzeige zu bedienen, weiß nicht ob Du das noch 
weißt..
Da hatte ich es eilig und aus heutiger Sicht gibts auch schnellere 
Prozessoren, klar, aber der Leidensdruck ne dicke schnelle Mühle zu 
verwenden ist heute für diesen Zweck noch recht gering, also kein Cache, 
kein Timer.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Jörg W. schrieb:
>> aber das Argument für einen Prozessor, weil er doch so einen schönen
>> Assemblerbefehlssatz hat, zieht heutzutage kaum noch in der realen Welt
>> außerhalb des Hobbys.
>
> Wäre das das primäre Argument, ich würde versuchen, mir einen µC auf
> Basis des 6309 von Hitachi zu schnitzen ...

Nicht Alles was hinkt ist ein Vergleich.

So weit ich weiß galt schon für den 6809 "finally done right, but to 
late", weil zur faktisch selben Zeit der 68k verfügbar wurde.

Ich sehe aber nicht das Du einen solchen 6309 8 Bit Mikro mit aktueller 
Peripherie "nicht mit dem Arsch angucken" würdest. :-)

Gruß,

Holm

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holm T. schrieb:
> So weit ich weiß galt schon für den 6809 "finally done right, but to
> late", weil zur faktisch selben Zeit der 68k verfügbar wurde.

Das dauerte schon ein paar Jahre, da das 68k-Hardwaredesign um einiges 
teurer und aufwendiger war als das des '09. Wer damals 68xx-Hardware 
designt hatte, konnte mit dem 68k zunächst nur wenig anfangen.

> Ich sehe aber nicht das Du einen solchen 6309 8 Bit Mikro mit aktueller
> Peripherie "nicht mit dem Arsch angucken" würdest.

Wir müssen halt klar Hobby und Arbeit unterscheiden. Als lustiges 
Spielzeug mit Reminiszenzen würde ich mir so ein Ding natürlich 
anschaffen. Keine Frage. Dazu müsste es noch nicht mal die Erweiterungen 
des 6309 draufhaben, der 6809-Befehlssatz würde reichen.

Aber wirklich ernsthaft damit arbeiten? Nur dann, wenn es einen 
brauchbaren C-Compiler, brauchbare Peripherie und vor allem brauchbare 
JTAG-Interfaces dafür gäbe.

Als ich meinen 6809 programmierte, gab es dafür zwar einen C-Compiler, 
aber der war ein K&R-Compiler, also noch nicht mal so etwas wie C89.

Und wenn ich mir die Peripheriebausteine ansehe, die man damals so 
verwendete, die ACIA 6850, die PIA 6821 oder den Timer 6840 - da ist 
das, was im MSP430 zu finden ist, doch irgendwie deutlich schicker. Die 
ACIA hatte das Problem des Baudratengenerators sehr elegant dadurch 
gelöst, daß sie einfach keinen hatte - das musste man also extern 
beischnallen.

Nee, war 'ne schöne Zeit damals, aber heute? Dafür bin ich zu alt.

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Holm T. schrieb:
>> So weit ich weiß galt schon für den 6809 "finally done right, but to
>> late", weil zur faktisch selben Zeit der 68k verfügbar wurde.
>
> Das dauerte schon ein paar Jahre, da das 68k-Hardwaredesign um einiges
> teurer und aufwendiger war als das des '09. Wer damals 68xx-Hardware
> designt hatte, konnte mit dem 68k zunächst nur wenig anfangen.

..."DTACK grounded" ??

>
>> Ich sehe aber nicht das Du einen solchen 6309 8 Bit Mikro mit aktueller
>> Peripherie "nicht mit dem Arsch angucken" würdest.
>
> Wir müssen halt klar Hobby und Arbeit unterscheiden. Als lustiges
> Spielzeug mit Reminiszenzen würde ich mir so ein Ding /natürlich/
> anschaffen. Keine Frage. Dazu müsste es noch nicht mal die Erweiterungen
> des 6309 draufhaben, der 6809-Befehlssatz würde reichen.
>
> Aber wirklich ernsthaft damit arbeiten? Nur dann, wenn es einen
> brauchbaren C-Compiler, brauchbare Peripherie und vor allem brauchbare
> JTAG-Interfaces dafür gäbe.
>

Ja natürlich, das meinte ich mit aktueller Peripherie im Chip..dann ist 
davon auszugehen das auch die SW Tools existieren würden wenn es einen
solchen Micro gäbe.


> Als ich meinen 6809 programmierte, gab es dafür zwar einen C-Compiler,
> aber der war ein K&R-Compiler, also noch nicht mal so etwas wie C89.
>
> Und wenn ich mir die Peripheriebausteine ansehe, die man damals so
> verwendete, die ACIA 6850, die PIA 6821 oder den Timer 6840 - da ist
> das, was im MSP430 zu finden ist, doch irgendwie deutlich schicker. Die
> ACIA hatte das Problem des Baudratengenerators sehr elegant dadurch
> gelöst, daß sie einfach keinen hatte - das musste man also extern
> beischnallen.

:-)

..und der ganze Kram war reichlich buggy (ACIA z.B.) wobei wir wieder 
bei den Errata währen. Auch eine Z80 SIO hat keinen Baudratengenerator 
wobei es i.A. Usus war einen CTC zu verwenden. Aber damals machten 9600 
Baud noch was her...

>
> Nee, war 'ne schöne Zeit damals, aber heute? Dafür bin ich zu alt.

Ach Quatsch, man wird doch wohl noch träumen dürfen.. ganz egal ob wir 
alte Säcke sind.

IMHO gibts den 6809 als Softcore... Moment:

https://opencores.org/project/6809_6309_compatible_core
Status

- Most instructions need less clocks than the original.
- Synthesizes in Lattice Diamond for the MachXO2 requiring ~1260 Slices (two-cycle multiplier) @ >40 MHz, tested, works.
- Synthesizes in XST for Spartan 2 using a bit less than 1200 Slices (fits in a XC2S100). Testing pending.
- Synthesizes in XST for Spartan 3 using ~1150 Slices, hw-multiplier. Testing on real FPGA pending.
- A simple vga text controller has been added, it needs some 70 SLICES and two blocks of ram of 4 kbyte each for font and text. It only outputs b/w. It may be removed to make the code smaller.

- All 6809 opcodes have been implemented.

- 6309 opcodes have to be added 

..wo ist also das Problem? Nu aber los ... :-) 40Mhz 6309 :))


Mich würde mal interessieren was Hitachi damals dazu getrieben hat die 
nennenswerten Features des 6309 gegenüber dem 6809 geheim zu halten,
hatten die Schiß das Moto denen die Lizenz  als 2nd Source entzieht?

Gruß,

Holm

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holm T. schrieb:
> Ich erinnere mal an den ATtiny 2313

Ist aber eben auch schon paar Jahre her.  Würdest du dir das heute 
kommerziell auch noch antun, also findest du noch jemanden, der dich 
dafür bezahlt?

Sicher kann man auch langsame Controller sinnvoll verwenden (sonst gäbe 
es ja keinerlei Grund für Microchip, noch weitere ATtinys nachzulegen), 
aber ganz ehrlich, wenn das Timing so popelig wird, dass man anfangen 
muss, die Befehle zu zählen – dann greife ich heutzutage lieber zu einem 
Controller, der 'ne Klasse schneller ist. Kostet eh' nicht mehr als der 
kleine.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> wenn das Timing so popelig wird, dass man anfangen
> muss, die Befehle zu zählen – dann greife ich heutzutage lieber zu einem
> Controller, der 'ne Klasse schneller ist. Kostet eh' nicht mehr als der
> kleine.

Hallo Jörg,

genau das ist das Problem: Ich habe das Gefühl, dass viele Ressourcen 
und Möglichkeiten von Dir nicht erkannt, dann nicht genutzt werden. Es 
ist immer so, sobald man sich in einem noch unbekannten Territorium 
bewegt, fehlen einem die Worte es zu beschreiben oder damit umzugehen.

Du darfst gerne widersprechen, aber überlege einmal. Als Madame Curie 
die Radioaktivität erforscht hat oder Röntgen seine Strahlen (engl. 
X-Rays), haben sie mit dem Zeugs rumgeballert ohne Ende. Das war nicht 
verkehrt. Als man aber gelernt hat mit dem Zeugs umzugehen, konnte man 
mit viel weniger Einsatz viel besser arbeiten. Heute werden bei 
laufenden Röntgengeräten Herzkatheter geschoben und die Ärzte tragen 
maximal Schürzen um sich zu schützen. Währen damals eben die Strahlen 
mit viel größerer Leistung verwendet wurden, auch zur Abendbelustigung.

Vielleicht kannst Du Dir nicht vorstellen, dass man so programmiert, wie 
ich es beschrieben habe. Aber generell immer dagegen argumentieren ist 
einfach falsch. Es wäre doch einen Versuch wert sich wenigstens einmal 
anzusehen, was so gemacht wird.

Ich glaube fast das ist einfach das Problem der Ingenieure. Alles was 
über den Tellerrand hinausgeht ist und bleibt falsch ... oder not 
invented here.

Es geht also nicht über Bytezählung, sondern manchmal nur um definierte 
Zustände und dann auch nur mit weniger als 10 OpCodes innerhalb der ISR 
- inkl. IRET.

Gruß

Bernd

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Holm T. schrieb:
>> Ich erinnere mal an den ATtiny 2313
>
> Ist aber eben auch schon paar Jahre her.  Würdest du dir das heute
> kommerziell auch noch antun, also findest du noch jemanden, der dich
> dafür bezahlt?
>
> Sicher kann man auch langsame Controller sinnvoll verwenden (sonst gäbe
> es ja keinerlei Grund für Microchip, noch weitere ATtinys nachzulegen),
> aber ganz ehrlich, wenn das Timing so popelig wird, dass man anfangen
> muss, die Befehle zu zählen – dann greife ich heutzutage lieber zu einem
> Controller, der 'ne Klasse schneller ist. Kostet eh' nicht mehr als der
> kleine.

..ich bin mir nicht mal sicher ob das nicht ein 90S2313 war ...

Die Auswirkungen Deiner Argumentation kann man recht gut an 
Computersoftware an und für sich nachvollziehen, Wordstar 3 lief in 
64KByte Memory mit 2,5Mhz und 8 Bit, guck Dir mal an wie zäh sich ein 
aktuelles (Firma nehm ich nicht in den Mund) Office auf einen 
"fensterorientierten 'Betriebsssystem'" heute so bewegt und wie lange Du 
brauchst nach dem Rechner einschalten bis Du überhaupt Deinen Text 
tippern kannst..

Das kann doch nicht der Weisheit letzter Schluß sein?!?

Gruß,

Holm

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jeder wie er mag.
Ich teile aber auch Jörgs Einschätzung, das einem handoptimierter Asm 
Code in der Realität schnell um die Ohren fliegt, während Timer eine 
sehr gutmütige und robuste Methode sind.
Früher habe ich das auch gemacht (Audio Sampler auf 8031), aber heute 
sehe ich da keine Notwendigkeit mehr.

Schon beim STM8S003 kannst Du diese Tricks wg der 3stage Pipeline 
vergessen.
Beim AVR haben die zu so ungeheuer nützlichen Dingen wie VUSB geführt.
Schön, geht, aber wofür ist das gut?

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holm T. schrieb:
> Wordstar 3 lief in
> 64KByte Memory mit 2,5Mhz und 8 Bit

Den Fehler in Deiner Argumentation findest Du sicherlich selbst, wenn Du 
Dir überlegst wie Du Dich zu diesen goldenen Zeiten im Netz bewegt hast.

Ein modernes OS tut ja nun ein wenig mehr.
64K ASM ist bestimmt noch zu warten.
Firefox, SAP, GIMP in ASM mit weltweit verteilten Entwicklern?
Platformübergreifende Software?
Ja, sehr komisch.

Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Michael K. schrieb:
> Holm T. schrieb:
>> Wordstar 3 lief in
>> 64KByte Memory mit 2,5Mhz und 8 Bit
>
> Den Fehler in Deiner Argumentation findest Du sicherlich selbst, wenn Du
> Dir überlegst wie Du Dich zu diesen goldenen Zeiten im Netz bewegt hast.
>
> Ein modernes OS tut ja nun ein wenig mehr.
> 64K ASM ist bestimmt noch zu warten.
> Firefox, SAP, GIMP in ASM mit weltweit verteilten Entwicklern?
> Platformübergreifende Software?
> Ja, sehr komisch.


Nein, da ist kein Fehler in meiner Argumentation. Natürlich möchte ich 
nicht die Zeiten ohne Netz zurück und ASCII in grün ist zwar nett, aber 
es gibt Besseres.

Evtl. wird Dir aber klar wie sich der Recourcenverbrauch der Software 
entwickelt hat wenn Du mal den damals verfügbaren Speicher und die 
Taktfrequenzen zu dem ins Verhältnis setzt was wir heute haben, ist das 
um den Faktor 1000 "besser" geworden? Ich glaube kaum und mittlerweile 
ist es ja auch Usus das Software macht was sie will (oder deren 
Hersteller) aber nicht das was sie soll. In wie fern ist es also sinvoll 
das ein OS ein wenig mehr tut als der Anwender möchte?
Der Anwender sitzt vor seinem PC und wartet länger als vor einen 
steinzeitlichen 8bit CP/M System bis die Kiste mal aus dem Knick kommt.

BTW: SAP ist ne Branchensoftware "Sanduhr Anzeige Programm".. geht mir 
glatt am Arsch vorbei. Nicht jede CP/M Software wurde in ASM 
geschrieben, nicht mal der CCP von CP/M selbst...

Gruß,

Holm

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Vielleicht kannst Du Dir nicht vorstellen, dass man so programmiert, wie
> ich es beschrieben habe.

Doch, kann ich. Habe ich vor 30 Jahren auch so gemacht. Will ich heute 
einfach nicht mehr haben. Muss ich heute auch nicht mehr haben, zum 
Glück.

@Holm: unsere Controller sind nicht deswegen so fett, weil wir da kein 
handgefeiltes Assembler-Timing mehr drauf laufen lassen wollen, sondern 
weil da für die Resultatberechnung number crunching läuft, für das man 
vor 10+ Jahren noch einen dedizierten DSP gebraucht hat. Die Caches sind 
dann einfach mit da – aber spätestens durch sie verbieten sich eben 
Timing-via-Erbsenzählung-Hacks.

: Bearbeitet durch Moderator
Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holm T. schrieb:
> Nein, da ist kein Fehler in meiner Argumentation.

Okay, dann nicht.
Bei gleichem Look and Feel und gleichem Funktionsumfang, wäre Wordstar 3 
auf einem i7 sicherlich die schnellste Textverarbeitung der Welt.
Wenn Du einen Treiber für den 9Nadler findest und lange genug 
probierst wie das was Du druckst wenigstens ähnlichkeit mit dem hat was 
Du geschrieben hast.

Treiberschicht und WYSIWYG gäbe es natürlich nicht.
Was hindert dich weiter mit dem C64 zu arbeiten?
Der telefoniert auch nicht nach hause.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael K. schrieb:
> handoptimierter Asm

Leute, Ihr habt es immer noch nicht verstanden. Das muss kein 
handoptmiertes ASM sein, um gut oder sehr gut oder vielleicht exzellent 
die Aufgabe zu erfüllen.

Schaut mal, Einstein war auch verblüfft, wie einfach E=mc2 ist. Alle 
anderen Forscher sind nie auf die Idee gekommen, dass es einfach geht. 
Aber nachdem sie alle ihren Wissensraum erweitert hatten, war es für sie 
ebenfalls die einzige Lösung.

Ihr bringt die Diskussion zum Kochen, ohne ein einziges Beispiel zu 
nennen. Der Vergleich mit Superhohen Sprachen, überzogenen Taktraten und 
supergeiler Show verbunden mit eskalierenden Taktraten ist für mich kein 
Maßstab.

Seht Euch in der Natur um. Viele Sachen sind einfach simpel und gut. 
Sind sie deshalb falsch? NEIN!

In anderen threads hatte ich Eure Einstellung bereits ebenfalls schon 
kritisiert.

Gruß

Bernd

Autor: Holm T. (holm)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Michael K. schrieb:
> Holm T. schrieb:
>> Nein, da ist kein Fehler in meiner Argumentation.
>
> Okay, dann nicht.
> Bei gleichem Look and Feel und gleichem Funktionsumfang, wäre Wordstar 3
> auf einem i7 sicherlich die schnellste Textverarbeitung der Welt.
> Wenn Du einen Treiber für den 9Nadler findest und lange genug
> probierst wie das was Du druckst wenigstens ähnlichkeit mit dem hat was
> Du geschrieben hast.

Vorsicht: bereits damals gabs Laserdrucker und auch Treiber dazu.
Ich finde auch noch eine Patchanleitung für WS in den ersten 100 Bytes 
des Programms um Bildschirm und Druckersteuersequenzen anzupassen.
>
> Treiberschicht und WYSIWYG gäbe es natürlich nicht.
> Was hindert dich weiter mit dem C64 zu arbeiten?
> Der telefoniert auch nicht nach hause.

Ja, Du kannst ja herumkaspern wie Du möchtest, ich werde Dich nicht dran 
hindern.
Kennst Die passende Bezeichnung für TeX im Verlgeich zum WYSIWIG?
WYGIWYN ..What You Get Is What You Need ..und das ist bewiesen. Office 
funktioniert evtl. mal wenn es Text statt Word heißt, bisher taugts 
maximal für einen Brief an die Oma...
Das Look von Word mag ja noch durchgehen, das Feel aber auf keinen Fall.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bernd B. schrieb:
[..]
>
> Ihr bringt die Diskussion zum Kochen,ohne ein einziges Beispiel zu
> nennen.


Ich habe doch gebeispielt.
An einer Diskussion ist absolut nichts schlechtes, auch an Jörgs 
schnelleren Mikros nicht.

Mit gehst es nur gegen den Strich "auf die Dauer hilft nur Power" 
akzeptieren zu sollen. Es gibt mehrere durchaus legitime Wege ein Ziel 
zu erreichen, aber mit viel Aufwand wenig zu erreichen ist suboptimal.

[..]
> In anderen threads hatte ich Eure Einstellung bereits ebenfalls schon
> kritisiert.
>
> Gruß
>
> Bernd

Häh?

Gruß,

Holm

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Ich habe doch gebeispielt.

Hallo Holm,

schon richtig. Dich meinte ich auch nicht mit den mangelnden Beispielen. 
Das galt in Richtung mit viel Power und viel Ressourcen alles platt zu 
machen.

Und eine Diskussion sollte auch keine Einbahnstraße sein. Man hört sich 
genseitig zu und behauptet nicht einfach, was der Gegenüber gar nicht 
meinte - auch wieder nicht gegen Dich und die Hälfte der Foristen hier 
im Thread.

Gruß

Bernd

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Ihr bringt die Diskussion zum Kochen, ohne ein einziges Beispiel zu
> nennen.
Hab ich, Audio Sampler auf 8031.
Sampling und Abspielroutine wurden in mühevoller Kleinarbeit verNOPt um 
auf gleiche Geschwindigkeit zu kommen.
Klar geht das.
Ist halt nur Scheisse wenn der Code wächst, Aufgaben dazukommen, IRQs 
bearbeitet werden müssen etc.
Immer muss man Rücksicht auf dieses spezielle Detail nehmen.

Auch funktioniert Deine Herangehensweise einfach nicht sobald Pipeline 
oder Cache dazukommen, was selbst bei 20Cent MCUs (STM8S003) schon der 
Fall ist.

Moderne MCUs sind einfach so performant, das ich mittlerweile mehr Wert 
darauf lege das es wartbar und auf andere MCUs übertragbar bleibt.
Durch moderne Timer und

Bernd B. schrieb:
> Viele Sachen sind einfach simpel und gut.
> Sind sie deshalb falsch? NEIN!
Sagt doch niemand.
Mach es doch, hat doch keiner was dagegen.
Ich sage auch nicht das ich das nie und unter keinen Umständen machen, 
nur halt nicht im Regelfall.
Ich springe zwischen verschiedenen MCU Familien und jede hat einen 
anderen ASM Befehlssatz, aber alle verstehen C. Mal eben einen 
Codeschnipsel aus einem anderen Prpjekt weiterverwenden geht halt mit 
ASM und Handoptimierten Timings die nur unter ganz bestimmten 
Rahmenbedingungen funktionieren, nicht.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Das galt in Richtung mit viel Power und viel Ressourcen alles platt zu
> machen.

Das war doch sowieso nur 'ne Behauptung von dir.

Lies doch mal weiter oben: die Ressourcen brauchen wir für ganz andere 
Zwecke, aber daraus ergibt sich, dass man es mittlerweile mit 
Controllern zu tun hat, bei denen so eine 
Instruction-level-Erbsenzählerei einfach gar nicht mehr funktioniert.

Aber selbst bei Controllern, bei denen sie funktionieren würde, stelle 
ich die Notwendigkeit für solche Tricksereien halt in Frage zu einer 
Zeit, wo ein potenterer (und genauso teurer) Controller lässig ohne 
solche unportablen Hacks auskommt. Der muss ja nun nicht gleich 'ne 
ganze Größenordnung potenter sein. Vor 30+ Jahren war es auch gang und 
gäbe, selbstmodifizierenden Code zu verbrechen ("ld HL, xxxx", wobei man 
die Adresse des Operanden xxxx an anderen Stellen dann als Variable 
benutzt hat), aber meinst du ernsthaft, dass man mit solcherart „Tricks“ 
heute noch jemanden hiterm Ofen hervor lockt?  Die Bits sind definitiv 
billiger geworden, und es ist müßig so zu tun, als müsste man jeden 
Sch*** von anno dunnemals auch heute noch genauso tun.

Zurück zu Gerhard: sowieso alles irrelevant. Er braucht 'n bisschen UART 
mit 1200 Bd, da braucht man derartigen Zirkus sowieso nicht.

: Bearbeitet durch Moderator
Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
[..]
>
> @Holm: unsere Controller sind nicht deswegen so fett, weil wir da kein
> handgefeiltes Assembler-Timing mehr drauf laufen lassen wollen, sondern
> weil da für die Resultatberechnung number crunching läuft, für das man
> vor 10+ Jahren noch einen dedizierten DSP gebraucht hat. Die Caches sind
> dann einfach mit da – aber spätestens durch sie verbieten sich eben
> Timing-via-Erbsenzählung-Hacks.

Ja doch, ich halte Euch auch nicht für doof. Hier gings aber gerade noch 
um einen MSP430 im Vergleich zu anderen µC seiner Klasse und das Faß mit 
"bigger is better" hast Du aufgemacht (Caches). Sicher würde ich einen 
MSP430 nicht als Number Cruncher vorschlagen, aber Gerhard wollte ein 
Preßluftdingens steuern und das handelt jeder halbwegs aktuelle 8-Bitter 
auf der linken Arschbacke ab, wenn nicht macht der Programmierer was 
grundsätzlich falsch.

Natürlich hat es auch Einfluß auf die Lösung mit was man "üblicherweise" 
arbeitet und wenn das fette 32Bitter sind, sieht natürlich 8Bitter mit 
seinen Möglichkeiten immer beschissen aus. Selbst wenn der die Hälfte 
des 32Bitters kosten würde, wäre die Entwicklung immer noch teurer als 
beim 32Bitter weil die Einarbeitung da wieder zuschlägt und Resourcen 
frißt. Ist mir Alles klar.

Manchmal werden aber heute zu Tage "Lösungen" gebracht die ich für stark 
überdenkenswert halte, mag sein das ich zu alt bin, aber mir geht 
beispielsweise der Vorteil einer über Smartphone steuerbaren Deckenlampe 
nicht auf, wenn es Jahrzehnte vorher ein simpler Schalter an der Wand 
auch zur Zufriedenheit getan hat, darauf will ich hinaus.

Gruß,

Holm

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> mir geht beispielsweise der Vorteil einer über Smartphone steuerbaren
> Deckenlampe nicht auf, wenn es Jahrzehnte vorher ein simpler Schalter an
> der Wand auch zur Zufriedenheit getan hat, darauf will ich hinaus

Bei der Deckenlampe gebe ich dir Recht.

Beim Heizkörperventil schon nicht mehr – wenn ich aus dem Urlaub 
zurückkomme und einen Tag vorher die Bude aus der Ferne wieder 
durchheizen kann, hat das schon einen Mehrwert … (sind wir ja fast 
wieder zurück bei Gerhards Pressluftdingens :).

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Holm T. schrieb:
>> mir geht beispielsweise der Vorteil einer über Smartphone steuerbaren
>> Deckenlampe nicht auf, wenn es Jahrzehnte vorher ein simpler Schalter an
>> der Wand auch zur Zufriedenheit getan hat, darauf will ich hinaus
>
> Bei der Deckenlampe gebe ich dir Recht.
>
> Beim Heizkörperventil schon nicht mehr – wenn ich aus dem Urlaub
> zurückkomme und einen Tag vorher die Bude aus der Ferne wieder
> durchheizen kann, hat das schon einen Mehrwert … (sind wir ja fast
> wieder zurück bei Gerhards Pressluftdingens :).

..das geht aber nur so lange der Hersteller nicht Pleite geht, IPV6 
gibts ja noch nicht, das muß erst noch erfunden werden....

Nun denke ich das Du Deine Heizung, nachdem der Hersteller während 
Deines Urlaubs Pleite gemacht hat, wieder in Betrieb bekommst wenn Du 
wieder zu Hause bist (hast ja keine linken Hände) ..aber wie viele 
Linkshänder gibts wohl so die dann ne neue Heizung kaufen müssen? Ergo: 
nicht Alles was man machen kann ist wirklich sinnvoll, und diese 
"Leuchtmittel" mit WLAN und Bluethoot Anbindung gibts wirklich. War da 
nicht Was mit einer Sicherheitslücke in Philips Leuchtobst?

Der von Dir angeführte Mehrwert-Fall kommt wie oft im Jahr vor?

Gruß,

Holm

Edit:

>Aber selbst bei Controllern, bei denen sie funktionieren würde, stelle
>ich die Notwendigkeit für solche Tricksereien halt in Frage zu einer
>Zeit, wo ein potenterer (und genauso teurer) Controller lässig ohne
>solche unportablen Hacks auskommt.

Nicht zu vergessen den Fall das $Hersteller noch Tausende Reels irgend 
eines Prozessors liegen hat und die verwursten will...auch die RV12P2000 
fand sich in Radios :-) es gibt da noch viel mehr Beispiele.

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin zur Zeit dabei dem MSP430 auf den Zahn zu fühlen und komme schon 
ganz gut mit ihm zurecht. Die befürchteten UART Flag Probleme traten 
nicht ein und es funktioniert auf Interrupt Basis alles wie es soll. Ich 
portierte ein Standard Monitor Programm von mir mit dem man auf die Chip 
Ressourcen zugreifen kann und das ging fast ohne richtige Probleme 
zustatten.

Bin auch überrascht wie schnell der uC trotz der 1Mhz Clock auf 
Kommandos reagiert. LPM Modes habe ich noch nicht ausprobiert. Muss nur 
noch die ADC und RTC und EEPROM Emulation anpassen. Da der MSP430 kein 
internes EEPROM hat werde ich natürlich FRAM dazu nehmen. Anstatt eines 
sonst üblichen externen RTC möchte ich den internen RTC dafür in 
Anspruch nehmen. Ein 32kHz Quarz ist ja auf der L.P. Board vorhanden.

Jedenfalls arbeitet es sich bis jetzt mit dem Teil sehr gut und hat mir 
bis jetzt Spaß gemacht damit zu arbeiten. Ich möchte im Augenblick 
zwecks Lernens die Driverlib vermeiden und die Peripherien "bare metal" 
konfigurieren. Es ist übrigens schon angenehm wie bei den STM32s mit 
einem JTAG/SBW Debugger arbeiten zu können.

Was mich noch interessieren würde: Inwieweit lohnt es sich noch auf 
ältere MSP430 Familienmitglieder für kleinere Sachen zuzugreifen? Für 
ein paar geplante batteriebetriebene Sensorprojekte hätte ich daran 
Interesse. Nur möchte ich dafür keinen Boliden wie den L.P. FR5994 dazu 
verwenden.

Jedenfalls bedanke ich mich für Eure Ratschläge und Enthusiasmus!

Gerhard

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
[..]
>
> Was mich noch interessieren würde: Inwieweit lohnt es sich noch auf
> ältere MSP430 Familienmitglieder für kleinere Sachen zuzugreifen? Für
> ein paar geplante batteriebetriebene Sensorprojekte hätte ich daran
> Interesse. Nur möchte ich dafür keinen Boliden wie den L.P. FR5994 dazu
> verwenden.
>
> Jedenfalls bedanke ich mich für Eure Ratschläge und Enthusiasmus!
>
> Gerhard

..klar doch, freilich kannst Du die "arthritischen" Chips für 
irgendwelchen Kram verwenden. Ich habe mir eine kleine Breakout Platine 
für MSP430F148/49 in China fertigen lassen weil ich etliche solcher 
Chips bekommen hatte. Hier im Markt gab es mal MSP430F1611 für Kleingeld 
und ein paar MSP430F2616 sind mir auch noch zugelaufen.. Alle diese 
Chips verwenden das selbe Footprint. Ich nehme logischerweise das Zeug 
wenn es irgendwas zu experimentieren gibt.

https://www.tiffe.de/images/MSP-s.jpg

Die Dinger haben freilich kein SBW, da ich aber preiswert einen 
MSP430-FET aufgetrieben habe und "mspdebug" auf meinem FreeBSD damit 
problemlos hantieren kann, ist das für mich nicht wirklich ein Nachteil.

Gruß,
Holm

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

schön... sehr schön!

Bei mir sind immer mindestens folgende Kriterien in der Diskussion: 
Platz , sog. Verfügbarkeit beim Distributor und "den F2011 bis F2013" 
gibt es im DIL-Gehäuse für ein Steckbrett (sog. wishboard).

Für Deine Prozessorauswahl empfehle ich Dir die Filterfunktion auf den 
TI-Internetseiten. Meine Auswahlmethode ist eher etwas unkonventionell.

Bei den alten "Gehäusen" meine ich, dass es immer Typen gibt mit 
gleichen PCB-Layout und Port-Anschlüssen oder besser. Allerdings sind 
die Portregister häufig mit neuem Namen vorzufinden. Auch sind die Ports 
manchmal etwas anders zu bedienen.

Ich habe für mich eine Strategie entwickelt oder erarbeitet, dass ich 
die Prozessortypen bei "gleicher" Port-Verwendung sehr kurzfristig 
austauschen und/oder anpassen kann. Dabei verwende und vergleiche ich 
die unterschiedlichen Family User's Guides. Aber das wächst bei Dir auch 
von ganz alleine, sobald Du mehrere Projekte erfolgreich beendet hast.

Zunächst, das Tool von der TI-Seite und nicht zu viel nehmen, aber etwas 
mehr als wie gerade notwendig. Das sollte doch eine klare Empfehlung 
sein - oder? (Smiley)

Noch ne Anmerkung: Die Interrupt-Vektor-Tabellen als erstes anpassen und 
immer schön modular programmieren...

Eigentlich hätte ich gar nicht antworten müssen, denn Holm hat es ja 
just in dem Augenblick, in dem ich meine Vorschau nutze.

Happy coding!

Bernd

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> und "den F2011 bis F2013" gibt es im DIL-Gehäuse

Den 'G2553 gibt es auch im (20poligen) DIL-Gehäuse, und der ist dann 
doch von der Peripherie her etwas besser ausgestattet als die 
'F20xx-Reihe (bis auf den 16-Bit-ADC des 'F2013). Und mit sechs Pins 
mehr am Gehäuse lässt sich doch auch mehr erreichen.

Das ist der Controller, der den neueren Revisionen des G2-Launchpads 
beiliegt.

Es gibt sogar einen MSP430 im 40poligen DIL-Gehäuse, den 'G2744, den 
aber verkauft TI selbst nicht, den gibt es ausschließlich bei Olimex 
als Bestandteil eines sogenannten "Booster-Packs":

https://www.olimex.com/Products/MSP430/Booster/MSP...

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Inwieweit lohnt es sich noch auf ältere MSP430 Familienmitglieder für
> kleinere Sachen zuzugreifen?

Gar nicht; kleine Chips gibt es auch für neuere Modelle mit SBW, z.B.:
http://www.ti.com/product/MSP430G2230 (SOIC-8)
http://www.ti.com/product/MSP430FR2000 (der billigste MSP)

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Clemens L. schrieb:
> Gerhard O. schrieb:
>> Inwieweit lohnt es sich noch auf ältere MSP430 Familienmitglieder für
>> kleinere Sachen zuzugreifen?
>
> Gar nicht; kleine Chips gibt es auch für neuere Modelle mit SBW, z.B.:
> http://www.ti.com/product/MSP430G2230 (SOIC-8)
> http://www.ti.com/product/MSP430FR2000 (der billigste MSP)

Hmm. Das sind aber beides Chips die aus heutiger Sicht so gut wie keinen 
RAM enthalten..es wird schwierig darauf Etwas mit dem gcc compiliertes 
zum laufen zu bekommen. Hast Du noch Empfehlungen für Chips mit etwas 
mehr Grips?
Der 2. hat nicht mal einen ADC ..

@rufus: Was diese Aktion mit dem MSP430-G2744 soll ist mir weitestgehend 
unklar. Wie Du schon schreibst gibts das Teil ausschließlich bei Olimex, 
CPUs als Ersatzbestückung gibts nicht, eine kommerzielle Anwendung ist 
damit völlig ausgeschlossen. Da es das Ding nur mit Olimex-Board gibt 
ist mir nicht klar wo da der Vorteil eines DIP40 ICs auf einer Platine 
gegenüber einem TQFP64 auf einer Platine ist.

Gruß,

Holm

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den 512 Byte RAM des zweiten Exemplares kann man auf einem MSP430 
durchaus einiges anstellen; der 'G2553, der seit geraumer Zeit auf dem 
G2-Launchpad drauf ist, lässt sich sogar mit der arduino-artigen 
Umgebung "Energia" nutzen.

Anders als bei AVRs verbrauchen Stringkonstanten auf MSP430 kein RAM ...


Der erstgenannte ('G2230) ist mit nur 128 Bytes RAM in der Tat sehr, 
sehr knapp bemessen.

Wenn man nicht sehr spezielle Rahmenbedingungen hat, die 8pinner 
erforderlich machen oder einen besonders günstigen Preis, würde ich den 
schon erwähnten 'G2553 einsetzen - das ist von dem von mir vor ein paar 
Postings erwähnten Olimex-Exoten abgesehen auch der "größte" MSP430, den 
es im frickelboardkompatiblen DIL-20 gibt.

http://www.ti.com/product/MSP430G2553

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..weiß ich, kenne ich. Das war der erste MSP430 den ich überhaupt in den 
Fingern hatte.

Gruß,

Holm

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> den ich überhaupt in den Fingern hatte.

Oh, ein "Späteinsteiger", das hätte ich jetzt nicht gedacht. Ich hatte 
mein erstes Projekt (geerbt) mit einem 'F1611 (der dann in der 
Produktion auf einen 'F157 abgerüstet werden konnte), da gab es die 
ganzen SBW-Nettigkeiten noch nicht.

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Das sind aber beides Chips die aus heutiger Sicht so gut wie keinen
> RAM enthalten.

Das sind die extremsten Beispiele. Größere "kleineren Sachen" gibt es 
natürlich auch: 
http://www.ti.com/microcontrollers/msp430-ultra-lo... 
("Other MSP430 MCUs" sind Flash, alle anderen sind FRAM)

> Hast Du noch Empfehlungen für Chips mit etwas mehr Grips?

Die, die auf den LaunchPads verbaut sind:
http://www.ti.com/tools-software/launchpads/launch...

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Holm T. schrieb:
>> den ich überhaupt in den Fingern hatte.
>
> Oh, ein "Späteinsteiger", das hätte ich jetzt nicht gedacht.

Mir ist es halt egal was das für ne CPU da drin ist, "stromsparend" 
hatte mich halt in die Richtung MSP430 gelockt, ich denke aber ein AVR 
kann das auch. Alles ok damit. Nur einen PIC16 möchte ich nicht 
unbedingt nochmal.
Bei 8051 knistern schon die Fußnägel..geht aber noch.

> Ich hatte
> mein erstes Projekt (geerbt) mit einem 'F1611 (der dann in der
> Produktion auf einen 'F157 abgerüstet werden konnte), da gab es die
> ganzen SBW-Nettigkeiten noch nicht.

Gesetzt den Fall man hat bereits wie ich den ehemals teuren MSP430-FET 
...wo ist denn nun der ungeheure SBW Vorteil aus Deiner Sicht? Es ist 
billiger und moderner..braucht weniger Anschlüsse als JTAG..aber damit 
isses IMHO schon gut.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clemens L. schrieb:
> Holm T. schrieb:
>> Das sind aber beides Chips die aus heutiger Sicht so gut wie keinen
>> RAM enthalten.
>
> Das sind die extremsten Beispiele. Größere "kleineren Sachen" gibt es
> natürlich auch:
> http://www.ti.com/microcontrollers/msp430-ultra-lo...
> ("Other MSP430 MCUs" sind Flash, alle anderen sind FRAM)
>
>> Hast Du noch Empfehlungen für Chips mit etwas mehr Grips?
>
> Die, die auf den LaunchPads verbaut sind:
> http://www.ti.com/tools-software/launchpads/launch...

Nichts Neues also.

Gruß,

Holm

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Beinahe-show-stopper für uns war damals, dass man einen Zählerwert nicht
> zuverlässig auslesen kann, während der Zähler läuft.

Das erinnert mich an den 8051, da gab es einen Beispielcode für das 
Lesen des Timers "on the fly":
again:
  mov  a,  th0
  mov  r7, tl0
  cjne a,  th0, again
  mov  r6, a
  ret

Für den 8051 gab es sehr viele Bücher mit Beispielcode in Assembler, 
z.B. von Philips und AMD.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Gesetzt den Fall man hat bereits wie ich den ehemals teuren MSP430-FET
> ...wo ist denn nun der ungeheure SBW Vorteil aus Deiner Sicht? Es ist
> billiger und moderner..braucht weniger Anschlüsse als JTAG..aber damit
> isses IMHO schon gut.

Die Anschlüsse sind es einerseits, die obendrein auch noch sonst eher 
unbenutzte Pins umfunktionieren, so daß mehr I/O ohne Verrenkungen zur 
Verfügung steht, und andererseits das Preisgefälle für Debuginterfaces 
und lange nötige Offenlegen der Debugschnittstelle.

Das erste G2-Launchpad war noch firmwarekastriert, d.h. konnte nicht 
jeden Controller per SBW ansteuern, aber das neue G2-Launchpad kann 
genau das.

Damit gibt es auch für Gelegenheitsprogrammierer der MSP430 keinen Grund 
mehr, auf anständige Debugmöglichkeiten zu verzichten.

Zwar gibt es Leute, die glauben, man könnte auch mit in den Code 
eingestreuten Testausgaben oder Pingewackel und Oszilloskopeinsatz 
"debuggen", aber das ist dann halt doch was anderes als die Möglichkeit, 
Breakpoints zu verwenden und im Single-Step-Betrieb dem Controller 
zuzusehen.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Holm T. schrieb:
>> Gesetzt den Fall man hat bereits wie ich den ehemals teuren MSP430-FET
>> ...wo ist denn nun der ungeheure SBW Vorteil aus Deiner Sicht? Es ist
>> billiger und moderner..braucht weniger Anschlüsse als JTAG..aber damit
>> isses IMHO schon gut.
>
> Die Anschlüsse sind es einerseits, die obendrein auch noch sonst eher
> unbenutzte Pins umfunktionieren, so daß mehr I/O ohne Verrenkungen zur
> Verfügung steht, und andererseits das Preisgefälle für Debuginterfaces
> und lange nötige Offenlegen der Debugschnittstelle.
>
> Das erste G2-Launchpad war noch firmwarekastriert, d.h. konnte nicht
> jeden Controller per SBW ansteuern, aber das neue G2-Launchpad kann
> genau das.
>

Ich habe mich nicht drum gekümmert was das MSP430-FET auf meiner Kiste 
konkret wie tut, aber ich habe das Ding als FreeBSD-Port installiert,
das bedeutet es wurde aus Quellen gebaut, ich habe kein Windows hier am 
Start.

NAME
       MSPDebug - debugging tool for MSP430 MCUs

SYNOPSIS
       mspdebug [options] driver [command ...]

DESCRIPTION
       MSPDebug is a command-line tool designed for debugging and programming
       the MSP430 family of MCUs. It supports the eZ430-F2013, eZ430-RF2500,
       Launchpad, Chronos, FET430UIF, GoodFET, Olimex MSP430-JTAG-TINY and
       MSP430-JTAG-ISO programming tools, as well as a simulation mode.



This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.

Using new (SLAC460L+) API
MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: mspfet0010
MSP430_Initialize: mspfet0010
Firmware version is 31200604
MSP430_VCC: 3300 mV
MSP430_OpenDevice
MSP430_GetFoundDevice
Device: MSP430F1611 (id = 0x0070)
8 breakpoints available
MSP430_EEM_Init
Chip ID data:
  ver_id:         6cf1
  ver_sub_id:     0000
  revision:       20
  fab:            40
  self:           0000
  config:         00
  fuses:          00
Device: MSP430F1611

Available commands:
    !               fill            power           setwatch_r      
    =               gdb             prog            setwatch_w      
    alias           help            read            simio           
    blow_jtag_fuse  hexout          regs            step            
    break           isearch         reset           sym             
    cgraph          load            run             verify          
    delbreak        load_raw        save_raw        verify_raw      
    dis             md              set             
    erase           mw              setbreak        
    exit            opt             setwatch        

Available options:
    color                       gdb_default_port            
    enable_bsl_access           gdb_loop                    
    enable_fuse_blow            gdbc_xfer_size              
    enable_locked_flash_access  iradix                      
    fet_block_size              quiet                       

Type "help <topic>" for more information.
Use the "opt" command ("help opt") to set options.
Press Ctrl+D to quit.

(mspdebug) 

Das Teil kann debuggen mit Breakpoints und steps, und kann wohl als 
GDB-Server arbeiten. Es bleiben wohl also nur die "weniger Drähte"....


> Damit gibt es auch für Gelegenheitsprogrammierer der MSP430 keinen Grund
> mehr, auf anständige Debugmöglichkeiten zu verzichten.
>
> Zwar gibt es Leute, die glauben, man könnte auch mit in den Code
> eingestreuten Testausgaben oder Pingewackel und Oszilloskopeinsatz
> "debuggen", aber das ist dann halt doch was anderes als die Möglichkeit,
> Breakpoints zu verwenden und im Single-Step-Betrieb dem Controller
> zuzusehen.

Ja. Allerdings ist das i.A. das letzte was ich ausprobiere um einen 
Fehler zu suchen. Meist nützt der Debugger eher weniger weil die 
eigentlichen Probleme z.B. Zeitprobleme sind, die sich im 
Einzelschrittmodus eher schlecht finden lassen.

Gruß,

Holm

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Das Teil kann debuggen mit Breakpoints und steps, und kann wohl als
> GDB-Server arbeiten.

Natürlich kann es das, dafür ist es schließlich da.


> Es bleiben wohl also nur die "weniger Drähte"....

Und der erheblich günstigere Preis für die Ez-Fet-Hardware (wie sie auf 
neueren Launchpads zu finden ist) als für die "vollwertigen" 
JTAG-Interfaces (MSP-FET430UIF bzw. das neue MSP-FET).

> aber ich habe das Ding als FreeBSD-Port installiert,

Das verwendet, so wie es aussieht, das alte Protokoll des 
MSP-FET430UIF und damit verwandter Geräte.

Das Ez-FET der neueren Launchpads sieht anders aus, aber TI hat den Kram 
erstmalig dokumentiert.

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Holm T. schrieb:
>> Das Teil kann debuggen mit Breakpoints und steps, und kann wohl als
>> GDB-Server arbeiten.
>
> Natürlich kann es das, dafür ist es schließlich da.
>
>
>> Es bleiben wohl also nur die "weniger Drähte"....

..genau 2 weniger um exakt zu sein.

>
> Und der erheblich günstigere Preis für die Ez-Fet-Hardware (wie sie auf
> neueren Launchpads zu finden ist) als für die "vollwertigen"
> JTAG-Interfaces (MSP-FET430UIF bzw. das neue MSP-FET).

Ja doch, ich hatte gefragt was "besser" ist wenn man dieses Ding bereits 
hat.
Ich habe auch noch ein Parallel-Port Dingens in der Werkstatt liegen,
und dort auch ein altes Notenbuch zum Zwecke ALL07-Controller zu 
spielen, damit geht das Selbe.
>
>> aber ich habe das Ding als FreeBSD-Port installiert,
>
> Das verwendet, so wie es aussieht, das alte Protokoll des
> MSP-FET430UIF und damit verwandter Geräte.

Mhh? "Using new (SLAC460L+) API"
(http://processors.wiki.ti.com/index.php/MSPDS_Open...)

> Das Ez-FET der neueren Launchpads sieht anders aus, aber TI hat den Kram
> erstmalig dokumentiert.

Tue doch nicht ständig so als ob ich die Launchpads nicht kennen 
würde...


TI wird wohl gemerkt haben das sie jahrelang Irgendwas falsch gemacht 
haben.

Gruß,

Holm

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> TI wird wohl gemerkt haben das sie jahrelang Irgendwas falsch gemacht
> haben.

Ja, die Hardware, die sie verbauten, wurde ihnen einfach zu teuer. Der 
'F1611 und der TI3410 kosten mehr als ein komplettes G2-Launchpad.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Holm T. schrieb:
>> TI wird wohl gemerkt haben das sie jahrelang Irgendwas falsch gemacht
>> haben.
>
> Ja, die Hardware, die sie verbauten, wurde ihnen einfach zu teuer. Der
> 'F1611 und der TI3410 kosten mehr als ein komplettes G2-Launchpad.

....werden so gehandelt..nicht kosten. Die Launchpads sind 
Promotion-Packs,
TI versucht damit Entwickler zu locken. Mit der finalen Preisbildung 
haben die aber so gar nichts zu tun.

BTW:
The MSP debug stack (MSPDS) for all MSP430™ microcontrollers (MCUs) and SimpleLink™ MSP432™ devices consists of a static library on the host system side as well as an embedded firmware that runs on debug tools including the MSP-FET, MSP-FET430UIF or on-board eZ debuggers. It is the bridging element between all PC software and all MSP430 and SimpleLink MSP432 microcontroller derivatives and handles tasks such as code download, stepping through code or break points. The MSP Debug Stack is used in integrated development environments such as Code Composer Studio™ (CCS), IAR's Embedded Workbench or tools like Smart RF Studio and Elprotronic's FlashPro430.

Diese "DLL" (/usr/local/lib/libmsp430.so) ist so wie es aussieht ein 
standardisiertes Interface zum Zugriff auf alle möglichen Programmer, 
auch auf den Kram der auf den Launchpads wohnt. Ich halte das auch für 
sehr vernünftig und es ist als Opensource verfügbar.
Die geben also das mit dazu was unser Jörg hier seit Jahren mit avrdude 
tut.

Gruß,
Holm

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Die geben also das mit dazu was unser Jörg hier seit Jahren mit avrdude
> tut.

Atmel gibt ja auch closed-source Kommandozeilentools mit bei, aber eben 
Windows-only. Der wesentliche Vorteil von avrdude demgegenüber außer 
Opensource und Mulitplattform ist „einer für alles“, also nicht für 
jeden Adapter ein eigenes Tool. Ich weiß aber, dass Atmel weiß, dass 
auch mancher ihrer Kunden das bevorzugt. Dadurch spendiert man mir immer 
mal Muster, damit ich ihre Kunden auch weiterhin bedienen kann. ;-)

Das MSP430-FET war dazumals übrigens das einzige USB-Gerät, welches mir 
jemals untergekommen ist, mit dem man nicht in einer Windows-VM 
arbeiten kann. Sollte unter IAR laufen (das wollte $KUNDE damals so), 
rannte in Timeouts. IAR meinte, es würde an der TI-DLL liegen, auf die 
auch sie zurückgreifen. Besonders krass: das billige Launchpad mit 
seinem HID-Interface konnte man hingegen problemlos sowohl auf dem 
Linux-Host als auch in der Windows-VM nutzen (auch abgekoppelt mit 
Fremd-Target), nur das teure FET ging nicht. :/

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Das MSP430-FET war dazumals übrigens das einzige USB-Gerät, welches mir
> jemals untergekommen ist, mit dem man nicht in einer Windows-VM arbeiten
> kann.

Da habe ich andere Erfahrungen gemacht.

Ich habe das zuletzt mit einer unter ESXi 6.0 laufenden VM mit Windows 
XP und IAR genutzt.

Die USB-Redirektion lief dabei über einen vSphere-Client, der wiederum 
auf einem Rechner mit Windows 8.1 lief.

Das funktionierte problemlos.

Was ich nicht ausprobiert hatte, war die Nutzung des USB-Ports des 
ESXi-Hosts, und auch einen dedizierten USB-Deviceserver von Silex habe 
ich in dieser Konstellation nicht getestet (den verwende ich für andere 
Dinge mit einer anderen VM, die auf dem gleichen ESXi-Host läuft).

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Holm T. schrieb:
>> Die geben also das mit dazu was unser Jörg hier seit Jahren mit avrdude
>> tut.
>
> Atmel gibt ja auch closed-source Kommandozeilentools mit bei, aber eben
> Windows-only. Der wesentliche Vorteil von avrdude demgegenüber außer
> Opensource und Mulitplattform ist „einer für alles“, also nicht für
> jeden Adapter ein eigenes Tool. Ich weiß aber, dass Atmel weiß, dass
> auch mancher ihrer Kunden das bevorzugt. Dadurch spendiert man mir immer
> mal Muster, damit ich ihre Kunden auch weiterhin bedienen kann. ;-)

Ich kann sowieso nicht nachvollziehen warum Hersteller unbedingt 
verheimlichen müssen wie man ihren Kack von Gestern heute nun gerade 
programmiert.
Das fing mit Eproms über PALs an und hört bei Controllern noch lange 
nicht auf. Ich halte es eigentlich für sinnvoll das denen die Kunden 
weglaufen.

>
> Das MSP430-FET war dazumals übrigens das einzige USB-Gerät, welches mir
> jemals untergekommen ist, mit dem man nicht in einer Windows-VM
> arbeiten kann. Sollte unter IAR laufen (das wollte $KUNDE damals so),
> rannte in Timeouts. IAR meinte, es würde an der TI-DLL liegen, auf die
> auch sie zurückgreifen. Besonders krass: das billige Launchpad mit
> seinem HID-Interface konnte man hingegen problemlos sowohl auf dem
> Linux-Host als auch in der Windows-VM nutzen (auch abgekoppelt mit
> Fremd-Target), nur das teure FET ging nicht. :/

Soweit ich mich erinnern kann hat auch dieser mspdebug die Firmware 
meines FET aktualisiert, das muß also nicht zwangsläufig heute noch so 
sein. (man weiß ja nicht was die da treiben)

Ich habe das mit einer VM nie probiert, erstens geht das USB Zeug von 
FreeBSD gegenüber diversen Linuxen eher bescheiden und zweitens ist der 
Leidensdruck unter Windows programmieren zu wollen für mich 
vergleichsweise gering, ich probiere das wenn ich muß... aber auch nur 
dann.

Gruß,
Holm

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
[..]
>
> Die USB-Redirektion lief dabei über einen vSphere-Client, der wiederum
> auf einem Rechner mit Windows 8.1 lief.
[..]

--läuft das auch auf einer Dyson Sphere?

SCNR,

Holm

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> --läuft das auch auf einer Dyson Sphere?

Eklige Vorstellung, wie? Windows 8.1 war wirklich hassenswert.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Da habe ich andere Erfahrungen gemacht.

War auch bislang meine einzige negative in dieser Richtung, soweit es 
VMware betrifft.  (Virtualbox ist da viel schlechter.)  War hier aber 
ein VMware Workstation, also angedachte Nutzung des Host-USB-Ports. 
Geht sonst mit allem, selbst Firmwareupgrades der Atmel-ICEs (deren 
Pendant zum FET) klappen.

Kann natürlich sein, dass TI das inzwischen auch repariert hat, ist 
schon paar Jahre her. Da der Weg über das Launchpad dann brauchbar 
funktioniert hatte, gab's auch keinen großen Leidensdruck, bei TI was zu 
reklamieren. (Bei Nutzung aus einer VM gehen entsprechende 
Support-Tickets in der Regel sowieso so aus, dass es dann heißt "nicht 
supportet".)  Am Ende wollte der Kunde uns dann doch nicht haben, damit 
hatte sich der MSP für uns auch erstmal erledigt.

Holm T. schrieb:
> Ich habe das mit einer VM nie probiert, erstens geht das USB Zeug von
> FreeBSD gegenüber diversen Linuxen eher bescheiden und zweitens ist der
> Leidensdruck unter Windows programmieren zu wollen für mich
> vergleichsweise gering,

Wenn $KUNDE partout IAR haben will, dann muss man es ja zumindest auch 
mal damit compilieren und testen. Primär hatte ich für die Entwicklung 
den GCC auf dem Linux-Host benutzt.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Lagebericht,

Mache außer mit ADC gute Fortschritte. Im Augenblick nervt mich dieses 
Subsystem. Aber das kriege ich schon noch hin. Soweit funktioniert alles 
andere wie es soll in meiner Portierung eines meiner Entwicklungshilfen.

Ein Manko hat das Teil aber: Es fehlt im Gegensatz zum STM32 ein 
seperater VBat Pin um die RTC unabhängig zu versorgen. In der L.P. Ist 
das ungünstig implementiert. Da bin ich besser dran dann eine externe 
RTC Bord über I2C zu betreiben. Die RTC im MSP ist nur dann benutzbar 
wenn die Versorgung nie abgeschaltet wird und die App die Schlafmodii 
entsprechend ausnützt. Aber das ist andrerseits nicht so schlimm. Nur 
etwas unbequem für meine Absichten. Für das Firmenprojekt sowieso nicht 
zutreffend.

Jedenfalls macht es mir Spaß den MSP kennenzulernen.

Schnes Wochenende noch,
Gerhard

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Die RTC im MSP ist nur dann benutzbar wenn die Versorgung nie
> abgeschaltet wird und die App die Schlafmodii entsprechend ausnützt.

Das ist doch für einen Controller dieser Klasse völlig normal. Würde man 
bspw. bei AVR genauso machen, die Leckströme im Schlaf sind (anders als 
bei den ARMs mit viel geringeren Strukturbreiten) sowieso 
vernachlässigbar. Da braucht dann nur der 32-kHz-Oszillator etwas Strom, 
aber das hast du bei einer externen RTC ja genauso.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe das auch nicht so kritisch, wie schon mal erzählt hatte ich bei 
einer Anwendung mit dem G2553 in LPM3 also mit RC Oszillator 800nA 
Betriebsstrom und habe angesichts dieser Tatsache dann auf einen 
Einschalter verzichtet. Das war freilich keine RTC, allerdings schätze 
ich den Stromverbrauch ähnlich gering ein. Man hat mehr damit zu tun 
aufzupassen welchen Ruhepegel Ports haben..so daß da keine Ströme 
rausfließen...

@J: klar doch, das war auch keine Kritik, sollte nur erklären warum ich 
VMs damit nicht ausprobiert habe. Mir ist ja selbst die 
Entwicklungsumgebung von TI mit Eclipse zu viel Streß..auch native.

@Gerhard: suche bei forum.43oh.com nach Deinem ADC Problem.

Gruß,

Holm

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holm T. schrieb:
> @J: klar doch, das war auch keine Kritik, sollte nur erklären warum ich
> VMs damit nicht ausprobiert habe.

Und ich habe nur erklärt, warum ich mir den Käse antun musste. War auch 
nicht freiwillig. ;-)

IAR ist gewiss ein guter Compiler, und im Vergleich zum damaligen 
Gebastel mit dem MSP-GCC kann ich ja sogar den Kunden verstehen, aber 
dass sie es nichtmal schaffen, wenigstens eine Kommandozeilenversion 
ihres Compilers als Linux-Binary zu liefern, ist einfach nur lästig. Das 
kann eigentlich nicht so schwer sein, ein Compiler verarbeitet Dateien 
und rechnet ein bisschen, da gibt's ja nichts dabei, was OS-abhängig 
wäre. (Dass sie keine Lust haben, ihre IDE zu portieren, ist natürlich 
verständlich, aber Vendor-IDEs nehme ich sowieso so gut wie nie.)

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> @Gerhard: suche bei forum.43oh.com nach Deinem ADC Problem.

Hallo Holm,

Danke. Werde ich machen.

Mein Abenteuer mit MSP430 geht weiter.

So schlimm finde ich die Windows Eclipse Umgebung nicht. Aber ich habe 
da keine so hohen Ansprüche. Manchmal treibt mich auch Eclipse fast zum 
Wahnsinn wenn es irgendwas macht was man nicht erwartet und sich die 
Umgebung durch irgendeine Fehlbedienung verändert und dann nicht gleich 
mitbekommt wie das passiert ist und wie man den alten Zustand wieder 
herstellen kann.

Was mich noch interessiert, das IDE hat eine Reihe von Options wo man 
andauernd Kommentare was man besser Für Power Savings machen könnte. Ich 
habe das zur Zeit abgeschaltet weil ich im Augenblick nicht daran 
interessiert bin. Was ist davon zu halten? Zu Herzen nehmen wenn man es 
tatsächlich braucht und sonst aber abschalten?

Die Probleme mit der ADC haben möglicherweise irgendwie was mit dem 
Clock System oder Interrupts zu tun. Wenn ich den ADC Code aktiviere, 
friert das ganze Program sobald ich GIE mache, ein und der Debugger gibt 
mir eine Meldung, daß er mit dem CPU nicht mehr kommunizieren könne. 
Interessantes Problem. Sobald ich den ADC nicht mehr initialisiere läuft 
wieder alles einwandfrei. Naja, solche Sachen regen mich nicht wirklich 
auf. Werde bestimmt irgendwie Mist gebaut haben. Ich möchte mir 
allerdings lieber selber den Gebrauch der Peripherien erarbeiten anstatt 
mir alles von der Driverlib machen lassen. Man lernt doch viel mehr wenn 
man mit den Dokus direkt arbeitet. Jetzt fange ich sogar noch zum 
träumen mit MSP Zeugs an. Es ist schlimm:-)

Naja, es ist ein interessantes Teil. Ich glaube es lohnt sich schon 
diesen Typ zu kennen. Man kann wirklich tolle Batterie betriebene Sachen 
damit auf die Beine stellen. Sicher mit PIC und Co. geht das auch. Ich 
sah von Microchip einen interessanten Vergleich zwischen PIC24 und MSP. 
Trotz teilweise etwas günstigerer Werten in einigen Bereichen bin ich da 
nicht so sicher ob der MSP in der Praxis vielleicht nicht doch besser 
abschneidet.

Ich experimentierte auch ein bischen mit höheren DCO Frequenzen und muss 
sagen für was ich jetzt gerade brauche, reichen 1Mhz dicke aus.

Weitere Berichte folgen...

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

hier schreibst Du:

Gerhard O. schrieb:
> Ein Manko hat das Teil aber: Es fehlt im Gegensatz zum STM32 ein
> seperater VBat Pin um die RTC unabhängig zu versorgen. In der L.P. Ist
> das ungünstig implementiert. Da bin ich besser dran dann eine externe
> RTC Bord über I2C zu betreiben. Die RTC im MSP ist nur dann benutzbar
> wenn die Versorgung nie abgeschaltet wird und die App die Schlafmodii
> entsprechend ausnützt.

und im Datenblatt hast Du doch sicher auch gesehen:

• Optimized Ultra-Low-Power Modes
– Active Mode: 118 µA/MHz
– Standby With VLO (LPM3): 500 nA
– Standby With Real-Time Clock (RTC) (LPM3.5): 350 nA (1)
– Shutdown (LPM4.5): 45 nA

Wo ist da jetzt das Problem? Sind die 350nA das Problem?

Dann noch zum ADC: Wo ist hier das Problem?

Ich habe mich gerade für einen anderen Typen entschieden und erwarte in 
den nächsten Tagen das Demoboard. Wir können uns dann sicher noch weiter 
austausschen...

Happy coding!

Bernd

PS @all: Free shipping und Rabatt bis Sonntag!

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bernd B. schrieb:
> Hallo Gerhard,
>
> hier schreibst Du:
>
> Gerhard O. schrieb:
>> Ein Manko hat das Teil aber: Es fehlt im Gegensatz zum STM32 ein
>> seperater VBat Pin um die RTC unabhängig zu versorgen. In der L.P. Ist
>> das ungünstig implementiert. Da bin ich besser dran dann eine externe
>> RTC Bord über I2C zu betreiben. Die RTC im MSP ist nur dann benutzbar
>> wenn die Versorgung nie abgeschaltet wird und die App die Schlafmodii
>> entsprechend ausnützt.
>
> und im Datenblatt hast Du doch sicher auch gesehen:
>
> • Optimized Ultra-Low-Power Modes
> – Active Mode: 118 µA/MHz
> – Standby With VLO (LPM3): 500 nA
> – Standby With Real-Time Clock (RTC) (LPM3.5): 350 nA (1)
> – Shutdown (LPM4.5): 45 nA
>
> Wo ist da jetzt das Problem? Sind die 350nA das Problem?
Das ist mir schon klar; nur während der Entwicklung geht die RTC 
Einstellung jedesmal beim Debug Laden oder wieder Einschalten flöten. 
Beim STM32 läuft die RTC wegen des extra Vbat auch bei der Entwicklung 
unaufgehalten durch. Bin eben verwöhnt. Und bei I2C RTCs ist es ähnlich.
>
> Dann noch zum ADC: Wo ist hier das Problem?
Naja, das ist noch so eine Sache. Der ADC funktioniert im Debugger und 
ich bekomme auch gute Werte. Aber die ISR ruft sich unnunterbrochen 
selber andauernd auf und blockiert das gesammte Programm und alle 
anderen Timer Interrupts. Auch wenn die DOKU sagt, daß beim Lesen des 
Interrupt Registers das IFG rückgesetzt wird. Da muß ich noch ansetzen. 
Das läßt sich im Debugger schön demonstrieren. Allerdings versuche ich 
das ganze Program im AM Modus laufen lassen. Wenn ich LPM verwende 
funktioniert das Programm. Bin halt noch zu unerfahren mit dem MSP...

Dann habe ich noch das etwas ärgerliche Problem, daß der Debugger mir 
Macken macht. Debuggen geht nur wenn ich nach Laden des Debug Codes 
einen Hard Reset mache und dann einen Soft Reset. Sonst verliert der 
Debugger Kontrolle und es gibt eine Debugger Fehler Meldung. Am Anfang 
hat er das nicht gemacht. Er verhält sich auch mit allen enderen Sourcen 
so. Irgendwie habe ich unabsichtlich einen Fehler in den Einstellungen 
gemacht. Habe aber bis jetzt den Einstellfehler noch nicht gefunden. 
Aber die letzten paar Tage hatte ich sowieso keine Zeit mich mit dem 
Teil zu beschäftigen.
>
> Ich habe mich gerade für einen anderen Typen entschieden und erwarte in
> den nächsten Tagen das Demoboard. Wir können uns dann sicher noch weiter
> austausschen...
Toll! Welche Bord erwartest Du denn? Auch eine mit FRAM Controller?

Grüße,
Gerhard
>
> Happy coding!
>
> Bernd
>
> PS @all: Free shipping und Rabatt bis Sonntag!

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
>> Wo ist da jetzt das Problem? Sind die 350nA das Problem?
> Das ist mir schon klar; nur während der Entwicklung geht die RTC
> Einstellung jedesmal beim Debug Laden oder wieder Einschalten flöten.
> Beim STM32 läuft die RTC wegen des extra Vbat auch bei der Entwicklung
> unaufgehalten durch. Bin eben verwöhnt. Und bei I2C RTCs ist es ähnlich.

Hallo Gerhard,

in meiner Entwicklungsumgebung kann ich während der Assemblierung (mit 
IAR) die aktuelle Uhrzeit und das aktuelle Datum in den Code als 
Konstante setzen. Diesen Zeitstempel benutze ich auch für die 
Versionskontrolle. Beim Initialisieren kann man dann mittels dieser 
Daten die Uhrzeit und Datum übernehmen. Du könntest Dir auch noch einen 
Mechanismus programmieren, der nachsieht, ob die RTC irgendwann einmal 
abgeschaltet wurde, z.B. bei einem zweiten oder weiterem Anlauf des 
Programms. Da Du ja FRAM beliebig beschreiben kannst, gehen auch ohne 
Stützbatterie Einstellungen nicht verloren. Gut alternativ geht 
natürlich auch eine CR2032.

Gerhard O. schrieb:
> Dann habe ich noch das etwas ärgerliche Problem, daß der Debugger mir
> Macken macht.

Okay, das könnte mit Deiner Umgebung zusammenhängen. Ich verfolge eher 
den Weg, genau das zu verwenden, was der Hersteller empfiehlt. Dafür 
sucht er auch für mich die Fehler beim Ablauf und der Verwendung. Ich 
konzentriere mich eher auf die Aufgabenstellung und weniger, ob ich 
irgendwelche OpenSource-Bibliotheken dazuladen kann. Im Augenblick 
befinden sich meine Bauteile noch in Fort Worth, aber direkt auf dem Weg 
zu mir. Sofern die Bauteile vor Freitag eintreffen, hätte ich eine 
Chance das mit dem neuen Board und IAR hier zu prüfen. Ab Freitag bin 
ich dann erst einmal in einem anderen Projekt und könnte "nur" lesen, 
nicht testen.

Mit dem Debuggen ist es auch so eine Sache: Sofern der Debugger aus 
bestimmten Registern die Werte ausliest, die nach dem Lesen neu gesetzt 
werden (bei meinen Applikationen bislang im Timer-Register für 
Verzweigungen - ACHTUNG: KEIN SEBLSTMODIFIZIERENDER CODE !!!) sind die 
Inhalte dann gelesen und das Programm reagiert dann mit der Fortsetzung 
des Codes nach den neuen Registerinhalten.

Es würde mich nicht wundern, wenn man das bei anderen Registern oder DMA 
oder so in den modernen Derivaten ebenfalls vorfindet. Aber wenn, dann 
finden wir das. Ausserdem steht das alles sauber beschrieben. Ich habe 
so manche "Entdeckung" anschließend in der Doku gefunden. ... wenn man - 
also ich - nur richtig lesen würde.

Auch wenn mehrfach unterstellt, selbstmodifizierenden Code machen wir 
nicht, aber ein guter Code ist für mich immer ein kleines Kunstwerk. Und 
das klappt bei diesem Prozessor ganz super.

Ich bin auch einmal gespannt, wie die 24MHz abzischen werden.

Happy coding!

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bernd B. schrieb:
> Gerhard O. schrieb:
>>> Wo ist da jetzt das Problem? Sind die 350nA das Problem?
>> Das ist mir schon klar; nur während der Entwicklung geht die RTC
>> Einstellung jedesmal beim Debug Laden oder wieder Einschalten flöten.
>> Beim STM32 läuft die RTC wegen des extra Vbat auch bei der Entwicklung
>> unaufgehalten durch. Bin eben verwöhnt. Und bei I2C RTCs ist es ähnlich.
>
> Hallo Gerhard,
>
> in meiner Entwicklungsumgebung kann ich während der Assemblierung (mit
> IAR) die aktuelle Uhrzeit und das aktuelle Datum in den Code als
> Konstante setzen. Diesen Zeitstempel benutze ich auch für die
> Versionskontrolle. Beim Initialisieren kann man dann mittels dieser
> Daten die Uhrzeit und Datum übernehmen. Du könntest Dir auch noch einen
> Mechanismus programmieren, der nachsieht, ob die RTC irgendwann einmal
> abgeschaltet wurde, z.B. bei einem zweiten oder weiterem Anlauf des
> Programms. Da Du ja FRAM beliebig beschreiben kannst, gehen auch ohne
> Stützbatterie Einstellungen nicht verloren. Gut alternativ geht
> natürlich auch eine CR2032.
Das wäre ein Gedanke. Das einzige Problem ist, dass der Compiler das 
Datum etwas unpraktisch ausgibt, z.B. Oct  9 2018 anstatt 18/10/09. Aber 
damit könnte man während der Entwicklung leben. Aber wie gesagt, wenn 
man mit LPM programmiert ist das kein Thema.
>
> Gerhard O. schrieb:
>> Dann habe ich noch das etwas ärgerliche Problem, daß der Debugger mir
>> Macken macht.
>
> Okay, das könnte mit Deiner Umgebung zusammenhängen. Ich verfolge eher
> den Weg, genau das zu verwenden, was der Hersteller empfiehlt. Dafür
> sucht er auch für mich die Fehler beim Ablauf und der Verwendung. Ich
> konzentriere mich eher auf die Aufgabenstellung und weniger, ob ich
> irgendwelche OpenSource-Bibliotheken dazuladen kann. Im Augenblick
> befinden sich meine Bauteile noch in Fort Worth, aber direkt auf dem Weg
> zu mir. Sofern die Bauteile vor Freitag eintreffen, hätte ich eine
> Chance das mit dem neuen Board und IAR hier zu prüfen. Ab Freitag bin
> ich dann erst einmal in einem anderen Projekt und könnte "nur" lesen,
> nicht testen.
Ich habe mein Projekt mit einer neuere Installation von CCS8 auf einem 
anderen PC getestet und habe das gleiche Problem. Die Einstellungen des 
Debuggers hatte ich nicht verändert. Im Augenblick muss ich nach Laden 
des Debug Programms immer explizit einen HARD RESET und SOFT RESET 
machen, sonst kriege ich das präsentiert: (MSP430: Can't Single Step 
Target Program: Could not single step device). Danach funktioniert 
Debuggen einwandfrei. Die FW des Debuggers traute ich mich noch nicht zu 
erneuern. Wenn ich das Elpotronic Flash Programm verwende sagt mir die 
Utility dass meine JTAG Version 1.00... wäre und will mir V3 
unterjubeln. Im gleichen Atemzug erklärt mir aber die Software, dass ein 
FW Upgrade aber das JTAG bricken könnte und ratet mir davon ab. Trau, 
schau, wem...

Naja, vieles Neue ist manchmal wunderlich...
>
Welche Bord hast Du Dir bestellt? Hast Du einen spezifischen Grund CCS 
zu vermeiden? An sich mag ich IAR - Ich arbeite in der Firma mit IAR für 
ARM. Aber für zu hause scheint mir CCS8 die bessere Wahl zu sein... Die 
IAR Version dürfte auch begrenzt sein.
> Mit dem Debuggen ist es auch so eine Sache: Sofern der Debugger aus
> bestimmten Registern die Werte ausliest, die nach dem Lesen neu gesetzt
> werden (bei meinen Applikationen bislang im Timer-Register für
> Verzweigungen - ACHTUNG: KEIN SEBLSTMODIFIZIERENDER CODE !!!) sind die
> Inhalte dann gelesen und das Programm reagiert dann mit der Fortsetzung
> des Codes nach den neuen Registerinhalten.
>
> Es würde mich nicht wundern, wenn man das bei anderen Registern oder DMA
> oder so in den modernen Derivaten ebenfalls vorfindet. Aber wenn, dann
> finden wir das. Ausserdem steht das alles sauber beschrieben. Ich habe
> so manche "Entdeckung" anschließend in der Doku gefunden. ... wenn man -
> also ich - nur richtig lesen würde.
Ja, das kenne ich auch;-)
NAja, das Problem mit dem ADC wird sich schon erklären lassen. Muss mich 
halt in die Doku mehr rein knien. Es ist bloß lustig, was bei allen 
anderen uC immer funktioniert hat, macht hier Zicken wenn man im AM 
Modus verbleiben will. Der Interrupt ADC Betrieb funktioniert im LPM 
Modus einwandfrei. Nur im AM Modus ruft er sich immer selber wieder auf 
und blockiert alles andere. Warum das so ist, kann ich noch nicht 
nachvollziehen. Aber es wird sich bestimmt bald herausstellen. Habe nur 
recht wenig Zeit dabei zu bleiben. Die ganzen Unterbrechungen sind auch 
nicht gerade förderlich.
>
> Auch wenn mehrfach unterstellt, selbstmodifizierenden Code machen wir
> nicht, aber ein guter Code ist für mich immer ein kleines Kunstwerk. Und
> das klappt bei diesem Prozessor ganz super.
An selbstmodifizerenden Code habe ich mich nie ran getraut. Ich dachte 
auch, dass das bei uC sowieso sehr unüblich wäre und möglich. Das ist 
eine andere Liga.
>
> Ich bin auch einmal gespannt, wie die 24MHz abzischen werden.
Auf was bezieht sich das? Den MSP430 overclocken? Lohnt sich das denn?

Schönen Tag noch,
Gerhard
>
> Happy coding!
>
> Bernd

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gerhard,

mein Board hat jetzt FedEx in Fort Worth verlassen und wartet wohl auf 
den Linienflieger. Ich habe mir den FR2355 bestellt und gleich ein paar 
von den IC für einen späteren Musteraufbau. Das soll einmal ein 
Meßsystem werden. Mit dem FR2355 bekommt man gleich die entsprechenden 
Vorverstärker und Eingangsbeschaltung für den ADC mit und spart die 
Teile auf der späteren Leiterplatte.

Also, ich hatte weiter oben im Thread einmal geschrieben, dass ich in 
ASM programmiere. Damit habe ich keine Codebegrenzung, die früher einmal 
bei 8k oder so lag. Mit meinem Code und mit den automatisch erstellten 
Listings sehe ich jede Bewegung des Prozessors. Ich habe z.B. 
Interrupt-Routinen nach der Erstellung angesehen und bemerkt, dass jede 
"if ... then ... else" je nach Entscheidung unterschiedliche Codelängen 
besitzt. (Dies ist nicht auf die ISR begrenzt, sondern immer so. Ich 
hatte nur eine Aufgabe mit ISR zu erfüllen, da mein Derivat keine UART 
hatte. Dabei ist mir das aufgefallen.) Das taucht auch manchmal bei 
Verzweigungen über Index-Tabellen in ISR-Routinen auf und steht auch im 
Family Guide. Sonst merkt man das eigentlich nicht. Bevor jemand genauer 
nachgefragt oder zugehört hatte, wurde mir oben mehrfach unterstellt, 
ich würde selbstmodifizierenden Code schreiben. Na ja, so sind sie. Das 
bedeutet, der Prozessor schreibt sich selbst den OP-Code für die 
nächsten Anweisungen. Früher hat man vielleicht vereinzelt so etwas 
gemacht, das war aber nicht empfehlendswert. Dazu müsste der Code auch 
ins RAM, da er ja zunächst erstellt und dann abgearbeitet wird. Im Flash 
geht das sowieso nicht so, da müsste man wieder einzelne Zellen Flashen 
und das geht auch nicht. Ausgenommen der kleine Speicherbereich mit den 
256 Byte oder so. In dem Bereich stehen die Kalibrierwerte für die 
Taktrate der CPU, wenn man ohne Quarz arbeitet. Man kann aber auch 
Unterprogramme an ein aufzurufenden Unterprogramm per Pointer übergeben, 
auch gleich mit Parametern. Das war damals in dem von mir verwendeten 
Pascal-Dialekt möglich. Damit bleibt der Code lesbar. Heute wird das mit 
Vererbung usw. in den objektorientierten Sprachen gemacht. Dann kann man 
aus den vererbten Unterprogrammen wieder welche herausnehmen, die einem 
dann nicht genehm sind und überschreiben. Aber das ist ein weites Feld, 
und Informatik ist nicht zu unterschätzen, was alles so geht. Wenn man 
das Prinzip einmal verstanden hat, kann man das auch in Assembler 
umsetzen. - Ich höre schon die Experten, die mir Beispiele aufzählen, 
warum das in Assembler nicht geht. - Egal!

Nein, die 24MHz sind keine Übertaktung, das ist obere Kante laut 
Datenblatt.
"
24MHz 105C ULP Microcontroller With 32 KB FRAM, 4 KB SRAM, 44 IO, 12-bit 
ADC, 12-bit DACs, OpAmp/PGA
"
So ganz habe ich noch nicht verstanden, was bei Dir mit dem ADC nicht 
klappt. Lass uns abwarten, bis ich die Teile bei mir in der Hand halte, 
evtl. IAR (für ASM) auf einem neuen Rechner installiert habe und das 
Demoprogramm ausprobieren kann. Dann finden wir bestimmt auch den Grund 
für die Reset-Bedingungen.

Im Augenblick weiß ich noch gar nicht, was ich mit den vielen 
I/O-Leitungen machen soll, [Scherz] vielleicht eine 
Geräteinnenbeleuchtung mit Lauflicht? [/Scherz]

Falls Du ebenfalls "zuviele" Leitungen ungenutzt hast, überlege, ob Du 
den klassischen Debug-Adapter-Anschluss auf Deine Leiterplatte mit drauf 
layoutest. Das ist mehr als die beiden Leitungen für SpyBiWire. Sieh 
einmal bei Dir im Datenblatt zum Prozessor nach. Du brauchst den 
Anschluss wahrscheinlich nicht, aber wenn dann doch, dann hast Du alle 
Möglichkeiten.

So, Review von Deinem Text:
Kannst Du das Datum vom Compiler nicht formatieren? Meist bieten die 
Entwicklungsumgebungen so etwas. Dazu gibt es die Metasprache bei den 
Compilern, die Direktiven.

Nochmals zum Reset beim Start: Kannst Du in der Entwicklungsumgebung 
nicht etwas in den sog. Options beim Start anklicken. Es sieht mir nach 
"Synchronisation" zum Quelltext aus.

Firmware Update: So ein Update habe ich auch schon einmal auf einem 
EVA-Board gemacht. Hast Du nur ein Board? Fehler!!! Ich bestelle immer 
mindesten 3 Boards (klar fragen die manchmal, ist für Ausbildung) Ein 
Board kostet weniger, als ich in 10 Minuten Arbeitszeit verbrate. 
Außerdem kann ich dann immer noch restliche Boards an Studenten 
verschenken, wg. Ausbildung und so.

Also, bei mir hat das Update in der IAR-Umgebung funktioniert. Einmal 
musste ich aber, wenn ich mich richtig erinnere, nach dem Update noch 
ein Hardware Update machen, irgendwas umlöten. Jetzt fällt mir wieder 
ein: Das Debug-Interface für LPT-Port (früher, ganz ganz früher und das 
Interface für USB hatte ich geabdated, auch einmal für die SpyBiWire). 
Das hat aber bei IAR immer ohne mucken funktioniert. Die helfen auch bei 
Problemen, die sie als Probleme erkennen. Bei "nicht lesen" helfen die 
nicht viel. - Meine persönliche Erfahrung.

So, [Scherz] das ist wieder ein teurer Text [/Scherz].

Weiterhin happy coding!

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Hallo Gerhard,
>
> mein Board hat jetzt FedEx in Fort Worth verlassen und wartet wohl auf
> den Linienflieger.

Hallo Bernd,

ich kann Deine Fragen erst heute Abend beantworten - Bin mächtig 
eingespannt.

Danke für die Infos zur Board. Ist das ein:

MSP430FR2355 LaunchPad™ Development Kit
(MSP‑EXP430FR2355)

Gruß,
Gerhard

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja!

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Ja!

Der 2355 ist ja ganz nett. Man müsste sich fast einen DIP40 auf TSSOP38 
oder QLPF-48 Adapter machen.

Ich habe gerade mit CCS8 die JTAG FW neu aufgespielt und jetzt 
funktioniert das Debuggen ohne vorherige RESETs wieder einwandfrei. Die 
Versionen waren interessanterweise dieselben. Möchte wissen welcher 
Geist das arme Ding geritten hatte. Die Debugger Einstellungen waren 
dieselben wie zu Hause. Das komische ist, am Anfang hatte das Debuggen 
auch geklappt. Die RESET Sache ist erst spaeter aufgetreten. Habe aber 
keine Ahnung ob ich der ehrliche Verursacher einer Falscheinstellung war 
oder ein Bug dafür verantwortlich ist. Jedenfalls hat es nichts mit dem 
Source Code zu tun. Mit anderen Demo Programmen machte er das auch. Mal 
sehen wie es heute Abend weitergehen wird.

Bis spaeter,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bernd B. schrieb:
> Hallo Gerhard,
>
> mein Board hat jetzt FedEx in Fort Worth verlassen und wartet wohl auf
> den Linienflieger. Ich habe mir den FR2355 bestellt und gleich ein paar
> von den IC für einen späteren Musteraufbau. Das soll einmal ein
> Meßsystem werden. Mit dem FR2355 bekommt man gleich die entsprechenden
> Vorverstärker und Eingangsbeschaltung für den ADC mit und spart die
> Teile auf der späteren Leiterplatte.
Ich habe mir das datasheet angesehen. Recht reich ausgestattes Teil.
>
> Also, ich hatte weiter oben im Thread einmal geschrieben, dass ich in
> ASM programmiere. Damit habe ich keine Codebegrenzung, die früher einmal
> bei 8k oder so lag. Mit meinem Code und mit den automatisch erstellten
> Listings sehe ich jede Bewegung des Prozessors. Ich habe z.B.
> Interrupt-Routinen nach der Erstellung angesehen und bemerkt, dass jede
> "if ... then ... else" je nach Entscheidung unterschiedliche Codelängen
> besitzt. (Dies ist nicht auf die ISR begrenzt, sondern immer so. Ich
> hatte nur eine Aufgabe mit ISR zu erfüllen, da mein Derivat keine UART
> hatte. Dabei ist mir das aufgefallen.) Das taucht auch manchmal bei
> Verzweigungen über Index-Tabellen in ISR-Routinen auf und steht auch im
> Family Guide. Sonst merkt man das eigentlich nicht. Bevor jemand genauer
> nachgefragt oder zugehört hatte, wurde mir oben mehrfach unterstellt,
> ich würde selbstmodifizierenden Code schreiben. Na ja, so sind sie. Das
> bedeutet, der Prozessor schreibt sich selbst den OP-Code für die
> nächsten Anweisungen. Früher hat man vielleicht vereinzelt so etwas
> gemacht, das war aber nicht empfehlendswert. Dazu müsste der Code auch
> ins RAM, da er ja zunächst erstellt und dann abgearbeitet wird. Im Flash
> geht das sowieso nicht so, da müsste man wieder einzelne Zellen Flashen
> und das geht auch nicht. Ausgenommen der kleine Speicherbereich mit den
> 256 Byte oder so. In dem Bereich stehen die Kalibrierwerte für die
> Taktrate der CPU, wenn man ohne Quarz arbeitet. Man kann aber auch
> Unterprogramme an ein aufzurufenden Unterprogramm per Pointer übergeben,
> auch gleich mit Parametern. Das war damals in dem von mir verwendeten
> Pascal-Dialekt möglich. Damit bleibt der Code lesbar. Heute wird das mit
> Vererbung usw. in den objektorientierten Sprachen gemacht. Dann kann man
> aus den vererbten Unterprogrammen wieder welche herausnehmen, die einem
> dann nicht genehm sind und überschreiben. Aber das ist ein weites Feld,
> und Informatik ist nicht zu unterschätzen, was alles so geht. Wenn man
> das Prinzip einmal verstanden hat, kann man das auch in Assembler
> umsetzen. - Ich höre schon die Experten, die mir Beispiele aufzählen,
> warum das in Assembler nicht geht. - Egal!
Interessant, es aus dieser Perspektive zu sehen. Es wäre vielleicht ganz 
nützlich Grundsätzliches über MSP430 ASM zu lernen. Große Projekte würde 
ich allerdings nicht in ASM machen wollen. Abgesehen davon wäre das in 
der Firma projektmäßig sowieso nicht möglich.
>
> Nein, die 24MHz sind keine Übertaktung, das ist obere Kante laut
> Datenblatt.
Ja, das stimmt.
> "
> 24MHz 105C ULP Microcontroller With 32 KB FRAM, 4 KB SRAM, 44 IO, 12-bit
> ADC, 12-bit DACs, OpAmp/PGA
> "
> So ganz habe ich noch nicht verstanden, was bei Dir mit dem ADC nicht
> klappt. Lass uns abwarten, bis ich die Teile bei mir in der Hand halte,
> evtl. IAR (für ASM) auf einem neuen Rechner installiert habe und das
> Demoprogramm ausprobieren kann. Dann finden wir bestimmt auch den Grund
> für die Reset-Bedingungen.
Das RESET Problem verschwand wie schon berichtet nach JTAG FW Update. 
Jetzt funktioniert der Debugger einwandfrei.

Das ADC Problem könnte möglicherweise ein Interrupt Bit Fehlauswertung 
sein. Dem DABla nach wird das Flagbit nur dan gelöscht wenn man den 
richtigen Channel ausliest. Ich werde mich heute Abend mit neuen Elan 
damit befassen.

Ein einfaches Demo Test Program im LPM funktioniert dagegen einwandfrei.
>
> Im Augenblick weiß ich noch gar nicht, was ich mit den vielen
> I/O-Leitungen machen soll, [Scherz] vielleicht eine
> Geräteinnenbeleuchtung mit Lauflicht? [/Scherz]
>
> Falls Du ebenfalls "zuviele" Leitungen ungenutzt hast, überlege, ob Du
> den klassischen Debug-Adapter-Anschluss auf Deine Leiterplatte mit drauf
> layoutest. Das ist mehr als die beiden Leitungen für SpyBiWire. Sieh
> einmal bei Dir im Datenblatt zum Prozessor nach. Du brauchst den
> Anschluss wahrscheinlich nicht, aber wenn dann doch, dann hast Du alle
> Möglichkeiten.
Ja. Ich würde schon gerne den Unterschied merken wollen. Mit SBW wenn 
ich Serial über dem Debugger mache gibt es immer eine kurze Pause 
zwischen Kommando und Antwort. Wenn ich das Programm ohne Debugger in 
Betrieb habe läuft die Kommunikation so schnell wie Serial es erlaubt 
auch bei 1Mhz unverzögert.
>
> So, Review von Deinem Text:
> Kannst Du das Datum vom Compiler nicht formatieren? Meist bieten die
> Entwicklungsumgebungen so etwas. Dazu gibt es die Metasprache bei den
> Compilern, die Direktiven.
Mit diesen Einzelheiten kenne ich mich noch nicht genügend aus. Werde in 
dieser Richtung recherchieren. Danke.
>
> Nochmals zum Reset beim Start: Kannst Du in der Entwicklungsumgebung
> nicht etwas in den sog. Options beim Start anklicken. Es sieht mir nach
> "Synchronisation" zum Quelltext aus.
Das hat sich erübrigt. Die Einstellungen zwischen beiden PCs waren 
identisch. Es hatte ja an der FW gelegen. Ich probierte etwas mit den 
Reset Einstellungen herum. Nichts hat genützt.
>
> Firmware Update: So ein Update habe ich auch schon einmal auf einem
> EVA-Board gemacht. Hast Du nur ein Board? Fehler!!! Ich bestelle immer
> mindesten 3 Boards (klar fragen die manchmal, ist für Ausbildung) Ein
> Board kostet weniger, als ich in 10 Minuten Arbeitszeit verbrate.
> Außerdem kann ich dann immer noch restliche Boards an Studenten
> verschenken, wg. Ausbildung und so.
Ja. Hast recht. Ich werde mir noch eine zweite Bord besorgen.
>
> Also, bei mir hat das Update in der IAR-Umgebung funktioniert. Einmal
> musste ich aber, wenn ich mich richtig erinnere, nach dem Update noch
> ein Hardware Update machen, irgendwas umlöten. Jetzt fällt mir wieder
> ein: Das Debug-Interface für LPT-Port (früher, ganz ganz früher und das
> Interface für USB hatte ich geabdated, auch einmal für die SpyBiWire).
> Das hat aber bei IAR immer ohne mucken funktioniert. Die helfen auch bei
> Problemen, die sie als Probleme erkennen. Bei "nicht lesen" helfen die
> nicht viel. - Meine persönliche Erfahrung.
Die macht man:-)
>
> So, [Scherz] das ist wieder ein teurer Text [/Scherz].

Schönen Abend noch,
Gerhard
>
> Weiterhin happy coding!
>
> Bernd

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Ich höre schon die Experten, die mir Beispiele aufzählen, warum das in
> Assembler nicht geht.

Dass so etwas nicht gehen würde, hat übrigens nie jemand behauptet.

Der Aufwand ist nur beträchtlich, sowohl initial als auch in der Pflege. 
Wenn du das als Hobby machst und damit glücklich bist, ist dagegen 
nichts einzuwenden, aber kommerziell produktiv wird sich das keiner 
antun – weil's ihm auch kein Kunde bezahlen will.

> Bevor jemand genauer nachgefragt oder zugehört hatte, wurde mir oben
> mehrfach unterstellt, ich würde selbstmodifizierenden Code schreiben.

Das war lediglich ein Beispiel von Dingen, die man natürlich nur mit 
Assemblerprogrammierung so machen kann. War dazumals "cool", ein paar 
Bytes zu sparen, indem man die Variablen gleich in die Opcodes reinlegt, 
gerade im CP/M-Betriebssystemkern wurde sowas regelmäßig gemacht. Fällt 
am Ende in die gleiche Kategorie wie abgezählte Befehle, um ein 
bestimmtes Timing irgendwo zu erreichen. Klar, kann man machen, aber als 
eine tolle Tat anpreisen mag sowas heutzutage keiner mehr. Macht man 
nur, wenn's unbedingt sein muss (wie bspw. V-USB als 
Software-USB-Implementierung auf den AVRs).

: Bearbeitet durch Moderator
Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Der Aufwand ist nur beträchtlich, sowohl initial als auch in der Pflege.
> Wenn du das als Hobby machst und damit glücklich bist, ist dagegen
> nichts einzuwenden, aber kommerziell produktiv wird sich das keiner
> antun – weil's ihm auch kein Kunde bezahlen will.

Wir haben hier den Fall das eine alte Generation Sonden von einem kurz 
vor der Rente stehenden Mitarbeiter immer in ASM programmiert wurden.
Die laufen super, ohne Frage.
Nur ist niemand, ausser diesem Mitarbeiter, mehr in der Lage die sich 
ständig erweiternde Funktionalität per ASM in eine MCU zu quetschen die 
so alt ist das sie kurz vor der Abkündigung steht, und die über die 
Jahre auch bis ins letze Bit ausgenutzt wurde.

Eine Portierung auf eine neue MCU ist durch das massive ASM gefriggel 
nicht sinnvoll möglich.
Seit geraumer Zeit müssen wir also neue und alte Generation parallel 
entwickeln, viele Arbeiten doppelt machen, bis die neue Generation die 
alte vollständig ersetzen kann.

Recourcen haben moderne MCUs im Übermass.
Wegen ein paar Prozent Performance bzw. Speicherplatznutzung ASM zu 
benutzen ist in jedem Fall eine Sackgasse.
Über kurz oder lang fällt einem das auf die Füssen.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Über kurz oder lang fällt einem das auf die Füssen.

Da habt ihr einfach zu spät oder zu falsch reagiert. Ich kenne sowas 
ähnliches. Ich hatte früher jahrelang die 78K4 Reihe von NEC in 
Benutzung und tonnenweise Geräte "draußen" bei den Kunden. Mit den 
Jahren wurden deren Anforderungen immer mehr (nicht weil die das 
wollten, sondern wegen Änderungen in der Gesetzeslage) und der Platz im 
Flash wurde enger.

Dabei fiel dann mal auf, daß IAR bei der 24 Bit Adressierung einen Bug 
im Compiler hatte, aber keine Lust, selbigen zu beseitigen. Also waren 
Assembler-Workarounds angesagt, um die draußen befindlichen Kisten am 
Leben zu halten.

Als mir DAS klar wurde, hab ich die Notbremse gezogen und ne neue 
Gerätegeneration hochgezogen, diesmal mit 32 Bittern. Genau SOWAS hättet 
ihr schon längst machen sollen. Naja, und wenige Jahre später war NEC 
dann komplett weg vom Fenster.

Immer an Gorbatschow denken: Wer zu spät kommt...

W.S.

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Genau SOWAS hättet
> ihr schon längst machen sollen.

Es wäre nur der halbe Aufwand wenn schon die alte Generation in C 
Programmiert worden wäre.
Für alte Sache verzeihlich weil die MCUs und Compiler nicht soweit 
waren.
Für neue Sachen einfach nur dumm, weil man sich Wartbarkeit und 
Portierbarkeit unnötigerweise dadurch verbaut.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> ich kann Deine Fragen erst heute Abend beantworten - Bin mächtig
> eingespannt.

Hallo Bernd,

Der ADC12 läuft nun einwandfrei auf allen 6 Kanälen im Auto Sequence 
Timer Trigger Modus mit 2kHz.

Machte einen Fehler mit den Interrupt Flags. Ich passte nicht auf und 
setzte ADC12IER0 auf dieselbe Nummer wie den Input Select. Anstatt die 
Nummer des letzten ADC12MCTL Register (7) mit der richtigen Interrupt 
Nummer zu machen, schrieb ich die Kanal Nummer (13) Das konnte nicht 
funktionieren weil die Interrupt Flag nie gesetzt wurde. So ein 
einfacher Fehler!

Die Messungen mit einem Poti an Vdd ergeben relativ ruhige Messungen mit 
rund +/- 2  Unsicherheit. Mit etwas Averaging dürfte das ganz gut gehen.

Man macht tatsächlich Fortschritte:-)

Als nächstes möchte ich das interne Thermometer im uC mitmessen.

Dann kommt die RTC dran. Später noch ein I2C LCD Character Display und 
ein Port Expander mit dem PCA9554..

Mir gefällt der uC trotz aller Schwierigkeiten die es gab. Das FRAM ist 
eine feine Sache.

Der Debugger benimmt sich nun.

Ist Deine Bord schon angekommen?

Gerhard

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ist Deine Bord schon angekommen?

Hallo Gerhard,

zu Deinen Fortschritten gratuliere ich Dir!

Meine Boards wollten Elvis noch einmal besuchen und reisten via Memphis 
TN. Jetzt sind sie im Transit. Lieferdatum soll 12. Oct. sein. Also die 
müssen noch fliegen und durch den Zoll, anschließend mit dem Pony 
Express durch die Republik zu mir. Ich denke, dass ich die Dinger doch 
erst bemuttern kann, wenn ich in etwa 3 Wochen meine kleine 
"Unterbrechung" abgeschlossen habe.

Sieh hier einmal, was Rufus bereits gepostet hat:

Rufus Τ. F. schrieb:
> http://www.ti.com/lit/zip/slac710

Ich bin einmal in das Dokument

   msp430fr599x_adc12_10.c

eingetaucht. Vielleicht kannst Du dort Anregungen für Deine Codes 
finden. Zu den andern Peripherien findest Du ebenfalls Beispiele.

Happy coding!

Bernd

Autor: Bernd B. (microwave-designer)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... so, was ich nicht erwartet habe aber wirklich dem Hersteller sehr 
hoch anrechne ist im Foto zu erkennen. Am 8.10. vormittags im Internet 
angefragt, bestellt, BEZAHLT und eben geliefert - aus MN, U.S.A.

So macht Entwicklung Spaß und so kommt man super voran.

Gruß in die Runde und falls es jemand von der Firma liest: DANKE!

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bei Dir scheint alles planmäßig fortzuschreiten.

Kleiner Lagebericht. Gestern probierte ich auch noch das interne 
Thermometer aus und es funktioniert ausgezeichnet. Auch die interne 
Betriebsspannungsmessung.

Nur stehe ich auf den Schlauch wie ich dynamisch die 
Referenzspannungsquelle für jeden Eingang wählen kann. Es ist mir 
bekannt wie man das ADC12MCTL Register für jede Messung konfigurieren 
kann. Ich sehe aber keinen Weg einen getriggerten Scan von N Kanälen mit 
dynamischer Umschaltung der Referenzspannung zu erzielen. Da die interne 
Temperaturmessung 1.2V braucht, ich aber auf den restlichen Kanälen z.B 
2.5V oder Ratiometrisch arbeiten will, weiß ich nicht wie ich das im 
Augenblick anstellen soll. Sicher man kann die Referenzquellen im MCTL 
register per Kanal festlegen. Ich stehe aber auf dem Schlauch wie ich im 
automatischen Scan kanalmäßig dynamisch auch die Referenzspannung 
wechseln kann. Z.B ich möchte eine solche Kanalliste:

A0-A3 - Ratiometrisch, Vref = Avcc
A4-A5 - 2.0V int. Vref
A6 - 2.5V int. Vref
A7 - Betriebspannung, intern mit 2.5V
A8 - Int. Temperatur mit VREF = 1.2V

Wie macht man diese Umschaltung automatisch. Im MCTL Register sehe ich 
da im Augenblick keine Möglichkeit. Man kann ja nur die VREF 
Möglichkeiten als solches festlegen, nicht aber die Spannung andauernd 
umschalten.

Die einzige Lösung die mir vorschwebt ist, die Eingänge so zu gruppieren 
daß gleiche VREF in einem Getriggerten Scan abgearbeitet wird und dann 
umgeschaltet wird und die nächste Gruppe mit gleicher Einstellung 
abgearbeitet wird. Das Problem ist auch, daß die Umschaltung der 
Referenz Totzeiten mit sich bringt.

Übersehe ich irgendwas?

: Bearbeitet durch User
Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Übersehe ich irgendwas?

Hallo Gerhard,

ehrlich gesagt, ich weiß es bislang nicht. Leider bleibt mir im 
Augenblick keine Zeit Dir hier zu helfen, da ich ab morgen zu 100 
Prozent in einem anderen Projekt stecke und noch vorbereiten muss. Ich 
würde aber wahrscheinlich den von Dir vorgeschlagenen Ansatz auch 
wählen, mindestens für den Anfang. Vielleicht liest hier jemand mit, der 
Dir kurzfristig helfen kann. Ich gehe auch davon aus, dass Du die 
Code-Schnipsel aus der SLAC710 schon angesehen hast.

Eigentlich ist es schade, denn meine Boards sind mittlerweile ebenfalls 
schon eingetroffen und ich könnte loslegen. ... könnte. Dabei wäre es 
egal, ob ich mit den ADCs anfange oder mit anderer Peripherie, die ich 
anschalten möchte. ... I2c, SPI, UART, ...

Wenn alles glatt läuft, würde ich ab dem 1. Nov. hier mit der 
Programmierung beginnen. Einige Module (SW) kann ich sicherlich schnell 
aus alten Projekten übernehmen, mindestens vom Konzept her.

Verstehe ich es richtig, dass Du im Augenblick den MSP430 für Dein 
Hobbyprojekt einsetzt und die HART-Schnittstelle noch nicht ansteht?

Erst einmal Gruß und happy coding!

Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Das ist schon Ok. Ich werde mich schon durchschlagen. Viel Spass mit 
Deinen Projekten. Hört sich interessant an.

Bernd B. schrieb:
> Gerhard O. schrieb:
>> Übersehe ich irgendwas?
>
> Hallo Gerhard,
>
> ehrlich gesagt, ich weiß es bislang nicht. Leider bleibt mir im
> Augenblick keine Zeit Dir hier zu helfen, da ich ab morgen zu 100
> Prozent in einem anderen Projekt stecke und noch vorbereiten muss. Ich
> würde aber wahrscheinlich den von Dir vorgeschlagenen Ansatz auch
> wählen, mindestens für den Anfang. Vielleicht liest hier jemand mit, der
> Dir kurzfristig helfen kann. Ich gehe auch davon aus, dass Du die
> Code-Schnipsel aus der SLAC710 schon angesehen hast.
>
> Eigentlich ist es schade, denn meine Boards sind mittlerweile ebenfalls
> schon eingetroffen und ich könnte loslegen. ... könnte. Dabei wäre es
> egal, ob ich mit den ADCs anfange oder mit anderer Peripherie, die ich
> anschalten möchte. ... I2c, SPI, UART, ...
>
> Wenn alles glatt läuft, würde ich ab dem 1. Nov. hier mit der
> Programmierung beginnen. Einige Module (SW) kann ich sicherlich schnell
> aus alten Projekten übernehmen, mindestens vom Konzept her.
>
> Verstehe ich es richtig, dass Du im Augenblick den MSP430 für Dein
> Hobbyprojekt einsetzt und die HART-Schnittstelle noch nicht ansteht?
Zur Zeit befasse ich mit dem MSP430 hauptsächlich aus privater Neugierde 
weil ich mittlerweile einige nützliche Aspekte für mich entdeckt habe. 
Deshalb wollte ich Erfahrungen sammeln. Ich habe da einige Projekte im 
Auge die vielleicht damit durchgezogen werden könnten. Der Schlafmodus 
ist ja beim MSP430 hoch entwickelt.

Bis wir in der Firma soweit sind richtige Planung zu machen vergeht noch 
einige Zeit da auch komplizierte mechanische Faktoren und Kosten 
mitspielen. Bevor man nicht den mechanischen Kostenfaktor und 
Herstellungsweise erfasst hat geht es sowieso nicht weiter. Die Mechanik 
verschlingt einen Löwenanteil der Anstrengungen. Da ist die Eletronik 
nur ein kleiner Bestandteil. Aber mit den inzwischen gewonnenen 
Erfahrungen kann ich dann später besser abwägen welcher uC am Ende die 
beste Wahl ist. Bis jetzt sieht der MSP gut aus. Es sieht so aus als ob 
man an HART sowohl als auch Foundation Fieldbus Steuerung interessiert 
ist. Da muss man noch recherchieren wieviele Ressourcen der FB Stack 
verschlingt und ob der MSP trotz seines großen Speichers groß und 
schnell genug ist. Da wir noch nie mit FB zu tun hatten kommt da einiges 
auf uns zu. Es ist jetzt viel zu früh genau zu planen. Bis das Projekt 
bewilligt wird ist das sowieso alles etwas Spekulation. Ich liebe es 
halt etwas von meinen "Feinden" zu kennen:-)

Jedenfalls bin ich persönlich schon von der Nützlichkeit der MSP430 
überzeugt. Mein portiertes Test Programm funktioniert schon ganz 
ordentlich. Muss nur noch die RTC adaptieren und die offenen Fäden mit 
dem ADC verknüpfen. Der ADC ist sehr genau. Die interne Batteriespannung 
mißt er haargenau ohne irgendwelche Calibrierung. Mit einem externen 
Vergleichs DMM stimmt das Resultat genau. Auch die Temperatur wird 
anhand der TLV Korrektur Daten genau berechnet und stimmt mit einen 
externen Thermometer immerhin auf auf besser als 2 Grad überein. Das ist 
schon mal nicht schlecht für den Anfang. Die bisherigen Schwierigkeiten 
ab und zu sind für einen mir unbekannten uC völlig normal und bringen 
mich nicht aus der Fassung. Nicht immer versteht man die Dokumentation 
gleich so wie man es möchte. Lesen und Verständnis sind manchmal 
unterschiedliche Dinge. Manche Terminologie ist dann teilweise auch noch 
etwas "schwammig" am Anfang. Die User Guide alleine hat immerhin über 
1000 Seiten. Komplexitätsmäßig ist der MSP den STM32 oder DSPICS von MC 
näher wie den meisten 8-Bittern.

Ich habe daheim überraschenderweise immer noch das Debug Reset Problem. 
Nach dem Laden der neuen JTAG FW hat es einmal funktioniert, da bin ich 
sicher. Aber gestern wie ich es wieder daheim ausprobiert hatte, ging es 
dann nicht mehr. In der Firma unter W10 macht er das definitiv nicht und 
funktioniert zuverlässig immer 100%. Ich habe alle Debuggereinstellungen 
verglichen und es besteht kein Unterschied. Vielleicht liegt es am W7X64 
daheim.

Ich werde es mal in meiner W10 Maschine installieren. Es liegt bestimmt 
nicht am Programm weil sich der Debugger auch mit allen anderen 
Programmen so verhält. Was mir aufgefallen ist, daß gleich nach dem 
Laden das Programm im MSP schon losläuft. Erst bei einem Hard Reset 
bekomme ich Kontrolle über den MSP.

Da ich keine Erfahrungen mit JTAG unter der Haube habe, weiß ich auch 
nicht wie ich da ansetzen kann. Ich habe mal früher mit ARM unter IAR 
mit Kommandozeilen und dem Segger JTAG gearbeitet. Aber das ist schon 8 
Jahre her. Mit Atollic TruStudio und dem STM32 habe ich keinerlei 
Probleme mit dem JTAG Debugger. Das funktioniert immer.

Schönen Abend noch und Spaß mit der neuen Bord.

Grüße,
Gerhard



>
> Erst einmal Gruß und happy coding!
>
> Bernd

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd,

Nachtrag:

Ich installierte CCS8 auf einer W10X32 Maschine und der Debugger laeuft 
da einwandfrei. Keine RESET Probleme. Da stimmt irgend ewtas nicht auf 
meinem W7X64 System.

Gerhard

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Wie macht man diese Umschaltung automatisch. Im MCTL Register sehe ich
> da im Augenblick keine Möglichkeit.

Wenn es nicht im MCTL-Register ist, geht es auch nicht automatisch.

> Das Problem ist auch, daß die Umschaltung der Referenz Totzeiten mit
> sich bringt.

Wahrscheinlich ist es deswegen nicht vorgesehen. Man müsste schon 
mehrere Referenzen parallel laufen lassen (was mit VeREF+/- und 
zusätzlicher Hardware ja auch möglich ist).

Autor: gaestchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ganz kurz zum Refernez Problem:
manche MSP430 haben noch eine Hardwarereferenz drauf und das sind eigene 
Resgiter und diese kann man dann umschalten zwischen zB 1,5 V und 2,5 V 
oder so, dazu muss man die externe Ref freigeben im ADC MCTL Register 
und dann entsprechend die Ref Register noch einstellen, das haben aber 
nicht alle MSP430, dann muss man mit den fixen internen oder externen 
Referenzen arbeiten, extern kann man natürlich nur eine einzige 
anschließen, oder man muss diese eben extern umschalten, was ich jetzt 
pauschal einfach mal nicht empfehlen würde wegen den entstehenden 
Ungenauigkeiten.

Autor: Bernd B. (microwave-designer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an Clemens und Gaestchen!

Gerhard, ich habe doch noch eine Blick ins slau376o.pdf riskiert: Das 
mit den ADC12MCTLx Registern im Kapitel 34.3.6 habe ich ebenfalls 
gesehen. Jeder Kanal beisitzt ein eigenes Register, siehe Seite 897. 
Auch das Bild auf Seite 867 zeigt einen netten Überblick, insbesondere 
die rechte obere Ecke.

Dann im Absatz 34.2.1:
"
The input channel and the reference
voltage levels (VR+ and VR-) are defined in the conversion-control 
memory.
"

So wie ich es verstehe, sollte es möglich sein, was Du vorhast.

Die Hinweise zur Stabilität oder zum Einschwingen sollt man überprüfen 
und entsprechend berücksichtigen. Z. B. durch wiederholtes Abtasten und 
miteinander vergleichen. Auch kann man die Wartezeit oder Taktraten 
variieren und das Ergebnis ansehen.

Temperaturmessung:
Vergiss nicht, Du misst die Chip-Temperatur. Nach langer Schlafenszeit 
sieht die u. U. anders aus, als nach Numbercrunching.

Reset:
Es sollte in der Entwicklungsumgebung einstellbar sein, dass nach 
Code-Download der Prozessor entweder losläuft oder auf die 
Speicherstelle geht, die Du angibst, praktischerweise RESET. Es ist 
durchaus möglich, dass diese Einstellung nur für eine Sitzung gilt oder 
vom Windows OS abhängt. Ich kenne Deine Software nicht. Wenn ich meinen 
IAR "refreshe" oder update, gehe ich durch alle Registerkarten und 
stelle erst einmal überall ein, was ich so schön finde. Dazu gehört auch 
der Start. Wenn der Prozessor gleich losrennt, kennt die Debug-Software 
vielleicht nicht den Ankerpunkt und erwartet einen "Neustart" der Codes.

Zum FB:
Ob es bereits Beispiele zum FB gibt, müsste man googlen. Es gibt viel, 
sehr viel. Manches wird dann von den TI App-Ings. übernommen und 
verfeinert. Z. B. Nutzung der SD-Card, Web-Server (lief mit weniger als 
10k Code), ... Ich habe gestern gesehen, dass es sogar (wenn ich richtig 
rate) etwas zum Filesystem auf der SD-Karte gibt. Damit wäre dann meine 
Software hinfällig? Glaube ich aber erst, wenn ich den Code angesehen 
habe. Ich schreibe auf SD-Cards auch große Dateien, sehr große und 
segmentiere und formatiere und und und.

Nochmals, immer schön modular bleiben! Dann kannst Du den Code später 
gut portieren!

Dass die ADCs bei TI gut sind, glaube ich gerne: Bei den ersten MSP430 
mit EPROM hatten sie Probleme und viel Aufwand investiert, um die 
Genauigkeit hinzubekommen. Das hat sich wohl gelohnt.

So, Selbstdisziplin!

Happy coding!

Bernd

Edit: "... mit EPROM"

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clemens L. schrieb:
> Gerhard O. schrieb:
>> Wie macht man diese Umschaltung automatisch. Im MCTL Register sehe ich
>> da im Augenblick keine Möglichkeit.
>
> Wenn es nicht im MCTL-Register ist, geht es auch nicht automatisch.
>
>> Das Problem ist auch, daß die Umschaltung der Referenz Totzeiten mit
>> sich bringt.
>
> Wahrscheinlich ist es deswegen nicht vorgesehen. Man müsste schon
> mehrere Referenzen parallel laufen lassen (was mit VeREF+/- und
> zusätzlicher Hardware ja auch möglich ist).

Hallo Clemens,

Danke für die Gedanken zu meinem Problem. Du hast recht. Nach 
überschlafen, werde ich einfach die Methode der Messung anpassen.

Da ja die Referenz nicht kanalmäßig manipuliert werden kann und auch 
Timings beachtet werden müssen ist es am Besten nur gleichwertige 
interne  Referenzspannungen zu gruppieren und scannen. Mit dem MCTL kann 
ich dann noch zwischen Referenz Modii differenzieren. Ich werde 
möglicherweise auch nur mit 2.5V arbeiten und dann kann ich alles in 
einer ISR auslesen.

Die Temperaturmessung mache ich dann separat ohne ISR mit Polling nur 
alle 1-60s. Dazu brauche ich nur den Timertrigger abschalten so dass der 
automatische Scan aufhört, die Referenz auf 1.2V umprogrammieren, wie 
vorgeschrieben warten und dann in Polling mode die T messen und dann 
wieder die Referenz auf 2.5V stellen und den Scantrigger wieder 
aktivieren. Mit dieser Methode könnte ich leben.

Das werde ich heute wenn ich dazu komme ausprobieren.

Schönes Wochenende,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gaestchen schrieb:
> ganz kurz zum Refernez Problem:
> manche MSP430 haben noch eine Hardwarereferenz drauf und das sind eigene
> Resgiter und diese kann man dann umschalten zwischen zB 1,5 V und 2,5 V
> oder so, dazu muss man die externe Ref freigeben im ADC MCTL Register
> und dann entsprechend die Ref Register noch einstellen, das haben aber
> nicht alle MSP430, dann muss man mit den fixen internen oder externen
> Referenzen arbeiten, extern kann man natürlich nur eine einzige
> anschließen, oder man muss diese eben extern umschalten, was ich jetzt
> pauschal einfach mal nicht empfehlen würde wegen den entstehenden
> Ungenauigkeiten.

Hallo Gaestchen,

Danke für Deine Vorschläge und Empfehlungen.

Für einen großen Temperatur Bereich ist die eingebaute VREF mit 100ppm/C 
sowieso nicht so tolle. Da ist eine bessere externe VREF sowieso 
angesagt. In anderen uC Projekten ging es ja auch mit nur einer VREF. 
Wie gesagt durch Gruppierung läßt sich damit leben.

Gruß,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Daanke für Deine Ausführungen und Vorschläge. Ja, die User Guide ist da 
recht nützlich.

Bernd B. schrieb:
> Danke an Clemens und Gaestchen!
>
> Gerhard, ich habe doch noch eine Blick ins slau376o.pdf riskiert: Das
> mit den ADC12MCTLx Registern im Kapitel 34.3.6 habe ich ebenfalls
> gesehen. Jeder Kanal beisitzt ein eigenes Register, siehe Seite 897.
> Auch das Bild auf Seite 867 zeigt einen netten Überblick, insbesondere
> die rechte obere Ecke.
>
> Dann im Absatz 34.2.1:
> "
> The input channel and the reference
> voltage levels (VR+ and VR-) are defined in the conversion-control
> memory.
> "
>
> So wie ich es verstehe, sollte es möglich sein, was Du vorhast.
Dynamische Umschaltung der Referenz durch das MCTL Register ist nicht 
von T.I. vorgesehen.
>
> Die Hinweise zur Stabilität oder zum Einschwingen sollt man überprüfen
> und entsprechend berücksichtigen. Z. B. durch wiederholtes Abtasten und
> miteinander vergleichen. Auch kann man die Wartezeit oder Taktraten
> variieren und das Ergebnis ansehen.
Habe ich schon gemacht.
>
> Temperaturmessung:
> Vergiss nicht, Du misst die Chip-Temperatur. Nach langer Schlafenszeit
> sieht die u. U. anders aus, als nach Numbercrunching.
Da könnte man was merken. Allerdings bin ich nicht zu fixiert auf dies 
Genauigkeit. Ich möchte die Temperatur nur ungefähr wissen. Für genauere 
Messungen wäre ein externer Swnsor sowieso angesagt. Im Augenblick geht 
es mir nur darum die uC Peripherie zu erkünden.
>
> Reset:
> Es sollte in der Entwicklungsumgebung einstellbar sein, dass nach
> Code-Download der Prozessor entweder losläuft oder auf die
> Speicherstelle geht, die Du angibst, praktischerweise RESET. Es ist
> durchaus möglich, dass diese Einstellung nur für eine Sitzung gilt oder
> vom Windows OS abhängt. Ich kenne Deine Software nicht. Wenn ich meinen
> IAR "refreshe" oder update, gehe ich durch alle Registerkarten und
> stelle erst einmal überall ein, was ich so schön finde. Dazu gehört auch
> der Start. Wenn der Prozessor gleich losrennt, kennt die Debug-Software
> vielleicht nicht den Ankerpunkt und erwartet einen "Neustart" der Codes.
Ich verwende im Augenblick nur den CCS8 von T.I. Bei IAR ist die 
Codesize Begrenzung ein Problem ausser zum Erproben des uC.
>
> Zum FB:
> Ob es bereits Beispiele zum FB gibt, müsste man googlen. Es gibt viel,
> sehr viel. Manches wird dann von den TI App-Ings. übernommen und
> verfeinert. Z. B. Nutzung der SD-Card, Web-Server (lief mit weniger als
> 10k Code), ... Ich habe gestern gesehen, dass es sogar (wenn ich richtig
> rate) etwas zum Filesystem auf der SD-Karte gibt. Damit wäre dann meine
> Software hinfällig? Glaube ich aber erst, wenn ich den Code angesehen
> habe. Ich schreibe auf SD-Cards auch große Dateien, sehr große und
> segmentiere und formatiere und und und.
Meine Bord hat eine uSD Karte drauf. Die Demoprogramme kamen mit Einem 
FAT FS. Sollte nicht zu viele Schwierigkeiten machen.
>
> Nochmals, immer schön modular bleiben! Dann kannst Du den Code später
> gut portieren!
Ja. Das lohnt sich immer. Ich tue das sowieso schon lange so. Ist 
einfach in meiner Natur. Ich portiere auch viele Sachen zwischen anderen 
uC und da ist das Voraussetzung.
>
> Dass die ADCs bei TI gut sind, glaube ich gerne: Bei den ersten MSP430
> mit EPROM hatten sie Probleme und viel Aufwand investiert, um die
> Genauigkeit hinzubekommen. Das hat sich wohl gelohnt.
Das ist mir nicht bekannt. Die Spannungsmessungen rauschen ohne AVG nur 
etwas mit +/- 2 Nummern. Die Temperaturmessung ist da viel schlechter. 
Mit AVG=16 wird die Temperatur nur um +/- 0.2 Grad stabil angezeigt und 
tanzt herum.
>
> So, Selbstdisziplin!
Ja. immer.

Grüsse,
Gerhard

P.S. Heute ist richtiges Programmierwetter. Es regnet und später ist bis 
zu 10cm Schnee angesagt. Aber es soll bald wieder warm werden.
>
> Happy coding!
>
> Bernd
>
> Edit: "... mit EPROM"

: Bearbeitet durch User
Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

was gibt es bei Dir Neues mit Deiner MSP430 Bord? Irgendwelche 
Überraschungen?

Bei mir ging alles in geordneten Bahnen. Mein W7X64 macht mit dem 
Debugger nun erklärlicherweise keine Mucken mehr. Seit einigen Tagen nun 
funktioniert der Debugger in CCS wie er soll. Kann es nicht begründen. 
Ich habe nichts an den Einstellungen geändert.

Alle Analog Sachen funktionieren nun. Die RTC funktioniert nun auch.

Falls es Dich interessiert, sind hier ein paar Kommando Beispiele des 
Test Programms:
u1?

DAM430 LIST OF ALL AVAILABLE COMMANDS
-------------------------------------
U1V     - Show Version String
U1A     - Print all analog channels
U1XIn,m - Print all digital registers
U1XO,n  - Output new digital register
U1V     - Show Version String
U1H     - Test Watchdog, Reset CPU
U1U     - Send error
U1T     - uC int Temp: T=C,T1=F,T0=RAW
U1S     - uC int Vdd val in Volts
U1K     - Free Command
U1M     - Free Command
U1PR    - Print all FRAM registers
U1PRn   - Print selected FRAM register
U1Pn,m  - Set new FRAM value
U1PD    - Restore default FRAM values
U1PE    - Erase FRAM values
U1@hhmmssyymmdddow - Set new time
U1C     - Print current RTC time and date
U1W     - Print Status Word

u1c

05:25:36 18/10/16 (02)
u1v

DAM430 GP V0.02, Oct 15 2018
u1ast

4095 1644 945 0 1 0 478 0 2053 2630 3.29 24.05
u1xi

185 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
u1pr

1 1 1000 16 -340 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0

u1p10,12234


UPD10 = 12234
u1pr

1 1 1000 16 -340 0 0 0
0 0 12234 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0

LED P1.0 einschalten:
u1xo1,1

OK

Mit einem solchen Programm, dass bei mir auf allen von mir benutzten uC 
läuft, teste ich meine neu entwickelten uC Schaltungen da ich damit 
alles durch testen kann. Auch für Testautomation in Zusammenarbeit mit 
LabVIEW ist es recht praktisch. Auf einem RS485 Bus lassen sich mehrere 
uC so steuern(deshalb der U1 Prefix). Die X Register werden dann so 
adaptiert, dass man alles der HW steuern und lesen kann. Auch I2C 
Devices z.B. werden so virtualisiert. Control Register solcher I2C 
Devices werden in einige der X-Register gemappt und lassen sich genauso 
so leicht steuern als ob sie ein Bestandteil des uC wären. Z.B. die 
internen Register eines PCA9554 sind dann als X-Reg 10... zugänglich. 
(z.B. PCA9554 Register:  X10=Input Port Register, X11=Output Port 
Register, X12=Polarity Inv. reg., X13=Configuration register). Ist dann 
total transparent und zumindest für mich sehr praktisch. Auch als 
Datenlogger/RTU lässt es sich einsetzen.
Neue Funktionen lassen sich sehr schnell hinzu hinzufügen da das 
Programm sehr modular strukturiert ist und neue Kommandos leicht 
hinzufügbar sind.

Ich habe übrigens die Absicht irgendwann ein früher benutztes FORTH 
System auf den MSP430 zu portieren. Das ist beim experimentieren sehr 
praktisch weil sich neue Funktionen einfach einbauen lassen.

Jedenfalls finde ich den MSP430 recht ansprechend.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..nur Anmerkung: gestern hat mir Fedex auch ein FR5994 Launchpad 
gebracht..habe mich von den diversen Gutscheincodes in "Markt" 
überzeugen lassen :-)

Mal sehen ob das auch so lange liegt wie die 3 Stellaris LM4F120 
Launchpads..

:-|

Gruß,

Holm

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> ..nur Anmerkung: gestern hat mir Fedex auch ein FR5994 Launchpad
> gebracht..habe mich von den diversen Gutscheincodes in "Markt"
> überzeugen lassen :-)
>
> Mal sehen ob das auch so lange liegt wie die 3 Stellaris LM4F120
> Launchpads..
>
> :-|
>
> Gruß,
>
> Holm

Dann hat Dich also auch der MSP430 Bazillus gepackt:-)
Viel Spaß mit dem Teil!

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Holm T. schrieb:
>> ..nur Anmerkung: gestern hat mir Fedex auch ein FR5994 Launchpad
>> gebracht..habe mich von den diversen Gutscheincodes in "Markt"
>> überzeugen lassen :-)
>>
>> Mal sehen ob das auch so lange liegt wie die 3 Stellaris LM4F120
>> Launchpads..
>>
>> :-|
>>
>> Gruß,
>>
>> Holm
>
> Dann hat Dich also auch der MSP430 Bazillus gepackt:-)
> Viel Spaß mit dem Teil!

..naja Gerhard..nicht Bazillus. Ich habe Dir schon am Anfang geantwortet 
das die Teile funktionieren wie andere auch, ich mache schon eine Weile 
damit rum, aber gleichzeitig (derzeit) auch mit AtXmega, At[mega tiny], 
Z80, Z8000, H8, STM32, 68k und ollen 8051ern. Selbst ein PSOC1 wartet 
hier noch das er mal geweckt wird. Ich habe wenig Vorbehalte gegen 
andere Architekturen und ein Z80 mit Peripherie unterscheidet sich doch 
durch den Compiler gesehen recht wenig von einem MSP340, mal abgesehen 
von der Größe des bzw. der Chips.
Aber ein Bisschen Rechnerkram gehört zu meinen Hobbies, ich habe auch 
PDP11en und VAXen..wie Du weißt auch nebenbei noch einen Plotter und 
außerdem Nadeldrucker :-)
Ich habe vielleicht eher einen generellen Rechnerbazillus.

Gruß,
Holm

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holm,

Da hast Du ja recht, trotzdem schadet es ja nicht ab und zu mal über'n 
Zaun zu gucken.

Du hast doch nicht etwa einen funtionierenden PDP11 bei Dir zu hause 
rumstehen? Das wäre toll. Zugang zu einem VAX/VMS hatte ich vor vielen 
Jahren in meiner vorherigen Firma. Hatte einen Kollegenfreund, der war 
SA und programmierte ihn jahrelang. War angeblich ein sehr solides 
System auf das man sich wirklich verlassen konnte. Hatten damals 
übrigens auch HP1000 Systeme mit einer HP Version von UNIX drauf. Die 
steuerten derzeit unser eigenes hausgemachte 400 Mhz Zellular Netzwerk 
in Alberta. Die "Handies" hatten damals übrigens noch 40W Sendeleistung 
und unglaubliche Reichweiten. Die hatten zur Steuerung übrigens einen 
80C85 uC drin. Damals waren die Recchenanaprüche noch bescheiden und es 
gab kein Internet. Das waren noch gute Zeiten. Alles Technik, made in 
Alberta. Von einem Hügel aus konnte man fast 150km zwischen Mobile und 
Feststation bewältigen. Aber das ist schon lange Geschichte. Heutzutage 
begnügt man sich scheinbar mit der Reichweite von schnurlosen Telefonen.

Zur Zeit arbeite ich mich durch die meisten Peripherien des MSP430. Als 
nächstes kommen SPI, I2C und CRC16 dran. Bin überrascht wir gut  der ADC 
funktioniert. Dann möchte ich noch die I2C Treiber für mein Testprogramm 
integrieren damit ich die üblichen Peripherien wie PCA9554 u.ä. steuern 
kann. Aber da muß ich zuerst eine 3/5V MOSFET
I2C Wandlerschaltung dazwischen klemmen. Das die MSP uC keine 5V 
verträglichen Eingänge haben, verwundert mich ein bischen. Aber daran 
gewöhnt man sich. Das Einzige was mir an den FR Typen etwas missfällt 
ist das Fehlen eines externen VBAT Eingang. Trotz 
Stromspar-Programmierung wäre es günstig die RTC und ein Teil des SRAM 
unabhängig am Leben zu erhalten können. Bin gespannt wie es weitergeht. 
Ich habe heute mal die RTC den ganzen Tag laufen lassen und unter 1s 
Abweichung zwischen PC und dem MSP gehabt. Nicht schlecht für 10 
Stunden.

Die 8051er mag ich auch - so schön uC nostalgisch:-)

Was mich jetzt am MSP430 motivierte, daß es endlich eine unbegrenzte 
Entwicklungsumgebung gab und man interessante Möglichkeiten hat 
stromsparende Geräte zu konstruieren. Ein Bekannter von mir hat immer so 
viel von den Dingern geschwärmt. Ob es in der Firma damit was werden 
wird muß sich erst zeigen. Bis man sich dort fürs Projekt entscheidet 
wird wohl noch einige Zeit dauern. Aber das macht nichts.


Gruß,
Gerhard

P.S. Bei uns ist ab morgen wahrscheinlich die Hölle los: es soll nun in 
ganz Kanada Cannabis frei im Handel geben. Bin gespannt ob die Leute 
damit auch umgehen werden können. Hat man in D auch solche Flausen im 
Kopf? Das wird wahrscheinlich lustig werden...

Holm T. schrieb:
> Gerhard O. schrieb:
>> Holm T. schrieb:
>>> ..nur Anmerkung: gestern hat mir Fedex auch ein FR5994 Launchpad
>>> gebracht..habe mich von den diversen Gutscheincodes in "Markt"
>>> überzeugen lassen :-)
>>>
>>> Mal sehen ob das auch so lange liegt wie die 3 Stellaris LM4F120
>>> Launchpads..
>>>
>>> :-|
>
>>> Gruß,
>>>
>>> Holm
>>
>> Dann hat Dich also auch der MSP430 Bazillus gepackt:-)
>> Viel Spaß mit dem Teil!
>
> ..naja Gerhard..nicht Bazillus. Ich habe Dir schon am Anfang geantwortet
> das die Teile funktionieren wie andere auch, ich mache schon eine Weile
> damit rum, aber gleichzeitig (derzeit) auch mit AtXmega, At[mega tiny],
> Z80, Z8000, H8, STM32, 68k und ollen 8051ern. Selbst ein PSOC1 wartet
> hier noch das er mal geweckt wird. Ich habe wenig Vorbehalte gegen
> andere Architekturen und ein Z80 mit Peripherie unterscheidet sich doch
> durch den Compiler gesehen recht wenig von einem MSP340, mal abgesehen
> von der Größe des bzw. der Chips.
> Aber ein Bisschen Rechnerkram gehört zu meinen Hobbies, ich habe auch
> PDP11en und VAXen..wie Du weißt auch nebenbei noch einen Plotter und
> außerdem Nadeldrucker :-)
> Ich habe vielleicht eher einen generellen Rechnerbazillus.
>
> Gruß,
> Holm

Autor: Holm T. (holm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Hallo Holm,
>
> Da hast Du ja recht, trotzdem schadet es ja nicht ab und zu mal über'n
> Zaun zu gucken.

Natürlich nicht..ich gucke doch über den Zaun.
>
> Du hast doch nicht etwa einen funtionierenden PDP11 bei Dir zu hause
> rumstehen? Das wäre toll.

Ja, allerdings Mikro-PDP11. Ich habe eine 11/83 im BA23 Gehäuse und noch 
diverse weitere Card Cages und Platinen, 11/53, 11/73 usw, auch noch 
einen KA630 Platinensatz (uVAXII). Auf letzterer hatte ich mal 4.3 
Quasijarus (wohl letzte BSD Version für VAX) installiert.
Auf der 11/83 läuft RSX11,RT11 und auch 2.11 BSD.
Ich habe noch mehrere VAXstations (u.a. VS4000/90) sowie eine 
VAX4000/300 mit DSSI Platten.

> Zugang zu einem VAX/VMS hatte ich vor vielen
> Jahren in meiner vorherigen Firma. Hatte einen Kollegenfreund, der war
> SA und programmierte ihn jahrelang. War angeblich ein sehr solides
> System auf das man sich wirklich verlassen konnte. Hatten damals
> übrigens auch HP1000 Systeme mit einer HP Version von UNIX drauf.

Einen HP1000/A600 hat ein Kumpel letztens bei einen Verwerter gefunden,
leider hat da Jemand schon Platinen (u.A. CPU) und Chips geklaut, 
wahrscheinlich weil die so schön geglänzt haben. Das war das Ende der 
Maschine, ansonsten wäre die sicher hier und ich hätte sie in Ordnung 
gebracht.

>Die
> steuerten derzeit unser eigenes hausgemachte 400 Mhz Zellular Netzwerk
> in Alberta. Die "Handies" hatten damals übrigens noch 40W Sendeleistung
> und unglaubliche Reichweiten. Die hatten zur Steuerung übrigens einen
> 80C85 uC drin. Damals waren die Recchenanaprüche noch bescheiden und es
> gab kein Internet. Das waren noch gute Zeiten. Alles Technik, made in
> Alberta. Von einem Hügel aus konnte man fast 150km zwischen Mobile und
> Feststation bewältigen. Aber das ist schon lange Geschichte. Heutzutage
> begnügt man sich scheinbar mit der Reichweite von schnurlosen Telefonen.

IMHO wurde das erste Funktelefonnetz überhaupt mit freier Durchwahl vom 
Funkwerk Köpenick DDR irgendwo in Südamerika installiert..hab da mal 
einen interessanten Artikel gelesen. Eigentlich hatten die sich mit dem 
Angebot überommen, haben es dann aber doch geregelt bekommen.
>
> Zur Zeit arbeite ich mich durch die meisten Peripherien des MSP430. Als
> nächstes kommen SPI, I2C und CRC16 dran. Bin überrascht wir gut  der ADC
> funktioniert. Dann möchte ich noch die I2C Treiber für mein Testprogramm
> integrieren damit ich die üblichen Peripherien wie PCA9554 u.ä. steuern
> kann. Aber da muß ich zuerst eine 3/5V MOSFET
> I2C Wandlerschaltung dazwischen klemmen.

Ich habe dafür die bekannte Schaltung mit 2 Mosfets erfolgreich 
eingesetzt.
(siehe Anhang)
IMHO habe ich dafür auch noch kleine leere Platinchen herumliegen, 
könnte ich Dir evtl. schicken ohne am Porto Pleite zu gehen..

>Das die MSP uC keine 5V
> verträglichen Eingänge haben, verwundert mich ein bischen. Aber daran
> gewöhnt man sich. Das Einzige was mir an den FR Typen etwas missfällt
> ist das Fehlen eines externen VBAT Eingang. Trotz
> Stromspar-Programmierung wäre es günstig die RTC und ein Teil des SRAM
> unabhängig am Leben zu erhalten können. Bin gespannt wie es weitergeht.
> Ich habe heute mal die RTC den ganzen Tag laufen lassen und unter 1s
> Abweichung zwischen PC und dem MSP gehabt. Nicht schlecht für 10
> Stunden.
>
> Die 8051er mag ich auch - so schön uC nostalgisch:-)

Naja gut, ich habe als letztes einen Timer für einen UV-Belichter damit 
gebaut, wollte SDCC mit den Dingern mal ausprobieren und hatte noch 
AT89C52 herumliegen.
>
> Was mich jetzt am MSP430 motivierte, daß es endlich eine unbegrenzte
> Entwicklungsumgebung gab und man interessante Möglichkeiten hat
> stromsparende Geräte zu konstruieren. Ein Bekannter von mir hat immer so
> viel von den Dingern geschwärmt. Ob es in der Firma damit was werden
> wird muß sich erst zeigen. Bis man sich dort fürs Projekt entscheidet
> wird wohl noch einige Zeit dauern. Aber das macht nichts.
>
>
> Gruß,
> Gerhard
Die Entwicklungsumgebung unterschiedet sich für mich nicht wesentlich 
von der für andere Mikros, ich programmiere unter FreeBSD, also Unix, 
oft gcc aber eben auch sdcc oder was mir da brauchbar erscheint. für den 
8051 gibts auch eine kleine niedliche 8051ide irgendwo auf github, hat 
wohl ein Rumäne geschrieben. Ich nehme allerdings meist die Unix Tools..

> P.S. Bei uns ist ab morgen wahrscheinlich die Hölle los: es soll nun in
> ganz Kanada Cannabis frei im Handel geben. Bin gespannt ob die Leute
> damit auch umgehen werden können. Hat man in D auch solche Flausen im
> Kopf? Das wird wahrscheinlich lustig werden...

Ich wäre froh wenn wir hier nur Deine Sorgen hätten.
Freies Canabis war ab und an in der öffentlichen Diskussion. Das ist mir 
mehr oder weniger egal, ich will mit Sowas nichts zu tun haben.

Flausen? Wir sind hier viel schlimmer dran, grenzenlose unkontrollierte 
Migration. Google nach Deutschland und Migranten, ich werde hier nicht 
mehr erzählen dürfen sonst schlägt hier wieder einer der unpolitischen 
Moderatoren mit der Löschkeule zu. Ich wäre froh über ein 
Einwanderungsgesetz wie das von Kanada..oder simpel eins mit Vernunft..

Gruß,
Holm

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Bin gespannt wie es weitergeht. Ich habe heute mal die RTC den ganzen
> Tag laufen lassen und unter 1s Abweichung zwischen PC und dem MSP
> gehabt. Nicht schlecht für 10 Stunden.

Finde ich nicht wirklich toll.  Das sind 28 ppm Abweichung, da sollte 
mit einem 32-kHz-Quarz mehr machbar sein.

Ansonsten:

AVR - Die genaue Sekunde / RTC: Echtzeituhr mit Uhrenquarz

Der Code dort ist zwar für einen AVR, aber die Idee dahinter kann man ja 
auch woanders implementieren. Ist letztlich sowas wie „ein Trimmer in 
Software“, um eine aus dem 32-kHz-Takt abgeleitete Uhr möglichst genau 
zu bekommen.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..kommt sicherlich auch drauf an was da genau für ein Quarz drauf sitzt.
Beim alten MSP430G2553 Launchpad lag ein 32Khz Quarz bei das selbst bei 
Bedarf aufgelötet werden konnte, beim 5994er habe ich keins in der 
Verpackung gefunden. Die bestückten Lastkapazitäten gehen natürlich auch 
mit ein.
Digitale Korrektur habe ich noch nicht gemacht..halte ich für Pfriem...
das Ergebnins wird korrigiert, aber nicht die Ursache.

Gruß,

Holm

: Bearbeitet durch User
Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> das Ergebnins wird korrigiert, aber nicht die Ursache.

Das Prinzip der Kalibrierung.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Digitale Korrektur habe ich noch nicht gemacht..halte ich für Pfriem...

Ist aber weniger aufwändig als ein Trimmer, hat letztlich den gleichen 
Effekt. Außerdem kann man es automatisieren, damit ist es besser 
geeignet für eine Massenfertigung als ein Trimmer.

Schließlich, wenn du zeitweilig eine bessere Zeitreferenz vorliegen hast 
(DCF-77, GPS), kannst du damit die Abweichung zur Laufzeit ermitteln und 
den Korrekturwert nachziehen, damit die RTC auch dann noch möglichst 
genau geht, wenn das Referenzsignal mal nicht anliegt. *)

Gemacht habe ich das selbst allerdings auch noch nicht.

*) Ja, man könnte das auch mit einer Kapazitätsdiode und einem DAC 
machen. :-)

: Bearbeitet durch Moderator
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Holm T. schrieb:
>> das Ergebnins wird korrigiert, aber nicht die Ursache.
>
> Das Prinzip der Kalibrierung.

Nein, Kalibrierung vergleicht nur gegen ein Normal.

https://de.wikipedia.org/wiki/Kalibrierung

Was du meinst ist Justage …

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Holm T. schrieb:
>> das Ergebnins wird korrigiert, aber nicht die Ursache.
>
> Das Prinzip der Kalibrierung.

Nein, das nennt man laborieren am Symptom.

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Holm T. schrieb:
>> Digitale Korrektur habe ich noch nicht gemacht..halte ich für Pfriem...
>
> Ist aber weniger aufwändig als ein Trimmer, hat letztlich den gleichen
> Effekt. Außerdem kann man es automatisieren, damit ist es besser
> geeignet für eine Massenfertigung als ein Trimmer.
>
> Schließlich, wenn du zeitweilig eine bessere Zeitreferenz vorliegen hast
> (DCF-77, GPS), kannst du damit die Abweichung zur Laufzeit ermitteln und
> den Korrekturwert nachziehen, damit die RTC auch dann noch möglichst
> genau geht, wenn das Referenzsignal mal nicht anliegt. *)
>
> Gemacht habe ich das selbst allerdings auch noch nicht.
>
> *) Ja, man könnte das auch mit einer Kapazitätsdiode und einem DAC
> machen. :-)

..will auch Keiner.
Sicherlich hat Du Recht und das einstellen eines Trimmers ist ja auch 
nicht ganz ohne. Automatisieren kann man auch einen Schraubendreher :-) 
.
Der Nachteil der digitalen Korrektur ist, das die Referenz dann Sprünge 
hat.

Gruß,
Holm

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..Funktelefon..muß wohl das hier gewesen sein:

https://de.wikipedia.org/wiki/URTES-Netz

Es gibt aber irgendwo einen hybscheren Artikel mit Bildern und Details.

Gruß,
Holm

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Der Nachteil der digitalen Korrektur ist, das die Referenz dann Sprünge
> hat.

Wenn du häufiger als einmal pro Sekunde interrupten lässt, kannst du die 
Sprünge allerdings auf den Subsekundenbereich einschränken, was für 
viele Fälle genügt.  Im Prinzip könnte man das Verfahren so weit 
ausfeilen, dass man normalerweise nur einen Interrupt pro Sekunde macht 
und lediglich dann, wenn mal wieder ein Sekundenbruchteil korrigiert 
werden soll, für eine (knappe oder reichliche) Sekunde lang die höhere 
Auflösung aktiviert, um entsprechend einzugreifen.

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...also Pfriem :-))

Gruß,

Holm

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Finde ich nicht wirklich toll.  Das sind 28 ppm Abweichung, da sollte
> mit einem 32-kHz-Quarz mehr machbar sein.

Guten Morgen,

Jörg, das war nur ein ganz grober Vergleich mit dem PC beim Auslesen. 
Ich werde das messtechnisch noch untersuchen. Die Auflösung vom PC war 
ja auch nur 1s. Was ich damit besagte war, dass sich die Zeitanzeige vom 
LP nicht vom PC unterschied, mit einer Ablese Unsicherheit von 1s. Ich 
habe das leider unglücklich formuliert.

Ganz abgesehen davon, wäre mir der DS3232 o.ae. wegen der internen 
Temperaturkompensierung lieber. Auch wenn man den Quarz kalibrieren 
würde oder einen digitale SW Korrektur Mechanismus einführen würde 
bleibt immer noch der parabolische Temperaturgang. Allerdings könnte man 
beim MSP auch noch die Temperatur miteinbeziehen. Dann könnte man vll. 
damit leben. Hängt halt davon ab ob es nur im Zimmer funktionieren muss 
oder auch draußen zwischen -40 bis 35 Grad. -40 kommen hier regelmäßig 
im Winter vor.

Gruss,
Gerhard

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Nein, das nennt man laborieren am Symptom.

Die Frage ist was man erreichen will.

Ich kann beliebig hohen Aufwand treiben um jegliche unerwünschte 
Abweichung bereits im Grundsatz zu beheben oder ich kann die Natur 
dieser Abweichung aufnehmen und herausrechnen.

Seit kühlschrankgroße Analogschaltungen für eine Fantastillion zunehmend 
durch Kreditkartengroße MCU Schaltungen für wenige Euro ersetzt wurden, 
neigt man des öfteren dazu die Möglichkeiten digitaler Algorithmen auch 
zu nutzen.

Ein paar Zeilen Code kosten keinen Platz, ziehen keinen Strom, driften 
nicht über Temperatur und Spannung, müssen nicht eingekauft und gelagert 
werden.
Jeder manuel abzugleichende Trimmer erfordert einen Messaufbau + 
Arbeitszeit, treibt die Kosten nach oben und schafft die zusätzliche 
Fehlerquelle 'Mensch'

Welche Vorgehensweise m.E. gepfriemel ist sollte wohl klar sein.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Holm T. schrieb:
>> Der Nachteil der digitalen Korrektur ist, das die Referenz dann Sprünge
>> hat.
>
> Wenn du häufiger als einmal pro Sekunde interrupten lässt, kannst du die
> Sprünge allerdings auf den Subsekundenbereich einschränken, was für
> viele Fälle genügt.  Im Prinzip könnte man das Verfahren so weit
> ausfeilen, dass man normalerweise nur einen Interrupt pro Sekunde macht
> und lediglich dann, wenn mal wieder ein Sekundenbruchteil korrigiert
> werden soll, für eine (knappe oder reichliche) Sekunde lang die höhere
> Auflösung aktiviert, um entsprechend einzugreifen.

Das wäre mal ein interessanter Versuch, den MSP430 im Schlaf ähnlich wie 
beim DS3232 die RTC softwaretechnisch zu kompensieren.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Hängt halt davon ab ob es nur im Zimmer funktionieren muss oder auch
> draußen zwischen -40 bis 35 Grad.

Volle Zustimmung.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> Ich habe dafür die bekannte Schaltung mit 2 Mosfets erfolgreich
> eingesetzt.
> (siehe Anhang)
> IMHO habe ich dafür auch noch kleine leere Platinchen herumliegen,
> könnte ich Dir evtl. schicken ohne am Porto Pleite zu gehen.

Hallo Holm,

danke fürs Angebot. Ist sehr nett von Dir. Ich habe aber schon einige 
Platinchen vom Chinesen mit gerade dieser Philips MOSFET Schaltung 
drauf. Allerdings ohne Spannungsregler. Das wird aber für I2C FW 
Versuche ausreichen. Die 5V für den 5V Teil kann ich ja von der LP 
Platine abgreifen.

Die Geschichte mit dem HP1000 finde ich traurig. Wirklich schade um das 
Teil. Bei uns ersetzten sie dann spaeter die Kühlschrank großen 30cm 
Diskpacks mit einem 3RU großen Einschub SCSI Dual Festplattensystem und 
HP1000 auf SCSI Bus Adapter. Die Dinger waren sehr robust. Einmal fiel 
die Wasser Klimaanlage im Computerraum aus und die Raumtemperatur 
schnellte auf +50 oder höher hinauf und die Anlage (4xHP1000) 
funktionierte immer noch ohne Ausfall.


Gruesse,
Gerhard

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holm T. schrieb:
> ..Funktelefon..muß wohl das hier gewesen sein:
>
> https://de.wikipedia.org/wiki/URTES-Netz
>
> Es gibt aber irgendwo einen hybscheren Artikel mit Bildern und Details.
>
> Gruß,
> Holm

Danke für die Info. Scheint ähnlich wie unser System gewesen zu sein. 
Der Wiki sagt allerdings nichts über den aktuell benutzten 
Frequenzbereich aus. Offiziell war die Reichweite bei uns auch bei 40km 
angegeben. In der Praxis, speziell von Hügeln aus mit den gestockten 
Fahrzeugdachantennen kam man auf wesentlich höhere Reichweiten. Die 
damaligen Ölfirmenkunden liebten das System.

HF technisch gesehen ist das heutige Zellularsystem reichweitenmaessig 
nicht einmal ansatzweise vergleichbar. Auch wurden bei uns sehr hohe 
Antennen Masten und hohe Sendeleistungen benutzt (bis zu 200m) weil die 
Reichweiten optimal sein mussten.

Ich habe noch so ein Mobilfunkgerät und es ist technisch wunderschön 
aufgebaut - und schwer:-). Da werkeln zwei 80C85 drin - Kein Quad Core 
CPU. Motorola PLL ICs. TCXO Frequenzstandard. RX mit NE60x ZF. Da war 
auch ein Luft Resonatoren Antennen Diplexer drin. Ein FAX Maschinen 
Anschluss war auch vorhanden. Hat 40W Sendeleistung. Gebaut für die 
Ewigkeit. Nur konnte niemand wissen, dass der liebe Fortschritt die 
zuverlässigste Technik kannibalisiert:-)

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Holm T. schrieb:
>> Nein, das nennt man laborieren am Symptom.
>
> Die Frage ist was man erreichen will.
>
> Ich kann beliebig hohen Aufwand treiben um jegliche unerwünschte
> Abweichung bereits im Grundsatz zu beheben oder ich kann die Natur
> dieser Abweichung aufnehmen und herausrechnen.
>
> Seit kühlschrankgroße Analogschaltungen für eine Fantastillion zunehmend
> durch Kreditkartengroße MCU Schaltungen für wenige Euro ersetzt wurden,
> neigt man des öfteren dazu die Möglichkeiten digitaler Algorithmen auch
> zu nutzen.
>
> Ein paar Zeilen Code kosten keinen Platz, ziehen keinen Strom, driften
> nicht über Temperatur und Spannung, müssen nicht eingekauft und gelagert
> werden.

Ja..das ist ja der Blödsinn.

Hat das Quarz einen negativen TK, kompensiert man mit einem Kondensator 
mit  Positivem.
Davon abgesehen halte ich es zumindest für Blödsinn einen Serienaufbau
softwaremäßig zu kompensieren, wenn dort Bilderbuchmäßig 2x 22pf als 
Lastkapazität eingebaut wurden, ohne zu checken was man mit 
beispielsweise 1x22 und 1x18pf erreicht.

> Jeder manuel abzugleichende Trimmer erfordert einen Messaufbau +
> Arbeitszeit, treibt die Kosten nach oben und schafft die zusätzliche
> Fehlerquelle 'Mensch'


Sagen junge und dynamische Manager.

>
> Welche Vorgehensweise m.E. gepfriemel ist sollte wohl klar sein.


Höre doch einfach auf zu agitieren, oder wie tauschen jetzt die Rollen, 
ich kann Dir den selben Käse auch erzählen.
Ich bin mir recht sicher das uns Beiden die Vor- und Nachteile beider 
Methoden klar sind. Du mußt jetzt nicht gezwungenermaßen das Gegenteil 
behaupten nur weil ich das geschrieben hatte.
Irgend einen Lerneffekt bei mir löst da was Du da schreibst auch nicht 
aus.

Gruß,

Holm

: Bearbeitet durch User
Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Holm T. schrieb:
>> Ich habe dafür die bekannte Schaltung mit 2 Mosfets erfolgreich
>> eingesetzt.
>> (siehe Anhang)
>> IMHO habe ich dafür auch noch kleine leere Platinchen herumliegen,
>> könnte ich Dir evtl. schicken ohne am Porto Pleite zu gehen.
>
> Hallo Holm,
>
> danke fürs Angebot. Ist sehr nett von Dir. Ich habe aber schon einige
> Platinchen vom Chinesen mit gerade dieser Philips MOSFET Schaltung
> drauf. Allerdings ohne Spannungsregler. Das wird aber für I2C FW
> Versuche ausreichen. Die 5V für den 5V Teil kann ich ja von der LP
> Platine abgreifen.


Naja, ich habe auch beim Chinesen welche machen lassen..und da ist 
einfach noch Rest...
>
> Die Geschichte mit dem HP1000 finde ich traurig. Wirklich schade um das
> Teil. Bei uns ersetzten sie dann spaeter die Kühlschrank großen 30cm
> Diskpacks mit einem 3RU großen Einschub SCSI Dual Festplattensystem und
> HP1000 auf SCSI Bus Adapter. Die Dinger waren sehr robust. Einmal fiel
> die Wasser Klimaanlage im Computerraum aus und die Raumtemperatur
> schnellte auf +50 oder höher hinauf und die Anlage (4xHP1000)
> funktionierte immer noch ohne Ausfall.
>
>
> Gruesse,
> Gerhard

Ja, geärgert hat es mich auch, aber irgendwann läuft mir Sowas wieder 
über den Weg. Wenn man Etwas unbedingt haben will muß man danach suchen 
und Geld ausgeben. Hat man das dann erst einmal und mühevoll repariert, 
spricht sich das beim Krempel herum und der Krempel findet dann Dich...

Gruß,

Holm

Autor: Holm T. (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Holm T. schrieb:
>> ..Funktelefon..muß wohl das hier gewesen sein:
>>
>> https://de.wikipedia.org/wiki/URTES-Netz
>>
>> Es gibt aber irgendwo einen hybscheren Artikel mit Bildern und Details.
>>
>> Gruß,
>> Holm
>
> Danke für die Info. Scheint ähnlich wie unser System gewesen zu sein.
> Der Wiki sagt allerdings nichts über den aktuell benutzten
> Frequenzbereich aus. Offiziell war die Reichweite bei uns auch bei 40km
> angegeben. In der Praxis, speziell von Hügeln aus mit den gestockten
> Fahrzeugdachantennen kam man auf wesentlich höhere Reichweiten. Die
> damaligen Ölfirmenkunden liebten das System.
>
> HF technisch gesehen ist das heutige Zellularsystem reichweitenmaessig
> nicht einmal ansatzweise vergleichbar. Auch wurden bei uns sehr hohe
> Antennen Masten und hohe Sendeleistungen benutzt (bis zu 200m) weil die
> Reichweiten optimal sein mussten.
>
> Ich habe noch so ein Mobilfunkgerät und es ist technisch wunderschön
> aufgebaut - und schwer:-). Da werkeln zwei 80C85 drin - Kein Quad Core
> CPU. Motorola PLL ICs. TCXO Frequenzstandard. RX mit NE60x ZF. Da war
> auch ein Luft Resonatoren Antennen Diplexer drin. Ein FAX Maschinen
> Anschluss war auch vorhanden. Hat 40W Sendeleistung. Gebaut für die
> Ewigkeit. Nur konnte niemand wissen, dass der liebe Fortschritt die
> zuverlässigste Technik kannibalisiert:-)

Ich schätze mal das das damals 70cm Technik gewesen ist. Köpenick hat 
später auch ganze Reihen kommerzieller Funktechnik im 2m und 70cm 
Bereich gebaut die u.A. bei der Polizei und der Feuerwehr aber auch bei 
der Deutschen Reichsbahn im Einsatz waren. Ich hatte von letzteren 
Geräten auch noch ein paar vom Schrott gezogen, waren wohl 10 und 20 
Watt Geräte im Duplexverfahren also mit Gegensprechen, die Weichen waren 
Koaxialkreise..

Gruß,

Holm

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.