Und mal wieder Hallo! Da ich immer noch kein Gespür dafür habe, wie schnell Bits und Bytes sind, hätte ich eine Frage diesbezüglich an euch. STM32F429 mit folgender aktiver Peripherie: - SDRam über FMC - 800*480*16bit LCD über LTDC, Daten kommen aus dem SDRam, DMA2D - Touchpanel für das LCD über I2C, mit Interrupt - Ethernet über STM-eigenen MAC, mit Interrupt - Externer AD-Wandler über FMC, soll höchste Prio haben, über DMA/Timer getriggert - Rest wird vermutlich keine Rolle spielen, da entweder in der Mainloop oder kaum Rechenzeitintensiv, allerdings auch mit DMA-Beteiligung Vom AD-Wandler sollen durchgehend, mit ein paar Dutzend kHz, 2 * 16Bit Werte ins SDRam geschrieben werden (DMA und DoubleBuffer, maximal 1MB / Buffer). Stellt der PC über Ethernet eine Anfrage für die Daten, wird ein Buffer an den PC verschickt. Dies geschieht auch nicht öfter als 1/s. Das ganze soll dann einen Datenstream bilden. Nun ist es ja so, dass das LCD und das Ethernet auch am SDRam hängen. Und alle werden auch über DMA bzw. DMA2D (auch DoubleBuffering in Bezug auf das LCD) mit Daten versorgt. Soweit ich das verstanden habe, agiert DMA2D ziemlich selbstständig, man kann nur eine gewisse "DeadTime" für den DMA2D-Transfer festlegen die dann für andere Peripherie freisteht. Diese habe ich gerade so eingestellt, dass das LCD noch synchron seine Daten bekommt. Nun geht es mir darum, dass kein AD-Wert verloren gehen darf. Bisher habe ich das so gelöst gehabt, dass die Wandlung ein anderer STM32F407 übernommen hatte und die Daten dann per SPI an den F429 verschickt hat. Aufgrund meiner "Programmierkünste" (programmiere seit etwa einem Jahr) erschien mir das damals als eine gute Lösung, da ein Controller nur für die Datenerfassung verantwortlich war und diese auch vollführt hat, egal ob ich gerade am Touchscreen rumtippe oder eine Ethernet-Message von Windoof reinkommt. Aber je mehr ich in diese kleine Welt einsteige, desto weniger glaube ich, dass ich dadurch etwas gewonnen habe. Denn ob die Daten nun per SPI vom anderen Controller kommen oder direkt über den ADC ist doch eigentlich wurscht oder? Danke schonmal! Grüße Reggie
Reginald L. schrieb: > Denn ob die Daten nun per SPI > vom anderen Controller kommen oder direkt über den ADC ist doch > eigentlich wurscht oder? Ist nicht wurscht. Der interne ADC ist PARALLEL (=schneller) am internen Bus angebunden, nicht seriell.
@ Reginald Leonczuk (Firma: HS Ulm) (reggie) >- Externer AD-Wandler über FMC, soll höchste Prio haben, über DMA/Timer >getriggert >Nun geht es mir darum, dass kein AD-Wert verloren gehen darf. Nun, dann braucht man einen FIFO. Der AD-Wandler wird mit konstanter Frequenz angestoßen und ausgelesen, auf der anderen Seite kann man burstartig die Daten lesen, auch mit DMA. > Bisher >habe ich das so gelöst gehabt, dass die Wandlung ein anderer STM32F407 >übernommen hatte und die Daten dann per SPI an den F429 verschickt hat. Das ist eine Form des FIFOs. >Aber je mehr ich in diese kleine Welt einsteige, desto weniger glaube >ich, dass ich dadurch etwas gewonnen habe. Doch. >Denn ob die Daten nun per SPI >vom anderen Controller kommen oder direkt über den ADC ist doch >eigentlich wurscht oder? Nö. Das ist ein entscheidender Unterschied. DMA mit mehreren Kanälen funktioniert nur dann, wenn die einzelenen Module wie LCD oder UART einen ausrechend großen Zwischenpuffer (FIFO) haben. Nur dann kann dort ein kontinuierlicher Datenstrom erzeugt bzw. empfangen werden.
Falk B. schrieb: >> Bisher >>habe ich das so gelöst gehabt, dass die Wandlung ein anderer STM32F407 >>übernommen hatte und die Daten dann per SPI an den F429 verschickt hat. > > Das ist eine Form des FIFOs. Tatsächlich, es fällt mir wie Schuppen von den Augen im Moment. Falk B. schrieb: >>Denn ob die Daten nun per SPI >>vom anderen Controller kommen oder direkt über den ADC ist doch >>eigentlich wurscht oder? > > Nö. Das ist ein entscheidender Unterschied. DMA mit mehreren Kanälen > funktioniert nur dann, wenn die einzelenen Module wie LCD oder UART > einen ausrechend großen Zwischenpuffer (FIFO) haben. Nur dann kann dort > ein kontinuierlicher Datenstrom erzeugt bzw. empfangen werden. Hm, hättest du einen Ratschlag für mich, ob ich bei dieser 2-Controller Lösung bleiben sollte oder gibt es vllt andere Möglichkeiten das auf einem Controller zu realisieren? In einem anderen Thread wurde mir geraten aufzupassen, wenn ich ein statisches Device zusätzlich zum SDRam anbinde, was mir natürlich auch logisch erscheint. Ich habe auch schon mit dem Gedanken gespielt in FPGA einzusteigen, dadurch verliere ich aber sehr viel Zeit die ich erst nach Beendigung meines Studiums aber auch gerne investieren würde. Was ich benötige sind im Prinzip schon die oben genannten Peripherien.
@ Reginald Leonczuk (Firma: HS Ulm) (reggie) >Hm, hättest du einen Ratschlag für mich, ob ich bei dieser 2-Controller >Lösung bleiben sollte Wenn sie für dich funktioniert, sicher. >oder gibt es vllt andere Möglichkeiten das auf >einem Controller zu realisieren? Man braucht Zusatzlogik, h´hier in Form eines FPGAs oder wenigstens CPLD + SRAM. > In einem anderen Thread wurde mir >geraten aufzupassen, wenn ich ein statisches Device zusätzlich zum SDRam >anbinde, was mir natürlich auch logisch erscheint. Dann musst du das Device aber im exakten zeitraster deiner Abtastrate auslesen. Egal ob per CPU oder DMA, bei höheren Abtastraten wird das schwierig. >Was ich benötige sind im Prinzip schon die oben genannten Peripherien. Die STM32 sind große Controller, vielleicht gibt es eine Kameramodul etc, das man für die Anwendung zweckentfremden kann.
Eieiei, bin am Tiefpunkt meines Projekts. Immerhin kann ich nicht mehr tiefer sinken :>
Reginald L. schrieb: > - Externer AD-Wandler über FMC, soll höchste Prio haben, über DMA/Timer > getriggert Das ist so ziemlich die (nennen wir's mal) ungünstigste Lösung. Bedenke, daß für einen ordentlichen Durchsatz der externe Bus paketweise benutzt wird. Vom und zum SDRAM geht es regelmäßig blockweise und deine Idee, einen externen ADC über den Bus anzuschließen würde ich nicht mal ansatzweise in Betracht ziehen. Spendiere dir lieber ein 208er Gehäuse, da sind genug Portpins dran, die du völlig ungestört benutzen kannst. Apropos: von was für einer Wandlergeschwindigkeit reden wir hier eigentlich? Wenn die nicht wenigstens um Faktor 100 kleiner ist als dein Systemtakt, dann solltest du auf ein FPGA umorientieren. Die ADC-Daten sollen ja auch noch verarbeitet werden und dafür braucht es Zeit. Ich bin mir mittlerweile sogar sehr sicher, daß ein DMA an dieser Stelle gar nichts Gutes bewirkt. Klar, per DMA kann man die Daten von X nach Y schaufeln und das kostet nur die Zeit für die Bus-Arbitration (scheußliches Wort..) und den eigentlichen Transfer, aber was nun, wenn die Daten nicht maht bei X sondern bei Y dastehen? Zum Verarbeiten kannst du nen DMA nicht nehmen, das muß dir CPU tun. W.S.
W.S. schrieb: > Spendiere dir lieber ein 208er Gehäuse, > da sind genug Portpins dran, die du völlig ungestört benutzen kannst. Über Bitbanging habe ich auch schon nachgedacht. Andererseits ist mir der Gedanke gekommen, dass für die paar Dutzend kHz ja eigentlich auch die SPI-Schnittschnelle ausreichend wäre. Allerdings beschäftige ich damit den MCU wieder länger... W.S. schrieb: > Apropos: von was für einer Wandlergeschwindigkeit reden wir hier > eigentlich? Wenn die nicht wenigstens um Faktor 100 kleiner ist als dein > Systemtakt, dann solltest du auf ein FPGA umorientieren. Die ADC-Daten > sollen ja auch noch verarbeitet werden und dafür braucht es Zeit. Im Moment handelt es sich um 10kHz, wahrscheinlich werden es nicht viel mehr, nachdem was ich bisher hergegeben haben. Allerdings würde ich mir noch gerne etwas Luft nach oben lassen, also werfe ich mal maximal 100kHz in den Raum. Die Daten werden auch im Roh-Zustand an den PC übergeben, also sämtliche Verarbeitung findet nicht im MCU statt. Die Daten werden auch nur einmal in den SDRam geschmissen und von dort direkt, ohne nochmaliges umpuffern, per Ethernet-DMA weitergeleitet. Da ich bisher noch nicht mit FPGAs gearbeitet habe (ein Begriff sind sie mir, grundlegender Aufbau und Programmierung sind mir auch bekannt), könntest du ein, zwei Sätze dazu schreiben wie das im Prinzip vonstatten gehen soll? Übernimmt der FPGA im Prinzip dann die Rolle meines jetzigen zweiten Controllers (F407) und schaufelt die Daten zb. per SPI an den F429er? W.S. schrieb: > Zum Verarbeiten > kannst du nen DMA nicht nehmen, das muß dir CPU tun. siehe oben?
@Reginald Leonczuk (Firma: HS Ulm) (reggie) >Im Moment handelt es sich um 10kHz, wahrscheinlich werden es nicht viel Das kann man noch relativ entspannt per Timer-Interrupt und Software machen. >mehr, nachdem was ich bisher hergegeben haben. Allerdings würde ich mir >noch gerne etwas Luft nach oben lassen, also werfe ich mal maximal >100kHz in den Raum. Das wird schon SEHR sportlich und belastet auch einen fetten 32 Bitter ganz ordentlich. >könntest du ein, zwei Sätze dazu schreiben wie das im Prinzip vonstatten >gehen soll? Übernimmt der FPGA im Prinzip dann die Rolle meines jetzigen >zweiten Controllers (F407) und schaufelt die Daten zb. per SPI an den >F429er? Ja. Das FPGA kann den AD-Wandler mit einem (software)jitterfreien Abtasttakt versorgen und die Meßwerte in einen kleinen FIFO schreiben. Von dort können sie dann burstartig und auch jitterbehaftet vom Contoller abgeholt werden. Z.B. könnte der Controller mit 1-10 kHz eine DMA-Übertragung per SPI triggern. Das entlastet die CPU deutlich. Das FPGA kann sehr klein sein, denn viel mehr als ein bisschen Statemachine und einen kleinen BRAM für die Meßwerte braucht man ja nicht.
Falk B. schrieb: >>Im Moment handelt es sich um 10kHz, wahrscheinlich werden es nicht viel > > Das kann man noch relativ entspannt per Timer-Interrupt und Software > machen. > >>mehr, nachdem was ich bisher hergegeben haben. Allerdings würde ich mir >>noch gerne etwas Luft nach oben lassen, also werfe ich mal maximal >>100kHz in den Raum. > > Das wird schon SEHR sportlich und belastet auch einen fetten 32 Bitter > ganz ordentlich. Und natürlich wie oben erwähnt synchrone(!) Abtastung von 2 Kanälen, also absolutes Maximum wären 200kHz. Echt, geht das schon so in die Vollen? Wundert mich etwas, da der ADC ja auch mehrere MHz Abtastrate erreichen kann?! Per DMA müsste das doch "gschwind" erledigt sein? Ich habe die ADC-Convertion-Rate auf 480 Clocks (10kHz Samplerate) stehen, das bedeutet, dass DMA noch weniger Zeit für die Datenübertragung hat, aber bisher hat sich noch kein Fehler eingeschlichen. Naja, zumindest keiner der mir aufgefallen wäre. Am PC kommen durchgehend genau die Anzahl Samples an, die auch ankommen sollen. Falk B. schrieb: > Ja. Das FPGA kann den AD-Wandler mit einem (software)jitterfreien > Abtasttakt versorgen und die Meßwerte in einen kleinen FIFO > schreiben. Von dort können sie dann burstartig und auch jitterbehaftet > vom Contoller abgeholt werden. Z.B. könnte der Controller mit 1-10 kHz > eine DMA-Übertragung per SPI triggern. Das entlastet die CPU deutlich. > Das FPGA kann sehr klein sein, denn viel mehr als ein bisschen > Statemachine und einen kleinen BRAM für die Meßwerte braucht man ja > nicht. Was mir noch nicht so recht in den Kopf will, ist die Sache mit dem FIFO. Ist der Zweck des Ganzen, dass der MCU mal hinterherhinken könnte mit dem Triggern des ADCs und somit bspws. ein oder mehrere Samples im Puffer liegen die nicht zu der geforderten Zeit aufgenommen bzw. übertragen wurden? Oder steckt da noch mehr dahinter?
@ Reginald Leonczuk (Firma: HS Ulm) (reggie) >> Das wird schon SEHR sportlich und belastet auch einen fetten 32 Bitter >> ganz ordentlich. >Und natürlich wie oben erwähnt synchrone(!) Abtastung von 2 Kanälen, >also absolutes Maximum wären 200kHz. >Echt, geht das schon so in die Vollen? Ja. > Wundert mich etwas, da der ADC ja >auch mehrere MHz Abtastrate erreichen kann?! Per DMA müsste das doch >"gschwind" erledigt sein? Wenn du es schaffst, die DMA passend an deinen ADC anzusteuern. Der AD-Wandler hat keinen FIFO, bestenfalls ein Ergebnisregister. >kommen durchgehend genau die Anzahl Samples an, die auch ankommen >sollen. Kann sein, aber wie sieht es mit dem Abtasttakt aus? Wie wird der generiert? Jitterarm? >Was mir noch nicht so recht in den Kopf will, ist die Sache mit dem >FIFO. Ist der Zweck des Ganzen, dass der MCU mal hinterherhinken könnte >mit dem Triggern des ADCs Nein, mit dem Auslesen! >und somit bspws. ein oder mehrere Samples im >Puffer liegen die nicht zu der geforderten Zeit aufgenommen bzw. >übertragen wurden? Ja. > Oder steckt da noch mehr dahinter? Reicht das nicht? Gerade wenn größere CPUs mit diversen Funktione beschäftigt sind, kann man kein ultrastrenges Timing für Interupts mehr ganrantieren, u.a. weil viele verschiedene Interrupts aktiv sind. OK, man kann priorisieren etc, aber auch das hat Grenzen. Wenn dann die Datenquellen nicht ausreichend entkoppelt, sprich, mit FIFOs gepuffert sind, gibt es Probleme. Wenn du es schaffst, mittels Timer, einen jitterfreien Abtast/Start Conversion Takt zu generieren und schnell genug mittels DMA die Daten aus dem AD-Wandler auslesen kannst, dann brauchst du keine Extralogik und keinen FPGA/FIFO. Wenn nicht, dann schon. Den Takt zu generieren ist leicht. Die Daten abholen ggf. nicht so ganz.
Es geht ja anscheinend um diesen IC ;-) Beitrag "STM32F4 FSMC / FMC mit SDRam und beispielsweise Flash" AD7606, ein 8-Kanal ADC mit simultaner Abtastung. Wenn der mit 200 kHz läuft, muss man in etwas weniger als 5us die Daten auslesen. OK, das kriegt man mit DMA hin. Effektiv sind es ja nur 8 Buszugriffe auf die gleiche Adresse. Mittels Hardware-Timer generiert man das CONVST A/B Signal, kurze Zeit später muss die DMA getriggert werden, um die Daten auszulesen.
Bei all den Nachteilen eines externen ADC (bzw. zweiten µC) sollte man aber auch bedenken, dass die Genauigkeit des µC-internen ADC von der Aktivität des µC abhängt. Atmel empfiehlt zum Beispiel, den ganzen µC während der Messung stillzulegen. Das wird nicht möglich sein, wenn der selbe µC auch das Display und alles Mögliche andere ansteuert, richtig? Wenn Dir 8 Bit Auflösung genügen, spielt diese Aspekt jedoch vermutlich keine Rolle.
@ Stefan Us (stefanus) >Bei all den Nachteilen eines externen ADC (bzw. zweiten µC) Welche Nachteile? Man muss halt ein wenig überlegen, was man tut. Dann läuft das schon. Ausserdem ist der ADC des OP ein Exot, der 8 Kanäle GLEICHZEITIG abtastet. Sowas hat kaum ein anderer ADC, von internen ADCs ganz zu schweigen. > sollte man >aber auch bedenken, dass die Genauigkeit des µC-internen ADC von der >Aktivität des µC abhängt. Jain. >Atmel empfiehlt zum Beispiel, den ganzen µC während der Messung >stillzulegen. Ich glaube das war nur eine Vorsichtsmaßnahme beim Design, als sie noch nicht so genau wußten, wie gut sich der ADC mit dem Digitalteil verträgt. Bei meinen ADC-Messungen konnte ich keine besondere Störung der Messung durch den aktiven Controller feststellen. Der ADC liefert erstaunlich stabile Werte, wenn die Außenbeschaltung stimmt.
Falk B. schrieb: > Wenn der mit 200 kHz > läuft, muss man in etwas weniger als 5us die Daten auslesen. Also eigentlich läuft der ja mit maximal 100kHz! Nur, dass ich eben zwei Kanäle auslese. Ich kann mir eigentlich gar nicht vorstellen, dass der F4 damit zu kämpfen hat. Vor allem über FSMC, da sind die Daten ja im Nu im SRam. Stefan U. schrieb: > Atmel empfiehlt zum Beispiel, den ganzen µC während der Messung > stillzulegen. Das wird nicht möglich sein, wenn der selbe µC auch das > Display und alles Mögliche andere ansteuert, richtig? Das finde ich aber auch schon ein bisschen heftig. Naja, seis drum, ich steige ja eh auf den externen ADC um, der stellt mir hier vor allem +-10V Eingänge bereit, die mir in meiner Umgebung sehr zugute kommen.
Reginald L. schrieb: > könntest du ein, zwei Sätze dazu schreiben wie das im Prinzip vonstatten > gehen soll? Parallel geht das, es ist ein FPGA innerlich ein riesiges Feld von logischen Verknüpfungen und Flipflops, aus denen man höhere Funktionen (gelegentlich Cores genannt) zusammenstellen kann. Diese arbeiten logischermaßen parallel zueinander, so daß z.B. ein Teil den ADC bedient, ein anderer die Daten vom ADC in chipinternem RAM zwischenspeichert, ein nächster dann ggf. Filterfunktionen auf die Daten anwendet, bis hin zu einem Teil, der eine komplette Ethernet- oder USB-Implementation darstellt. Wenn du z.B. mal in die Liste der bei Xilinx vorhandenen IP's reinschaust, dann merkst du, was da eigentlich abgeht. Aber deine 10 kHz Abtastrate oder eventuell bis zu 192 kHz Abtastrate ist davon noch meilenweit entfernt. Sowas macht man per I2S und wenn du nen µC mit 100 MHz Systemtakt nimmst und dich bei dem Interrupthandler nicht allzu ungelenkig anstellst, dann packt der das durchaus noch. Du hast dann ja von Sample zu Sample rund 250 Systemtakte (1x rechts, 1x links). Aber als Zwischenspeicher würde ich internen RAM und keinen externen SDRAM benutzen. Mittlerweile gibt es Chips, die mehr als 128 K internen RAM haben. sollte dafür ausreichen. Mach halt die Ethernet-Pakete passend zum vorhandenen RAM. Es hat vor Zeiten ein Bauprojekt für einen SDR-Transceiver gegeben, der auf einem FPGA von Altera basiert: 100 MHz ADC und DAC auf der einen Seite des FPGA, Ethernet PHY auf der anderen Seite. Ein Layout dazu schwirrt sogar in den Tiefen dieses Forums herum und die "Software" also die HDL-Files gibt's auch irgendwo, hab's bloß nicht en detail gemerkt. Im Prinzip enthält der FPGA ne digitale geregelte Eingangsstufe, dann einen digitalen Mischer und nen digitalen LO, dann ne digitale ZF, Demodulatoren und eben als Ausgang nen Eternet MAC. Aber das ist vermutlich zwei Nummern dicker als du es brauchst. W.S.
@ Reginald Leonczuk (Firma: HS Ulm) (reggie) >> Wenn der mit 200 kHz >> läuft, muss man in etwas weniger als 5us die Daten auslesen. >Also eigentlich läuft der ja mit maximal 100kHz! Nur, dass ich eben zwei >Kanäle auslese. Ich kann mir eigentlich gar nicht vorstellen, dass der >F4 damit zu kämpfen hat. Vor allem über FSMC, da sind die Daten ja im Nu >im SRam. Nach einiger Überlegung und Diskussion kann man wohl sagen, daß der F4 das relativ leicht schafft. Ich war da wohl am Anfang ein wenig zu pessimistisch und hab unbewußt zu sehr an eine reine Softwarelösung gedacht.
W.S. schrieb: > Diese arbeiten > logischermaßen parallel zueinander Achso, also die Logik die ich da implementiere kann ich gleichzeitig laufen lassen? Im Prinzip so, wie, wenn ich im µC 10 Timer laufen lasse die mir verschiedene PWMs per Hardware rauslassen? Also reine "Hardware"? Wenn sich mein Zeitplan nicht dem Ende zuneigen würde, wäre ich just in diesem Moment umgestiegen. Wird auf jeden Fall in Zukunft in Angriff genommen.
Falk B. schrieb: > Das entlastet die CPU deutlich. > Das FPGA kann sehr klein sein, denn viel mehr als ein bisschen > Statemachine und einen kleinen BRAM für die Meßwerte Nur mal zur Info: In den aktuellen 8051 z.B. EFM8LB haben die internen ADC eine Logik verbaut, die unabhängig von der CPU Daten in das externe RAM schreibt und bereits eine Vorverabeitung durchführen kann z.B. Mittelwertbildung und einfache Filter. http://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee.aspx Und es gibt auch ARM uC mit M4/M0 die auch noch günstiger als STM32F429 sind, da kann sich der M0 um den ADC und der M4 um die Filter kümmern: http://www.nxp.com/products/software-and-tools/hardware-development-tools/lpcxpresso-boards/lpcxpresso-board-for-the-lpc54100-family-of-mcus:OM13077
Lothar schrieb: > z.B. Mittelwertbildung > und einfache Filter. Die Berechnungen die ich am Signal durchführe werden eh alle am PC gemacht. Es bringt einfach keine Vorteile das in der MCU zu machen. Lothar schrieb: > Und es gibt auch ARM uC mit M4/M0 die auch noch günstiger als STM32F429 > sind, da kann sich der M0 um den ADC und der M4 um die Filter kümmern: Das hört sich auch gut an mit den zwei Cores. Gibts die auch in "fetter"? Is ja n 64-Pinner. Auf den Preis kommts mir nicht an, is ja keine Serie.
Reginald L. schrieb: > Die Berechnungen die ich am Signal durchführe werden eh alle am PC > gemacht. Es bringt einfach keine Vorteile das in der MCU zu machen Eine wichtige Anwendung solcher uC ist ja die Automatisierung wo die GUI zwar am PC ist, der uC aber weiter laufen soll, wenn der PC mal abstürzt. Reginald L. schrieb: > Gibts die auch in "fetter"? Is ja n 64-Pinner Das wären dann die LPC43xx mit 100 oder 256 Pins. Die sind immer noch günstiger als der STM32F429 sind aber meist nur als BGA lieferbar. Es gibt aber sehr günstige Eval-Boards. Das günstigste ist der Debugger für 15 EUR dort wird nämlich ein LPC4370 verwendet. Da hat der ADC aber schon 80 MSPS also etwas überdimensioniert. Es wird ernsthaft empfohlen, zwei solche Debugger zu kaufen und mit dem einen den anderen als Eval-Board zu programmieren. Es gibt dafür auch Demo-Software zur Oszilloskop-Emulation und Bildverarbeitung: http://thomasweldon.com/tpw/lpc4370/lpc4370tutorial1/index.html http://de.farnell.com/nxp/om13054-598/lpc-link2-universell/dp/2364729
Lothar schrieb: > Eine wichtige Anwendung solcher uC ist ja die Automatisierung wo die GUI > zwar am PC ist, der uC aber weiter laufen soll, wenn der PC mal > abstürzt. Der µC leitet in meiner Anwendung dann auch Sicherheitsmaßnahmen ein, in Bezug auf die Motorsteuerung, falls der PC nicht mehr will. Alles andere ist hier nicht notwendig. Lothar schrieb: > Das wären dann die LPC43xx mit 100 oder 256 Pins. Die sind immer noch > günstiger als der STM32F429 sind aber meist nur als BGA lieferbar. Es > gibt aber sehr günstige Eval-Boards. Wow, das is ja der Hammer! Obwohl ich zwecks möglicher Eigenlöterei von BGA eigentlich erst mal nichts wissen möchte. Wo kriegst du solche "Neuigkeiten" eigentlich her? Surfst du ab und an auf den Herstellerwebsites umher oder gibts da eine spezielle Site? Die Site auf diesem Forum ist diesbezüglich ja leider schon etwas überholt. Was es nicht alles gibt... :>
Reginald L. schrieb: > Wo kriegst du solche "Neuigkeiten" eigentlich her? Wir setzen die LPC ein. Die LPC hatten zu Anfang einen 8051 Kern und dann ARM Kerne. Die Peripherie ist deutlich einfacher zu programmieren als bei den Atmel und ST ARM zugleich gibt es bei den LPC Peripherie die es sonst nicht gibt wie z.B. die State Machines. Und die LPC sind die einzigen ARM die es auch als DIP gibt. Aktuell muss man aber sagen, dadurch dass NXP Freescale gekauft hat, ist noch nicht raus ob jetzt die LPC oder die Kinetis das Rennen machen.
Lothar schrieb: > Aktuell muss man aber sagen, dadurch dass NXP Freescale gekauft hat, ist > noch nicht raus ob jetzt die LPC oder die Kinetis das Rennen machen. Meine Vermutung ist, daß es wohl halbe halbe sein wird. Gerade bei den kleineren M4F gibt's bei den LPC Nachholebedarf. Deren M4F sind die fetteren LPC4000er und LPC4300er und die sind oft schlichtweg überdimensioniert. Da haben die Kinetis MK02FN und Konsorten die Nase vorn - allerdings zu dem Preis, daß es eigentlich bei allen Kinetis an der Taktversorgung hapert und daß deren Doku zum Haareraufen ist. Man überlege sich mal, daß die nen M4F nebst einigem offenbar relativ schnellen Speicher und USB und I2S auf den Chip gepackt haben und die Taktversorgung für beides ist so grottenschlecht, daß man den Systemtakt nicht als Takt für den USB nutzen kann und wenn man ihn für I2S benutzt, handelt man sich ein Jittern ein, das jeden ADC versaut. Mal ganz abgesehen davon, daß man nur ganz bestimmte Quarzfrequenzen benutzen kann, weil eben die gesamte Taktversorgung zu hakelig ist. W.S.
W.S. schrieb: > Gerade bei den kleineren M4F gibt's bei den LPC Nachholebedarf Nun es gibt ja die kleinen LPC54100 als QFP-64 die gerade auch noch weiterentwickelt wurden. Was eher fehlt ist generell QFP-32 da einfach zu löten: QFP-48 ist schon wieder ungünstig. Die LPC1500 als QFP-32 wären nötig. Da gibt es allerdings auch bei Kinetis nichts und nirgends anders auch ausser der einzige STM32F334
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.