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?
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.
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
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.
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
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.
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
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/mcu/msp430/MSP-EXP430FR5994/latest/index_FDS.html Viel Erfolg!
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.
infoman schrieb: > Da kommt der AVR Quatsch nicht mit. Kannst du einfach die billige Polemik stecken lassen? Danke.
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
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?
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
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.
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.
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. :)
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.
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
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, ...
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.
..wohl ein besonders dümmliches Exemplar von Troll.. Gruß, Holm
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
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.
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
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.
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
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
1 | configure --target=msp430 |
bauen können, oder?
guck mal in den Port.. /usr/ports/devel/gcc-msp430-ti-toolchain Gruß, Holm
OK, tnx! Wenn ich mal wieder Zeit habe, mit dem Launchpad rumzuspielen, welches noch in der Ecke liegt …
..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
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.
... ich meine: KEINE Bücher verwenden, nur TI-Seiten und die PDFs runterziehen! Gruß Bernd
Na, dann wird ja langsam alles besser. Gut so.
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
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
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.tsp?baseLiteratureNumber=slac536&fileType=zip 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/HART_Modem_IC_HT20C15-LQ_Application_Note.pdf 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?
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?
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).
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...?
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.
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. :)
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.
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
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.
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.
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
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
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
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
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
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
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.
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?&contentType=3&releasePeriod=179#Microcontrollers%20%28MCU%29 (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.
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
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)
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
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.
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
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
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.
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 ...
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.
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
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
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
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. ;-)
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
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
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.
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
1 | Status |
2 | |
3 | - Most instructions need less clocks than the original. |
4 | - Synthesizes in Lattice Diamond for the MachXO2 requiring ~1260 Slices (two-cycle multiplier) @ >40 MHz, tested, works. |
5 | - Synthesizes in XST for Spartan 2 using a bit less than 1200 Slices (fits in a XC2S100). Testing pending. |
6 | - Synthesizes in XST for Spartan 3 using ~1150 Slices, hw-multiplier. Testing on real FPGA pending. |
7 | - 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. |
8 | |
9 | - All 6809 opcodes have been implemented. |
10 | |
11 | - 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
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.
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
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
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?
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.
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
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
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.
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
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
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
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
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.
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
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
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 :).
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.
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
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
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
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/MSP430-G2744BP/open-source-hardware
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)
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
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
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.
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-low-power-mcus/products.html ("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/launchpads.html#msp430_mcu
:
Bearbeitet durch User
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
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-low-power-mcus/products.html > ("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/launchpads.html#msp430_mcu Nichts Neues also. Gruß, Holm
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":
1 | again: |
2 | mov a, th0 |
3 | mov r7, tl0 |
4 | cjne a, th0, again |
5 | mov r6, a |
6 | ret |
Für den 8051 gab es sehr viele Bücher mit Beispielcode in Assembler, z.B. von Philips und AMD.
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.
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.
1 | NAME |
2 | MSPDebug - debugging tool for MSP430 MCUs |
3 | |
4 | SYNOPSIS |
5 | mspdebug [options] driver [command ...] |
6 | |
7 | DESCRIPTION |
8 | MSPDebug is a command-line tool designed for debugging and programming |
9 | the MSP430 family of MCUs. It supports the eZ430-F2013, eZ430-RF2500, |
10 | Launchpad, Chronos, FET430UIF, GoodFET, Olimex MSP430-JTAG-TINY and |
11 | MSP430-JTAG-ISO programming tools, as well as a simulation mode. |
1 | This is free software; see the source for copying conditions. There is NO |
2 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
3 | Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc. |
4 | |
5 | Using new (SLAC460L+) API |
6 | MSP430_GetNumberOfUsbIfs |
7 | MSP430_GetNameOfUsbIf |
8 | Found FET: mspfet0010 |
9 | MSP430_Initialize: mspfet0010 |
10 | Firmware version is 31200604 |
11 | MSP430_VCC: 3300 mV |
12 | MSP430_OpenDevice |
13 | MSP430_GetFoundDevice |
14 | Device: MSP430F1611 (id = 0x0070) |
15 | 8 breakpoints available |
16 | MSP430_EEM_Init |
17 | Chip ID data: |
18 | ver_id: 6cf1 |
19 | ver_sub_id: 0000 |
20 | revision: 20 |
21 | fab: 40 |
22 | self: 0000 |
23 | config: 00 |
24 | fuses: 00 |
25 | Device: MSP430F1611 |
26 | |
27 | Available commands: |
28 | ! fill power setwatch_r |
29 | = gdb prog setwatch_w |
30 | alias help read simio |
31 | blow_jtag_fuse hexout regs step |
32 | break isearch reset sym |
33 | cgraph load run verify |
34 | delbreak load_raw save_raw verify_raw |
35 | dis md set |
36 | erase mw setbreak |
37 | exit opt setwatch |
38 | |
39 | Available options: |
40 | color gdb_default_port |
41 | enable_bsl_access gdb_loop |
42 | enable_fuse_blow gdbc_xfer_size |
43 | enable_locked_flash_access iradix |
44 | fet_block_size quiet |
45 | |
46 | Type "help <topic>" for more information. |
47 | Use the "opt" command ("help opt") to set options.
|
48 | Press Ctrl+D to quit. |
49 | |
50 | (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
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.
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_Source_Package) > 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
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.
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:
1 | 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
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. :/
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).
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
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
Holm T. schrieb: > --läuft das auch auf einer Dyson Sphere? Eklige Vorstellung, wie? Windows 8.1 war wirklich hassenswert.
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.
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
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.
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
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.)
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...
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!
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
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
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
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
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
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
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
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
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.
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.
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.
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
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
Angehängte Dateien:
-
20181010_160927_resized.jpg
5,4 KB
... 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
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
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
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
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
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).
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.
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
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
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
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
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.
..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
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!
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
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
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
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.
..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
Holm T. schrieb: > das Ergebnins wird korrigiert, aber nicht die Ursache. Das Prinzip der Kalibrierung.
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
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 …
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
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
..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
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.
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
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.
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.
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.
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
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:-)
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
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
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
Gerhard O. schrieb: > Hallo Bernd, > > was gibt es bei Dir Neues mit Deiner MSP430 Bord? Irgendwelche > Überraschungen? Hallo Gerhard, ... ich bin noch nicht ganz wieder zurück angekommen... Ich hatte oben etwas von Selbstdisziplin geschrieben, damit meinte ich mich! Ich musste mich noch auf mein Projekt vorbereiten. Dann nächster Punkt: Die Spannungsreferenz für den A/D-Wandler bezieht der MSP430 in unserer Variante aus dem Referenzmodul. Das habe ich nach Deinem Anmerken ebenfalls gefunden. Somit kann über die Control-Register zum Wandler auch die Referenz nicht umgeschaltet werden. - Das für die Jungs und Mädels, die später einmal diesen Thread lesen. Im Users Guide müssen wir einmal nachsehen, ob die 32kHz Referenz schaltbare Kondensatorbänke hat. Das haben viele moderne Chips mit Frequenzaufbereitung. Dann wäre da noch die Zeitkorrektur / -Kompensation in Sekunden pro Woche möglich. Dieses Verfahren haben viele Geräte namhafter Hersteller, z. B. Bosch (Wärmetechnik) oder Crouzet in den SPS. Weiteres Lösungssuchen später... wahrscheinlich nach dem 31.10.. Ach ja, in der betreffenden Tagesschau war eine Wetterkarte abgebildet, in der über Canada eine riesen Wolke lag. Kommentar des Moderators, nur so könne man ... als Nachbarn ertragen. So far Bernd
Hallo Bernd, Danke für die Nachrichten. Habe selber zur Zeit mit Aussenarbeiten am Grundstück zu tun und wenig Gelegenheit zum Spielen mit Elektronik. Der Winter steht vor der Tür. War hatten kurzfristig schon 10cm. Bin gespannt welche Erfahrungen Du damit machen wirst. Meine nächsten MSP430 Eroberungen sollen I2C, SPI, CRC sein. Den Analog Comparator möchte ich auch noch auf den Zahn fühlen. Meine bisherige Steuer SW funktioniert sehr sauber. Mit der SW kann ich bequem alle relevanten Register auslesen und setzen, 8x Analog auslesen mit Die-Temperatur und die interne geteilte Betriebsspannung. Ich mag jetzt mittlerweile diesen uC sehr gern. Die Zeit ihn gut genug zu erlernen wird sich für ein paar Anwendungen bestimmt lohnen auch wenn es nicht unbedingt das Arbeitspferd für das erwähnte Projekt werden sollte. Der Debugger ist schon eine feine Sache wenn man ihn mal braucht. Danach möchte ich die verschiedenen Schlaf Möglichkeiten ausprobieren um Stop and Go Betrieb Erfahrungen zu sammeln. Ich möchte mir bei Gelegenheit auch eine eigene Platine entwerfen. Die Launchpad ist für den Anfang zwar sehr bequem, macht aber doch nicht alles was ich speziell möchte. Die Launchpaduhr ist einigermaßen genau. Ich ließ sie ein Woche laufen und habe nur 1-2s Abweichung beobachtet. Wenn man bedenkt, daß der Quarz unselektiert oder abgeglichen ist, ist es trotzdem nicht so schlecht. Ich habe eine Eigenbau STM32F103 Platine mit RTC Batterie und interner RTC die ich jetzt mindestens ein Jahr rumstehen hatte und kürzlich las ich die Zeit aus und sie war nur um 5min falsch. Der Quarz ist dort auch nicht abgeglichen. Ob es sich lohnt den MSP-FET zu kaufen? An sich könnte eine Steckerverbindung zum Launchpad Debugger auch ihren Zweck erfüllen. Naja, das hat ja noch Zeit. Gruß, Gerhard Bernd B. schrieb: > Gerhard O. schrieb: >> Hallo Bernd, >> >> was gibt es bei Dir Neues mit Deiner MSP430 Bord? Irgendwelche >> Überraschungen? > > Hallo Gerhard, > > ... ich bin noch nicht ganz wieder zurück angekommen... > > Ich hatte oben etwas von Selbstdisziplin geschrieben, damit meinte ich > mich! Ich musste mich noch auf mein Projekt vorbereiten. > > Dann nächster Punkt: Die Spannungsreferenz für den A/D-Wandler bezieht > der MSP430 in unserer Variante aus dem Referenzmodul. Das habe ich nach > Deinem Anmerken ebenfalls gefunden. Somit kann über die Control-Register > zum Wandler auch die Referenz nicht umgeschaltet werden. - Das für die > Jungs und Mädels, die später einmal diesen Thread lesen. Ich habe schon eine Ausweichlösung dafür. Muß es aber erst ausprobieren. > > Im Users Guide müssen wir einmal nachsehen, ob die 32kHz Referenz > schaltbare Kondensatorbänke hat. Das haben viele moderne Chips mit > Frequenzaufbereitung. Dann wäre da noch die Zeitkorrektur / > -Kompensation in Sekunden pro Woche möglich. Dieses Verfahren haben > viele Geräte namhafter Hersteller, z. B. Bosch (Wärmetechnik) oder > Crouzet in den SPS. Ich glaube es macht für gewisse Anwendungen weniger Arbeit einen DS3231 o.ä. extern dranzuhängen. Der kompensiert sich mit Temperaturschwankungen selber. > > Weiteres Lösungssuchen später... wahrscheinlich nach dem 31.10.. > > Ach ja, in der betreffenden Tagesschau war eine Wetterkarte abgebildet, > in der über Canada eine riesen Wolke lag. Kommentar des Moderators, nur > so könne man ... als Nachbarn ertragen. Ja. Da ist was Wahres dran:-) > > So far > > Bernd
:
Bearbeitet durch User
Gerhard O. schrieb: > Ob es sich lohnt den MSP-FET zu kaufen? Lohnt nicht. > An sich könnte eine > Steckerverbindung zum Launchpad Debugger auch ihren Zweck erfüllen. So ist es. Wir hatten uns damals in der Firma das FET gekauft. Ende vom Lied: habe ich in der VM nicht zum Laufen bekommen, IAR hat die Hände gehoben, läge wohl an der TI-DLL. Launchpad als Debugger funktionierte dagegen out of the box, völlig klaglos, sowohl under Linux (Host) als auch Windows (VM).
Jörg W. schrieb: > Gerhard O. schrieb: >> Ob es sich lohnt den MSP-FET zu kaufen? > > Lohnt nicht. > >> An sich könnte eine >> Steckerverbindung zum Launchpad Debugger auch ihren Zweck erfüllen. > > So ist es. > > Wir hatten uns damals in der Firma das FET gekauft. Ende vom Lied: habe > ich in der VM nicht zum Laufen bekommen, IAR hat die Hände gehoben, läge > wohl an der TI-DLL. > > Launchpad als Debugger funktionierte dagegen out of the box, völlig > klaglos, sowohl under Linux (Host) als auch Windows (VM). Hallo Jörg, Dankeschön für Deinen Kommentar. Ja, mit der Launchpad funktioniert das alles wunderschön. Grüsse, Gerhard
Gerhard O. schrieb: > Ja, mit der Launchpad funktioniert das alles wunderschön. Dann lass es einfach dabei. ;-)
Hallo Gerhard, Hinweis: http://www.ti.com/lit/an/slaa322d/slaa322d.pdf Man könnte also über die Parabel aus Bild 4 oder eine Tabelle korrigieren. Dazu könnte man über einen bestimmten Zeitraum, z. B. Tage oder Wochen die aktuelle Temperatur des Boards aufaddieren (letztendlich mitteln, wie die Durchschnittstemperatur in diesem Intervall war und korrigieren). Klar, oberhalb und unterhalb 25°C in unterschiedlichen Variablen abspeichern, sonst hat man einmal bei 15°C und einmal bei 35°C den Mittelwert von 25°C, also nichts zu korrigieren und das wäre falsch oder ungeschickt. Den Watchdogtimer könnte man alle 2 Sekunden als Intervall-Timer programmieren und bei jedem 100-ten Ereignis den Messwert abspeichern. Die genaue Strategie und die genauen Parameter bitte selbst festlegen. Hier im Forum gab es jüngst einen Beitrag, wie man nur mit Integerwerten ohne Gleitkommazahlen auskommt. Daraus kann man sicher noch einiges ableiten. Und wenn man sowieso einen Sekunden Tic hat, kann man den Watchdog wieder als WD verwenden. Happy coding! Bernd
Gerhard O. schrieb: > Ob es sich lohnt den MSP-FET zu kaufen? Hallo Gerhard, hier findest Du Doku: http://www.ti.com/lit/ug/slau278ad/slau278ad.pdf Ich habe hier mittlerweile einige der FETs im Schrank und alle Versionen laufen so, wie die Hersteller beschrieben haben, keine Problem bei den Inbetriebnahmen. Erst hatte ich den Adapter mit LPT-Anschluss, dann den mit USB, dann den USB-Stick für F2011 bis F2013. Jetzt schreiben sie im Internet: http://www.ti.com/tool/MSP-FET430UIF The next generation flash emulation tool, MSP-FET has been released and replaces the MSP-FET430UIF kit. The MSP-FET430UIF is no longer recommended for new designs. The MSP-FET430UIF is a powerful flash emulation tool to quickly begin application development on the MSP430 MCU. It includes USB debugging interface used to program and debug the MSP430 in-system through the JTAG interface or the pin saving Spy Bi-Wire (2-wire JTAG) protocol. The flash memory can be erased and programmed in seconds with only a few keystrokes, and since the MSP430 flash is ultra-low power, no external power supply is required. The debugging tool interfaces the MSP430 to the included integrated software environment and includes code to start your design immediately. The MSP-FET430UIF development tools supports development with all MSP430 flash devices. Wäre ich konsequent, müsste ich mir das Teil auch wieder kaufen. Meine Empfehlung: Solange Du das 4-Draht J-TAG Interface nicht unbedingt brauchst, wisrt Du mit dem 2-Draht J-TAG (Spy-Bi-Wire) auskommen. Ich hatte auch schon einmal überlegt, ein Lauchpad zu zersägen und in ein Gehäuse zu bauen, na, ja... Hast Du Geld im Budget in Deiner Firma, bestell Dir das aktuelle Teil. Privat, warte, bis Du wirklich nicht anders kannst... Happy coding! Bernd
Hallo Bernd, Danke für den Hinweis auf dies Quarz App Note und Tipps. Recht nützliche Ratschläge sind da enthalten. Wäre ganz interessant ob man den MSP übungshalber als DS3231 Ersatz einspannen könnte. Da ließe sich einiges auf die Beine stellen. Man könnte törichterweise auch das Aging Verhalten des Quarzes vorprognostizieren und die Zukunft deuten:-) Man muß auch bei der Wahl des Quarzes sehr aufpassen und möglicherweise künstlich altern und sortieren. Bin fast der Ansicht, für Hobbyprojekte die Quarzanschlüsse des MSP hochzubiegen und einen TH Quarz in der Luft anzulöten. Da würde man sich die Probleme mit Feuchtigkeit und Verschmutzung schon von vornherein ersparen. Luft ist ja bekanntlich ein gutes Dielektrikum. Am besten wäre es langzeitmäßig die ganze Schaltung in einen hermetisch verschlossenen und mit Dessikant versehenen Alublock einzuschließen. Dann können sich alle frequenmaßgeblichen Komponenten mit gleicher Zeitkonstante verändern und verhindert unkontrollierte TK Exkursionen bis sich alle Komponenten angeglichen haben. Der MSP erlaubt da einige interessante Möglichkeiten für Betrieb und Überwachung die weit über die Möglichkeiten des DS3231 hinausgehen. OK auch noch über die Hinweise zum FET. Im Augenblick genügt mir der Launchpad Debugger. Wenn das Projekt in der Firma aktiv wird, ist auch Geld für die Werkzeuge da. Gruß, Gerhard Bernd B. schrieb: > Hallo Gerhard, > > Hinweis: > http://www.ti.com/lit/an/slaa322d/slaa322d.pdf > > Man könnte also über die Parabel aus Bild 4 oder eine Tabelle > korrigieren. > > Dazu könnte man über einen bestimmten Zeitraum, z. B. Tage oder Wochen > die aktuelle Temperatur des Boards aufaddieren (letztendlich mitteln, > wie die Durchschnittstemperatur in diesem Intervall war und > korrigieren). Klar, oberhalb und unterhalb 25°C in unterschiedlichen > Variablen abspeichern, sonst hat man einmal bei 15°C und einmal bei 35°C > den Mittelwert von 25°C, also nichts zu korrigieren und das wäre falsch > oder ungeschickt. > > Den Watchdogtimer könnte man alle 2 Sekunden als Intervall-Timer > programmieren und bei jedem 100-ten Ereignis den Messwert abspeichern. > Die genaue Strategie und die genauen Parameter bitte selbst festlegen. > > Hier im Forum gab es jüngst einen Beitrag, wie man nur mit Integerwerten > ohne Gleitkommazahlen auskommt. Daraus kann man sicher noch einiges > ableiten. Und wenn man sowieso einen Sekunden Tic hat, kann man den > Watchdog wieder als WD verwenden. > > Happy coding! > > Bernd
:
Bearbeitet durch User
Hallo Gerhard, danke für die Antwort! Beine hochbiegen geht, habe ich auch schon gemacht, aber immer nur im Probeaufbau. Davon rate ich ab! Baue Deine privaten Projekte immer so, dass Du sie später einmal richtigen Experten zeigen kannst, ohne Deinen professionellen Charakter zu demontieren. Vielleicht benötigst Du einmal Deine Schaltungen für Bewerbungen in einem anderen Unternehmen oder sogar in Deiner Firma (ich weiß immer noch nicht, welche...) Ich hatte schon einmal ein Projekt im Ex-Bereich Zone A. Da wurde alles mit Glasperlen zugeschüttet, auch die Hochfrequenzschaltungen - Mikrostreifenleitung und so. Obendrauf war so eine Art Honig, also wasserundurchlässige Masse. Die Geräte konnte man nach der Auslieferung nicht mehr öffnen oder abgleichen, aber prima durch neue ersetzen. Gestern bin ich beim Lesen auch auf einen Hinweis gestoßen, dass man die MSP430 auch noch feiner, als über 2- oder 4-Draht J-TAG programmieren kann. Also über 4-Draht, aber mit Urlader, Bootstrapper und so weiter, ich glaube auch SW-Update über UART. Damit hatte ich mich beim MSP430 noch nie auseinander gesetzt. Beim Z8 ganz ganz früher hatte ich es ja selbst programmiert. Dabei ist mir gleich eingefallen, dass man ein "verschüttetes" Gerät super bauen könnte und im Feld neue SW einspielen könnte. ... also kontaktlos, z.B. NFC, IR oder so. Zu Zeitsynchronisierung empfehle ich eigentlich einen Befehl über die Schnittstelle (HART) um sie zu setzen. Es wäre sicher möglich aus der Differenz und History die entsprechenden Korrekturwerte für Alterung, Abweichungskorrektur, etc. zu prognostizieren und die Cal-Termine nach hinten zu schieben. Das macht man ja im Labor mit den Meßgeräten ähnlich: Dreimal im Jahresrhythmus kalibriert und keine nennenswerten Abweichungen erlauben einmal aussetzen, dann später zweimal, usw. DS3231: Ich habe eben nachgesehen bei Maxim, +-3ppm sind eine Größenordnung besser als der normale Uhrenquarz hat. Du kannst sicher einen DS3231 ersetzen. Bedenke jedoch, SW kann Fehler enthalten, sollte nicht - weiß ich. Das, was die Maxim Ingenieure entwickelt haben beinhaltet abgeschlossene Ingenieurleistung. Dein Ansatz mit einem MSP430 startet vielleicht bei NULL. Wie auch immer, hobbymäßig wäre es interessant. Lob und Anerkennung wirst Du nicht viel ernten. So, jetzt brauche ich noch etwas Zeit, damit ich mit meinem MSP430 anfangen kann. Gruß in die Ferne! Bernd
Es kann schon lohnen, zumindest die Neuauflage des 'G2xxx-Launchpads
(MSP-EXP430G2ET) zu kaufen. Deren integrierter SBW-Adapter ist nicht
mehr mit der (alten und teuren) Hardware des MSP-FET430UIF aufgebaut,
sondern mit der neuen (und firmwareseitig auch offengelegten)
Ez-FET-Hardware. Obendrein gibt es jetzt auch Unterstützung fürs
Energiemonitoring ("EnergyTrace").
http://www.ti.com/tool/msp-exp430g2et
Ansonsten sollte man den MSP-FET430UIF (graue Kiste) nicht mehr (als
Neugerät) anschaffen, der MSP-FET (kleine schwarze Schachtel) ist die
schnellere und leistungsfähigere Variante.
Angehängte Dateien:
Rufus Τ. F. schrieb: > der MSP-FET (kleine schwarze Schachtel) ist die > schnellere und leistungsfähigere Variante. Hallo Rufus, hast Du einen link? Ich hatte ja bereits geschildert, dass ich ein Launchpad durchsägen wollte. Dann hat man aber nur den 2-Draht J-TAG. Ansonsten hier noch einmal ein Foto, das ich bereits vor ein paar Wochen hochgeladen hatte. Gruß Bernd
Bernd B. schrieb: > hast Du einen link? Das Ding ist auf der Seite des MSP-FET430UIF (http://www.ti.com/tool/MSP-FET430UIF) verlinkt, von der hier im Thread bereits ausführlich zitiert wurde: http://www.ti.com/tool/msp-fet Dein Bild zeigt die erste reine SBW-Implementierung, die als ez430F2013 verkauft wurde: http://www.ti.com/tool/EZ430-F2013 Darin ist in abgespeckter Form exakt die gleiche Hardware wie im alten MSP-FET430UIF verbaut, es fehlen nur die Treiberbausteine für 4-Draht-JTAG, und die Firmware ist künstlich kastriert. Auf dem alten G2-Launchpad war die gleiche Hardware mit ähnlicher, und ebenfalls kastrierter Firmware untergebracht. Rein theoretisch ist es also möglich, den Ez430F2013 oder das alte G2-Launchpad zum vollwertigen MSP-FET430UIF mit 4-Draht-JTAG-Unterstützung umzubauen, aber ... das dürfte sich echt nicht mehr lohnen.
Hallo Bernd, Bernd B. schrieb: > Hallo Gerhard, > > danke für die Antwort! > > Beine hochbiegen geht, habe ich auch schon gemacht, aber immer nur im > Probeaufbau. Davon rate ich ab! Baue Deine privaten Projekte immer so, > dass Du sie später einmal richtigen Experten zeigen kannst, ohne Deinen > professionellen Charakter zu demontieren. Ja. Ich weiß:-) Wenn man wirklich stabile extrem hochohmige Sachen bauen will ist Luft trotzdem das beste Dielektrikum. (>1000MOhm) Beim Oszillator muss man halt die PCB nach allen Regeln der Kust reinigen. T.I. empfiehlt ja für den Oszillator Teil einen Silikon konformalen Ueberzug. > > Vielleicht benötigst Du einmal Deine Schaltungen für Bewerbungen in > einem anderen Unternehmen oder sogar in Deiner Firma (ich weiß immer > noch nicht, welche...) > > Ich hatte schon einmal ein Projekt im Ex-Bereich Zone A. Da wurde alles > mit Glasperlen zugeschüttet, auch die Hochfrequenzschaltungen - > Mikrostreifenleitung und so. Obendrauf war so eine Art Honig, also > wasserundurchlässige Masse. Die Geräte konnte man nach der Auslieferung > nicht mehr öffnen oder abgleichen, aber prima durch neue ersetzen. So etwas liebe ich überhaupt nicht. Wir verwenden fuer diesen Zweck Ex. sichere schwere Gehäuse und I.S. Barrieren. > > Gestern bin ich beim Lesen auch auf einen Hinweis gestoßen, dass man die > MSP430 auch noch feiner, als über 2- oder 4-Draht J-TAG programmieren > kann. Also über 4-Draht, aber mit Urlader, Bootstrapper und so weiter, > ich glaube auch SW-Update über UART. Damit hatte ich mich beim MSP430 > noch nie auseinander gesetzt. Beim Z8 ganz ganz früher hatte ich es ja > selbst programmiert. Dabei ist mir gleich eingefallen, dass man ein > "verschüttetes" Gerät super bauen könnte und im Feld neue SW einspielen > könnte. ... also kontaktlos, z.B. NFC, IR oder so. Ja. Das geht. Ein Bekannter von mir ladet neue Programme mittels ESM12/8266 drahtlos. > > Zu Zeitsynchronisierung empfehle ich eigentlich einen Befehl über die > Schnittstelle (HART) um sie zu setzen. Es wäre sicher möglich aus der > Differenz und History die entsprechenden Korrekturwerte für Alterung, > Abweichungskorrektur, etc. zu prognostizieren und die Cal-Termine nach > hinten zu schieben. Das macht man ja im Labor mit den Meßgeräten > ähnlich: Dreimal im Jahresrhythmus kalibriert und keine nennenswerten > Abweichungen erlauben einmal aussetzen, dann später zweimal, usw. Das zukünftige Aktuator Projekt braucht höchstwahrscheinlich keine Echtzeituhr. Das ist hauptsächlich mein persönliches Interesse. > > DS3231: Ich habe eben nachgesehen bei Maxim, +-3ppm sind eine > Größenordnung besser als der normale Uhrenquarz hat. Du kannst sicher > einen DS3231 ersetzen. Bedenke jedoch, SW kann Fehler enthalten, sollte > nicht - weiß ich. Das, was die Maxim Ingenieure entwickelt haben > beinhaltet abgeschlossene Ingenieurleistung. Dein Ansatz mit einem > MSP430 startet vielleicht bei NULL. Wie auch immer, hobbymäßig wäre es > interessant. Lob und Anerkennung wirst Du nicht viel ernten. So sehe ich das auch. Was ich interessant finden würde, wäre ein Ensemble von Uhrenquarzen die aktuell Alterungsraten in beide Richtungen aufweisen und dann die Uhrenlaufgaenge statistisch auszuwerten. Damit könnte man die Alterungsrate vielleicht reduzieren. Ich las mal vor einigen Jahren eine Arbeit darueber wo das genauso gemacht wurde. Wenn man dann jeden Quarz mit dem hochfrequenten DCO Signal zählt erhält man dann für jeden Quarz Perioden Werte die relativ zueinander das aktuelle Aging zueinander in Relation bringen. Wenn man dann diese Summen auswertet bekommt man einen Mittelwert der eine geringere Alterungsrate hat als ein einzelner Quarz. Das geht aber nur wenn man die Quarze entsprechend aussucht. Sie müssen über +/- 3 ppm gestreut sein. Citizen arbeitete in den siebziger Jahren an einer hochgenauen Armbanduhrkonzept wo zwei Uhrenquarze gegeneinander verglichen wurden um den Temperaturgang zu kompensieren. Der eine Quarz hatte eine normale Umkehrtemperatur und der Zweite eine um einen genauen bestimmten Betrag tiefere UKT so dass sich die Kurven der Parabeln gegenläufig überschneiden. Da beide Quarze um einige zig. kHz voneinander verschieden sind bleibt die Differenzfrequenz bei Temperaturänderungen annähernd konstant. Ich kann leider nicht den Artikel darueber finden. Natürlich wird die resultierende Alterung davon nicht beeinflusst. Clevere Leute, die Japaner! Also, es gibt da noch interessante Konzepte zum erproben... Schönen Abend noch, Gerhard > > So, jetzt brauche ich noch etwas Zeit, damit ich mit meinem MSP430 > anfangen kann. All the power to you! > > Gruß in die Ferne! > > Bernd
Bernd B. schrieb: > Gestern bin ich beim Lesen auch auf einen Hinweis gestoßen, dass man die > MSP430 auch noch feiner, als über 2- oder 4-Draht J-TAG programmieren > kann. Also über 4-Draht, aber mit Urlader, Bootstrapper und so weiter, > ich glaube auch SW-Update über UART. Das nennt sich BSL, das ist ein etwas verfrickeltes UART-Protokoll. Das kann jeder MSP430, nur belegt das Pins, die man sonst auch gerne mit anderen Dingen nutzen will, anders als die SBW-Pins. Obendrein lässt sich BSL nicht mit einem einfachen Terminalprogramm o.ä. nutzen, das Protokoll ist dazu einfach zu verkorkst.
Im Anhang ein Artikel über die Seiko Dual Quarz Methode der Temperatur Kompensation. Angeblich sollen +/-5s/a erreicht worden sein. (Meine erste Erklärung war übrigens falsch.) Siehe auch: https://forums.watchuseek.com/f9/seiko-twin-quartz-specs-153545.html
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > BSL, das ist ein etwas verfrickeltes UART-Protokoll. BSL läuft über UART, I²C, oder USB, je nach Chip. > Das kann jeder MSP430 Außer die ganz kleinen Flash-Modelle, z.B. MSP430G2001.
Gerhard O. schrieb: > Ich kann leider nicht den > Artikel darueber finden. Hallo Gerhard, gut dass wir darüber sprechen: https://forums.watchuseek.com/f9/thermocompensation-methods-movements-2087.html Text oberhalb und unterhalb Fig. 11. Die zitierte Ref. 9 ist leider nicht mehr im Internet erreichbar. Ja, wieder etwas dazu gelernt, danke. Bei Deiner Beschreibung Gerhard O. schrieb: > mit dem hochfrequenten DCO Signal zählt meinst Du sicher nicht den DCO. Der Digital Controlled Oscillator wird verwendet um so eine Art PLL-System aufzubauen. Der DCO ist justierbar und eine Vielfache von 32kHz wird so weit geteilt, bis eben die 32kHz heraus kommen. Der DCO rastet dann auf 8MHz ein, wenn man ihn durch 244.14063 teilt und auf die 32.768kHz anbindet. Über die Modulationsregister bekommt man die Nachkommazahl. Früher war man an so komische Quarze wie z. B. Vielfache von 9.600Baud gebunden. Dann hat ein interner Zähler die Baudrate exakt heruntergeteilt, usw... Jetzt können wir mit dem DCO und dem Prinzip fast jeden Takt einstellen. Meist benutze ich zum Starten des Prozessors die 8MHz über die eingebauten Kalibrierwerte. Dann locke ich auf die 32kHz, usw. Sofern ich einmal in meinem Hausbussystem (eine der eigenen Applikationen) die 8MHz gefunden habe, findet keine weitere Korrektur statt. Das gesamte Bussystem läuft dann locker ein Jahr oder so ohne Nachabgleich. (Lob an TI.) Ab und zu springt dann das FI (Fieh - Fehlerstromschutschalter, Bauteil für Gewitter und so) raus und der Hausbus wird neu hochgefahren. Batterie-Pufferung habe ich nicht vorgesehen. Aber den Quarz an HFXT habe ich auch schon gemacht, ist halt klassisch. Mit dem von Dir benannten Verfahren kann man ja locker eine Temperaturkompensation durchführen. Ich sehe gerade in der Voransicht, Du hast die Literatur ebenfalls gefunden. Gruß Bernd
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.