Der MSP430-Tread II

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Der MSP430-Tread II

Beitrag von Kuddel »

Nachdem ich mich schon an der Auswahl der MSPs herumärgerte:

http://www.fingers-welt.de/phpBB/backup/22/39877_1.htm

mag ich den blöden MSP430 immer weniger. Das ganze Moped hinkt ja an allen Ecken und Kanten:
http://e2e.ti.com/support/microcontroll ... 93945.aspx
Der von mir ausgesuchte MSP2452 hat mit dem Launchpad 1.4 und einer gewissen Einstellung also ein Problem. Ich hab´gleich ein problem weniger *grummel*

Wollte ich nur mal aus Frust loswerden.
Gruß
Kuddel
...der die Zahnabdrücke aus der Tischkante erstmal wieder herausfeilt.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Also ich persönlich frag mich ja immer wozu diese 16bitter nötig sind.
Brauchste keine Leistung nimmste 8 bit, brauchste welche dann 32bit ARM/MIPS.
Aber 16bit?
Wirklich günstig sind die ja auch ned.

Die MSP sollen ja so stromsparend sein und für Batteriebetrieb ausgelegt sein.
Aber das Teil will maximal 3,6V und eine Liion Zelle liefert bis zu 4,2V <- toll für Batteriebetrieb ausgelegt wenns noch nen LDO brauch...

Die Timer von den Dingern haben ja mal überhaupt keine zufriedenstellenden Betriebsarten im vergleich zu Atmel prozessoren (AVR und ARM).

Also AVR gefällig der Herr? :lol:
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Fritzler hat geschrieben:
Also AVR gefällig der Herr? :lol:
Schön, dass es AVRs gibt. Jemand anders wird sagen: PIC alles andere stinkt und noch wieder jemand anders will nichts anderes aus Z80 haben.
Wir wissen alle, dass du einen AVR-Tick hast :)
Was ich damit sagen will: Wir sollten hier lieber am Problem selber arbeiten und nicht über andere Prozessoren diskutieren. Wer einen speziellen µC nicht mag, soll halt einen anderen verwenden. Die Beratung dazu sollte in ein anderes Thema ausgelagert werden, alleine schon weil die Gefahr eines Glaubenskrieges besteht, der dieses Thema hier empfindlich stören könnte.

Kuddel, hast du die Probleme schon in der Praxis gehabt? Ich habe auf den schnellen Blick am Ende der von dir verlinkten Diskussion etwas von Firmware Update des Programmers gelesen.
Hat das keine Abhilfe geschaffen?
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Das war bezogen auf:
Wollte ich nur mal aus Frust loswerden.
Und der Smily sitzt da nicht umsonst ...
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Sven hat geschrieben:Kuddel, hast du die Probleme schon in der Praxis gehabt? Ich habe auf den schnellen Blick am Ende der von dir verlinkten Diskussion etwas von Firmware Update des Programmers gelesen.
Hat das keine Abhilfe geschaffen?
Ich musste die Einstellung im Debugger ändern, dan ging es. Aber es ist inzwischen die dritte vollkommen unlogische Eigenart, die mir richtig Zeit gekostet hat.Irgendwann verliert man das vertrauen.
Fritzler hat geschrieben:Das war bezogen auf:
Wollte ich nur mal aus Frust loswerden.
Und der Smily sitzt da nicht umsonst ...
Hatte ich auch so verstanden. Also alles gut.

Aber dáccord bin ich immer noch nicht. Irgendwie ist im Debug-Modus die Resettaste unwirksam. Ich meine, das war vorher nicht. Inzwischen hat sich aber scheinbar das Composer-Studio selber ein Update gezogen, ist dabei abgestürzt *Koppschüddel*

Aber noch habe ich Mut.Zudem meine Software eigetlich echt dünn ist. Ein Display (also nur das nackte Glasdingens) soll die Temperatur aus dem Controller anzeigen.
Gruß
Kuddel
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Reset kann ja auch nicht mehr gehen, weil Spy by Wire auf dem Resetpin liegt :geek:
RST/NMI/SBWTDIO
Musst also ausm Debugmode raus damit das wieder geht.
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Fritzler hat geschrieben: Und der Smily sitzt da nicht umsonst ...
Dann nehm ich es zurück. Trotzdem der Hinweis, dass hier nicht zur Diskussion über andere Prozessoren ausarten zu lassen.
Jede Prozessorenfamilie wird so ihre spezifischen Probleme haben. Je breiter gefächert das ganze ist und je speziellere Prozessoren es gibt, desto vielfältiger werden die wohl ausfallen.

