Hallo zusammen, NXP hat mit seinen Kinetis Produkten für mich sehr interessante Controller am Markt. Leider steht keine wirklich große Community dahinter. Wie hoch seht ihr die Hürden sich in deren Controller einzuarbeien und innerhalb einiger Wochen (max 8 (Projektarbeit)) ein fertiges Projekt abzuliefern? Eingesetzte Peripherie: CAN, BLE, I2C. C- STM32- (kaum) CMSIS-Erfahrung vorhanden. Vielen Dank
Warum Kinetis? Ist ja ok, aber wenn Du auf eine grosse Community Wert legst, wirst Du am besten mit den STM32 Controller bedient. Grosse Zahl and Dev-Boards für wenige Euros und zahlreiche Entwicklings-Tools. Die dauer für Dein Projekt hängt entscheidend fon Deinem KnowHow und deinen Fähigkeiten ab. Mit einem STM32 Nucleobord und ChibiStudio schätze ich für mich maximal 1 Woche https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.html http://www.chibios.org/dokuwiki/doku.php
Sehr gute Erfahrungen! Wenn man mit STM32 und mit Kinetis gearbeitet hat und beide kennt wird man die STM32 hassen und die Kinetis lieben. Die STM32-Peripherie ist im Vergleich dazu dermaßen verknotet und verkorkst daß es fast unmöglich ist dort ohne abstrahierende Libs auf den Registern direkt zu arbeiten ohne Gefahr zu laufen dem Wahnsinn anheimzufallen und Stühle und Tische aus dem geschlossenen Fenster zu werfen, bei Kinetis hingegen ist alles so sauber und logisch organisiert daß es im Vergleich dazu ein wahrer Traum ist.
:
Bearbeitet durch User
>...fast unmöglich ist dort ohne abstrahierende Libs >auf den Registern direkt zu arbeiten... Mit einer guten HAL ist es auch nicht nötig, Register direkt anzusprechen. Mit 'guter HAL' meine ich natürlich nicht das CMSIS/CubeMX Gewurstel von STM, sonder die HAL die zB. mit ChibiOS schon dabei ist! (und natürlich auch ohne ChibiOS verwendet werden kann)
Auch die LPC von NXP sind sehr gut, die 32 Bit Peripherie gefällt mir auch besser. ST hat einfach ein besseres Marketing. Karim schrieb: > Eingesetzte Peripherie: CAN, BLE, I2C. C- > STM32- (kaum) CMSIS-Erfahrung vorhanden. hier sind Boards die direkt von mbed unterstützt werden, da sind auch einige mit Kinetis dabei.
Ich habe auch mit verschiedenen LPCs herumgespielt. Der Einstieg ist einfach. Die IDE auf Eclipse ist praktisch. Und die mitgelieferten APIs haben mir gefallen, da klappte vieles auf Anhieb. Würde ich immer wieder nehmen, wenn ich einen ARM-M0 bräuchte.
Die Demo-Boards (FRDM-xxxx) mit Onboard-Debugger lassen sich übrigens alle auf J-Link umflashen (bei Segger runterladen) oder auch auf CMSIS-DAP (geht mit OpenOCD) und dann braucht man nicht diese komische proprietäre Debug-Software (war früher zumindest mal so). Geht alles problemlos auch unter Linux.
Karim schrieb: > Wie hoch seht ihr die Hürden sich in deren Controller > einzuarbeien und innerhalb einiger Wochen (max 8 (Projektarbeit)) ein > fertiges Projekt abzuliefern? Ich sehe das mit sehr gemischten Gefühlen. Der Grund dafür ist, daß deren Dokumentation extrem eigenartig und schwierig zu lesen ist. Nichts steht dort, wo man es braucht und die Leute von Freescale tun sich auch extrem schwer, ihre Chips verständlich zu beschreiben. Selbst um herauszukriegen, ob der Chip nun einen M4 oder einen M4F enthält, muß man sich halb tot suchen. Freescale hat beides im Portfolio, also ist Aufpassen angesagt. Manche haben DSP+FPU und andere nicht. Einen Bootlader haben m.W. die Kinetis nicht. Allerdings habe ich mich mit diversen Kinetis zuletzt vor etwa 2 Jahren befaßt. Vielleicht gibt's da ja was Neues. Abgesehen davon sind die verschiedenen Produktreihen fast nicht miteinander zu vergleichen. Manche sind nett in der Benutzung und in ihren Peripherie-Cores und andere sind extrem störrisch. Wenn ich mich recht erinnere, war die MKE Reihe so eine störrische: Zwar Li-Akku-kompliant (was ein dickes Plus ist), dafür aber nicht mal dedizierte Einstell-Register für die Pin-Funktionalitäten wie man sie bei anderen Reihen (z.B. MK02) hat. Ein elendes Problemkind ist bei manchen Produktreihen die Taktversorgung. Selbstverständlich kann man einen externen Quarz (so im üblichen 2..16 MHz Bereich) anschließen - aber das nützt nichts, denn dieser muß zuerst auf 32..39kHz heruntergeteilt werden, um dann per FLL wieder in passende Höhe gebracht zu werden und diese FLL hat einen derartigen Jitter, daß der USB-Core damit nicht betrieben werden kann. Also guck nach Chips, die nicht nur die elende FLL, sondern eine PLL enthalten. Ansonsten gibt es bei vielen Chips nette Gimmicks: hardwaremäßige Querverdrahtungen diverser Art, die so manche Konstruktion ermöglicht, die man woanders eben nicht hinbekommen kann. Ebenso bei manchen Chips einen DMA-Core, der auch geschachtelte Funktionsschleifen kann. Fazit: Mit einigen Reihen kommt man binnen eines halben Tages zu Potte und andere Reihen schmeißt man nach 6 Wochen vergeblichen Bemühens frustriert in die Tonne. Generell habe ich den Eindruck von Kinetis, daß sie aus einem firmeninternen Modul-System zusammengebaut wurden, wobei die hinter den verschiedenen Modulen stehenden Teams sich gegenseitig hassen. So passen die Module nicht wirklich gut zueinander und die Dokumentation ist extrem formalistisch, weil nur so die Teams dazu gezwungen werden konnten, ihre Beiträge zu den Manuals zu liefern. Also lade dir die diversen Dokumentationen herunter und lies selber. Das ist besser als jede Anfrage hier. Bernd scheint ein Liebhaber des Dokumentationsstils von Freescale zu sein, er lobt das immer über alles. Deswegen nochmal: lies es selber und bilde dir deine eigene Meinung. W.S.
W.S. schrieb: > Der Grund dafür ist, daß deren Dokumentation extrem eigenartig und > schwierig zu lesen ist. Nichts steht dort, wo man es braucht und die > Leute von Freescale tun sich auch extrem schwer, ihre Chips verständlich > zu beschreiben. Das hast Du jetzt schon x-mal geschrieben, stimmen tut's (nach meiner persönlichen Erfahrung) trotzdem nicht. Was/wieviel hast Du schon auf Kinetis gemacht? Bernd K. schrieb: > Wenn man mit STM32 und mit Kinetis gearbeitet hat und beide kennt wird > man die STM32 hassen und die Kinetis lieben. das würde ich hingegen unterschreiben.
W.S. schrieb: > und diese FLL hat einen > derartigen Jitter, daß der USB-Core damit nicht betrieben werden kann. Die mit USB haben eine echte PLL. Zum Beispiel der KL26.
W.S. schrieb: > Wenn ich mich > recht erinnere, war die MKE Reihe so eine störrische: Zwar > Li-Akku-kompliant (was ein dickes Plus ist), dafür aber nicht mal > dedizierte Einstell-Register für die Pin-Funktionalitäten wie man sie > bei anderen Reihen (z.B. MK02) hat. Da seh ich jetzt eigentlich keinen Nachteil drin, eher im Gegenteil, es wurde Redundanz entfernt. Wenn ich am UART den TX-Pin aktiviere greift der sich automatisch den zugehörigen Portpin, genauso wie ich es haben will. Im PINSEL-Register kann ich einstellen welchen davon wenns mehrere Möglichkeiten gibt. Ebenso muß man dort nicht erst den GPIO mit Takt versorgen wenn man überhaupt irgendwelche Pins für irgendwas benutzen will, die sind ab Reset schon an. Eigentlich geht es beim MKE in dieser Hinsicht genauso pragmatisch direkt zu wie damals beim AVR, darüber hat sich dort auch noch keiner beschwert, im Gegenteil: Beim STM32 muss ich erst dies und jenes einschalten und konfigurieren bevor ich überhaupt erst die Pins benutzen kann, das wurde immer als erstes auf den Tisch gebracht bei jeder Diskussion AVR <-> STM32. Nun gibts auch ARMe bei denen das genau so simpel geregelt ist wie beim AVR und nun ist es plötzlich auch wieder nicht recht. Mir persönlich ist das egal, ob ich jetzt noch vorher zwei Bits extra irgendwo setzen muss oder ob das implizit automatisch geht ist mir Wumpe denn die zwei Konfigurationseinstellungen mehr oder weniger machen den Kohl auch nicht mehr fett und ich sehe unterm Strich auch keinen praktischen Mehrwert oder Verlust. Nenne doch mal ein Szenario bei dem Du zum Beispiel einen UART-Pin oder einen PWM-Ausgang oder SPI oder was auch immer aktivieren willst ohne auch den zugehörigen Pin-Mux auf genau diese Funktion zu konfigurieren, mir fällt auch nach mehreren Jahren praktischer Arbeit damit keins ein. Dieser separate manuelle Pin-Mux ist vollkommen redundant. Deshalb geht das dort automatisch und man muss keine Abstriche machen.
Bernd K. schrieb: > Da seh ich jetzt eigentlich keinen Nachteil drin, eher im Gegenteil, es > wurde Redundanz entfernt. Wenn ich am UART den TX-Pin aktiviere greift > der sich automatisch den zugehörigen Portpin, genauso wie ich es haben > will. Nein, so geht das eben dort nicht, denn zuvor greift die Präzedenz gemäß Funktionsliste der Funktion 0..7. Wenn da irgend ein Core Präzedenz hat, dann greift sich dieser das Pin und dein UART ist abgehängt. Das Ende vom Lied ist bei diesen Chips, daß die Funktionalität eben immer noch zusätzlich davon abhängt, was denn sonst so alles auf dem Pin noch möglich ist und was davon den Vorrang hat. Ich kann sowas überhaupt nicht leiden. Ich will den Pins ihre verdammte Funktion SELBST zuweisen und basta. Und bei einigen Reihen geht das ja auch bestens. Ich hab hier noch ein paar alte Versuchsbrettl herumfliegen mit MKL05Z8VLC4, MKE02Z16VLC4, MKE06Z128VLD4. Eh ich mich über die ärgere, laß ich sie lieber in der Kiste sedimentieren. Weiter gemacht hatte ich damals mit den MK02FN128VLH10 und MK22FN128VLH10 und ein paar andere Typen stecken von damals noch in ihren Tüten. Wie gesagt, die Kinetis sehe ich mit sehr gemischten Gefühlen. Wahrscheinlich fasse ich nur noch diejenigen mal wieder an, die sich von Anfang an ordentlich programieren lassen hatten - und ansonsten werde ich mich wohl eher an die neueren Typen von Nuvoton halten. Hab noch keine da, das 'neueste' sind bei mir die NUC120/140 von vor mehr als 5 Jahren. Aber sowohl das aktuelle Portfolio von Nuvoton als auch die Dokumentation als auch die Preise sind mit recht interessant. W.S.
W.S. schrieb: > Nein, so geht das eben dort nicht, denn zuvor greift die Präzedenz gemäß > Funktionsliste der Funktion 0..7. Wenn da irgend ein Core Präzedenz hat, > dann greift sich dieser das Pin und dein UART ist abgehängt. Wie gesagt, ich versteh immer noch nicht was Du willst! Wenn Du auf dem Pin die Funktion B haben willst warum solltest Du dann gleichzeitig auf dem selben Pin auch noch die Funktion A aktivieren die Du da dort gar nicht haben willst? Lass A doch einfach ausgeschaltet! Oder legs mit dem PINSEL auf einen anderen Pin! Nochmal: In welchem Szenario willst Du A auf dem selben Pin einschalten aber nicht benutzen weil dort schon B aktiv ist? Klär mich auf! > Ich hab hier noch ein paar alte Versuchsbrettl herumfliegen mit > MKL05Z8VLC4, MKE02Z16VLC4, MKE06Z128VLD4. Eh ich mich über die ärgere, > laß ich sie lieber in der Kiste sedimentieren. Schenk sie dem Threadersteller, der interessiert sich dafür.
:
Bearbeitet durch User
Bernd K. schrieb: > Nochmal: In welchem Szenario willst Du A auf dem selben Pin einschalten > aber nicht benutzen weil dort schon B aktiv ist? Klär mich auf! OK, ich klär dich auf: ich will normalerweise natürlich nicht auf einem Pin zwei verschiedene Funktionen aktiv haben. Aber mir ist es auch zu lästig, für jedes Pin durch alle dort relevanten Cores zu tingeln, um alle bis auf den einen dediziert auszuschalten. Mit richtigen Zuweisungsregistern ist das alles um Größenordnungen einfacher: man weist zu und fertig. Es kommt einem da kein anderer Core dazwischen. Das vereinfacht die Programmierung der Firmware ganz erheblich, weil man in den jeweiligen LL-Treibern keine Seiteneffekte auf andere Treiber hat. Ich denke mal, wir hatten dieses Thema schon vor langer Zeit diskutiert. W.S.
W.S. schrieb: > für jedes Pin > durch alle dort relevanten Cores zu tingeln, um alle bis auf den einen > dediziert auszuschalten. Bitte was? Was ausschalten? Du schaltest die ein die Du brauchst. Fertig. Die anderen Peripherien die Du nicht brauchst lässt Du komplett in Ruhe, die schaltest Du gar nicht erst ein, denn die sind allesamt aus ab Reset. Ich glaub Du schreibst hier über Dinge die Du noch nie selbst gesehen hast oder gar in der Hand hattest, ich würde mal nen Gang zurückschalten und erst mal die Fakten checken.
:
Bearbeitet durch User
Bernd K. schrieb: > Ich glaub Du... nanana, nicht so. Aber lassen wir das. Dir sind dedizierte Pin-Setupregister nicht so wichtig, mir hingegen sehr - da sind wir halt unterschiedlicher Ansicht. Und persönliche Unterstellungen schätze ich auch nicht. Für den TO sollte dieser Thread inzwischen ausreichen, er kann sich das alles ja selber anlesen. Ein paar erste Eindrücke hat er ja schon - vorausgesetzt, er liest hier überhaupt noch mit. Hab da aber meine leisen Zweifel. W.S.
Hi Wie verhält es sich dann bei Peripherie von der ich nur einige Pins verwenden will? Z.b. SPI nur in Senderichtung oder UART nur in Empfangsrichtung? Matthias
Lohnenswert ist auch ein Blick auf https://mcuoneclipse.com Der Autor (FH-Prof in der Schweiz) ist zwar erklärter Fanboy, erklärt aber gut den Umgang mit den Kinetis. Abgesehen davon fand ich die ST-Toolchain und -Beispiele immer einen Graus an Inkompatibilitäten und seltsamen Konzepten. Im Kinetis-Umfeld fand ich das durchdachter (aber auch lange nicht perfekt).
Angehängte Dateien:
-
ke04-uart-te-re.png
130 KB -
ke04-spi-bidir.png
24 KB
Μαtthias W. schrieb: > Wie verhält es sich dann bei Peripherie von der ich nur einige Pins > verwenden will? Ich geb mal ein Beispiel vom UART: Jede Peripherie mit optionalen Pins hat Bits in ihren Konfig-Registern die diese separat einschalten. So kann man zum Beispiel einen UART initialisieren der nur RX macht, der TX-Pin bleibt dann weitergin GPIO. (siehe Bild). > SPI Man kann den Datenpin in einen bidirektionalen Modus schalten wo ein Datenpin wahlweise Senden oder Empfangen kann, MOSI wird dann zu MOMI (oder MISO zu SISO) und der andere pin bleibt GPIO. Dann kann man einstellen ob man Senden oder Empfangen will (siehe Bild). Auch den Slave-Select-Pin kann man ein oder ausschalten. So geht das bei jeder Peripherie bei der eine Betriebsart mit eingeschränkter Pinzahl Sinn ergibt. Zusätzlich gibt es noch ein PINSEL-Register bei denen man bei einigen Peripherien auf Ausweichpins umschalten kann sofern dort eine Mehrfachbelegung mit anderen Peripherien vorliegt. Es lässt sich in der Praxis immer eine Kombination finden bei der man alles benutzen kann was man braucht, die möglichen Pinbelegungen empfand ich zu keinem Zeitpunkt irgendwie "unglücklicher" als bei anderen.
Angehängte Dateien:
-
Manual_Reset_Section.png
11 KB
Dear Sir, We are using MK61FX512VMJ12 Controller, We are faced programming dumping issue as attached screenshot Since we are using manual reset Switch for resetting controller , When we use manual reset path the controller not working even old program also got erased , We tried for the reprogramming of the IC it is showing the error as attached, In the manual reset we are using the Supervisor IC along with the Switch , Kindly help us to solve this issue, when we are this controller for the several applications with the same manual reset circuits some boards are not given this issue but some boards are facing lot of issue Thanks and Regards: Chidanand N M +91 9591519820 chidanand@slntech.com
Max G. schrieb: > Lohnenswert ist auch ein Blick auf https://mcuoneclipse.com > Der Autor (FH-Prof in der Schweiz) ist zwar erklärter Fanboy, erklärt > aber gut den Umgang mit den Kinetis. Naja, Erich Styger ist nicht (jedenfalls nicht nur) "Fanboy", sondern ganz offizieller Freescale/NXP Mitarbeiter. Von seiner Webseite habe ich auch schon das ein oder andere lernen können, nicht nur was Kinetis angeht, sondern allgemein. Seine Kinetis-spezifischen Blogartikel sind mir aber viel zu sehr auf Freescales/NXPs IDEs und Tools zugeschnitten. Da kann man sehr schön sehen was passiert wenn man sich zu sehr in deren Abhängigkeiten begibt. Erst CodeWarrior, dann obsolet, danach Kinetis Design Studio, was nun auch obsolet ist und nun ist MCU Xpresso da. Solange man nur lernt wo man in dieser oder jener IDE hinklicken muss aber nicht verstanden hat was da eigentlich passiert, d.h. warum man das so macht, hat man eben eine grundsätzliche Abhängigkeit von diesen Hersteller-Tools. Das gilt natürlich genauso für ST. Eigentlich haben die Kinetis-Controller das auch gar nicht nötig. Den Ausführungen von Bernd kann ich mich nur anschließen. Die Kinetis-Serie waren für mich meine ersten ARMs und ich fand die eigentlich sehr schick. Ich bin nur auf ST umgestiegen, weil ich als Student dort einfach viel günstiger an fertige Boards gekommen bin. Soetwas wie ein BluePill (und sei es nicht für 2€, sondern meinetwegen 10€) gibt es im Kinetisuniversum (soweit ich weiß) leider nicht.
Chidanand N. schrieb: > We are faced programming dumping issue as attached screenshot I don't know about this particular controller but the smaller ones are pulling their own reset pin low periodically when they are not programmed (the watchdog is doing this) and I see you have connected the output of your reset circuit to its input. Why is this? Other than that I have no idea what might be wrong in your application, sorry. Maybe ask in the Freescale/NPX forum, there are freescale engineers who know their chips better than me.
Bei größeren µC wie auch bei den Kinetes habe die Peripheriemodule keine Pins. Sondern nur Ein/Ausgänge Die Pins werden vom Port Modul verwaltet und dort wird auch die zu GPIO alternative Verwendung eingestellt und auch Treiberstärke usw... bei den Kinets sind es bis zu 8 möglichen alternativen ich kenne auch µC da geht das bis 20.
Christopher J. schrieb: > Solange man nur lernt wo man in dieser oder jener IDE hinklicken muss > aber nicht verstanden hat was da eigentlich passiert, d.h. warum man > das so macht, hat man eben eine grundsätzliche Abhängigkeit von diesen > Hersteller-Tools. Mein Einstieg in Kinetis war hier: https://github.com/0xc0170/kinetis_klxx_gcc Die hab ich dann Schritt für Schritt zerpflückt und noch weiter abgespeckt und wieder zusammengesetzt, so lange bis mir jede einzelne Datei und jede Zeile darin und deren genauer Zweck vertraut war, ein Makefile-Projekt in Eclipse aufgesetzt als Template für spätere Projekte, hab mit der Taktkonfiguration das Handbuch gewälzt bis ich das im Griff hatte und dann hab ich losgelegt. Später hab ich das dann auch problemlos auf KE04 portiert und auch auf ein paar Nicht-Kinetis Cortexe von STM und von GD und mit all dem was man bei sowas lernt kann man das später in kürzester Zeit für jeden beliebigen neuen Cortex-M erneut vollführen.
Volle22 schrieb: > Die Pins werden vom Port Modul verwaltet und dort wird auch die zu GPIO > alternative Verwendung eingestellt und auch Treiberstärke usw... Ja, bei den meisten anderen Kinetissen aber nicht beim MKE04 (und anderen MKE evtl. auch nicht, ich kenn sie nicht alle), das war ja das "Problem" von WS, da geschieht das automatisch beim Aktivieren der Peripherie-Aus/Eingänge und die Peripherie "nimmt" sich den zugehörigen Pin einfach und was "zugehörig" ist kann man in gewissen Grenzen im Pinsel-Register umschalten. Man wählt dort also nicht pro Pin die Peripherie aus die zugeordnet ist sondern man wählt pro Peripherie aus welchen Pin sie bekommen würde wenn man sie einschaltet. Aber sonst kann man eigentlich genau das selbe machen im Rahmen der verfügbaren Alternativpins, es wird nur gewissermaßen von der anderen Seite aus konfiguriert. Und ich finde das jetzt auch nicht irgendwie komplizierter oder unzugänglicher, es ist eigentlich genauso leicht zu überblicken und zu handhaben, wenn nicht sogar leichter in vielen Situationen weil meist die Defaults schon so gesetzt sind wie man sie braucht und man die Peripherie nur noch einschalten muß und schon kanns losgehen. Der MKE04 ist sowieso sehr überschaubar und wenig komplex, ein idealer Einsteiger ARM oder auch für Umsteiger von AVR sehr empfehlenswert, fast genauso leicht mit dem Handbuch allein zu beherrschen wie ein Atmega, sogar noch ein bisschen logischer aufgebaut, aber das ist ein subjektiver Eindruck.
:
Bearbeitet durch User
Christopher J. schrieb: > Naja, Erich Styger ist nicht (jedenfalls nicht nur) "Fanboy", sondern > ganz offizieller Freescale/NXP Mitarbeiter. Tatsache, auf dem LinkedIn-Profil steht das. War mir nicht bewusst. > Erst CodeWarrior, dann obsolet, danach Kinetis > Design Studio, was nun auch obsolet ist und nun ist MCU Xpresso da. Jetzt, wo du´s sagst...ich habe schon beim Zwangsumstieg auf KDS aufgegeben. Hatte mit dem KDS-Umstieg aber nur teilweise zu tun. > So etwas wie ein BluePill (und sei es nicht > für 2€, sondern meinetwegen 10€) gibt es im Kinetisuniversum (soweit ich > weiß) leider nicht. Ja, für die Cortex M0+ geht es irgendwo bei 15 EUR los, für die Cortex M4 um die 30 EUR. Ist nicht wirklich bastelfreundlich, vor allem nicht im Vergleich zu den Dumpingpreisen von ST.
Max G. schrieb: > Ja, für die Cortex M0+ geht es irgendwo bei 15 EUR los, für die Cortex > M4 um die 30 EUR. Ist nicht wirklich bastelfreundlich, vor allem nicht > im Vergleich zu den Dumpingpreisen von ST. Ähemm... Warum versteifst du dich darauf, irgend ein fertiges Eval-Board haben zu wollen? Die Preise für LP aus China sind heutzutage sowas von günstig, daß man weitaus besser fährt, wenn man sich sein Board selber baut. Dann wird das ganze auch billiger. Und was die Chip-Preise bei ST betrifft, so war es zumindest vor etwa 2 Jahren so, daß diese um etwa 20% höher lagen als die von vergleichbaren LPC von NXP - und die Preise der Kinetis waren bislang noch einen Tick billiger als die vergleichbaren LPC. Die angeblich billigeren STM32-Preise sind ein Mißverständnis, das von den in China gefertigten STM32F103 und Konsorten herrührt. Diese sind allerdings tatsächlich so billig, daß man - egal ob man ST nun mag oder nicht - für sehr viele Bastelzwecke eben so einen Chip benutzt. Mache ich auch so. Hab grad mal bei Mouser geschaut: Die MKE-Reihen sind dort tatsächlich recht billig zu haben, so im 1.50€ Bereich, allerdings mit mickriger Flash/Ram-Ausstattung. Offenbar gehen die nicht wirklich gut. Andere Reihen liegen dann gleich im Bereich so ab 5€ aufwärts. Also nicht so billig wie man es sich wünscht. Ich selber schiele deswegen eher nach Nuvoton, siehe: https://direct.nuvoton.com/de/m4-mcu/ wo man für nen M4 Preise im 2€ Bereich findet. Alternativ GigaDevices mit ihren STM32-Derivaten, aber da ist man ja wieder bei der 16 bittigen STM32-Peripherie, wo Leute wie Bernd nen Haß drauf haben. Ich selber sehe das eher moderat, wo's paßt, isses gut, wo nicht, nimmt man was anderes. also: Board selber machen, das wird erstens billiger und zweitens wird es besser auf die eigenen Projekte passen. W.S.
Nachtrag: Vielleicht könnten wir ja hier mal so ein billiges µC-Board mit nem billigen Kinetis drauf machen. Ich steuere main, conv, gio, cmd und ggf. systick, events, gdi und fonts bei und Bernd macht die config und die Lowlevel-treiber dazu. Obwohl: lowlevel serial, systick, tasten, ir-rx für MK02FN.. hab ich ja auch schon im Portfolio. Aber das ist ja auch ein Typ mit Pinkonfig-Registern... Also: Wär das was? W.S.
W.S. schrieb: > Warum versteifst du dich darauf, irgend ein fertiges Eval-Board haben zu > wollen? Die Preise für LP aus China sind heutzutage sowas von günstig, > daß man weitaus besser fährt, wenn man sich sein Board selber baut. Dann > wird das ganze auch billiger. Just for the record: der Hinweis auf Bluepill & Co kam nicht von mir. Für den ersten Einstieg ist es trotzdem einfacher, ein fertiges Board zu nutzen. Dann kann man mit hinreichender Wahrscheinlichkeit davon ausgehen, dass die HW in Ordnung ist. Bei einem Eigenbau mit einem unbekannten µC rätselt man dann gegebenenfalls, woran es denn nun hängt - Schaltplan, Layout, Aufbau, Software. Hat mich mit dem STM32L051 mal einen Haufen Nerven gekostet, weil ich nach meiner Erinnerung Reset nicht an den Debugger gelegt hatte. Dein Vorschlag, ein preiswertes Demoboard aufzubauen, klingt reizvoll. Aber: als fertiges Teil hast du RoHS und WEEE am Hals. Als Bausatz ist es auch etwas schwierig, nicht jeder mag SMD löten. Wobei man das auch als Auswahlkriterium für die Zielgruppe nehmen könnte ;) Letztendlich läuft es aber auf diejenigen hinaus, die - abseits vom AVR- und STM32-Mainstream etwas machen wollen - keine 30 EUR für ein fertiges Board ausgeben wollen - SMD Finepitch löten können und wollen Da dürften nicht viele übrig bleiben.
Christopher J. schrieb: > Soetwas wie ein BluePill (und sei es nicht > für 2€, sondern meinetwegen 10€) gibt es im Kinetisuniversum (soweit ich > weiß) leider nicht. den Teensy-LC gibt's für 11$: https://www.pjrc.com/teensy/teensyLC.html
Bernd K. schrieb: > Wenn man mit STM32 und mit Kinetis gearbeitet hat und beide kennt wird > man die STM32 hassen und die Kinetis lieben. Warum hassen? > Die STM32-Peripherie ist im Vergleich dazu dermaßen verknotet und > verkorkst daß es fast unmöglich ist dort ohne abstrahierende Libs auf > den Registern direkt zu arbeiten ohne Gefahr zu laufen dem Wahnsinn > anheimzufallen und Stühle und Tische aus dem geschlossenen Fenster zu > werfen, bei Kinetis hingegen ist alles so sauber und logisch organisiert > daß es im Vergleich dazu ein wahrer Traum ist. Kannst du das an einem (einfachen) Beispiel demonstrieren? Wäre sehr interessiert, da ich gerade vor der Entscheidung stehe einen 32-Bit Controller auszuwählen.
Bertram schrieb: > Kannst du das an einem (einfachen) Beispiel demonstrieren? Die Peripherie der STM32 war im Gegensatz zu den LPC von NXP ursprünglich nur 16 bittig und ST tut sich schwer, das bei neueren Typen so langsam mal auszumerzen. Das sind nicht nur die Timer, sondern die ganze Malaise sieht man deutlicher, wenn man sich die 16 bittigen I2S Cores anschaut. Stell dir vor, ein Audio-Sample (2x 32 Bit) in 16 Bit Häppchen empfangen zu müssen. 192 kHz Samplefrequenz und das mal 4, und obendrein kein Fifo im I2S-Core. Per Interrupt kriegt man Pickel und ne Krise und per DMA muß man sich krumm machen, diesen Zirkus stabil zum Laufen zu kriegen. Mit den neueren SAI-Cores ist das zwar ein bissel leichter, aber noch lange nicht so, wie man sich das wünschen würde, nämlich ein komplettes Sample (L+R) mit einem Int zur Verarbeitung herein zu kriegen. W.S.
Markus F. schrieb: > Christopher J. schrieb: >> Soetwas wie ein BluePill (und sei es nicht >> für 2€, sondern meinetwegen 10€) gibt es im Kinetisuniversum (soweit ich >> weiß) leider nicht. > > den Teensy-LC gibt's für 11$: https://www.pjrc.com/teensy/teensyLC.html Die Teensies hatte ich damals auch auf dem Schirm. Was mich jedoch total verstört hat war, dass dort die SWD-Pins nicht herausgeführt sind und alles hinter einem Closed-Source Bootloader verdongelt ist. Letzteres kann ich ja noch verstehen, schließlich müssen die Teensy-Schöpfer ja auch von irgendwas leben aber die Sache mit dem SWD hat mich zu sehr abgeschreckt. Wer wissen möchte welche Verrenkungen bei einem Teensy nötig sind um SWD-Zugang zu bekommen, dem sei (wieder einmal) die Seite von Erich Styger empfohlen: https://mcuoneclipse.com/2014/08/09/hacking-the-teensy-v3-1-for-swd-debugging/ Max G. schrieb: > W.S. schrieb: >> Warum versteifst du dich darauf, irgend ein fertiges Eval-Board haben zu >> wollen? Die Preise für LP aus China sind heutzutage sowas von günstig, >> daß man weitaus besser fährt, wenn man sich sein Board selber baut. Dann >> wird das ganze auch billiger. > > Just for the record: der Hinweis auf Bluepill & Co kam nicht von mir. > Für den ersten Einstieg ist es trotzdem einfacher, ein fertiges Board zu > nutzen. Ja, der Hinweis kam von mir. Das BluePill ist alles andere als perfekt aber man kann es direkt auf Lochraster verlöten, die Debug-Pins sind separat herausgeführt und im Zweifelsfall passt das Ding auch gut in ein Steckbrett. Kurzum: Mit dem Erstellen von Platinen und Löten von SMD-Bauteilen hat man erstmal nichts am Hut. Ich meine dabei nicht, dass man das nicht beherrschen könnte, selbst wenn es nur Hobby ist, im Gegenteil. Nie war es so einfach und so günstig eigene Platinen fertigen zu lassen und SMD ist mit Heißluft meiner Meinung nach sehr einfach zu beherrschen (abseits von BGA vielleicht) aber als Einsteiger in der Mikrocontrollerwelt muss man sich ja nicht in alles zugleich hineinstürzen.
Bertram schrieb: > Kannst du das an einem (einfachen) Beispiel demonstrieren? Wäre sehr > interessiert, da ich gerade vor der Entscheidung stehe einen 32-Bit > Controller auszuwählen. Was mich als jemanden der gerne auf den Registern direkt arbeitet besonders stört ist die Sache wie diese insbesondere bei Peripherien mit mehreren Kanälen organisiert sind. Bei Kinetis sind sie in erster Ordnung nach Kanal und in zweiter Ordnung nach Funktion sortiert, das bedeutet zum Beispiel ein Timer hat 6 identische Blöcke in seinem Adressraum die alle identisch aufgebaut sind. Beim STM32 hingegen ist alles in erster Ordnung nach Funktion und in zweiter Ordnung nach Kanal sortiert und dann verteilen sich mal hier 4 Kanäle auf 2 Register, ein Stückchen weiter alle 4 in je einem Register und irgendwo noch 4 Kanalbits an einem freien Platz in einem globalen Konfigregister untergebracht als ob Registeradressen Geld kosten würden und man sie sparen muß. Du kannst nicht mal eben eine Funktion von einem Kanal auf nen anderen legen ohne jedes einzelne Bit auszutauschen weil das gleiche Bit für nen anderen Kanal einen anderen shift hat (und deshalb auch nen anderen Namen was auch die Header aufbläht) und manchmal auch noch in ein anderes Register kommt. Beim Kinetis änderst Du einen Arrayindex und es wird der andere Registerblock benutzt, die Bits sind komplett identisch. Das lässt beim STM32 nur sinnvoll beherrschen wenn man eine Abstraktion hat die dieses Chaos wieder glattzieht, beim Kinetis braucht man sowas nicht, die Register sind schon von sich aus sauber sortiert. GPIO-Konfiguration genauso: beim STM32 mal 4 Konfig-Bits pro Pin auf 2 Register verteilt, mal 2 Bit pro Pin in einem Register, mal 1 Bit pro Pin, etc. alles ineinander verschränkt in so wenige Register wie möglich gequetscht. Wenn Du einen Pin umkonfigurieren willst musst Du etliche Register anfassen, maskieren, odern, etc. Beim Kinetis hat jeder Pin sein eigenes 32-Bit Konfigregister wo alle Einstellungen (Alternate, IRQ, Pullup, Pulldown, Drive-strength, Filter, Slew-Rate, etc) in einem einzigen Register zu finden sind das für jeden Pin identisch aufgebaut ist. So zieht sich das wie ein roter Faden durch die ganze Peripherie, die Kinetis-Register sind für menschliche Programmierer optimiert, sie sind so sortiert daß es maximal übersichtlich und einfach zu benutzen ist, die STM32-Register sind für seelenlose Codegeneratoren gemacht oder für HAL-Bibliotheken die sich dann zur Laufzeit einen abbrechen müssen nur um einen Pin umzukonfigurieren. Das spürt man deutlich wenn man die gleichen Low-Level-Sachen mal auf der einen mal auf der anderen MCU implementiert, je länger man sich damit beschäftigt desto offensichtlicher wird der Unterschied.
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.