Seit ein paar Wochen frage ich mich, ob die "Freedom-Boards" aka Freescale FRDM-KL25Z/-KL26Z inkl. der IDE (Windows) ein wenig veraltet sind und ob es dementsprechend wenig sinnvoll ist, damit ein Testprojekt zu starten. Die IDE (Eclipse based) ist, wenn ich es richtig im Kopf habe, das letzte mal 2014 geupdated worden, also vor 7 Jahren. Daher auch mein Eindruck, dass FRDM-KL... auch mit M0+ Core eher Alteisen ist. Wenn das so ist, was wäre eine empfehlenswerte Alternative für dieses Testprojekt, das folgendes macht: Es sollen 2500 Spannungen (Widerstandsmatrix) über einen ext. 16-bit ADC inkl. Ansteuerung erfasst werden und zwar 10x bis 100x pro Sekunde. Eine Messung ist also die Erfassung von 2500 16-Bit Werten = Matrixgröße, die vom ADC über DMA (SPI Verbindung mit Interrupt) intern im SRAM abgelegt werden. Wenn die letzte Messung den Referenzwert liefert, gilt die Messung als gültig und der ganze Datenblock wird übertragen, entweder auf SD-Karte oder über UART an einen Host-PC, die Art steht noch nicht fest, wichtig ist nur, dass die irgendwo hinkommen. Dementsprechend groß müsste auch das SRAM sein, nämlich 2500 Werte zu 16 Bit = 5 kB* nur für eine Messung. Ich gehe davon aus, dass während der erste Datenblock über UART weggeschrieben wird oder auf SD-Karte landet, dass dann schon der 2. Messung läuft, also evtl. wären 10 kB SRAM nötig. Möglicherweise ist es auch möglich, direkt die Daten ohne SRAM-Zwischenspeicherung irgendwo hinzuschreiben. Das Speichern der Daten und versenden/wegschreiben soll wenn's eben geht über DMA gehen. Und weil bei uns noch diverse FRDM-KL25Z/-KL26Z Borads rumliegen, dachte ich vllt. könnte ich damit.... Weil ich aber auch meinen Horizont mal verbreitern will, wäre eine Alternative auch nicht schlecht. Mit STM32Fxxx habe ich schon ein paar Projekte bearbeitet, selbiges auch mit 8-Bit AVR (ATmega). Als Alternative, sollte Freescales FRDM... von gestern sein, dachte ich an evtl. AVR 32-Bit (32 Bit wegen SRAM usw.) oder eine andere Alternative, vllt. Renesas oder andere. Ich darf es mir aussuchen! Nur möchte ich, dass es mich fachlich weiter bringt. Mit TI-Controllern (CC...) habe ich auch ein paar schlechte Erfahrungen gemacht und die lagen darin begründet, dass die Doku streckenweise für den Arsch ist. Ich habe in Sachen TI meine Vorbehalte. Was vllt. noch wichtig ist, die IDE sollte unter Linux laufen und debuggen sollte auch möglich ohne sauteures Spezial-Zeug sein. Hat jemand eine Empfehlung? FRDM-KL... (oder Nachfolger?), Atmel, NXP, ST, ...?? * für die Korinthenkacker unter uns, 5 kB sind 5×1024 Byte = 5120 Byte, es kommen zu den 5000 Byte an Messwerten noch Zeitstempel u. a. dazu.
K. H. schrieb: > Freescale [...] > für die Korinthenkacker unter uns Jetzt eben NXP. Starte doch dein Projekt mit dem Kram als Grundlage und ziehe eine Hardware-Abstraction dort ein, wo ein modernerer μC von NXP andere Hardware hat. Damit wäre es leichter, den Kram zu portieren. K. H. schrieb: > Mit STM32Fxxx habe ich schon ein paar Projekte bearbeitet Oder mach' gleich mit denen was, da gibt es auch nette Evalboards. mfg mf
Dafür gibts von NXP die MCUXpresso Umgebung, und die wird noch aktualisiert. Auch Mbed-OS unterstützt die FRDM, da wäre dann Code für Filesysteme und SD Card drin, nur den DMA für den ADC muss man sich selber bauen.
Die NXP-Webseite ist eine Katastrophe. Wohl dem, der dort nichts suchen und finden muss. Und das Zubehoer der Entwicklungsumgebungen, hat sich zu wahren Monstern entwickelt. Also z.B. Generatoren fuers Pin-Mapping usw. usf. Bei NXP gibt es dann nur alles oder nichts. Alles schlaegt mit 174 MB zu Buche wo das Javaapplet zur Pinkonfiguration das man braucht, gerade mal 300 kB hat. Ob es in dem grossen Archiv ist, weiss ich nicht mal. Ich hab das Applet dann "ausserhalb" von NXP aufgespuert. Und alles was ein wenig aelter und "angestaubter" ist, findet man ueberhaupt nicht mehr. Ein Referenzmanual fuer die LPC81x ist z.B. bei NXP quasi nicht existent. Statt dessen wird einem eine "preliminary" Version untergejubelt. @ TO: Schmeiss das alte Zeug einfach weg.
K. H. schrieb: > Seit ein paar Wochen frage ich mich, ob die "Freedom-Boards" aka > Freescale FRDM-KL25Z/-KL26Z inkl. der IDE (Windows) ein wenig veraltet > sind Du kannst dir seltsame Fragen stellen. Frag dich lieber, ob du die Schaltung des Boards hast, ob der µC da drauf dir ausreicht, ob dir die an Pinheads oder Lötaugen geführten Portpins ausreichen und ob dir die auf dem Board sonst noch verbauten BE nicht stören. Und dann frag dich, ob und wie gut du mit der Dokumentation zum µC zurecht kommst. Das sind die eigentlichen Fragen zum Thema, mal abgesehen davon, daß es durchaus eine Herausforderung ist, mit einem µC 100*2500 Messungen in 16 Bit pro Sekunde zu tun und die Ergebnisse wegzuspeichern. W.S.
K. H. schrieb: > Seit ein paar Wochen frage ich mich, ob die "Freedom-Boards" aka > Freescale FRDM-KL25Z/-KL26Z inkl. der IDE (Windows) ein wenig veraltet > sind und ob es dementsprechend wenig sinnvoll ist, damit ein Testprojekt > zu starten. Die IDE (Eclipse based) ist, wenn ich es richtig im Kopf > habe, das letzte mal 2014 geupdated worden, also vor 7 Jahren. Daher > auch mein Eindruck, dass FRDM-KL... auch mit M0+ Core eher Alteisen ist. Die IDE ist doch egal. Solange Du einen passenden Compiler und passende Binutils und passende Header hast, funktioniert das doch, egal, ob vi, emacs, vscode oder was auch immer. DU da es ARM ist, kannst Du auch einen beliebigen ARM Debugger nehmen. > Wenn das so ist, was wäre eine empfehlenswerte Alternative für dieses > Testprojekt, das folgendes macht: > Es sollen 2500 Spannungen (Widerstandsmatrix) über einen ext. 16-bit ADC > inkl. Ansteuerung erfasst werden und zwar 10x bis 100x pro Sekunde. Wenn nur das Ergebnis zählt, bist Du auf einem RPi oder Beaglebone oder so wohl am schnellsten fertig. Ein Pi4 hat 6 SPI-Ports, da sollte sich was machen lassen. RAM hast Du genug, Massenspeicher ist auch nicht das Problem. > Mit STM32Fxxx habe ich schon ein paar Projekte bearbeitet, selbiges auch > mit 8-Bit AVR (ATmega). Als Alternative, sollte Freescales FRDM... von > gestern sein, dachte ich an evtl. AVR 32-Bit (32 Bit wegen SRAM usw.) AVR32 ist EOL. Wenn, dann PIC32. > oder eine andere Alternative, vllt. Renesas oder andere. Ich darf es mir > aussuchen! Nur möchte ich, dass es mich fachlich weiter bringt. Mit > TI-Controllern (CC...) habe ich auch ein paar schlechte Erfahrungen > gemacht und die lagen darin begründet, dass die Doku streckenweise für > den Arsch ist. Ich habe in Sachen TI meine Vorbehalte. Was vllt. noch > wichtig ist, die IDE sollte unter Linux laufen und debuggen sollte auch > möglich ohne sauteures Spezial-Zeug sein. TI TIVA funktioniert für mich, damit habe ich einiges gemacht. Die CC-Chips sind von Chipcon, die sich von TI haben kaufen lassen, also keine TI Eigenentwicklung. TIVA kommt von Liminary Micro. MSP430 von TI Freising. Ist also alles nicht so einfach. Im Prinzip ist das egal. Vielleicht solltest Du dich bei ARM mal von den Herstellertools verabschieden, wenn Dir die nicht gefallen. fchk
W.S. schrieb: > Frag dich lieber, ob du die Schaltung des Boards hast, ob der µC da > drauf dir ausreicht, Wenn man mit einem DevKit oder Eval-Board rum macht, dann gibt es dazu auch einen Schaltplan. Wenn nicht, ist das wertlos. Bisher war das noch kein Problem. W.S. schrieb: > ob dir die an Pinheads oder Lötaugen geführten > Portpins ausreichen und ob dir die auf dem Board sonst noch verbauten BE > nicht stören. Was sind BE? Aber die Pins (Anzahl) reicht schon, dazu braucht man sooo viele Pins jetzt nicht. Die Widerstandsmatrix ist eine 52x44 Matrix = 52 Zeilen/Spalten und 44 Spalten/Reihen = 2288 Messwerte + diverse Leermessungen. Angesteuert werden die 52 Zeilen mit sieben 8-Bit Shift-Registern, die hintereinander geschaltet sind. Dazu braucht man nur einen Clock- und einen Reset-Pin. Für die 44 Spalten nehme ich drei 16-Bit analog Switches (CD74HC4067). Die Teile zusammen brauchen 4 Pins für die Selektion des Schalters (2⁴ = 16, alle IC's parallel) und jeweils einen /Enable Pin, der aber eig. überflüssig ist. Die gleichzeitig drei aktiven Schalter der drei analog Switches gehen zu einem 4-Kanal ADC (synchron, SPI) und der ADC meldet sich, wenn die Meßwerte konvertiert sind. Über den Interrupt wird dann ein DMA-Transfer ausgeführt und die Messwerte landen im (Ring-)Speicher. Dann werden die analog Switches einen weitergeschaltet und es kommen wieder drei Messwerte rein. Wenn der Ringspeicher voll ist, wird gecheckt ob der letzte Messwert dem Referenzwert entspricht, dann wird der Zeitstempel und Datenblock-Nummer zugefügt und alles an einen Host-PC über UART geschickt oder evtl. auf SD-Karte gespeichert oder beides. W.S. schrieb: > Und dann frag dich, ob und wie gut du mit der > Dokumentation zum µC zurecht kommst. Genau das war das Problem bei den TI-µP's CC2xxx. Verschiedene Dokumente, verschiedene Erklärungen für eine Frage, keine der Angaben in den Dokus war richtig bzw. vollständig. Die vollständige Erklärung zu der Frage, die andere Leute übrigens auch hatten, gab es dann damals ca. ein halbes Jahr vor meiner Fragestellung im E2E-Forum (TI) von einem TI-Engineer. Darauf kam die Frage von den Usern, warum diese goldige Erklärung nicht im der Doku steht. Auf sowas habe ich schlichtweg kein Bock, das ist zermürbend und frisst elendig viel Zeit, weil man dann erst weiß, dass die Doku so ziemlich für den Arsch ist. No Y. schrieb: > PIC32MZ / PIC32MX Klingt interessant, zumal das wohl die Nachfolger von AVR32 sind, oder? Frank K. schrieb: > Die IDE ist doch egal. Solange Du einen passenden Compiler und passende > Binutils und passende Header hast, funktioniert das doch, Im Prinzip ist die IDE egal. Die Sache ist nur, die muss auf meinem Läppie laufen und da läuft kein Win-Dos drauf. Deswegen kann ich mit der alten Freescale/NXP-IDE von 2014 nix anfangen, weil es das Zeug nur für Win-Dos gibt. Frank K. schrieb: > Wenn nur das Ergebnis zählt, bist Du auf einem RPi oder Beaglebone oder > so wohl am schnellsten fertig. Das haben wir uns auch schon gefragt, ob das möglich wäre. Aber der Hintergrund ist das Real-Time Zeug. Es müsste, egal was passiert, alle 10 bis 100 ms eine komplette Messung stattfinden, das heißt, alle Widerstandswerte werden im zeitlich nahezu gleichen Abstand erfasst. Ich denke nicht, dass ein RPi ohne beinharte Echtzeiterweiterung (if available) das hinbekommt. Die Pinne, Ports usw. sind nicht das Problem, deswegen habe ich oben mal grob den Aufbau erklärt (sieben Shift-Register hintereinander, drei 16-Bit analog Switches parallel, 4-Kanal synchr. 16-Bit ADC). Ich denke, so ein *Pi kommt zeitlich ins Schleudern, wenn neben der Messung noch andere Dinge auf einmal dazwischen kommen. Frank K. schrieb: > TI TIVA funktioniert für mich, damit habe ich einiges gemacht. Die > CC-Chips sind von Chipcon, die sich von TI haben kaufen lassen, also > keine TI Eigenentwicklung. TIVA kommt von Liminary Micro. MSP430 von TI > Freising. Ist also alles nicht so einfach. Interessant, das könnte evtl. auch die grottige Doku zu den CC.... µP's erklären, mit denen ich zu tun hatte, wo zu einer speziellen Frage die Antwort nicht im Datenblatt steht und auch nicht in (diversen) Application Notes oder sonstwo, sondern in einem Beitrag im E2E-Forum von einem TI Mitarbeiter kam. Sowas ist frustrierend. Wie ist es denn bzgl. Doku zur TIVA-Serie? Und ist MSP430 noch aktuell? Johannes S. schrieb: > Dafür gibts von NXP die MCUXpresso Umgebung, und die wird noch > aktualisiert. Habe ich gesehen und es gibt sie für Linux und mal eben checken.... YES! im AUR-Repository (Arch User Repo.) ist das Zeug auch drin. https://aur.archlinux.org/packages/?O=0&K=mcuxpresso So muss das! Johannes S. schrieb: > Auch Mbed-OS unterstützt die FRDM, da wäre dann Code für Filesysteme und > SD Card drin, nur den DMA für den ADC muss man sich selber bauen. Mbed ist doch das Zeug, das nur online geht, oder? Also im Brauser Code schreiben usw. Und debuggen soll nicht gehen. Ich habe da Bedenken. Ein Ex-Kollege hat auch mit Mbed was gemacht, war aber nicht so begeistert davon. Was SD-Karte und Filesystem angeht, da habe ich das Zeug Ende letzten Jahren/Anfang dieses Jahres den open-source FAT-Treiber von Elm-Chan auf einem STM32F030 am SPI-Port zum laufen gebracht. :]
K. H. schrieb: > Mbed ist doch das Zeug, das nur online geht, oder? Oder. 'nur online' ist ein wohl ein nicht totzukriegendes Gerücht, es gibt sehr wohl ein Buildsystem (bzw mittlerweile zwei, das neuere mit CMake) das offline arbeitet und das gesamte OS ist schon lange bei github gehostet. Damit hat man schon mal einen Teil portabel, solange man bei Cortex-M bleibt. Aber auch im SDK für MCUXpresso ist FatFS, USB und weiteres drin: https://mcuxpresso.nxp.com/en/builder?hw=FRDM-KL26Z
No Y. schrieb: > Nein PIC32 hat nichts mit AVR32 zu tun. > > PIC32 sind schnelle MIPS. > AVR32 war glaub auch ARM..? nein, eine eigene Architektur. Die SAMs waren/sind die ARMs. fchk
Johannes S. schrieb: > Aber auch im SDK für MCUXpresso ist FatFS, USB und weiteres drin: > https://mcuxpresso.nxp.com/en/builder?hw=FRDM-KL26Z Ähhmmmmm, ja.... > Sign In > Email Address or NXP Company ID Die machen da lieber ein Geheimnis raus. Oder "mal eben" registrieren. Das kann ich später noch machen, wenn es vllt. mal soweit sein wird. Oder ich guhgel mal nach Code und kuck mir das mal an.
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.