Ich habe hier noch irgendwo ältere Launchpads, kann ich dir damit testweise aushelfen? Von ein bischen Software, egal ob auf PC oder µC wollen wir uns doch nicht verarschen lassen!

Reset im Debugmode kann nicht gehen, weil über den Pin auch der Debugger/Programmer angeschlossen ist.
Nachtrag: Da war ich wohl zu langsam. Fritzler hat das auch schon erklärt ;)
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Bin ja nicht ganz unschuldig, So eine Steilvorlage für einen Prozessorkrieg hinzulegen.

Das mit dem Resetpin leuchtet ein. Obwohl ich felsenfest der Meinung bin, dass es vorher ging. Na ja, Wayne.

Bitte keine weiteren Launchpads ;-) In Zukunft keine MSPs mehr. Obwohl die geringe Stromaufnahme wirklich fein ist.
Inzwischen huschen ein paar Zahlen über das Display. Nach (wie ich gerade sehe) einenm halben Jahr Projektpause...
Den Rest mache ich später. Ich gehe erstmal in den eigenen Standbymodus ;-)
Gruß
Kuddel
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Ich muss ja gestehen, dass ich generell überhaupt kein Fan von Microcontrollern bin. Ich brauch mein Linux und meinen ganz normalen C Compiler, um Programme zu schreiben :D
Steuerungen versuche ich immer soweit wie möglich diskret und am allerbesten direkt elektrisch aufzubauen (mit Relais). :ugeek:

Zieht der Resetknopf den entsprechenden Pin auf Masse oder geht das als Leitung in den Programmer IC, der dann über seine Pins den µC Reset Pin gegen Masse schaltet?
Meine Launchpads liegen im kalten dunklen Keller, tief vergraben in einer Kiste. Ich will heute Nacht keinen Lärm mehr machen. Das kann ich frühestens morgen selber überpüfen.
(Insbesondere bei Elektronik mit mehreren Platinenvarianten glaube ich keinem Schaltplan blind)
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

In Zukunft keine MSPs mehr. Obwohl die geringe Stromaufnahme wirklich fein ist.
Wenn dir das Energiesparen wichtig ist, dann guck dich doch mal bei den Gecko EFM32 um.
Isn ARM, sehr stromsparend und hat auch nen Interface für nackte Glas LCDs.
Gibts allerdings nur in QFN und BGA :x

@sven:
Beim Debug wird in der CPU intern die Resetleitung vom Resetpin gelöst.
Sonst würde ja bei jedem Low während der Signalübertragung auf der Leitung der Prozessor resetten.
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Fritzler hat geschrieben: @sven:
Beim Debug wird in der CPU intern die Resetleitung vom Resetpin gelöst.
Sonst würde ja bei jedem Low während der Signalübertragung auf der Leitung der Prozessor resetten.
Klar, leuchtet ein. Hätte ich auch selber drauf kommen können. Dass die Kommunikation auch mal "lows" hat, war mir da grad nicht vor Augen :)
Wobei, ich würde µC Herstellern auch zutrauen, zum Debuggen einen eigenen Low-Pegel zu definieren, der den Reset sicher noch nicht auslöst. :twisted:

Mal sehen, mir steht bald vielleicht mal ein ernsthaftes Projekt ins Haus, dass einen µC erfordern könnte. Da bin ich mal auf meinen persönlichen Frustfaktor gespannt.
Benutzeravatar
flogerass
Beiträge: 1145
Registriert: Mo 12. Aug 2013, 17:46
Wohnort: Nord-Östlich von Ulm

Re: Der MSP430-Tread II

Beitrag von flogerass »

