Hi. Stefanus F. schrieb: > Wenn wir in Zusammenhang mit STM32 von einer HAL sprechen, dann meinen > damit die Cube HAL, ein Produkt von ST. Wer ist "wir" ? Ich zumindest nicht... > > Du kannst gerne deinen eigenen Sprachgebrauch entwickeln, aber dann sind > Konflikte zu erwarten. Du reagierst hier auf ein Problem aggressiv, dass > du selbst erzeugt hast. Hier muss ich aber widersprechen und mich (ein wenig) auf die Seite von W.S. stellen. Derjenige mit dem "ungenauen" Sprachgebrauch warst jetzt DU, denn DU hast in einem Thread der ursprünglich mit MSP430 begann einfach mal von HAL geschrieben und dabei das ganz spezifische "Cube HAL" gemeint, was aber zum einen nur eine Lib für eine ganz bestimmte Familie von mehreren in diesem Thread angesprochenen ist und zum anderen zwar "HAL" im Namen hat (und auch eine gewisse Abstraktion herbeiführt) aber es ist keine vollständige HAL im Wortsinn, sondern einfach das was andere Hardwarehersteller mit Library und/oder LowLevel Treiber benennen. (wobei die Cube HAL, wie viele andere von den Controllerherstellern bereitgestellt Bibliotheken IN TEILBEREICHEN natürlich auch über das hinausgeht was man als LowLevel bezeichnen kann) Denn wenn diese Cube HAL deine oberste Abstraktionsschicht ist, du aus deinem Hauptprogramm direkt mit der CubeHAL arbeitest, dann ist dieses Programm weiterhin absolut HArdwarespezifisch und nicht einmal ansatzweise Portabel. Noch nicht einmal wenn du von ein STM M3 auf einen beliebigen M3 eines anderen HErstellers wechselst. Für den Wechsel musst du dann genauso an deinem HAuptprogramm herumschrauben Im privaten Bastelprojekten mag das vielleicht keinen großen Unterschied machen, im kommerziellen Umfeld kann das wirklich erhebliche Auswirkungen haben. Kleine Änderungen an vielen Stellen bedeuten einfach einen wahnsinns Aufwand sobald bei der SW Erstellung bestimmte normative Anforderungen eingehalten werden müssen. (Wie z.B. Entwicklung nach EN62304 oder Vergleichbares für andere Branchen). Da du das Hauptprogramm veränderst musst du quasi weit vorne im Entwicklungsprozess wieder anfangen und hast beginnend ab dem Schritt Software Architektur nahezu denselben Test- und Dokumentationsaufwand wie bei einer kompletten Neuerstellung. Mit einer richtigen, gut durchdachten, HAL greifst du jedoch nur an einem Punkt ein, vor allem aber änderst du nichts an den eigentlichen Programmalgorithmen. Damit keine Änderung an dem eigentlichen Programmablauf und vor allem keine änderung an der Architektur. Was nicht geändert wurde muss weder erneut durchs Review noch erneut im Rahmen von Unit- und Integrationstests getestet werden. Bleibt halt nur noch das Review für die neue HAL und natürlich der Systemtest um sicherzustellen das alles richtig läuft. Und auch bei der späteren (neu) Validierung des Produktes kann man ggf. ordentlich Arbeit sparen! Gruß Carten
Holm T. schrieb: > Du machst irgendwas falsch (Pegel an Anschlüssen mit Pullup?). > Beim G2553 hatte ich in LPM1 deutlich weniger als 1µA worauf hin ich > beschlossen hatte den Einschalter für die Mimik weg zu lassen. > Speisung erfolgte aus einer R6 großen Lithium Primärzelle. Ich krieg folgende Werte: LPM0: 80µA LPM1: 79µA LPM2: 30µA LPM3: 13µA bei 3,33V (wobei ich alle anderen Messgeräte und Breakouts entfernt habe). Der Verbrauch der Pullups im Leerlauf ist praktisch nicht (kaum) messbar. Im Betrieb sollten die Pullups max. 2 x 3,33V / 120K = 54µA ziehen. Vielleicht liegts an der MIL-Version des MSP430 die ich nicht besitze.
:
Bearbeitet durch User
Carsten S. schrieb: > Derjenige mit dem "ungenauen" Sprachgebrauch warst jetzt DU, denn DU > hast in einem Thread der ursprünglich mit MSP430 begann einfach mal von > HAL geschrieben und dabei das ganz spezifische "Cube HAL" gemeint Verdrehe nicht die Tatsachen. Lothar hat mit HAL angefangen. Mein erster Beitrag dazu war dieser: Stefanus F. schrieb: > Die HAL muss man nicht benutzen. Wenn man mit Produkten eines Hersteller arbeitet und sich für einen Fachmann hält, sollte man mit der Nomenklatur des Herstellers vertraut sein. Die Cube HAL gibt es seit über 5 Jahren. Wenn jemand in Zusammenhang von Windows von einem Fenster spricht, meint er auch nicht das Loch in der Hauswand. Und mit Explorer ist ganz klar der Dateimanager gemeint, oder denkst du dabei an einen Mann in Jack-Wolfskin Montur? > Denn wenn diese Cube HAL deine oberste Abstraktionsschicht ist, du aus > deinem Hauptprogramm direkt mit der CubeHAL arbeitest, dann ist dieses > Programm weiterhin absolut HArdwarespezifisch und nicht einmal > ansatzweise Portabel. Noch nicht einmal wenn du von ein STM M3 auf einen > beliebigen M3 eines anderen HErstellers wechselst. Da hast du meine volle Zustimmung. Genau aus diesem Grund bin ich von Cube HAL nicht begeistert. Dazu kommen noch immer wieder gravierende Bugs.
Angehängte Dateien:
Andreas V. schrieb: > Stromverbrauch bei LPM0; ca. 80µA bei 3,3V Wenn das Programm nichts mehr vor hat, dann geht auch LPM4. (Siehe Abschnitt 2.3 des User's Guide.) Und wie bei allen anderen µCs auch, solltest du alle nicht benutzten Pins als Ausgang (oder wenigstens als Eingang mit Pull-Up/-Down) konfigurieren (siehe Abschnit 2.5 des User's Guide). Rufus Τ. F. schrieb: > Für LPM0 werden 56 µA angegeben (typ), Deine gemessenen 80 µA sind also > ein ziemlich guter Wert, insbesondere, wenn man bedenkt, daß Du bei 50% > höherer Versorgungsspannung gemessen hast (3.3V statt 2.2V). Auch mit 3,3 V sollte der Wert nicht so hoch sein.
:
Bearbeitet durch User
Holm T. schrieb: > Du machst irgendwas falsch (Pegel an Anschlüssen mit Pullup?). > Beim G2553 hatte ich in LPM1 deutlich weniger als 1µA Andreas nutzt LPM0, nicht LPM1.
W.S. schrieb: > So langsam werd ich böse. > > Also: SchalteLampe() ist die HAL. Viele (ich auch) unterscheiden halt nochmal zwischen der abstrakten Hardware (Lampe, Schalter, Ventil) gegen die die Anwendung arbeitet und der Abstraktion der physikalischen Prozessorperipherie (GPIO, SPIU, CAN, etc.) gegen den die erstere arbeitet und mischen das nicht wild durcheinander so wie Du das propagierst. Deshalb wird noch ne Schicht eingezogen und der Portieraufwand sinkt erheblich wenn man den µC wechselt oder die Lampe woanders anschließt. Die obere Schicht (schalte_lampe()) ist meist nur hauchdünn aber notwendig um dafür zu sorgen daß die untere Schicht (die HAL des Prozessors) nichts mehr von "Lampen" und dergleichen wissen muß.
:
Bearbeitet durch User
W.S. schrieb: > Also: SchalteLampe() ist die HAL. Da gibt es keine weitere HAL, denn > SchalteLampe() erledigt das sowohl plattformspezifisch, also auch > projektspezifisch. Eine Anwendung kann durchaus mehrere Abstraktionschichten haben. HAL bezeichnet allgemein die unterste Ebene. Weil hier gegen die Hardware abstrahiert wird. Also durchaus sowas wie SetGPIO, ReadI2C oder SendUART Auf so einer HAL können nun auch weitere Ebenen aufsetzen. z.B. Treiber für bestimmte Bausteine oder höhere Bussysteme/Protokolle. Oder auch direkt die Anwendung. > Und wenn Änderungen anstehen, z.B. µC Wechsel oder Schaltungsänderungen, > dann mußt du das ohnehin in deiner Software auch ändern. Da kommst du > niemals drumherum. Fragt sich bloß, wo überall in deine Firmware. Genau. Und wenn man sowohl Plattform als auch Anwendung in eine einzige Abstraktionsschicht packt, dann muss diese immer bei jeder Änderung anpacken. Eine spezieller Treiber oder Protokoll der durch eine HAL auf die Hardware zugreift muss nur angefasst werden, wenn sich das Protokoll selbst ändert. Gerade Änderungen an der Hardware lassen diese Teil dann kalt.
Rufus Τ. F. schrieb: > Holm T. schrieb: >> Du machst irgendwas falsch (Pegel an Anschlüssen mit Pullup?). >> Beim G2553 hatte ich in LPM1 deutlich weniger als 1µA > > Andreas nutzt LPM0, nicht LPM1. Ja..und ich meinte eigentlich LPM3..also falsche Baustelle. Gruß, Holm
Holm T. schrieb: > Rufus Τ. F. schrieb: >> Holm T. schrieb: >>> Du machst irgendwas falsch (Pegel an Anschlüssen mit Pullup?). >>> Beim G2553 hatte ich in LPM1 deutlich weniger als 1µA >> >> Andreas nutzt LPM0, nicht LPM1. > > Ja..und ich meinte eigentlich LPM3..also falsche Baustelle. > > Gruß, > > Holm Ich weiss was falsch lief! Und wieder mal habe ich erlebt dass Theorie und Praxis identisch sind. Ich habe die Spannung auf 2,2V heruntergesetzt. Im Realbetrieb stimmen die Werte dann mit den Werten im Datenblatt überein. Probleme: - Ich kann nicht mehr debuggen. - Der MSP430 lässt sich nicht mehr programmieren. ;-) Andreas
:
Bearbeitet durch User
Andreas V. schrieb: > Probleme: Dein Debuginterface weiß auch von der reduzierten Versorgungsspannung? Verwendest Du das G2-Launchpad (wenn ja, welches), oder verwendest Du eines der "großen" JTAG-Interfaces (MSP-FET bzw. MSP-FET430UIF)?
Rufus Τ. F. schrieb: > Dein Debuginterface weiß auch von der reduzierten Versorgungsspannung? > > Verwendest Du das G2-Launchpad (wenn ja, welches), oder verwendest Du > eines der "großen" JTAG-Interfaces (MSP-FET bzw. MSP-FET430UIF)? Hey Cool! Jetzt weiss ich auch wofür "Override Defaults" und "Target Vcc in Volt" ist. Allerdings bringt mich nur bedingt weiter, weil das "VCC(PGM/ERASE) Program and erase supply voltage" (Siehe Seite 40 im MSP430G2553 Datenblatt) von 2,2V bis 3,6V geht. Das ist grenzwertig! Ich habe - zwei MSP-EXP430G2 - ein MSP-EXP430F5529LP
:
Bearbeitet durch User
Hast Du Dir gerade betonte Mühe gegeben, meine Frage falsch zu verstehen?
Rufus Τ. F. schrieb: > Hast Du Dir gerade betonte Mühe gegeben, meine Frage falsch zu > verstehen? Ich verwende die ganze Zeit in erster Linie das MSP-EXP430G2 über SBW und 3,3V wenn Du das meinst.
Bernd K. schrieb: > Viele (ich auch) unterscheiden halt nochmal zwischen der abstrakten > Hardware (Lampe, Schalter, Ventil) gegen die die Anwendung arbeitet und > der Abstraktion der physikalischen Prozessorperipherie (GPIO, SPIU, CAN, > etc.) gegen den die erstere arbeitet und mischen das nicht wild > durcheinander so wie Du das propagierst. Ich mische hier garnichts, sondern mache es direkt: HW<--->LLTreiber<--->Anwendung. Das ist ne robuste Konfiguration. Wenn man es macht wie du es vorschlägst, dann wird daraus: HW<--->LibFunc<--->LLTreiber<--->Anwendung. Das schafft dann eine Abhängigkeit von der betreffenden LibFunc - und die ist fast immer bei den heutigen IDE's nicht im Projekt selber, sondern außerhalb des Projektes. Damit machst du dir ne Abhängigkeit auf von der Toolchain. Ein Projekt, was mit einer IDE und einem Compiler funktioniert, versagt dann gelegentlich bei einer anderen IDE und/oder einem anderen Compiler. Ich selber kenne das zur Genüge, schließlich tanze ich seit langen Jahren zwischen NEC, Fujitsu und Arm herum und kann und will mich nicht abhängig machen von den Eigenheiten der jeweiligen Tools. Da soll NICHTS Unnötiges zwischen LL-Treiber und HW stehen. Und LibFunc ist unnötig, denn deren Autoren können es nicht besser als man selbst im LL-Treiber. So wie du das schreibst, nehme ich an, daß du es immerzu nur mit dem gleichen Environment zu tun hast. Deshalb bemerkst du nicht, wie dünn das Eis ist, auf dem du dich bewegst. Ich habe den ganz bestimmten Eindruck, daß all die Leute, die lieber eine LibFunc zum Wackeln am Pin benutzen als selbiges selbst zu tun, eine ganz tief sitzende Heidenangst haben vor jeder direkten Berührung mit der Hardware. Deshalb machen sie das, selbst wenn das dazu führt, daß die Performance damit drastisch in den Keller geht. Das Argument der Portierbarkeit ist albern, schließlich ist es entweder gar kein Aufwand, wenn man innerhalb der funktionskompatiblen µC-Familie bleibt oder es muß ohnehin der LL-Treiber umgeschrieben werden, wenn man einen anderen Hersteller wählt - weil dann die vorherige LibFunc garnicht mehr zur Verfügung steht. Ich mache dir mal nen Vorschlag: Lies dich mal etwas in die Supportfiles von Nuvoton ein und vergleiche das dann mit dem Pendant von ST. Und wenn dann das Rauchen deines Kopfes nachgelassen hat, wirst du meine Argumente etwas besser verstehen. Das Portieren eines LL-Treibers an eine andere Hardware ist zumeist einfacher als das Anpassen eines LL-Treibers an einen andersartigen Satz von Supportfiles. Nun haben wir hier den alleprimitivsten Fall des Pin-Wackelns besprochen. Andere Peripherie ist da fast immer komplexer - und da muß man sehen, ob das Fremd-Zeugs von Chip- oder Tool-Herstellern (Keil,IAR,Gcc,ST,NXP,Coocox,... etc) als LL-Treiber was taugt oder nicht. In der Regel taugt es nicht dazu, sondern ist eher als Anregung oder Beispiel zu sehen. Wenn es tatsächlich was taugen würde, dann könnte man die Hierarchie auf HW<--->LibFunc<--->Anwendung. verkürzen. Aber ich habe noch kein einziges Hersteller-File gesehen, das übergreifend eine wirkliche hardwareunabhängige Schnittstelle nach oben geboten hätte. Keil hat so etwas zwar versucht, aber die sind dann doch mittendrin stecken geblieben. W.S.
Nun, gerade schriebst Du, daß Du bei 2.2V nicht programmieren und debuggen könntest, und da stellt sich für mich halt die Frage, wie Du das überhaupt mit dem MSP-EXP430G2 hinbekommen möchtest. Das nämlich unterstützt nur den Betrieb mit 3.6V, und biete keine anpassbare Targetspannung. (Zu sehen in http://www.ti.com/lit/ug/slau318g/slau318g.pdf, Seite 12, Tabelle 4)
Rufus Τ. F. schrieb: > Nun, gerade schriebst Du, daß Du bei 2.2V nicht programmieren und > debuggen könntest, und da stellt sich für mich halt die Frage, wie Du > das überhaupt mit dem MSP-EXP430G2 hinbekommen möchtest. > > Das nämlich unterstützt nur den Betrieb mit 3.6V, und biete keine > anpassbare Targetspannung. > > (Zu sehen in http://www.ti.com/lit/ug/slau318g/slau318g.pdf, Seite 12, > Tabelle 4) Danke, das hatte ich nicht mehr in Erinnerung. Das Merkwürdige dabei ist allerdings dass er mit 2,8V sehr wohl flashen und debuggen kann. Man verzeihe mir: Ich verwende IAR; Eclipse habe ich auf dem kleinen Netbook nicht mehr zum Laufen bekommen. Was mich auch wundert. IAR disabled normalerweise Optionen die man nicht benutzen darf. "Override Defaults" und "Target Vcc in Volt" sind aktiviert...
:
Bearbeitet durch User
Andreas V. schrieb: > Das Merkwürdige dabei ist allerdings dass er mit 2,8V sehr wohl flashen > und debuggen kann. Naja, dann ist vielleicht der vom µC kommende High-Pegel gerade noch so im Rahmen, daß die SBW-Hardware des Launchpads (effektiv ein leicht abgespeckter MSP-FET430UIF) sie als High-Pegel erkennen kann. Schick ist das nicht, denn die SBW-Hardware liefert in Gegenrichtung einen 3.6V-Pegel in Deinen µC, d.h. 0.8V über VCC. Um bei anderen Betriebsspannungen als den vorgegebenen 3.6V programmieren/debuggen zu können, ist dann doch ein "vollwertiges" Debuginterface wie der MSP-FET oder der ältere MSP-FET430UIF nötig. Die beiden können ihre "Target"-Spannung zwischen 1.8V und 3.6V verstellen. Wenn Du den Schaltplan des MSP-FET430UIF (zu finden in http://www.ti.com/lit/ug/slau647l/slau647l.pdf) vergleichst mit dem des G2-Launchpads (zu finden in http://www.ti.com/lit/ug/slau318g/slau318g.pdf), wirst Du feststellen, daß dem Launchpad der einstellbare Spannungsregler U3 fehlt, der vom 'F1612 über Pin 5 (ein DAC-Ausgang) angesteuert wird.
0,5V Differenz gehen meisten noch gut, darüber ist mit Problemen zu rechnen.
Stefanus F. schrieb: > 0,5V Differenz gehen meisten noch gut, darüber ist mit Problemen zu > rechnen. Spätesterns jetzt ist der Punkt erreicht, als aus "Entwicklung" "Basteln" wurde :-)
TrollJäger schrieb: > Stefanus F. schrieb: >> 0,5V Differenz gehen meisten noch gut, darüber ist mit Problemen zu >> rechnen. > > Spätesterns jetzt ist der Punkt erreicht, als aus "Entwicklung" > "Basteln" wurde :-) Die 0,5V sind nicht frei erfunden, sondern ergeben sich aus dem Spannungsabfall von Silizium Dioden (man muss darunter bleiben).
Rufus Τ. F. schrieb: > Naja, dann ist vielleicht der vom µC kommende High-Pegel gerade noch so > im Rahmen, daß die SBW-Hardware des Launchpads (effektiv ein leicht > abgespeckter MSP-FET430UIF) sie als High-Pegel erkennen kann. > > Schick ist das nicht, denn die SBW-Hardware liefert in Gegenrichtung > einen 3.6V-Pegel in Deinen µC, d.h. 0.8V über VCC. > > Um bei anderen Betriebsspannungen als den vorgegebenen 3.6V > programmieren/debuggen zu können, ist dann doch ein "vollwertiges" > Debuginterface wie der MSP-FET oder der ältere MSP-FET430UIF nötig. > > Die beiden können ihre "Target"-Spannung zwischen 1.8V und 3.6V > verstellen. > > Wenn Du den Schaltplan des MSP-FET430UIF (zu finden in > http://www.ti.com/lit/ug/slau647l/slau647l.pdf) vergleichst mit dem des > G2-Launchpads (zu finden in > http://www.ti.com/lit/ug/slau318g/slau318g.pdf), wirst Du feststellen, > daß dem Launchpad der einstellbare Spannungsregler U3 fehlt, der vom > 'F1612 über Pin 5 (ein DAC-Ausgang) angesteuert wird. Glaube nur was Du misst! Ich habe die Vcc noch mal mit dem Oszi und Multimeter nachgemessen. Das Launchpad läuft mit sicheren 3,5V. SBW geht auch immer mit dieser Spannung nach draussen. Du hast zu 100% Recht! Vor Allem: Das MSP-FET430UIF kostet nur noch 25 €uronen!!!! Das war mal anders! Weihnachten naht! Obwohl SBW auch gut funzt. Ich werde den MSP430 "standalone" mit Batteriespannung von 3V betreiben. Da bleibt man sicher innerhalb der Toleranzen. Bei LiPo's habe ich ein Problem! Ein Stepup- bzw. Stepdown-Converter, so wie ich es in letzter Zeit bei Neuentwicklungen sah, macht auch bei hohem Wirkungsgrad in meinen Augen keinen Sinn, weil man da auch Energie verbrät.
Nachtrag: Ich arbeite die ganze Zeit mit 3,3V. Ich wollte nur die Werte vom Datenblatt überprüfen als ich mit der Spannung nach unten ging.
W.S. schrieb: > Wenn man es macht wie du es vorschlägst, dann wird daraus: > HW<--->LibFunc<--->LLTreiber<--->Anwendung. > > Das schafft dann eine Abhängigkeit von der betreffenden LibFunc - und > die ist fast immer bei den heutigen IDE's nicht im Projekt selber, Nein die ist selber geschrieben.
Von "dem Spannungsabfall" an Siliziumdioden zu sprechen qualifiziert als Bastler.
Uwe B. schrieb: > Von "dem Spannungsabfall" an Siliziumdioden zu sprechen qualifiziert als > Bastler. Sprachen wir davon?
Andreas V. schrieb: > Uwe B. schrieb: >> Von "dem Spannungsabfall" an Siliziumdioden zu sprechen qualifiziert als >> Bastler. > > Sprachen wir davon? Siehe oben
Holm T. schrieb: > Ich habe alles Mögliche schon in den Fingern gehabt und der MSP430 ist > nicht das Schlechteste Teil, auch wenn mich die recht vielen nie > beseitigten Fehler etwas nerven. Ansonsten find ich den durchaus gut > gemacht, er hat ja auch deutsche Väter. Es geht mir die ganze Zeit durch den Kopf: Wer hat denn den Prozessor entwickelt?
Holm T. schrieb: > na aber...: > > https://de.wikipedia.org/wiki/TI_MSP430 > > Gruß, > > Holm Danke, wer lesen kann ist klar im Vorteil! Die erste Zeile hatte ich glatt überlesen. Da sieht man mal wie oberflächlich man teilweise noch liest...
Beitrag #5828228 wurde von einem Moderator gelöscht.
Beitrag #5828240 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.