Hallo! Ich versorge meinen µC (einen passenden muss ich erst auswählen) mit einer 1,5V Batterie und Step-Up-Konverter. Die Batterielaufzeit sollte möglichst lange sein. Dabei kam die Idee auf, einen externen Uhrenquarz als Takt zu verwenden (die Geschwindigkeit spielt eine untergeordnete Rolle). Gibt es hier irgendwelche Standardtypen? Muss ich bei der µC Auswahl beachten, dass der µC extern getaktet werden kann oder kann das jeder? Es sollte ein µC von Atmel sein... In diesem Zusammenhang bin ich auch auf den "Sleep Mode" gestoßen. Hat das irgendwas mit der externen Taktung zu tun oder ist das eine weitere Möglichkeit, die Batterielebenszeit zu verlängern? Danke, lg
Werner Weinwurm schrieb: > Dabei kam die Idee auf, einen externen Uhrenquarz als Takt zu verwenden Da gilt wie immer RTFDS, lies das Datenblatt. Da steht für jeden Prozessor drin, mit welchen Quarzen man ihn betreiben kann und wie die Beschaltung dafür ist. Wenn da keine Uhrenquarze erwähnt sind würde ich es lassen, bei manchen Prozessoren muss man dafür Fuses setzen. Gruss Reinhard
Sofern Du keine große Genauigkeit des Taktes brauchst, ist es ratsam, einen internen Taktgeber zu verwenden. Alle neueren AVRs bieten diese Möglichkeit. Du solltest schon sagen, was der µC erledigen soll. Sonst kann man keinen konkreten Typ vorschlagen.
Werner Weinwurm schrieb: > Muss ich bei der µC Auswahl beachten, dass > der µC extern getaktet werden kann oder kann das jeder? Er wird nicht extern getaktet sondern erzeugt den Takt mit Hilfe des Quarzes. Ein Quarz ist keine Taktquelle!Der µC muß für Uhrenquarze geeignet sein. Auch die meisten der anderen Fragen dind Abhängig vom konkret gewählten Chip. Schreib Dir die genauen Anforderungen auf und nimm einen µC und schau nach ob er die Anforderungen erfüllt (Datenblatt). Er muß nicht exakt alle und nur diese Anforderungen erfüllen. Es reicht wenn er alle Anforderungen erfüllt. Er darf also auch größer sein. Das erleichtert die Suche. Zeit ist Geld. Bei kleinen Stückzahlen lohnt sich die Suche nach dem perfekte Modell kaum. Atmel ist nur eine Marke. Die bauen sehr sehr verschiedene Sachen. ATTiny, ATMega, ATXMega, diverse ARM Derivate, AVR32.... Das bringt uns nicht weiter ohne Modellbezeichnung. Werner Weinwurm schrieb: > Hat > das irgendwas mit der externen Taktung zu tun oder ist das eine weitere > Möglichkeit, die Batterielebenszeit zu verlängern? Beides und noch mehr. Das sind also nicht die einzigen Auswirkungen/Ziele. Es Spart strom. Auch wenn ein Quarz keine externe Taktung ist (siehe oben) gibt es bei SLEEP-Modes manchmal einiges zu beachten bezüglich der verschiedenen Taktquellen. Aber das ist wiederum äußerst modellspezifisch. Du merkst die Art der Fragestellung ist sehr fruchtlos. Es scheint dein Einstig zu sein. Daher würde ich folgendes vorschlagen. 1. Entweder Du nimmst einen kleinen ATTiny und schaust was man daraus machen kann und arbeitest Dich Schritt für Schritt ein. Erst danach geht es an konkrete Projekte und hast dann eine Vorstellung was Du brauchst. 2. Oder Du nimmst gleich einen möglichst großen ATMega der möglichst viel an Bord hat. Dann kannst Du Dich bei der Einarbeitung besser auf das vorgenommene Problem konzentrieren und mußt Dich nicht so oft um Hardwaregrenzen kümmern (zu wenig Speicher, Soft-UART etc....) Für das konkrete Projekt bleiben dann zwar wahrscheinlich Ressourcen über. Ein kleinerer Chip hätte es wohl auch getan. Aber das weiß man erst hinterher. Das ist aber nicht so schlimm als eine nicht funktionierende Lösung weil man trotz aller Tricks nicht alles in einen zu kleinen Chip reingezaubert bekommt. Erst den Chip wählen, dann loslegen und konkrete Fragen stellen wenn sie da sind. Du willst den Chip abhängig von den Antworten wählen, noch bevor Du die genauen Fragen kennst (Es gibt potentiell unendlich viele Fragen.) Das macht man erst mit Erfahrung, nicht zum Einstieg. Selbst im Professionellen Umfeld wechselt man nicht immer zum "perfekten" Chip, sondern bleibt oftmals auch beim bekannten Modell. Das hat verschiedene Gründe, was aber jetzt off-topic geraten würde.
Nimm einen C8051F912 von SiLabs, der hat alles was Du extern "anschrauben" möchtest und läuft auch mit einem 32kHz Quarz, sowie bis zu 24,5MHz intern.
Oder, oder, oder... Oder einen ATTiny43, der hat schon einen kleinen Step-up-Controller integriert. Die Frage ist: Lernen oder Konkretes Projekt. Für ein konkretes Projekt mit der ersten Komponentenauswahl gleich ein stromsparendes Batteriegerät zu entwerfen als Einstieg halte ich für unrealistisch. Etwas ähnliches erst einmal überhaupt ans Laufen zu bekommen und dan zu optimieren ist sinnvoller. Die meisten Produkte werden Iterativ entwickelt, also nach und nach verbessert.
Für Uhrenquarze gibt es keine große Unterschiede. 2^15 = 32678Hz ist der Standard, die Lastkapazität der Quarze ist zwar unterschiedlich braucht aber nur bei Uhren genau zu sein. Ob der Oszillator des betreffenden Kontroller Uhrenquarze "kann",siehe Datenblatt. Mit den 32 kHz als Takt ergäbe das beim Stromverbrauch gegenüber dem internen Takt eine deutliche Stromersparnis (ohne sleep-mode). Der sleep-mode ist eine gängige und wirksame Methode, Strom zu sparen. Meist besser: mit internem Takt + sleep-Abschnitte arbeiten als mit 32kHz. Je nach Kontrollertyp bestehen da deutliche Unterschiede in der Arbeitsweise des sleep-mode, da ist eingehendes Studium des jeweiligen Kontrollers notwendig.
Für Uhrenquarze gibt es keine große Unterschiede. 2^15 = 32678Hz ist der Standard, die Lastkapazität der Quarze ist zwar unterschiedlich braucht aber nur bei Uhren genau zu sein. Ob der Oszillator des betreffenden Kontroller Uhrenquarze "kann",siehe Datenblatt. Mit den 32 kHz als Takt ergäbe das beim Stromverbrauch gegenüber dem internen Takt eine deutliche Stromersparnis (ohne sleep-mode). Der sleep-mode ist eine gängige und wirksame Methode, Strom zu sparen. Meist besser: mit internem Takt + sleep-Abschnitte arbeiten als mit 32kHz. Je nach Kontrollertyp bestehen da deutliche Unterschiede in der Arbeitsweise des sleep-mode, da ist eingehendes Studium des jeweiligen Kontrollers notwendig. Ein Tipp: erstmal zum Laufen bringen und anschließend den sleep-mode ins Programm einbauen.
Peter R. schrieb: > Ein Tipp: erstmal zum Laufen bringen und anschließend den sleep-mode ins > Programm einbauen. Und beispielsweise an der ATMEL ATMega Architektur erläutert. Es gibt unterschiedliche Tiefschlazustände. Gerade da kann es mal haken und das Teil spielt dann Dornröschen, wenn man das Datenblatt nicht genau beachtet hat. Also erst einmal mit einem einfachen IDLE beginnen und später erst die tieferen Sleep-Modi testen. Dann hat die Software immerhin schon die passende Struktur und muß nur noch im Detail für die tieferen Schalfmodi angepaßt werden. Eine Software komplett ohne SLEEP zu entwerfen und dann auf SLEEP umzustellen ist da etwas aufwändiger. Zum Powermanagment und Sleep gibt es unter anderem hier einen schönen Artikel, der das Datenblatt aber natürlich nicht ersetzt. Manche Funktionseinheiten weisen bezüglich der Sleep-Modi unerwartete Besonderheiten auf. https://www.mikrocontroller.net/articles/AVR-Tutorial:_Power_Management
Der MSP430 hat ein gut durchdachtes und gut dokumentiertes Clocksystem. Mit dem Launchpad kannst du für kleines Geld schnell durchstarten. Low Power hat er sowieso und eignet sich perfekt für Batteriebetrieb. Für Anfänger ist er besser geeignet als die avr, da gibt es nix zu verfusen, sich aus zu sperren, ... Der MSP hat eine modernere Architektur als die in die Jahre gekommenen avr. Atmel arbeitet wohl schon intensiv an der Ablösung, Cotex M0 :-P
@16-Bit Er will einen Atmel haben. Zum Anderen: Nicht immer ein langsamer Takt energieeffizienter als ein schnelller Takt
Coder schrieb: > @16-Bit > Er will einen Atmel haben. > > Zum Anderen: Nicht immer ein langsamer Takt energieeffizienter als ein > schnelller Takt Was der Bauer nicht kennt, ...
16 bit schrieb: > Für Anfänger ist er besser geeignet als die avr, da gibt es nix zu > verfusen, sich aus zu sperren, ... > Der MSP hat eine modernere Architektur als die in die Jahre gekommenen > avr. Atmel arbeitet wohl schon intensiv an der Ablösung, Cotex M0 :-P Moderner ist nicht unbedingt besser. Die AVR werden auch laufend weiterentwickelt. Das spricht nicht für eine Ablösung. Es geht mehr um eine Eweiterung der Produktpalette. Die Vor- und Nachteil der jeweiligen Architekturen sind Anwendungsspezifisch (qualitative Aussage, besser Akkuleistung) und manchmal auch unterschiedlich stark in der Relevanz (quantitative Aussage). Überzogenes Beispiel: Ein Quadkopter stört sich kaum am Stromverbrauch des µC auch wenn es ein "Batteriegerät" ist. x besser als y Einsteiger sollten solche Diskussionen meiden. Erst kommen die Grundlagen, dann kommt die Funktionalität. Wer sich vor den ersten Schritten in die optimale perfekte Komponentenauswahl vertieft, verliert sich und kommt nicht zum Start. Erst sollte man die Architektur des Gerätes selbst optimal haben. Wen man dann sieht, daß der µC wesentlich zum stromverbrauch beiträgt, kann man immer noch den passenden µC nebst passendem Entwickler besorgen (Firma) oder sich in die alternative Architektur einarbeiten, falls es sich lohnt. Es gibt keine universaloptimalen Chips. Ohne konkrete Aufgabenstellung sind das Glaubenskriege. Mit konkreter Aufgabenstellung sind das oftmals nur unbedeutende Nebenkriegsschauplätze, zu unbedeutend für einen nachträglichen Architekturwechsel. Als Einsteiger kann man das fließend unterteilte Ausmaß der Relevanz (bedeutend bis unbedeutend) kaum vorher sinnvoll abschätzen. Das kann man erst mit Erfahrung und einem vollständigen Pflichtenheft des Geplanten Gerätes. Aufgrund der leichten Verfügbarkeit und der Verbreitung in diesem Forum ist AVR also keine schlechte Wahl für den Einstieg. MSP430 ist ebenfalls geeignet, auch wenn ich da jetzt nicht im Blick habe ob Du selber löten willst oder nicht. Aber diese Entscheidung ist nebensächlich für den Eistieg in die Materie.
Mein Reden! Warum sollte man sich als Neueinsteiger mit dem betagten avr Kram rumärgern, wenn es besseres gibt. :-D Um sich auf die eigentliche Problemstellung zu konzentrieren, muss der Controller und vor allem die Handhabung easy und fehlerunanfällig sein. Da sehe ich den MSP und das launchpad weit vor den avr. Auf der embedded world war der Atmel Stand in den letzten Jahren immer von den GA Jägern belagert, die den avr als hobby haben. Dies Jahr sah es anders aus. Die avr waren verbannt und SAM ist das neue Aushängeschild. Der Stand wurde auch wieder von echtem Fachpublikum besucht. Mal sehen, für wen Atmel sich entscheidet. ;-)
@16bit: auf die Gefahr hin spitzfindig zu werden: als die moderne MSP-Architektur erfunden wurde, noch unter dem Namen PDP8/11, da waren die Erfinder des AVR noch mit einfacherem als Computern beschäftigt. Man nicht bedeutet, daß mir deren Vorzüge nicht bekannt wären. Nur versuch mal so ein SSOP14 in ein Steckbrett zu drücken. Oder irgendwo aufzulöten, wenn deine Augen schon ein halbes Jahrhundert in Betrieb sind. Zum programmieren in ASM(11) genial, aber das ist eben nicht alles.
Die werden beides weiter Produzieren :P Dann hoffe ich mal, daß hier jemand mal ein Tutorial verfaßt für die MSP430 Architektur. Nicht daß er dann in ein anderes Forum abhaut. Ich werde es nicht schreiben. Ich bin noch beim AVR und hab noch keinen ausreichend schweren Grund umzusteigen :P
Nicht umsteigen, sondern neu einsteigen! Als Ersttäter sollte man auf das modernere und weniger fehlerträchtige setzen. Sitzt du noch an einem P1?
16 bit schrieb: > Für Anfänger ist er besser geeignet als die avr Vor mir liegt noch ein TI Entwicklungssystem auf einem USB-Stick, Typ eZ430-F2013, bereit für den Elektroschrott. Warum? Ich wollte mit dem Chip was probieren, aber bevor ich dazu gekommen bin hat TI die Produktion eingestellt. War mir dann zu wenig vertrauenswürdig. Hat jemand Interesse? Gruss Reinhard
Alles entwickelt sich weiter. Die AT90 sind auch nicht mehr angesagt. Zum Einstieg ist das Tool der Wahl das launchpad.
Um mal in eine andere Richtung zu schauen: Wie groß ist denn der Standby-Verbrauch des StepUp? Ist der AVR-Sleep-Mode da noch wichtig?
>Ich wollte mit dem Chip was probieren, aber bevor ich >dazu gekommen bin hat TI die Produktion eingestellt. ? http://www.ti.com/product/msp430f2013 Der msp430f2013 wird nach wie vor produziert.
Bastler schrieb: > Um mal in eine andere Richtung zu schauen: > Wie groß ist denn der Standby-Verbrauch des StepUp? > Ist der AVR-Sleep-Mode da noch wichtig? Also der MSP und der Atmel schenken sich nix, wenn es um Stand-By Verbrauch geht. Nen 328p bekommt man bis auf 1µA wenn man weiss was man wie abschalten kann. In der Regel liegt man drüber (dann sind es halt 10-x0µA) weil halt doch noch was anderes dranhängt, das sich schlecht oder gar nicht runterfahren lässt. Beim MSP gehts aber einfacher und kommt noch weiter runter aber mein Gott, 1µA wie lange hält da ne Batterie oder Knopfzelle? Es gibt auch noch spezielle Low-Powertypen von Atmel da ist dann der Vorteil vom MSP auch dahin. Das Problem beim MSP: Nutzt kaum einer, wenig freie Doku, Beispielprojekte,... Selbst wenn der x-belibige Atmel technisch schlechter ist, das macht die massige Doku, Tutorials,... die es für Atmels gibt wieder wett, der MSP ist vergleichsweise ein Exot, Hobbybastler setzen den kaum ein, obwohl es inzwischen auch solche Arduinoartigen Boards gibt, samt IDE und sogar billiger. Hier mal ein Schritt für Schritt Versuch wie man sich immer weiter runtertastet: https://www.sparkfun.com/tutorials/309
16 bit schrieb: > Als Ersttäter sollte man auf das modernere und weniger fehlerträchtige > setzen. Sitzt du noch an einem P1? Ich weiß einsteigen vs umsteigen. Für mich wäre es ein Umsteigen wenn ich das Tutorial schreiben würde. Für den Themenersteller wäre es ein Einstieg. Ich bin da in einer anderen Rolle. Wieso wird hier eigentlich immer dem AVR implizit unterstellt fehlerträchtiger zu sein? Weil er 8 statt 16 Bit hat? Kern und Befehlssatz sind einfach und übersichtlich, kein besonderes Fehlerpotential im Vergleich zum MSP.
Sogar der olle PIC12F675 ist für Uhrenquarze spezifiziert, hat einen Low-Power-Mode für externen Quarz 32kHz. Sicher meinen die aber damit auch 32,768kHz. Bei manchen meiner Anwendungen langweilt der sich dann sogar noch. Man nimmt doch nur das, was man an Performance wirklich braucht. Kürzlich betrieb ich den PIC noch mit externem RC-Glied, und nur 0,8 Hz, das war in Energiesparung nicht so erfolgreich, wie ich erwartet hätte. Das ist aber auch noch nicht völlig ausgetestet, ich schaltete noch nicht alle Peripherals ab, die nach Reset an sind, und man diese aber nicht immer braucht.
Und mit einem PC sollte man das besser nicht vergleichen. Ein "moderner" PC wird von einem Prozessor angetrieben dessen Befehlsatz immer wieder erweitert und angeflickt wurde. Ist das besser? Das Militär interessiert sich durchaus noch für den Pentium. Weil er bekannt und zuverlässig ist. Wenn es seinen zweck erfüllt... Modern hat nicht wirklich was mit dem alter zu tun. Oder würdest Du das Rad aufgrund des alters der Erfindung für obsolet erklären? Wesentlich ist doch eher, daß das Teil seine Aufgabe zuverlässig und gut erfüllt.
@45°C aktuell in der sonne: Der Frager schrieb: "ich versorge meinen MC mit 1,5V und StepUp-Regler" Mache dieser brauchen mehr als ein schlafender MC BTW, weiß jemand wo dieses verdammte IPad das mü versteckt?
Bastler schrieb: > Mache dieser brauchen mehr als ein schlafender MC 45°C aktuell in der sonne schrieb: > blabla Und wieder einer der nicht verstanden hat was stromsparende Controller asumacht.
Bastler schrieb: > BTW, weiß jemand wo dieses verdammte IPad das mü versteckt? Unter -> Einstellungen/Allgemein/Tastatur/Tastaturen kannst Du die griechische Tastatur hinzufügen. Dann hast Du das komplette griechische Alphabet. (Umschalten der Tastaturen mit der Globus-Taste links neben der Leertaste) Du kannst auch einen Kurzbefehl erstellen, der das μ einfügt.
Carsten R. schrieb: > 16 bit schrieb: >> Als Ersttäter sollte man auf das modernere und weniger fehlerträchtige >> setzen. Sitzt du noch an einem P1? > > Ich weiß einsteigen vs umsteigen. Für mich wäre es ein Umsteigen wenn > ich das Tutorial schreiben würde. Für den Themenersteller wäre es ein > Einstieg. Ich bin da in einer anderen Rolle. > > Wieso wird hier eigentlich immer dem AVR implizit unterstellt > fehlerträchtiger zu sein? Weil er 8 statt 16 Bit hat? Kern und > Befehlssatz sind einfach und übersichtlich, kein besonderes > Fehlerpotential im Vergleich zum MSP. Es geht nicht um 16 vs 8. avr gibt es auch mit 32 bit, das weisst du? Es geht um die Handhabung und die Fehlermöglichkeiten für Anfänger. Der MSP hat eine gut durchdachte Architektur und das launchpad ist für kleines Geld zu haben. Das sieht bei avr anders aus. Aktuell laufen hier wieder ein paar threads, bei denen sich die user verfused und beim controller ausgesperrt haben.
Carsten R. schrieb: > Und mit einem PC sollte man das besser nicht vergleichen. Ein > "moderner" > PC wird von einem Prozessor angetrieben dessen Befehlsatz immer wieder > erweitert und angeflickt wurde. Ist das besser? Das Militär interessiert > sich durchaus noch für den Pentium. Weil er bekannt und zuverlässig ist. > Wenn es seinen zweck erfüllt... > > Modern hat nicht wirklich was mit dem alter zu tun. Oder würdest Du das > Rad aufgrund des alters der Erfindung für obsolet erklären? Wesentlich > ist doch eher, daß das Teil seine Aufgabe zuverlässig und gut erfüllt. Genau, die Räder an deinem Auto sind aus Stein oder Holz! :-D Die Dinos sind ausgestorben, was wird aus dir?
Diese Diskussion kommt immer wieder hoch. Ich bin Anfänger und sehe mich noch die nächsten Jahre als ein solcher. Angefangen mit Arduino. Finde ich für den Anfang immer noch gut und die Boards sind günstig und leicht zu beziehen. Natürlich will ein Anfänger erst mal was bauen, was ihm nützlich und zugleich lehrreich ist. Und natürlich weiß ein Anfänger nicht, was das für ein immenser Lernaufwand ist. Wie soll er das auch wissen? Das wird ihm dann hier bei den ersten Fragen eingeprügelt. Er will auch einen µC nehmen, der auch für alle noch kommenden Aufgaben geeignet ist. Am besten einen Cortex und dann gleich einen großen ... bis ... bis er das Datenblatt sieht. Was wird man den bauen? Sind es nicht eher kleinere Projekte, wo ein paar Pins reichen? Wenn ich die ganzen Filme zum Tiny13 sehe, was manche damit gemacht haben. Der ist billig und reicht für kleinere Aufgaben völlig. Das Datenblatt ist auch nicht so lang. Ich finde man sollte ihn zum Üben empfehlen.
Der controller ist das eine, wie sieht es mit Zubehör und boards aus? Vergleiche einmal avr und MSP.
16 bit schrieb: > Der controller ist das eine, wie sieht es mit Zubehör und boards aus? > > Vergleiche einmal avr und MSP. Mit smd fange ich zum Beispiel gar nicht mehr an. Das ist mir zu fummelig. Hab auch schon Platinen geätzt und würde das für eine kleine Serie zum testen einmal machen, dann aber bestellen und am besten schon bestückt. Ansonsten Lochraster. Der MSP ist sicher und mit recht interessant, aber man kann sich auch verzetteln und das gerade als Anfänger.
Der Tiny13 für "mal eben" und für größere Sachen den ATmega 328, das reicht für mich persönlich. Mag sein, dass ich in zwei Jahren was ganz anderes sage, aber im Moment wäre ich von den anderen Teilen einfach überfordert.
F. Fo schrieb: > 16 bit schrieb: >> Der controller ist das eine, wie sieht es mit Zubehör und boards aus? >> >> Vergleiche einmal avr und MSP. > > Mit smd fange ich zum Beispiel gar nicht mehr an. Das ist mir zu > fummelig. > > Hab auch schon Platinen geätzt und würde das für eine kleine Serie zum > testen einmal machen, dann aber bestellen und am besten schon bestückt. > Ansonsten Lochraster. > Der MSP ist sicher und mit recht interessant, aber man kann sich auch > verzetteln und das gerade als Anfänger. MSP gibt es auch als DIL/DIP. Und wobei verzettelst du dich? Bestimmt nicht bei den Fuses. :-D
@16bit: hab nen breiteren; muß noch besser sein; Weiber sind ganz geil drauf!
16 bit schrieb: > Es geht nicht um 16 vs 8. avr gibt es auch mit 32 bit, das weisst du? Klar weiß ich das. Das war auch nur eine Provokation ;-) Ich hätte gerne einen konkreten Wink was denn wirklich besser sein könnte. Das sind immer die beschriebenen Glaubenskriege. 16 bit schrieb: > Es geht um die Handhabung und die Fehlermöglichkeiten für Anfänger. Der > MSP hat eine gut durchdachte Architektur und das launchpad ist für > kleines Geld zu haben. Das sieht bei avr anders aus. Aktuell laufen hier > wieder ein paar threads, bei denen sich die user verfused und beim > controller ausgesperrt haben. Günstige Einstigsplattformen gibt es für alle, so auch für AVR. Da tun die sich nicht viel. Was an AVR ist nicht durchdacht? Ich meine Prinzipiell an der Architektur, nicht etwas wie "Die Konfiguration des USART gefällt mir nicht" Was sind grundlegende Schwächen? Alleine das man darüber erst diskutieren muß, zeigt doch daß der Unterschied weder offensichtlich noch gravierend ist, abgesehen von bestimmten Aufgaben/Einsatzszenarien in denen mal der Eine und mal der Andere Situationsbezogen einen Vorteil haben könnte. Die Fuses sind größtenteils Optional. Da heißt es nicht umsonst: Einsteiger lassen soweit wie möglich die Fuses so wie sie sind. MSP hat diese Funktionen die durch die Fuses ermöglicht werden größtenteils erst gar nicht. Das sind Extras, mit denen man auch Unfug anstellen kann. Aber das Fehlen von Extras ist kein prinzipieller Vorteil. Das man den AVR per Fuse von der Taktquelle abschneiden kann ist leider eine unvermeidliche Folge einer bewußten Designeentscheidung. Man möchte verschiedene Taktquellen erlauben. Aber in dem einen Fall erlaubt man der Software umzuschalten, in dem Anderen ist dies "extern" zu erledigen. Und anstatt terure/rare Pins dafür zu opfern hat man die als Fuses integriert. Die nächstgrößere AVR-Serie ATXMega erlaubt der Software den Taktwechsel. Diese Möglichkeit ist nicht immer sinnvoll und daher manchmal bewußt unterbunden. Wenn man nur den Chip betrachtet mag man das nicht sehen. Aber wenn man die Umgebung mit einbezieht ist diese bewußte Einschränkung durchaus sinnvoll um andere Fehler zu vermeiden. Trotzdem ist es eine Detaileigenschaft und keine grundsätzliche Eigenschaft der Architektur, denn ATXMega ist auc AVR, nur etwas erweitert und in diesem Punkt wieder etwas anders. 16 bit schrieb: > Genau, die Räder an deinem Auto sind aus Stein oder Holz! :-D > > Die Dinos sind ausgestorben, was wird aus dir? Du schreibst das MSP generell besser sei. Ich bestreite ja nicht das es Weiterentwicklungen gibt. Die gibt es auch hier innerhalb der Produktlinien. Aber bisher haben wir nur "modern" vs "alt" als Argument das das Eine besser sei als das Andere. Das es Unterschiede gibt, ist klar. Aber welche davon sind generell vorteilhaft Richtig, die Dinos sind "fast" ausgestorben. Das ist kein Belegt dafür, daß alles was länger existiert nach x Jahren veraltet ist. Irgendwann vielleicht, aber das Zeigt erst der Kontext. es gibt auch viele viele alte Rassen,weil sie in der Lage sind zu überleben = sie sind ihren herausforderungen ausreichend gut gewachsen und die Konkurrenz ist nicht dominant überlegen um sie zu verdrängen. Glaubenskrieg, Detailfragen, nichts womit sich einsteiger belasten müssen/sollten. Beides geht aber es gibt keine Zwingenden Gründe für a oder b, jedenfalls nicht ohne Kontext
Zur Thema "MSP vs AVR": Der MSP ist in diesem Forum nicht so präsent, wie der AVR. Wer den MSP einsetzt, schaut bei TI oder direkt in den dedizierten Forum nach, aber hier nicht wirklich. Dann findet auch man Beispielprojekte, Tutorials, Datenblätter und Source-Beispiele, die auch sehr gut sind. Man muss bereit sein die Suchfunktionen einzusetzten. Die Crux... man muss Englisch können Zum Stromsparen: Optimier erst mal deine Schaltung hinsichtlich des Stromverbrauchs.
Nebenei: Wer eine Fuse versemmelt, hat den Chip nicht zerschossen. Eventuell hat er nicht den passenden Schlüsseldienst um wieder reinzukommen, ok. Interessant ist aber, wenn man sich verfust weiß an es sofort und man weiß wo der Fehler liegt. schlimmstenfalls braucht man ein zwei CReservechips. Die Einstellmöglichkeiten der Fuses der Software zugänglich zu machen, kann wiederum zu Softwarefehlern führen die sehr schwer auffindbar sind. Zeit ist Geld. Es ist anders. Aber grundlegend besser? Man hat den eindruck weil man das Eigene beser kennt und es so gewohnt ist. @ Coder *100% zustimm* Genau auf diesen Pragmatismus wollte ich hinaus. Der µC ist zwar wichtig aber der µC ist nicht das Gerät, sondern nur ein Teil davon.
@16bit: Die Dinos gibt es immer noch. Als Echsen oder Vögel. Und die Wohnzimmerschrankwandgroße PDP11 (nicht die späten Modelle) leben weiter als MSP. Hühner schmecken ganz gut und die MSP Architektur ist durch den Untergang von DEC auch nicht schlechter geworden. Nur handlicher als ein AVR ist sie eben auch nicht. Am Besten verabredest du dich mal mit c-hater zum ASM11 programmieren ;-)
BTW, wurde eigentlich meine Frage zum StepUp schon beantwortet? Wenn der nämlich nicht nur 1..5μA, sondern 1..5mA Ruhestrom hat, dann kommt's auf den Sleep-Mode nicht mehr an.
Carsten R. schrieb: > Da heißt es nicht umsonst: > Einsteiger lassen soweit wie möglich die Fuses so wie sie sind. Also doch schwierig für Einsteiger. ;-) Carsten R. schrieb: > Die nächstgrößere AVR-Serie ATXMega erlaubt der > Software den Taktwechsel. Atmel hat es erkannt. ;-) Carsten R. schrieb: > Interessant ist aber, wenn man sich verfust weiß an es > sofort und man weiß wo der Fehler liegt. schlimmstenfalls braucht man > ein zwei CReservechips. Die Einstellmöglichkeiten der Fuses der Software > zugänglich zu machen, kann wiederum zu Softwarefehlern führen die sehr > schwer auffindbar sind. Warum schreibt man dann überhaupt noch Software. Nach deiner Meinung sollte man alles in Hardware lösen. ;-) Carsten R. schrieb: > Genau auf diesen Pragmatismus wollte ich hinaus. Der µC ist zwar wichtig > aber der µC ist nicht das Gerät, sondern nur ein Teil davon. Und warum schreibst du dann hier Romane? Einfach lesen: 16 bit schrieb: > Es geht um die Handhabung und die Fehlermöglichkeiten für Anfänger. 16 bit schrieb: > Der controller ist das eine, wie sieht es mit Zubehör und boards aus?
16 bit schrieb: > Carsten R. schrieb: >> Da heißt es nicht umsonst: >> Einsteiger lassen soweit wie möglich die Fuses so wie sie sind. > > Also doch schwierig für Einsteiger. ;-) Dann laß doch Bitte den wesentlichen Satz direkt davor mit beim Zitat. Carsten R. schrieb: > Die Fuses sind größtenteils Optional. Carsten R. schrieb: > Aber das Fehlen von Extras ist kein prinzipieller Vorteil. Zusätzliche Funktionen sind kein Nachteil wenn man sie auch ignorieren kann. Es sind Optionen. Man muß sie nicht benutzen. Für einen Einsteiger wäre es noch schwieriger diese Funktionen beim MSP nachzurüsten. :P Trotzdem: Uninteressant, Zubehör, kein Bestandteil der AVR Architektur als solche, wie man beim Beispiel des ATXMega sieht, da ist es anders. 16 bit schrieb: > Carsten R. schrieb: >> Die nächstgrößere AVR-Serie ATXMega erlaubt der >> Software den Taktwechsel. > > Atmel hat es erkannt. ;-) Nein sie bieten einfach beide Optionen an. Es ist wie gesagt eine Entscheidung ob die Software das machen können darf oder nicht. Das kann man mit ja oder nein beantworten, je nach Bedürfnissen. Dies ist einfach nur eine breitere Palette. 16 bit schrieb: > Warum schreibt man dann überhaupt noch Software. Nach deiner Meinung > sollte man alles in Hardware lösen. ;-) Falsch. Das ist nicht meine Meinung. Atmel hat für einen Teil seiner Produkte entschieden die Taktkontrolle und einige andere Hardwarefunktionen nicht der Software zu überlassen. Da der Takt in vielen Geräten, es gibt auch ein paar taktlose Systeme, eine wesentliche Eigenschaft sehr Hardwarenaher Natur ist, kann das auch Sinn machen. Softwarevalidierung ist schon schwer genug. Wer will da schon Fehler in der Software suchen die eigentlich ok ist wenn die Fehler in unpassend getakteter Hardware steckt. Normalerweise ist die zuverlässige Hardwareausführung nicht Sache des Softwareentwicklers. Das macht das Debuggen noch schwerer. Viel Spaß mit der Peripherie, wenn der Systemtakt nicht stimmt. Die Taktkontrolle der Software zu überlassen ermöglicht (Option) auch den Takt zur Laufzeit zu verändern. Das wiederum erfordert das Umkonfigurieren der Peripherie(Taktteiler). Dabei können laufende Datenübertragungen korrumpiert werden. Diese Option macht es komplizierter und darum auch schlechter nach Deiner Argumentation. Also könnte man dies auch dem MSP430 ankreiden, ist aber einfach nur eie Designentscheidung. Also ist diese Entscheidung durchaus nachvollziehbar. Eine Designentscheidung, manchmal Vorteilhaft, manchmal nachteilig, manchmal unbedeutend. Noch deutlicher wird es bei den Fuses für den Speicherzugriff. Die Software kann ohne Hardwareunterstützung gar nicht verhindern daß sie ausgelesen wird. Manches geht nur in Hardware. Oder willst die Platine und beispielsweise die Spule für den Step-Up plus Diode auch in Software lösen? viel Spaß :P
Um es auf den Punkt zu bringen. Man kann einfache oder Komplexe Software schreiben. Man muß oftmals ein Experte sein um hochkomplexe Software zu schreiben die alles aus der Hardware herausholt und alle Features nutzt. Darum geht es aber nicht. Es geht darum ob man schon ein Experte sein muß um selbst einfache Sachen zu Lösen. Zusätzliche Optionen! die man nicht nutzen muß, verschlechtern diese Situation nicht. Jede Architerktur hat ihre Eigenarten. Die Frage ist: Behindern sie einen im Alltag oder ergänzen sie nur Möglichkeiten. Man kann prinzipiell auf jedem µC ein nutzloses Programm schreiben. Es geht aber darum, wie schwer es ist ein sinnvolles funktionstüchtiges Programm zu schreiben. Also wo sind da die konkreten Nachteile? Es bleibt beim blinden: Es ist besser. Sie sind nur unterschiedlich.
Carsten R. schrieb: > Die Taktkontrolle der Software zu überlassen ermöglicht (Option) auch > den Takt zur Laufzeit zu verändern. Das wiederum erfordert das > Umkonfigurieren der Peripherie(Taktteiler). Dabei können laufende > Datenübertragungen korrumpiert werden. Diese Option macht es > komplizierter und darum auch schlechter nach Deiner Argumentation. Nicht wirklich. Der Peripherie-Takt kann auch bei den uralten AVRs per Software umgestellt werden und kann somit bei einem Softwarefehler ebenso zu weiteren Fehlern führen. Noch schlimmer ist, dass die alten AVRs schlicht stehen bleiben, wenn der externe Takt ausfällt. Kein automatisches Umschalten des Takts, um zumindest diesen Fehler signalisieren zu können und/oder weitere Fehler zu verhindern. Zudem müssen bei vielen Controllern mit dieser Fähigkeit bestimmte Schreibsequenzen eingehalten werden, damit der Takt tatsächlich umgestellt wird oder es kann, wie z.B. bei den SiM3U, gezielt der Schreibzugriff auf einzelne Peripheriegeräte ausgeschaltet werden.
Arc Net schrieb: > Der Peripherie-Takt kann auch bei den uralten AVRs per Software > umgestellt werden Habe ich auch nie bestritten. Ich meine den Seitenefekt, daß wenn der Takt geändert wird, einige Peripherietaktteiler angepaßt werden müssen. Und während dieser Umstellung werden laufende Übertragungen korrumpiert. Das wäre eine zusätzliche Fehlerquelle. Ob man von solchen Funktionen Gebrauch macht steht einem natürlich frei, ebenso wie der Gebrauch der Fuses. Arc Net schrieb: > Noch schlimmer ist, dass die alten AVRs schlicht stehen bleiben, wenn > der externe Takt ausfällt. Kein automatisches Umschalten des Takts, um > zumindest diesen Fehler signalisieren zu können und/oder weitere Fehler > zu verhindern. Du sprichst von Ausfall, einem Defekt. Ist es denn nun besser wenn der µC auf eine andere Taktquelle umschaltet und sich dann dank anderem Takt anders verhält? Das Gerät läuft scheinbar weiter aber plötzlich kann ich nicht mehr per USART kommunizieren. Die PWM läuft nicht mehr mit der vorhergesehenen Frequenzen... etc. Viel Spaß bei der Fehlersuche wenn man dann nicht daran denkt. Es ist eine Möglichkeit von mehreren, nicht besser, nicht schlechter, nur anders. Arc Net schrieb: > Zudem müssen bei vielen Controllern mit dieser Fähigkeit bestimmte > Schreibsequenzen eingehalten werden, damit der Takt tatsächlich > umgestellt wird oder es kann, wie z.B. bei den SiM3U, gezielt der > Schreibzugriff auf einzelne Peripheriegeräte ausgeschaltet werden. Und was ändert das an der Problematik mit den Taktteilern? Taktumstellung im laufenden Betrieb ist etwas für Fortgeschrittene. Für gewöhnlich ist der Takt eine Hardwareentscheidung des Gerätes. Die faßt man exakt einmal an und dann nie wieder. Will ich einen anderen externen Takt muß ich die Hardware ändern. Dann kann ich auch die Fuse ändern. Damit ist dann sichergestellt, daß die Hardware nur mit dem vorgesehenen Takt läuft. Ein Softwareprotokoll zur Umstellung kann das auch. Aber man kann auch da Fehler machen und es hat andere Eigenheiten. Und eine automatische Taktumstellung kann dafür sorgen daß sich der Takt ändert. Wenn ich mich dann einmal bei der Konstruktion verfuse ist das zugegeben doof aber korrigierbar. Dafür kann ich bei der anderen Strategie wie beschrieben an ganz anderer Stelle auf andere Art und Weise Amok laufen. So oder so wird man immer Fehler machen können und auch machen. Aber ich erkläre eine Sicherung doch nicht für schlecht, weil sie durchbrennen kann. Es ist eine Facette und die hat nicht direkt was mit AVR zu tun, sondern sie wird in einigen aber nicht allen AVR so gehandhabt. Darum ist MSP430 nicht prinzipiell besser, aber anders.
Werner Weinwurm scheint seinen persönlichen Sleep-Modus gefunden zu haben. Jedenfalls kommt keine Reaktion mehr von ihm. Wir haben ihn wohl mit unseren Standradmitteln so ermüdet, daß er diesen Thread nicht mehr polled.
@Coder Stehst Du auf Filme über Glaubenskriege und ander relogiöse Auseinandersetzungen? :P Dabei wollte ich gerade betonen daß es kaum Wert ist über dieses Thema zu philosophieren, abgesehen von Anwendungen mit speziellen Anforderungen.
@Carsten R. Nein ich bin ein friedlicher Zeitgenosse. Ich bewundere deine Geduld. Thema einfach auf sich beruhen lassen!
Carsten R. schrieb: > Oder > willst die Platine und beispielsweise die Spule für den Step-Up plus > Diode auch in Software lösen? Du schreibst quantitativ nicht qualitativ. ;-) Nach deiner Logik müssten die GPIO auch gefused werden. Der dumme Programmierer könnte aus einem Eingang einen Ausgang machen und dann ... Carsten R. schrieb: > Es geht darum ob man schon ein Experte sein muß um > selbst einfache Sachen zu Lösen. Genau, also sollte man den Fusekram meiden. Carsten R. schrieb: > Ist es denn nun besser wenn der > µC auf eine andere Taktquelle umschaltet und sich dann dank anderem Takt > anders verhält? Ja, wenn es der Profgrammierer so will. Es gibt nicht nur Deppen aus dieser Welt. Carsten R. schrieb: > Glaubenskriege und ander relogiöse > Auseinandersetzungen Das ist hier dein Ziel? Ich bleibe bei: 16 bit schrieb: > Es geht um die Handhabung und die Fehlermöglichkeiten für Anfänger. Und da ist der MSP mit launchpad einfach besser geeignet.
16 bit schrieb: > Du schreibst quantitativ nicht qualitativ. ;-) > Nach deiner Logik müssten die GPIO auch gefused werden. Der dumme > Programmierer könnte aus einem Eingang einen Ausgang machen und dann ... Wo kommt denn der Schwachsinn her? Diese Schlußfolgerung ist natürlich völliger Schwachsinn, da stimme ich dir zu, aber es ist in keinster Weise erkennbar wie Du mir so etwas unterstellen kannst. Ich sagte es gibt nachvollziehbare Gründe warum man manche hardwarenahe Entscheidungen von der Firmware in Fuses auslagern kann, nicht daß man alle auslagern muß. Es könnte Sinn machen so etwas auch für GPIOs anzubieten wenn man sich dafür eine exerne Schutzschaltung ersparen kann. Der Bedarf ist allerdings gering da oftmals ohnehin schon Vorwiderstände vorhanden sind, die mit den internen Dioden zusammen oftmals ausreichen. Das ist jetzt aber am Thema vorbei. 16 bit schrieb: > Genau, also sollte man den Fusekram meiden. NEINNNNNNN. Selbst wenn man sie meiden wollte, müßte man sie nict aus der Hardware verbannen. Man muß dafür kein Experte sein um das zu benutzen und man kann es auch ignorieren. Das Ding läuft auch mit default-Fuses. Wer ein geschütztes Softwareprotokoll schreiben kann um einen anderen µC auf einen exteren Quarz umzustellen, kann auch eine Fuse umstellen. 16 bit schrieb: > Carsten R. schrieb: >> Ist es denn nun besser wenn der >> µC auf eine andere Taktquelle umschaltet und sich dann dank anderem Takt >> anders verhält? > > Ja, wenn es der Profgrammierer so will. Es gibt nicht nur Deppen aus > dieser Welt. Was hat der Programmierer den jetz damit zu tun? Es wird doch gerade dem AVR angekreidet, daß er nicht automatisch auf eine Reservetaktquelle umschaltet bei defekt und andere µC dies automatisch tun. Darauf bezog sich der Satz von mir. Arc Net schrieb: > Noch schlimmer ist, dass die alten AVRs schlicht stehen bleiben, wenn > der externe Takt ausfällt. Genau genommen ist es ja umgekehrt. Sie starten mit dem internen Oszillator und die Software schaltet dann um. Bei einem Defekt wie beschrieben läuft das Ding dann genauso vor die Wand. In der Entwicklung ist das Softwareprotokoll komplexer als ein Mausklick nach Fusetabelle. Der einzige unterchied besteht darin, daß man irgendeine Taktquelle in Reserve braucht bei einigen AVR wenn man mit den Fuses rumspielt. Das ist ein seperater Vorgang den man nur bewußt eingeleitet und nicht versehentlich. Wenn das nicht bei dem Entwicklungsboard sinnvoll beschrieben ist, ist das ein Manko des Boards. Bei meinem war das dabei. Es gibt auch schlechte Boards für MSP430. Es sind FUSES = Sicherungen, die dafür sorgen daß das Teil nur die definierte Taktquelle nutzt. Ich habe entweder die Freiheit den Takt zu wählen und kann damit Unfug anstellen. Oder ich kann den Takt eindeutig festlegen, dabei auch eventuell Fehler machen und habe danach aber eine definierte Taktquelle. Einmal soll es iodiotensicher sein, weil niemand Fuses setzen kann und dann sind dann doch nicht alle Deppen und können das andere Verhalten perfekt vorhersehen und beherrschen? Es ist völliger Unsinn zu sagen, beim Fusen sind alle Deppen und ohne Fuses sind alle clever. Du selbst schreibst: "Es gibt nicht nur Deppen" argumentierst aber damit, daß man sich mal vertun kann, aber natürlich nur bei AVR. "Es gibt nicht nur Deppen" heißt, man kann es richtig machen. Du jedoch argumentierst mit: Man kann es falsch machen. Das gilt für alle Plattformen! Die Frage ist, wie von mir schon genannt, wie schwer ist es das richtig zu machen? 16 bit schrieb: > Und da ist der MSP mit launchpad einfach besser geeignet. Und ich Frage noch immer: Was genau ist denn besser daran? Bislang ist es noch immer nur eine Behauptung. Und die Aussage, AVR ist schlecht weil er Fuses kennt. Bloß weil nicht alles wie MSP430 ist, ist diese nicht zwangsläuig besser. Was genau macht den MSP430 dnn überlegen?
Investierte 10€ und bestellt dir ein launchpad. Stecke es an deinen Rechner und mache deine ersten Gehversuche mit dem MSP. Dann vergleiche es mit deinem Einstieg bei avr. Dann hat sich das hier schnell erledigt. ;-)
16 bit schrieb: > Investierte 10€ und bestellt dir ein launchpad. Stecke es an deinen > Rechner und mache deine ersten Gehversuche mit dem MSP. Dann vergleiche > es mit deinem Einstieg bei avr. Dann hat sich das hier schnell erledigt. > ;-) Kannst du mir eins nennen? Das probiere ich dann auch gern. :-) Ich sag auch später den Unterschied, ob ich damit leichter zurecht kam.
Das MSP430 LaunchPad Value Line Development kit kostet 6.20 € http://www.exp-tech.de/Mainboards/MSP430-LaunchPad-Value-Line-Development-kit.html Das ist schon sehr sehr günstig. Würde ich heute einsteigen käme ich schon in Versuchung wenn dieses Forum für MSP430 genauso stark wäre wie für AVR. Aber das kann ja noch werden. Technisch tun die beiden sich nicht viel.
Carsten R. schrieb: > Das MSP430 LaunchPad Value Line Development kit kostet 6.20 € > > http://www.exp-tech.de/Mainboards/MSP430-LaunchPad-Value-Line-Development-kit.html > > Das ist schon sehr sehr günstig. Würde ich heute einsteigen käme ich > schon in Versuchung wenn dieses Forum für MSP430 genauso stark wäre wie > für AVR. Aber das kann ja noch werden. Technisch tun die beiden sich > nicht viel. Hab das leider zu spät gelesen, aber trotzdem da auch noch eins bestellt. Kriege jetzt also zwei davon und hab mir noch dazu Set aus 5 Stk. besteht aus: MSP430G2102IN20, MSP430G2202IN20, MSP430G2302IN20, MSP430G2402IN20, MSP430G2352IN20, bestellt. Das sollte doch wohl reichen?
> Würde ich heute einsteigen käme ich > schon in Versuchung Habe ich es mir doch gedacht. Seitenweise Abhandlungen über Dinge, die man nicht kennt. Du bist schon der Größte. Ich kenne avr und MSP und weiss daher wovon ich spreche.
16 bit schrieb: > > Ich kenne avr und MSP und weiss daher wovon ich spreche. Dann erzähle mir doch bitte was von PWM bei den Dingern! Jetzt hab ich mir die schließlich wegen dir bestellt und gleich einen ganzen Haufen davon.
F. Fo schrieb: > Dann erzähle mir doch bitte was von PWM bei den Dingern! > > Jetzt hab ich mir die schließlich wegen dir bestellt und gleich einen > ganzen Haufen davon. Für mich brauchst du nichts zu bestellen. Ich habe verschiedene boards hier liegen. :-) TI hat mit dem Family User Guide eine sehr gute Dokumentation. Das ist sehr gut strukturiert und immer nur ein paar Seiten zum Thema. Gezielte Fragen werden sicherlich auch hier beantwortet. Es gibt einen eigenen Unterbereich. Es wäre schön, wenn du für andere Interessierte von deinen Erfahrungen berichtest. Mach doch einen Beitrag im MSP Bereich auf.
Was soll denn nun wieder dieser Unfug heißen? Ich hab nie was gegen den MSP430 gesagt. Ich sehe die im wesentlichen als gleichwertig an. Gerade deswegen ist der MSP430 nicht auszuschließen aber auch nicht zu bevorzugen. Gerade deswegen steht man dann erst einmal zwischen den Stühlen. Das ist normal bei zwei gleichwertigen Prudukten wenn man unvoreingenommen ist. Ich sträube mich nur gegen die unbegründete pauschale Aussage das MSP430 moderner und AVR fehlerträchtiger sei. Das ist nonsense. Bei ihrer Entwicklung wurden nur hier und da im Detail ein paar unterschiedliche Designentscheidungen getroffen. Diese Unterschiede werden nur in speziellen Situationen wirklich relevant und die meisten dieser Kleinigkeiten sind nicht mal Architekturspezifisch (AVR vs MSP430) sondern eher eine Frage des konkreten Produktes wie am Beispiel dieser inzwischen lächerlich diskutierten Clockfuses. Das sieht man daß sie nicht AVR-spezifisch sind. MSP430 ist nicht automatisch besser moderner und weniger Fehlerträchtig als andere, bloß weil es einige µC mit Clockfuses gibt. Man kann beide nehmen oder es auch sein lassen. Es ist nur Unfug den einen grundlos zu diskreditieren und das ander als das modernste seit geschnitten Brot anzupreisen. Technisch gäbe es für mich keinen Grund den MSP430 nicht zu nehmen. Das gleiche gilt aber auch für den AVR. Aber irgendwomit muß man anfangen. Es ist einfach nur eine Entscheidung und Geschmackssache, gepaart mit Pragmatismus (wo bekomme ich leicht zubehör, Informationen , Tutorials und Forenhilfe), nicht mehr, nicht weniger. In diesem Forum gibt es zur Zeit mehr support für AVR, dafür ist das launchpad günstig. Die Techdocs sind für beide ebenso umfangreich wie suboptimal (ewig lange generische copy&paste-Orgien in denen beispielsweise die Unterschiede der einzelnen Timer unauffälig eingestreut sind). Die Techdocs sind zwar vollständig aber nicht gerade Einsteigerfreundlich. Darum sind weitere Lernquellen mindestens genauso wichtig. Wen interessiert es dann ob ich ein Detail das man so oder so Lösen kann, bei dem einem Chip mit Fuses und bei dem anderen per Software gelöst wurde. Wichtig ist nur, daß es a) funktioniert b) verständlich beschrieben wurde und c) das ich jemand fragen kann der es erklärt wenn es nicht verständlich oder unnötig kompliziert beschrieben wurde. Technische Detailfragen sind für die Wegentscheidung des Einstiegs unwichtig. Wichtig ist nur daß es kein Urwald ist. Letztlich läuft es darauf hinaus, das man sich für einen entscheidet. Und das ist dann natürlich immer das Beste^^ Auch wenn viele sehr ähnlich sind. Beim PIC könnte ich noch Bedenken verstehen, weil sie nicht so einheitlich sind und teilweise ein bisschen kruddelig in der Speicherverwaltung sind wenn man das zu Fuß(Assembler) programmieren will. Aber auch das ist nicht immer wirklich relevant, aber es wäre wenigstens eine konkrete Nennung einer Sache die man als suboptimal ansieht. Mal ganz nebenbei: Wie gut kennst du denn die AVR im Detail?
16 bit schrieb: > Gezielte Fragen werden sicherlich auch hier beantwortet. Es gibt einen > eigenen Unterbereich. > > Es wäre schön, wenn du für andere Interessierte von deinen Erfahrungen > berichtest. Mach doch einen Beitrag im MSP Bereich auf. Das werde ich dann sicher machen. Nun, ein wenig Erfahrung mit µC's hab ich ja schon und deshalb ist die Aussage nicht ganz so streng zu werten. Das sieht jetzt schon mal ziemlich aufgeräumt aus. Was mir aber nicht gefällt!!!! Dass die von TI dafür nur eingeschränkte Software zur Verfügung stellten. Auch wird es sicher eine Umstellung sein, dass die Dinger kaum Strom an den Ports vertragen können.
Bin aber nach einem bisschen lesen schon jetzt schwer beeindruckt. Nicht nur vom MSP, auch dass ich mir da einfach den Code zusammen klicken kann. Nicht schlecht. Mal sehen,ob das dann so funktioniert. MSP430x2xx Family User's Guide ist auch toll gemacht.
F. Fo schrieb: > den Code zusammen klicken > kann Kannst du nicht. Da geht es um die Initialisierung.
Ganz unproblematisch scheinen MSP's auch nicht zu sein. Hier in Forum gibt's seitenweise Probleme mit "Fuses", die aber eben nicht separat versteckt sind, sonder sich in der Source breitmachen. Fast wie die Code-Orgien, mit denen man einen ARM hochfahren muß. Fast wie ein Mainframe-IPL. Nicht falsch verstehen, ich bin begeistert von der MSP-Architektur, aber daß der ganze Chip einfacher zu handhaben wäre, ist etwas verklährt betrachtet. Hat man am AVR die leidige DIV8-Fuse geändert und braucht keine genaue Zeitbasis, dann braucht man da nicht mehr ran. (habe bewußt nicht @16bit geschrieben, sonst geht er gleich wieder in Abwehrhaltung ;-)
Eher eine offensive Missionarposition. Oftmals sind scheinbare Verbesserungen nur Veränderungen.
Bastler schrieb: > Ganz unproblematisch scheinen MSP's auch nicht zu sein. Hier in Forum > gibt's seitenweise Probleme mit "Fuses", die aber eben nicht separat > versteckt sind, sonder sich in der Source breitmachen. Fast wie die > Code-Orgien, mit denen man einen ARM hochfahren muß. Fast wie ein > Mainframe-IPL. > Nicht falsch verstehen, ich bin begeistert von der MSP-Architektur, aber > daß der ganze Chip einfacher zu handhaben wäre, ist etwas verklährt > betrachtet. > Hat man am AVR die leidige DIV8-Fuse geändert und braucht keine genaue > Zeitbasis, dann braucht man da nicht mehr ran. > (habe bewußt nicht @16bit geschrieben, sonst geht er gleich wieder in > Abwehrhaltung ;-) Die Hand drüber halten und dann hat der gemacht was ich will, das hat auch leider nicht geklappt; Ist gerade angekommen und ich hab schon mal ein bisschen gespielt. Da ist in jedem Fall auch ne Menge Code nötig. Unterm Strich haben alle Systeme, denke ich, ihre Vor- und Nachteile.
Leute, ihr redet euch die Köpfe nur heiß. Der Ansatz des TO ist grundfalsch: 1,5 Volt Batterie, dann Stepup-Wandler, dann µC mit Uhrenquarz. Entweder man nimmt von vornherein einen µC, der für 1.5 Volt und weniger geeignet ist (sollte dann ja bis 0.9V noch arbeiten) und für's Stromsparen extra ausgelegt ist (was den Uhrenquarz einschließt). Allerdings gibt es sowas eher nicht im allgemeinen Bastlerbedarf. Oder man kann das alles steckenlassen und gleich mit nem Lithiumakku anfangen - ohne irgendeinen StepUp-Wandler. Controller für Spannungen von 3 bis 4.2 Volt gibt's wie Sand am Meer und deren "LowPower"-Teil ist meistens überhaupt nicht wirklich so stromsparend wie ein echter 1.5V Controller. Deshalb sollte es auch ein Li-Akku sein. Die echte Stromspar-Alternative wäre, auch den LoPower-Teil des µC nicht zu benutzen und dafür einen echten RTC (Seiko-Epson) zu nehmen, der den µC so alle paar Sekunden mal aus dem absoluten Tiefschlaf weckt. Dann ist auch der Uhrenquarz überflüssig. W.S.
W.S. schrieb: > Allerdings gibt es sowas eher nicht im allgemeinen Bastlerbedarf. > > Oder man kann das alles steckenlassen und gleich mit nem Lithiumakku > anfangen - ohne irgendeinen StepUp-Wandler. Controller für Spannungen Haben diese LiPo-Akkus zum Basteln schon die Ladeschaltung drin oder muss man die noch extra ranfummeln? Die Dinger sollen ja sehr heikel sein beim Laden. Nen NiCd kann ich an ich ja "direkt an der Steckdose laden" so rubust sind die, NiMH ähnlich und wenn mal einer verreckt ist es auch egal die kosten ja nix aber LiPo, da sind schon einige in Rauch aufgegangen wenn man diverse Blogs liest. Mir sind die ehrlich gesagt zu empflindlich um die unbeaufsichtigt zu lassen, Nässe mögen sie auch nicht, das allein schon ist für mich ein NoGo, da ich viele MCs draussen betreibe. Man denke da nur an die selbstentzündeten Airbusse, Handys, iPads,... und da sassen keine Hobbybastler in der Entwicklung. Was ist mit diesen Hochleistungskondensatoren, ginge das auch als Batterieersatz für LowPower-Mcs die nur ab und an aufwachen was messen und wieder schlagen gehen?
rubbelkondensator schrieb: > Was ist mit diesen Hochleistungskondensatoren, ginge das auch als > Batterieersatz für LowPower-Mcs die nur ab und an aufwachen was messen > und wieder schlagen gehen? Ja, dafür gehen die. Allerdings halten die ihre Ladung nicht besonders gut (ein paar Tage natürlich schon aber halt nicht Jahre) deshalb muss man die immer etwas nachladen z.b. mit einem kleinen Solarmodul. Wenn du ein zwischending zwischen Akku und Kondensator haben willst kann du ja dir mal Lithium Ionen Kondensatoren anschauen, vielleicht taugen die ja was für deinen Zweck.
rubbelkondensator schrieb: > Man denke da nur an die selbstentzündeten Airbusse Nicht Airbuss - Boing Dreamliner! ;)
Immer diese Glaubenskriege... Als erstens, die Aussage von W.S. kann ich voll unterschreiben, es ist Lötzinn mit 1,5V und Stepup Wandler zu arbeiten. Ich habe ein Projekt mit einem AVR und einem MSP430 am anderen Ende, der MSP430 aus Stromspar- und Neugiergründen :-) Als Stromversorgung baue ich dort eine Lithiumprimärzelle mit 3,6V 2600mAh ein, die Saft LS14500, Größe wie eine 1,5V AA Zelle. Equivalentes gibts auch bei Reichelt für unter 3 Euro. das AVR am anderen Ende wird aus USB gespeist. Erfahrungen mit dem MSP: Die Doku ist gewöhnungsbedürftig, man muß stets das Family- und das Device Manual gleichzeitig offen haben wenn man sich die Programmiererei der Peripherie zusammensuchen muß. Ungewöhnlich ist das Clock Konzept z.B. eines MSP430G2553 (der bei Launchpads mitgeliefert wird), es ist nicht so recht möglich die CPU mit einem externen HF Quarz (.z.B. 16Mhz) direkt zu betreiben, man muß den DCO über den Uhrenquarz kalibrieren. Direkt der Quarzclock als CPU Takt geht da nicht (es geht trotzdem, ist aber außerhalb der Spec). Die Peripheriei/Timer kann aber sehr wohl aus den 32Khz gespeist werden, auch seriell mit 9600 Baud ist auf Grund cleverer Teilergeschichten mit 32Khz Takt möglich. Die Granualarität der Timerei leidet natürlich unter dem niedrigen Takt. Ein weiteres Problem kann der Geiz mir RAM sein, größere MSPS haben auch mehr RAM, aber nicht im Entwicklerfreundlichen DIP Gehäuse. 512Bytes ist da nicht soo der Bringer für eine PDP11 :-) Mit dem Flash muß ich mich nochmal unterhalten, die Teile haben kein EEPROM und was ich von FRAM so halten soll, ist mir momentan auch noch nicht klar. Das Launchpad als Programmer/Debugger ist für die knapp 5 Dollar preislich wohl nicht mehr zu unterbieten, da ist bei Atmel Alles teurer. Eine Bitte hätte ich an TI: Macht einen DIP40 oder notfalls einen PLCC44/68 mit reichlich RAM und I/O auf dem man entwicklen kann um dann das Endprodukt auf einen kleineren, passenderen MSP umzusetzen. Achja, IMHO sollten bekannte Errata auch mal aus den Devices verschwinden, oder? Es list sich seltsam wenn die selben Bugs über verschiedene Silicon Revisions konstant in den Dingern vorhanden bleiben. Da ich die GNU Compiler und Devel Tools auf FreeBSD benutze gibt es für mich von der Softwareseite kaum einen merkbaren Unterschied. Ich programmiere die Peripherie aber weder bei AVR noch beim MSP über das mitgelieferte Klickibunti (auch die Fuses beim AVR nicht) sondern gucke ins Datenblatt was die Bits machen. Ich habe noch nie einen AVR verfused. Ich werde also in Zukunft nicht das Eine oder das Andere benutzen, sondern das von dem ich denke das es besser paßt. Mit C programmiert merkt man weder den Unterschied zwischen 8 und 16 Bit noch muß man sich großartig umgewöhnen. Die Peripherie ist sowieso nur 8 Bit Breit. Nochwas: Es gibt wohl für die MSPs eine Arduino ähnliche Geschichte, deren Name ist mir aber momentan entfallen. IMHO passen sogar irgendwelche Schields direkt dran. Das interessiert mich aber nicht so sonderlich, ich habe gar keinen Arduino.. PIC12 und 16's hatte ich auch schon mal in den Fingern, habe die mit Assembler programmieren müssen. Da bildeten sich aber innerhalb kurzer Zeit Ekelblasen...das wird dauern bis ich wieder einen anfasse. Das nächste Projekt findet auf Grund der nötigen Rechenleistung auf einem STM32F107 statt. Gruß, Holm
Hallo Holm, vielen Dank für deine Eindrücke! Hatte vorgestern das erste MSP Board erhalten und fand dass es mit noch einem Controller und Headern, Quarz und Kabel geliefert wurde, echt klasse. Ich glaube diese starke Verteidigung von dem einem oder anderem System kommt daher, dass die Leute sich in dem einem oder anderem System gut auskennen. Da ich selbst noch Anfänger bin, bin ich ziemlich offen für alles. Einiges gefällt mir sehr gut an den MSP's, aber dass ich ihn einfach in die Hand nehme und er programmiert sich durch meine Gedanken von selbst (starke Übertreibung), wird auch hier nicht der Fall sein. So wie ich das bisher verstanden habe, man kann wohl jeden GPIO mit PWM versehen. Das empfinde ich schon als einen großen Vorteil (aus Erfahrung). Trotzdem, zunächst werde ich das Lernen auf den AVR's weiter machen. Da bin ich schon etwas mehr zu Hause. Das mit der Taktung kann auch vielleicht einmal ein Vorteil sein/werden, aber im Moment sehe ich das bein den AVR's einfach als einfacher an, den Takt schon gleich fest legen zu können. Da ich mit Arduino angefangen habe und nun sehe, dass das immer mehr wächst und es einfach einfach ist, da was zu machen, kann ich und werde ich dieses ganze Projekt nicht verteufeln. Ich will C, C*++ und Assembler können und nicht in diesen .ino stecken bleiben. Trotzdem kann ich sagen, will jemand schnell an ein Ziel und ist das was er bauen will das vornehmliche Ziel, so ist Arduino keine schlechte Wahl.
Ich habe auch noch keinen Controller gefunden der sich mit Gedankenübertragung programmieren ließe, leider ... PWM hat mich bisher nur ein mal für eine Motorsteuerung interessiert, ich habs nicht so mit bunten LEDs :-) Die Clocksystem vom MSP430 ist auch kein Nachteil, das bezog sich nur auf den MSP430G2553, also den der auch beim Launchpad beiliegt. Für Basteleien geht das wie schon angedeutet trotzdem mit dem direkten Quarztakt und für den DCO gibt es Kalibriervariablen fertig im Flash (das ist in seiner Granularität bei den unterschiedlichen MSPs auch unterschiedlich weit ausgebaut. Im Endeffekt ist es unter C recht einfach damit klar zu kommen. Das hier schaltet den Low Frequency Xtal Oszillator ein: BCSCTL3 = (BCSCTL3 & ~XCAP_3) | XCAP_1; Wobei man die Lastkapazitäten für den Quarz mit den XCAP Einstellungen variieren kann, der Takt läßt sich auf eineim IO Pin ausgeben um ihn zu messen. Den Systemclock dreht man hiermit auf 16Mhz: BCSCTL1= CALBC1_16MHZ; DCOCTL = CALDCO_16MHZ; Wobei sich das "life" auf andere Frequenzen drehen läßt. es ist beispielsweise möglich den Takt während des Programmlaufes auf 1Mhz zu setzten (oder wo anders hin) wenn das Ding gerade nicht viel zu tun hat, das ist schon ein Stück weit flexibler als der Fusemechanismus der meisten AVRs. Es muß kein NAchteil sein, das die CPU aus einem RC OSzillator betrieben wird, Zeitabhängigkeiten programmiert man nicht als Verzögerungsschleife und für genaue Sachen gibts noch 2 16 Bit Zeitgeber und selbst der Watchdog läßt sich als solcher mißbrauchen und kann als normaler interruptfähiger Timer laufen. Meine Bastelleien für mich selbst landen meistens auf einer Lochrasterplatte die hinten mit CUL Draht verfitzt ist, Meiner bescheidenen Meinung nach lohnt es nicht extra Platinen zu entwerfen wenn man nur 1 Stück benötigt. Als Prozessor kommt drauf, was sich gerade in der Bastelkiste befindet und "paßt". Für ARM Prozessoren ist diese Verfahrensweise natürlich weniger geeignet. Einen Arduino würde ich auch nur als bereits verdrahteten Einplatinenrechner ansehen und genauso wie bisher programmieren, die ganze dazugehörige Software würde ich wahrscheinlich liegen lassen ohne mir die anzusehen. Ich habe einen ziemlichen Baukasten aus dem was ich schon mal Softwaremäßig gemacht habe und bediene mich halt da. Ich habe schon Alles mögliche an Prozessoren programmiert und in dieser Hinsicht auch keine Berührungsängste. Das schrägste an Mikros waren bisher 8048 und PIC12C, Bei den PICs geht mir die Bankerei auf den Fisch, aber wenn es dann halt ein kommerzieller Auftrag ist, mache ich auch das. Dieses Arduino-ähnliche Projekt für MSP430 heißt übrigens Energia (www.energia.nu), aber ich habe da nicht wirklich einen Plan was das so treibt.. Für Dich als lernender einer "richtigen" Programmiersprache wird es schon richtig sein, wenn Du erst einmal eine Plattform benutzt sonst wirst Du Dich simpel "vertüddeln" weil Du mit mehreren Unbekannten gleichzeitig hantierst. 2 Spielprojekte möchte ich unbedingt mal noch auf die Reihe kriegen: einen SBC mit einer russischen PDP11 CPU (K1801VM2 oder VM3) auf dem auch Sachen wie RT11 oder RSX laufen und eine Eigenbau Bitslice CPU aus AM2901 oder -03 Bausteinen mit Mikroprogrammierung. Beides ist recht anspruchsvoll weil es IC Gräber werden.. Gruß, Holm
Und ich dachte, solche Diskussionen kommen nur bei Threads mit der Frage "Was ist besser, ... oder ..." Wenn der TO aber doch schon sagt, es sollte ein Atmel (vermutlich AVR) sein, dann warum sollte man PIC, MSP, usw noch nennen? Ist doch total hohl. Wenn er überhaupt Einsteiger ist. Selbst wenn er einer ist, ist es doch naheliegend, dass er sich schon einige Sachen angeguckt und probiert hat. Ich kauf mir doch auch kein PICKIT3, mache ein paar Lauflichter, bin zufrieden und wechsel dann einfach, weil jemand hier das gesagt hat, zu einem anderen Hersteller. Das ist rausgeworfene Zeit und Geld. Kein Wunder dass von ihm nichts mehr kommt, wenn nach 1 1/2 Tagen 70 Beiträge sind und es nach ca 4-5 sowieso immer das gleiche "Ich hab den Größeren" verbunden mit "Ich will das letzte Wort haben" ist. Da geht so ne Antwort wie "Wieviel Strom zieht denn der StepUp" oder "Du hast nen Falschen Ansatz" drin unter.
Hallo Holm, mit viel Interesse habe ich deine wirklich fachkundigen Ausführungen gelesen. Das hilft mir sehr weiter. Gestern habe ich wieder mal, nach langer Zeit, was gemacht. Meine Fritzbox wird zu heiß und da muss ein Lüfter her. Da ich nun schon einige Monate nicht mehr gelötet und programmiert hatte, viel mir das ganz schön schwer (vielleicht auch, weil ich bei der Hitze kaum noch schlafen kann). Ich hab es mit Arduino (völlig oversized) und es funktioniert, wie ich das will. Das ist im Moment die Hauptsache. Ja, man kann sich verzetteln und ich habe mittlerweile von dem Zeug so viel hier, dass ich bis ich 70 bin eigentlich nichts neues mehr brauchen werde. Hat sich so ein bisschen zur Sucht entwickelt. Ich will für mich im Moment nun nur noch mit dem Tiny13 und seinen Brüdern beschäftigen. Werde auch erstmal alles aus dem Buch nachbauen. So, nun aber Schluss mit dem kapern des Threads. Vielen Dank, Holm!
Wie jetzt? Was machst du jetzt mit dem launchpad? Deine Lüfterregelung ist doch ein tolles Projekt für den Einstieg. Es gibt viele Beispiele für PWM: http://www.msp430launchpad.com/2010/07/timers-and-clocks-and-pwm-oh-my.html http://gushh.net/blog/msp430-servo/
16 bit schrieb: > Wie jetzt? Was machst du jetzt mit dem launchpad? Die bleiben erstmal liegen. Wenn ich wieder ein bisschen drin bin und C gut genug kann, dann kommen die auch wieder in Betracht. Sind ja nicht weg und Schimmel setzen die ja auch nicht an. Hoffe in fünf Jahren so viel zu wissen, dass ich mir, so wie Holm, den µC nehme, der am besten zum Projekt passt.
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.