Fritzler hat geschrieben:
In Zukunft keine MSPs mehr. Obwohl die geringe Stromaufnahme wirklich fein ist.
Wenn dir das Energiesparen wichtig ist, dann guck dich doch mal bei den Gecko EFM32 um.
Oder die STM8L. Ich finde die Ausstattung von den Dingern genial! Und der Preis ist unschlagbar, und die ICD-Hardware gibts für fast geschenkt.
Dazu den Cosmic-Compiler, der so gut optimiert, dass man komplexe C-Programme noch in den kleinsten µC kriegt. Und dabei funktioniert das Debugging noch! (Da gibt's zumindest bei Microchip probleme) Ich weiß allerdings nicht wie da momentan die Lizenzierung aussieht.
Benutzeravatar
Longri
Beiträge: 112
Registriert: Sa 17. Aug 2013, 14:01
Wohnort: Potsdam
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Longri »

Moin,

ich finde Diskussionen über die Prozessorarchitekturen abartig. Das kommt gleich nach den Diskussionen über das beste Betriebssystem oder die beste Programmiersprache.

Jeder soll mit dem arbeiten, mit dem er am besten klar kommt. Wichtiger ist das er die Möglichkeiten seiner Architektur durch sauberen Code gut ausnutzt. Da ist alles andere nebensächlich. Der eine mag nun Z80 mit Assembler, der andere ATMEL oder ARM in C und der Dritte nimmt nun BASIC oder Luna auf irgendeiner Architektur.

Hinzu kommt das nicht jeder das "Programmier-Gen" in sich trägt und bei der aktuellen Codezeile schon genau weiß was in zwölf Zeilen später stehen soll. Genauso sieht es mit den booleschen Funktionen aus. Jeder der zwischenzeitlich die Bitschubserei auf Fußpilzebene beherrscht sollte sich mal erinnern wie lange er gebraucht hat bis er das begriffen hat.

Dem einen reicht es eben wenn auf der Arduino-Plattform einen Pin anmachen kann, der andere nimmt eben nur den ARM und schaufelt dort Bits. Deswegen mag ich auch solche Äußerungen á la "Faildiuno" & co. nicht. Für viele ist es eben der Einstieg in die Programmierung von µProzessoren.

Immer daran denken - Der Weg ist das Ziel.

in diesem Sinne

Gruß Longri
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Es soll ja mal ein Temperatrulogger werden. Die Temperaturmessung und Anzeige auf das LCD klappt nun.

Nun muss ich die Werte noch ins EEprom speichern, und dann auf den PC transferieren. Letzteres ist wegen des Gehäuses meine Herausforderung:
tempkl.jpg
tempkl.jpg (67.49 KiB) 3133 mal betrachtet
Das sehr nette Gehäuse (siehe Bild) von dem Moped hat einen kleinen, einklappbaren USB-Anschluss. Wäre es jedes andere Kabel würde ich die Daten über RS232 oder sonstwas in den PC bringen. Aber wenn schon so ein hübsches Kabel da ist, das nun mal USB haben muss...

Ich dachte erst, ich gebe PS2-Daten darüber. Klappt aber nicht, weil die so nicht vom USB-Port aufgenommen werden. Also muss ich was dazwischen machen, z.B. den Chip UC451A002. Den kann ich aber leider nirgends finden. Eine eigene USB-Routine ist mir zu stressig. Wird ja größer als das eigentliche Projekt.

Irgend welche weiteren Ideen, wie ich den USB-Stecker nutzen kann?
Gruß
Kuddel
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Wie wäre es mit seriellen Daten ala RS232 nur ohne Pegelwandler? Dann müsstest du nur aus so einem Kollegen hier ein spezielles USB Verlängerungskabel bauen: http://www.electrodragon.com/product/pl ... cables-1m/
Die Teile gibt es fertig in etwa zu dem Preis auch in anderen Formfaktoren. Bei diesem Kabel müsste wirklich nur noch eine USB Buchse angelötet werden.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Ach so, ich vergas zu schreiben: Von dem seriellen bin ich inzwischen auch weg, weil ich folgende Idee hatte:
Thermologger anschließen.
Excel oder so starten.
Start auf dem Logger drücken.
Automatisch wird die Tabellenkalkulation automatisch mit den Werten gefüllt.
Also bin ich inzwischen soweit, dass ich kein Extraprogramm für den PC brauchen kann. Die Daten landen sowieso in einer Tabellenkalkulation. Eine Frau soll das ganze nämlich Bedienen. Es ist somit völlig unmöglich, die Importfunktion von Ecel und Co zu verwenden, zu kompliziert ;-) Daher die Idee mit der Tastaturemulation.

Also Schwierigkeitsstufe2: USB UND einfach.
Gruß
Kuddel
bastelheini
Beiträge: 1663
Registriert: So 11. Aug 2013, 13:55

Re: Der MSP430-Tread II

Beitrag von bastelheini »

Oder du schreibst in Excel ein Script, welches auf Knopfdruck gestartet wird. Das kann deine seriellen Daten dann bequem und fehlerfrei auswerten. Die Tastaturversion ist anfällig, zb wenn der Mauszeiger woanders steht oder der Fokus auf dem falschen Fenster ist, Windows ein Update machen will und solche Sachen.


Dafür ist VBA doch gedacht und bei jedem Officezeugs dabei oder? Und MSComcontrol beherrscht das auch.
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Kuddel hat geschrieben: Also Schwierigkeitsstufe2: USB UND einfach.
Das schließt sich gegenseitig aus ;)
Eine gegen alle Eventualitäten gerüstete Software ist nicht mehr einfach zu programmieren.

Investier die Zeit lieber in eine saubere Doku möglicher Einzelprogramme. Das ist deutlich schneller und weniger fehlerlastig als eine vermeintlich einfach zu bedienende Software ;)

Eine Tastaturemulation scheitert schon an solch simplen Dingen wie schon genannt worden sind: Focus auf dem falschen Fenster. Irgendwas ploppt auf (was man nicht mehr unterdrücken kann) usw.

Nimmt man das aber in Kauf und ist sich der Konsequenzen bewusst gibt es doch noch folgende Möglichkeit:
Man könnte jetzt eine alte Tastatur auseinanderfriemeln und die Elektronik Verwerten. Der µC muss dann nur über das bereits vorhandene USB Kabel irgendwie die Tastenmatrix der Tastatur emulieren. Also geschickt die entsprechenden Kontakte kurzschließen.
Geht hier aber nicht komplett einfach, weil du auf den vorhandenen USB Stecker bestehst, der mit 4 Kabeln einfach zu wenig Leitungen hat. Da müsstest du evtl. mit einem Schieberegister oder I²C Portexpander arbeiten.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Sven hat geschrieben: Nimmt man das aber in Kauf und ist sich der Konsequenzen bewusst gibt es doch noch folgende Möglichkeit:
Man könnte jetzt eine alte Tastatur auseinanderfriemeln und die Elektronik Verwerten. Der µC muss dann nur über das bereits vorhandene USB Kabel irgendwie die Tastenmatrix der Tastatur emulieren. Also geschickt die entsprechenden Kontakte kurzschließen.
Geht hier aber nicht komplett einfach, weil du auf den vorhandenen USB Stecker bestehst, der mit 4 Kabeln einfach zu wenig Leitungen hat. Da müsstest du evtl. mit einem Schieberegister oder I²C Portexpander arbeiten.
Ja, sowas klingt gut.
Ich könnte dieses Ding hier:

http://www.reichelt.de/?%20ARTICLE=9781 ... av_tabprod
umbauen und mit PS2-Daten füttern.
Aber das IC, welches auf eben dieser Schaltung ist, müsste man doch irgendwie kriegen.
Ach so: Schwierigkeitsstufe 3: Ich brauche da 10 Stück von. So viele Gehäuse habe ich, und die will ich irgendwie verbasteln. Warum auch immer.

Edit: Dieses IC:
http://www.overclock.net/t/335084/rewir ... st_3903932
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Du brauchst nicht 10 Stück davon. Ein Adapterkabel reicht aus um alle 10 Sensoren auszulesen :)

Das Adapterkabel selber besteht aus der umgefrickelten Tastaturelektronik. Dafür musst du nur eine Tastatur zerlegen. Die µCs in den Temperaturloggern geben ihre Daten auf die USB Stecker aus und steuern damit im Adapterkabel irgendwie die alte Tastaturelektronik an. 4 Pins reichen für ein Schieberegister oder einen I²C Portexander aus.
Daran tüdelst du dann die Elektronik, die Tastendrücke auf der Tastatur emuliert.

Diese ganze Umwandlungsmimik erfolgt erst außerhalb der Logger. Die USB Anschlüsse deiner Logger führen gar kein USB Signal. Die kommen in eine speziell beschriftete USB Buchse mit der Ausgabeelektronik.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Ich wills ja immer noch komplett in das Gehäuse reinkriegen. Ich weiß, es ist nicht sonnvoll.
Um es mit den Worten eines ehemaligen Präsidenten: "Wir machen es nicht, weil es einfach ist. Sondern, weil es schwer ist."
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Dann musst du in den sauren Apfel beißen und eine USB Tastatur mit deinem µC emulieren. :D
Das beinhaltet eine vollständige Implementation des USB Protokolls.

Ansonsten halt die RS232 zu USB Lösung mit einem netten FTDI Chip IM Gehäuse und einer entsprechenden Software auf dem PC. Wenn du diese Software entsprechend intelligent baust
ist das nur ein Doppelklick auf "Daten laden", die dann direkt in eine Excel-Tabelle geschrieben werden und einmal Daten kopieren in die große Exceltabelle.

Openoffice Dateien sind nur gezippte XML Dateien, die könnte man direkt manipulieren.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Wieso Importfunktion in Excel?
Excel frisst auch so .csv, die muss nur etwas speziell sein.
-> Semikolon als Trennzeichen und \r\n für Newline

Ansonsten hier noch was für USB aufm MSP:
http://hackaday.com/2012/12/03/msp430-b ... d-usb-1-1/

Sonst gibts eigentlich kein Software USB für den MSP, weils die auch mit USB Hardware gibt.

Wenn alle Stricke reißen musste eben das AVR VUSB Projekt für den MSP430 portieren :lol:
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Bitbangig USB ist aber schon ein bischen pervers :D

Wahrscheinlich gibt es den MSP mit 7 Segment LCD Interface nicht mit Hardware USB :geek:
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Der hackadaylink ist schon heftig. USB über einen MSP in Assembler zu schreiben, Hut ab. Die Sache gucke ich mir mal an.
Mein MSP430 kann weder LCD noch USB. Die LCD-Funktion habe ich selber gemurkst, oder ge-Bitbangingt, wie Du so schön schreibst.

Gerade gefunden: den MAX3420E
http://e2e.ti.com/support/microcontroll ... 49793.aspx
Ist aber wohl eben so schwer zu beschaffen wie der UC451A002.

Inzwischen habe ich mir das Gehäuse noch mal angesehen. Ich habe mich da doch ein weing weit aus dem Fenster geleht, als ich sagte, da passt noch was rein.
Vielleicht gibt es noch eine ganz andere Möglichkeit.
Übrigens: In der Originalschaltung wird ein USB-Stick simuliert, in den eine (sehr hübsche) pdf generiert wird. Leider sind die Bausteine scheinbar nach dem schreiben geschützt.: Ein Windbond SPI-Flash W25x10BV. Als Hauptchip noch ein AT91SAM und ein kleiner Speicher Typ 24AA256.
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Da wird auf folgenden Baustein verwiesen: http://www.ti.com/product/TUSB3410
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Na da kannst ja gleich den FT232 nehmen :lol:

USB MUSS in Assembler geschrieben werden weils recht zeitkritisch ist, da muss die Bitzeit eben stimmen.
Zumindest bei den Gurken ohne Hardware USB.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Das gefällt mir an der PS2-Schnittstelle. Die kann ich mit ´nem Toastbrot schreiben, die ist so herrlich Zeitunkritisch ;-)
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Das PS2-Tastatur-Protokoll funktioniert jetzt. Jetzt wollte ich mal mir dem Interupt herumspielen.

Aber irgendwie verstehe ich das Launchpad nicht: Zuerst habe ich mit dem Code-Composer mein Programm geschrieben, und dann darüber gestartet.Es blieb dann auch an, auch wenn ich "Stopp" drücke. Alternativ habe ich eine Batterie angschlossen. Problem: Die Frequenz, mit dem er TI rennt, ist immer unterschiedlich. Mit Batterie läuft er langsamer als über den Code-composer gestartet. Und seid neuesten stoppt der MSP, wenn ich über Codecomposer stoppe. Ich finde leider nicht wirklich Informationen dazu.

Frage: Bekommt der MSP430 seinen Takt mal über das Launchpad, wenn dort angeschlossen, und mal über z.B. dem internen DSO?
Und wenn ja: wie kann ich es ändern?
Danke
Gruß
Kuddel
Benutzeravatar
Sven
Beiträge: 4421
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der MSP430-Tread II

Beitrag von Sven »

Hast du schonmal das MSP430 Tutorial zum Thema Clocks bzw. Taktquellen durchgearbeitet? Das Taktsystem der MSP430 Prozessoren ist wirklich etwas mächtig und unübersichtlich.
Das hängt aber auch damit zusammen, dass im Standby bestimmte Clocks weiterlaufen können, um Module des µCs zu versorgen.

Wie sieht es denn mit der Betriebsspannung aus? Der maximale Arbeitstakt ist von der Betriebsspannung abhängig. Das kommt auf einer der ersten "Folien" des Tutorial Workshops auch vor.
Am Launchpad läuft das Teil auf maximaler Betriebsspannung.

Für den internen Oszillator gibt es eine Kalibrierungstabelle, je nach Modell sind die sogar schon ab Werk kalibriert. Bei den Chips, die beim Launchpad mitgeliefert werden, ist die Kalibrierung für
eine Frequenz vorhanden.
Achtung, man kann das Register überschreiben, sowohl versehentlich, als auch zur Nachkalibrierung.
Benutzeravatar
augustamars
Beiträge: 705
Registriert: So 11. Aug 2013, 21:33
Wohnort: Augsburg
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von augustamars »

Werfe auch mal was rein.
Heute habe ich so eines bekommen, allerdings komplett leere Platine:
Bild
Ein MSP430 hätte ich da, aber brauche ich unbedingt den oberen Teil drauf oder geht Programmieren auch über JTAG / ISP o.ä. ?
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Das große IC oben rechts, ist leider ein MSP430 irgendwas. Nützt also nix ohne deren Programmierung. Aber das Launchpad selber sollte man günstig irgendwo herzu kriegen sein.

Gruß
Kuddel
Benutzeravatar
Dirk
Beiträge: 49
Registriert: Di 10. Sep 2013, 16:03

Re: Der MSP430-Tread II

Beitrag von Dirk »

Moin,
die MSP-Familie wurde nicht erfunden, um AVR, PIC usw. zu ersetzen, sondern kostengünstig und Ernergiesparend zu arbeiten. (Leuchtweitenregulierung, Autoinnenraumbeleuchtung dimmen, und vieles mehr.

Ich bekam von einem User aus dem Forum im Tausch so ein Board und versucht gleich mit der TI-Software zu arbeiten...Hmmm das ist nicht der Hit.

Dann fand ich etwas im Web. ENERGIA !!! Ein Superteil und ein Forum, was fast so gut ist wie bei Fingers! LOB

Forum Energia: http://forum.43oh.com/forum/28-energia/

Schaut es euch an und die Freude steigt für diese günstigen IC`s/MC`s. Sample ist auch möglich und erwünscht bei TI.

Im Forum >---ENERGIA sieht man, was da alles `rauszuholen ist, mit wenig Programmierarbeit.

Der Befehlssatz ist Ja übersichtlich.

Energia ist kostenlos... nur einfach, wie immer Reg. und man braucht auch nicht per E-Mail informiert werden.

Schaut mal nach.

Auch ein PRG des Monats ist da ausgeschrieben. Mitmachen und gewinnen.

Das Board bekommt man im Web oder bei TI. Letzter Preis war € 4.30 mit 2 MC`s.
LG
Dirk
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Eigentlich wollte ich heute weitermachen, mit dem Code: "die geloggten Temperatur ein mal pro Minute ins Flash schreiben".
Habe aber eine "Schreibblockade":
schreibblockade.jpg
schreibblockade.jpg (92.24 KiB) 2369 mal betrachtet
manuel
Beiträge: 765
Registriert: Fr 7. Feb 2014, 00:14

Re: Der MSP430-Tread II

Beitrag von manuel »

Hallo,

das sich Leute in DE über den MSP430 ärgern wundert mich kaum, den kennt ja fast niemand. Was beim MSP430 gut ist: es gibt nen GCC, es gibt nen 15 Euro GDB kompatiblen JTAG Adapter, und der schon erwähnte geringe Verbrauch. Und multplizieren kann er meistens auch recht flott, sogar "fractional arithmetic", sprich so a weng Signalverarbeitung geht auch. Mehrere Multitasking kernels gibts auch zur Auswahl.

Vor allem das es einen GCC dafür gibt finde ich gut, weil so kann man software auf nem PC testen und dann auf dem MSP430 einfach laufen lassen (portable software schreiben know how vorausgesetzt). Auf dem uC selber alles zu debuggen ist total doof, das sollte man lieber bleiben lassen.

Liebe Grüße,
Manuel
Benutzeravatar
ferdimh
Beiträge: 9381
Registriert: Fr 16. Aug 2013, 15:19

Re: Der MSP430-Tread II

Beitrag von ferdimh »

Könnte es sein, dass du aus der PIC-Ecke kommst?
Also GCC ist auch für AVR selbstverständlich... Es existiert da auch eine wirklich elaborierte Toolchain... JTAG-Debugging ist ebenfalls mit kostengünstiger Hardware möglich (habe ich aber noch nie genutzt - Mir konnte noch keiner plausibel erklären, wofür das wirklich gut ist - ich habe eigentlich immer einen anderen I/O-Kanal dafür genutzt).
Nach meinem Eindruck fällt der MSP430 (außer beim Stromverbrauch, der in dem Bereich selten relevant ist) genau in die Lücke zwischen AVR und ARM. Er kann nicht so viel mehr, dass es lohnen würde, mal eben eine neue Plattform kennen zu lernen. Dies könnte sich natürlich ändern, wenn Atmel bei Kenntnis seiner marktbeherrschenden Stellung die Preise weiter anzieht.
Nichtsdestotrotz darf man sich natürlich gerne mit dem Teil beschäftigen. Ich sehe nur nicht die Notwendigkeit, wenn es um "Getting the job done" geht. Aber das gehört eh eigentlich nicht hierher.
manuel
Beiträge: 765
Registriert: Fr 7. Feb 2014, 00:14

Re: Der MSP430-Tread II

Beitrag von manuel »

Hallo,

PIC ? Nö. Aber verständlich was du schreibst, PICs sind nun mal a weng seltsam (kein richtiger Stack, komische Wortbreiten, nicht linearer Speicher usw). Ein richtiger Stack und linearer Speicheradressraum ist schon mal ein guter Anfang.

Grüße,
Manuel
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Die Software ist fast fertig, ich muss nun nur noch die Werte ins Flash speichern. Genau hier stolpere ich gerade: Wo darf ich denn hinspeichern? Der Flash bei msp430g2452 ist 8 k Groß. Aber irgendwie werde ich nicht schlau draus, wo das Programm und so abgelegt ist.
Wenn das programm kleiner 1kB ist, kann ich einfach den Bereich 1024-7168, also hex 0400 bis 1C00 vollschreiben?
Danke
Gruß
Kuddel
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Gibt dir der Compiler keinen Assemblerdump?
Da siehste dann die Speicheradressen wo was liegt.
Ansonsten sollte alles ab 0x0 aufwärts liegen.
Benutzeravatar
flogerass
Beiträge: 1145
Registriert: Mo 12. Aug 2013, 17:46
Wohnort: Nord-Östlich von Ulm

Re: Der MSP430-Tread II

Beitrag von flogerass »

Was für eine Datei fällt denn bei deinem Kompiler hinten raus? Bei *.hex-Dateien kenne ich es so, dass da die absolute Adresse mit drin steht.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Ich mach gerade mal wieder Blödsinn:
for (tmp=0; tmp < speicheradresse ;tmp++){
//Wert ausgeben
Tastenauswahlps2(speicheradresse); //Den Wert "Speicheradresse" über die Tastaturausgeben
anzuzeigenderwert=tmp; //Der Wert wird im Display über einen Interrupt angezeigt
}
Diese Routine soll die gelöggten Werte aus dem Speicher an die Tastatur ausgeben.
Der Wert "speicheradresse" ist zu beginn "9".
Und so sieht adie Ausgabe aus:
9
70
70
70
etc.
Wieso wird der Wert "speicheradresse" plötzlich auf 70 geändert.

So funktionier es:
for (tmp=0; tmp < 9 ;tmp++){
//Wert ausgeben
Tastenauswahlps2(speicheradresse); //Den Wert "Speicheradresse" über die Tastaturausgeben
anzuzeigenderwert=tmp; //Der Wert wird im Display über einen Interrupt angezeigt
}
Ich finde den Fehler nicht.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Sicher, dass die Variable auf 70 springt und nicht das Anzeigen von 9 auf 10 diesen Effekt verursacht?

Zeig mal den Code zum Anzeigen.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Gerade probier: Wenn ich das anzeigen auskommentiere, dann ändert sich nichts.
Gruß
Kuddel
Edit: Wenn ich
Tastenauswahlps2(speicheradresse); //Den Wert "Speicheradresse" über die Tastaturausgeben
ausklammere, dann geht es.
So sieht die Routine dazu aus:

Code: Alles auswählen

void Tastenauswahlps2(int wert){
	 // Wert einer Taste zuweisen
	 int rausgeben;
	 int taste[9];
	 taste[0]=0x45;
	 taste[1]=0x16;
	 taste[2]=0x1E;
	 taste[3]=0x26;
	 taste[4]=0x25;
	 taste[5]=0x2E;
	 taste[6]=0x36;
	 taste[7]=0x3D;
	 taste[8]=0x3E;
	 taste[9]=0x46;
	 //zuserst das vorzeichen
	 if(wert<0){
		 ps2ausgabe(0x4a); //-
		 ps2ausgabe(0xF0);
		 ps2ausgabe(0x4a);
	 }
	 //Jetzt die Zehner
	 rausgeben=wert/10;
	 ps2ausgabe(taste[rausgeben]); //6
	 ps2ausgabe(0xF0);
	 ps2ausgabe(taste[rausgeben]); //6

	 //Einer
	 rausgeben=wert%10;
	 ps2ausgabe(taste[rausgeben]); //6
	 ps2ausgabe(0xF0);
	 ps2ausgabe(taste[rausgeben]); //6

	 // Und Enter
	 ps2ausgabe(0x5a); //Enter
	 ps2ausgabe(0xF0);
	 ps2ausgabe(0x5a);

 }
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Fehler gefunden:

Code: Alles auswählen

void Tastenauswahlps2(int wert){
	 // Wert einer Taste zuweisen
	 int rausgeben;
	 int taste[9];
	 taste[0]=0x45;
	 taste[1]=0x16;
	 taste[2]=0x1E;
	 taste[3]=0x26;
	 taste[4]=0x25;
	 taste[5]=0x2E;
	 taste[6]=0x36;
	 taste[7]=0x3D;
	 taste[8]=0x3E;
	 taste[9]=0x46;
 }
taste[9], aber 10 mal gefüllt. Der Wert ging denn "irgendwohin" *Grumel*
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der MSP430-Tread II

Beitrag von xoexlepox »

Kuddel hat geschrieben:Der Wert ging denn "irgendwohin"
Vermutlich nicht "igendwohin", sondern in "speicheradresse" der aufrufenden Funktion ;) Deshalb kam nach dem ersten Aufruf immer "70" dabei heraus ( 0x46 = 70 ).
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Ich muss da noch eine Frage stellen:
Der MSP430 hat doch so einen herrlich niedrigen Stromverbrauch. Habe jetzt mal den MSP vom Launchpad runtergenommen und mitsamt Display etc. auf ein Breadboard geklemmt. Ergebnis: 0,63 mA.
Der MSP läuft auf 32kHz-Quarz, der schwingt auch, und ist auch so initialialisiert (BCSCTL3|=XCAP_3;). Ziehe ich den Quarz ab, bleibt der Prozessor stehen.
Die Peripherie baucht nur 0,1 mA, habe auch jeden Pin mal abgesteckt, scheint auch kein Fehler drin zu sein.
Der Stromverbrauch sollte doch wesentlich niedriger sein, oder liege ich falsch?
Gruß
Kuddel
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Guck doch mal ins Datenblatt da gibts doch sicherlich Diagramme für Takt und Stromverbrauch.
Auch die Spannung ist wichtig, bei 3,3V zieht der ja mehr als bei 1,8V.

Ansonsten muss der ja nicht immer auf Volldampf arbeiten, also programmier doch mal noch Sleepmodes ein.
Damit der nur aufwacht wenn was zu tun ist und sich dann wieder schlafen legt.
Benutzeravatar
Kuddel
Beiträge: 5074
Registriert: Fr 28. Jun 2013, 10:56
Wohnort: Denk immer an St. Alamo!

Re: Der MSP430-Tread II

Beitrag von Kuddel »

Sleep geht nicht, weil er ja das Display treiben muss. Das Display hat keinen Treiber, ist nur das Glasteil, ohne Elektronik.
Laut Datenblatt sollte es wesentlich weniger sein. 220µAbei 1Mhz, bei 32kHz entsrechend weniger.
Gruß
Kuddel
manuel
Beiträge: 765
Registriert: Fr 7. Feb 2014, 00:14

Re: Der MSP430-Tread II

Beitrag von manuel »

Hallo,

wegen dem Flashschreiben: man kann globale Variablen mit entsprechende direktiven einer bestimmten Speicher "section" zuweisen. Diese muß dam beim linken einer bestimmten adresse zugewiesen werden und alles ist gut. Mit GCC macht man das so:

__attribute__ ((section (".flashrw")))
const char meine_daten[256] = { 0 , 1, 2, 4, 5 , 6 };

Beim linken dann folgendes in die LDFLAGS einbauen:

-Wl,--section-start -Wl,.flashrw=0xf400

meine_daten landet dann bei Adresse 0xf400. Es sollte klar sein das dies nur geht wenn meine_daten const ist...
Bei den MSP430 die ich verwendet hab war die Flash block größe 256 bytes, deshalb sollte man schauen das der linker nicht auf die Idee kommt in einen der flash blöcke die man beschreibt irgendwas anderes reinzupflanzen, also entsprechend "padden".

Zu den sleep modi, da gibts mindestens 4 wenn ich mich recht entsinne...

Grüße,
Manuel
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der MSP430-Tread II

Beitrag von Fritzler »

Padden geht dann mit:

__attribute__((section (".flashrw")))
__attribute__((aligned(256)))
const char meine_daten[256] = { 0 , 1, 2, 4, 5 , 6 };
Beim linken dann folgendes in die LDFLAGS einbauen:

-Wl,--section-start -Wl,.flashrw=0xf400
Oder nen Linkerscript einbauen, ist dann etwas schöner zu bedienen.
Braucht man aber eigentlich eher bei ARM.
Antworten