Hallo zusammen, folgende Aufgabenstellung: Ich bekomme 24 Bit Daten in einer Datei geliefert. Ca 50.000 Werte, tendentiell eher mehr. Diese Werte möchte ich aus der Datei auslesen, in einem Array speichern und parallel an 24 Pins ausgeben. Geschwindigkeit mind 500khz, am liebsten 1 MHz. Erster Versuch ESP32: - Der ESP hat nur ca 320kb Speicher, da wirds mit einem Array in dieser Größe schwer. Des weiteren hat er nur maximal 22 nutzbare Pins...wenn ich den Speicher erweitere um das Array speichern zu können fallen weitere Pins weg. Ansonsten funktioniert es genau wie gewünscht über die parallele Ausgabe der i2s (Sound) Schnittstelle. Zweiter Versuch ESP32-S3: - Der ESP hat 8MB PSRAM, ein Speichern des Arrays ist kein Problem. Hier ist jedoch die parallele Ausgabe von i2s in einen LCD Baustein gewandert, dieser kann Hardwareseitig maximal 16 Bit parallel ausgeben. Des weiteren habe ich diese 16 bit parallel, designed für ein Display noch nicht so konfiguriert bekommen das wirklich stumpf die Bits die ich hereingebe genau so rauskommen. Bevor ich nun viel viel Zeit mit einem weiteren Versuch vergeude, hier mal die Frage: Wie kann ich elegant 24 Bit Daten aus einer Datei einlegen und diese an 24 Pins mit der gewünschten Geschwindigkeit parallel ausgeben? Die STM können meines Wissens auch nur 16 Bit. Jemand eine Idee?
Drei SN74HCS595 o.Ä per SPI (+DMA?) befüllen? Ein STM32 mit >24MHz am SPI ist ja keine Seltenheit...
:
Bearbeitet durch User
Klaus schrieb: > - Der ESP hat nur ca 320kb Speicher, da wirds mit einem Array in dieser > Größe schwer. 50000 Werte à 24 Bit sind 150 kiByte. Wo ist das Problem?
Εrnst B. schrieb: > rei SN74HCS595 o.Ä per SPI (+DMA?) befüllen? So ein Quark. Einfach einen 32 Bit Controller mit ausreichend RAM und DMA nehmen, da läuft die Datenausgabe automatisch.
Klaus schrieb: > Wie kann ich elegant 24 Bit Daten aus einer Datei einlegen und diese an > 24 Pins mit der gewünschten Geschwindigkeit parallel ausgeben? Mit einem 32 bit Prozessor, der auch 32 bit Ports hat, wie AVR32. Noch eleganter per zeitgebergetriggetem DMA. Ansonsten 3 8 bit ports in der nötigen Geschwindigkeit laden und per Clock-Impuls am 25 Ausgang zeitgleich in ein 24 bit Latch ubertragen. Da muss der Prozessor halt deutlich schneller sein.
Klaus schrieb: > Die STM können meines Wissens auch nur 16 Bit. Jemand eine Idee? Schau dir mal die Cortex-M4 von NXP an. Da sind die GPIO öfters 32Bit breit organisiert.
Klaus schrieb: > Die STM können meines Wissens auch nur 16 Bit. Jemand eine Idee? Die Ausgabepin im Multiplex betreiben. Schon der 8-Bit µP von Intel 8008 hat seine PIN so verwaltet.
Beitrag #7178468 wurde von einem Moderator gelöscht.
Ich habe einen STM32H7. Der kann 1MByte im Ram Speichern. Genug um die Daten im Ram zu halten. Der hat 'Up to 168 I/O ports with interrupt capability'. Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an? Der hat 480 MHz Taktfrequenz. Das müßte doch alles reichen.
Beitrag #7178488 wurde von einem Moderator gelöscht.
RP2040 hat 26 GPIO Pins hat mehr als genug Speicher hat DMA und PIO (könnte die Daten mit 100MHz rausjagen) lächelt müde bei der Aufgabenstellung und weiß gar nicht was er mit seinen zwei Kernen denn nun anfangen soll. Am besten schlafen. Gut, ist nicht besonders günstig, kostet immerhin als fertiges Teil 4,10€
c-hater: > Z.B. könnte ein RP2040 mit links und 40 Fieber all den Quatsch > machen, bloß im letzten Schritt würde er scheitern, weil er > schlicht nicht genug GPIOs hat. Hmmm... überseh ich da was? Der RP2040 hat 30 freie GPIOs. Der Pi-Pico klaut 4 davon für internen Kram (leider so, dass nur noch 23 in Folge frei sind).
foobar schrieb: > c-hater: >> Z.B. könnte ein RP2040 mit links und 40 Fieber all den Quatsch >> machen, bloß im letzten Schritt würde er scheitern, weil er >> schlicht nicht genug GPIOs hat. > > Hmmm... überseh ich da was? Der RP2040 hat 30 freie GPIOs. Der Pi-Pico > klaut 4 davon für internen Kram (leider so, dass nur noch 23 in Folge > frei sind). Korrekt: GPIO_00…GPIO_15 GPIO_16…GPIO_22 GPIO_26…GPIO_26 Macht 26 Stück. Aufeinander folgend ist bei der Aufgabenstellung jedoch unnötig, da man so etwas sowieso direkt von der Hardware erledigen lässt. Hat man mitgekauft, da kann man sie auch benutzen.
> GPIO_26…GPIO_26
was natürlich:
GPIO_26…GPIO_28
heißen soll.
Beitrag #7178523 wurde von einem Moderator gelöscht.
Beitrag #7178525 wurde von einem Moderator gelöscht.
Klaus schrieb: > Bevor ich nun viel viel Zeit mit einem weiteren Versuch vergeude, hier > mal die Frage: Wie kann ich elegant 24 Bit Daten aus einer Datei > einlegen und diese an 24 Pins mit der gewünschten Geschwindigkeit > parallel ausgeben? Es gibt spezielle Speicherbausteine, sogenannte FIFOs. Sowas wie das hier: https://www.renesas.com/eu/en/products/memory-logic/fifo-products/synchronous-fifos/72v36110-128k-x-36-supersync-ii-fifo-33v Dieses Exemplar hat einen Speicher von 128k Einträgen zu 36 Bit Breite, also genug für 24 Bit Datenbreite. Die Daten kann man hintereinander am Eingang reinschreiben, und man kann sie davon unabhängig am Ausgang wieder rausholen. Zeitlich sind beide Seiten völlig entkoppelt. Man kann auch am Eingang nur mit 9 Bit reinschreiben, und der Chip macht aus 4 nacheinander reingeschriebenen 9-Bit Worten wieder ein 36-Bit Wort. Man kann auch langsam reinschreiben und schnell wieder rausholen, muss natürlich dann aufpassen, dass der Speicher in der Zwischenzeit niemals leer läuft. Heuzutage wird so etwas gerne in einem FPGA realisiert, aber die FIFO-Chips gibts immer noch. fchk
Klaus schrieb: > folgende Aufgabenstellung: Ich bekomme 24 Bit Daten in einer Datei > geliefert. Ca 50.000 Werte, tendentiell eher mehr. > Diese Werte möchte ich aus der Datei auslesen, in einem Array speichern > und parallel an 24 Pins ausgeben. Geschwindigkeit mind 500khz, am > liebsten 1 MHz. Na, dann tue es doch. Hier wird dich niemand daran hindern wollen. Klaus schrieb: > Bevor ich nun viel viel Zeit mit einem weiteren Versuch vergeude, hier > mal die Frage: Wie kann ich elegant 24 Bit Daten aus einer Datei > einlegen und diese an 24 Pins mit der gewünschten Geschwindigkeit > parallel ausgeben? So etwas ist die falsche Frage. Die eigentliche Frage wäre, auf welche Weise deine geheimnisvollen Daten von irgendeinem Verbraucher zur Kenntnis genommen werden sollen. Also wie stellst du dir das angedachte Interface vor? Und wie schnell du womit und von was für einem Datenträger du eine Datei lesen kannst, können dir ale Anderen hier nicht beantworten, denn soweit reicht die hiesige Glaskugel nicht. W.S.
Hui...hier ist ja eine sympathische Atmosphäre :-D Ich habe es tatsächlich genau so formuliert wie es werden soll, und nicht anders. Ich habe eine Datei mit z.B. 50000 24Bit Werten. Diese iss in das Ding rein, wie ist eigentlich egal. Am ESP32 habe ich die Datei per Webinterface in den Spiffs geladen und von da weiter in ein Array geschoben. Beim ESP klappt tatsächlich alles super, nur der RAM ist zu klein für ein größeres Arrayind die Hardware kann keine 24Pins liefern. Daher die Sondierung mit welcher Hardware ich dasganhe vernünftig lösen kann. Möchte ungerne wieder etwas entwickeln und am ende merken das Esso gar nicht klappt. Ob die Hardware 10, 100 Euro oder mehr kostet wäre tatsächlich egal in dem Fall. Hauptsache das ganze läuft anständig. Bisher hört sich für mich die Geschichte mit dem STM32H7 gut an. Oder tatsächlich ein FIFO an den ESP hängen
Klaus schrieb: > Bisher hört sich für mich die Geschichte mit dem STM32H7 gut an. Oder > tatsächlich ein FIFO an den ESP hängen FIFO ist Unsinn, denn dann sind die Daten nach einem Durchlauf weg.
Falk B. schrieb: > Einfach einen 32 Bit Controller mit ausreichend RAM und DMA nehmen, da > läuft die Datenausgabe automatisch. Sollte aber auch einer sein, der nicht (wie viele STM32) auf nur 16-bit IO kastriert worden ist. Atmel-ARMs können das an sich (nicht nur deren AVR32). Andere Frage ist: was für ein Handshake wird gebraucht? Es wird ja nicht genügen, die Daten mit maximal möglicher Rate auf 24 Portpins rauszukegeln, sondern irgendwie muss man der Datensenke ja auch mitteilen, dass da jetzt gültige Daten vorliegen. Möglicherweise muss diese auch noch bestätigen, dass sie die Daten erhalten hat. Je nach Protokoll kann es dann mit DMA schnell Essig sein. Allerdings sollte es auch ohne DMA rein mit CPU kein Problem sein, die Daten da rauszuwackeln und noch ein paar Steuerleitungen zu bedienen.
Falk B. schrieb: > FIFO ist Unsinn, denn dann sind die Daten nach einem Durchlauf weg. Unfug, der Eingang Retransmit (RT) wurd bereits erfunden.
Jörg W. schrieb: > Sollte aber auch einer sein, der nicht (wie viele STM32) auf nur 16-bit > IO kastriert worden ist. Atmel-ARMs können das an sich (nicht nur deren > AVR32). Wobei das letztlich wahrscheinlich ueber den Handschacke abgefangen werden koennte. Auch bei der synchronen Ansteuerung bei 32bit Ports gibt es ja Momente mit ungueltigen Zwischenmustern, die man auf Empfaengerseite abfangen muss. Wobei ich dir trotzdem Recht gebe dass man darauf schauen soll, um nicht das Timing unnoetig zu verkomplizieren. > Andere Frage ist: was für ein Handshake wird gebraucht? Es wird ja nicht > genügen, die Daten mit maximal möglicher Rate auf 24 Portpins > rauszukegeln, sondern irgendwie muss man der Datensenke ja auch > mitteilen, dass da jetzt gültige Daten vorliegen.
Es gibt keinen Handshake. Es kommen die 24 Bit an 24 Pins raus und gehen direkt an 24Pins eines VectorModukatirs. Daher sollte die Taktrate schon stabil sein.
Klaus schrieb: > Es gibt keinen Handshake. Wir wird es dann synchronisiert? Irgendwie sollte die Datensenke ja nicht gerade genau dann abtasten, wenn die Datenquelle umschaltet. Gemeinsamer Takt zwischen beiden?
Nein, gar nichts. Das Teil reagiert einfach auf die 24 Bit die am Eingang anliegen
Klaus schrieb: > VectorModukatirs Wäre es so schwer zu sagen welches Bauteil du genau meinst? Denn ein paralleles Interface ist ggf. gar nicht notwendig: "3-wire or 4-wire SPI supporting up to a 61.44 MHz SPI clock speed" Sprich das Teil kannst du direkt an einen Raspberry Pi 4 packen und glücklich sein. Kein uC, einfach nur direkt rausschreiben über einen Kernel Treiber. Oder muss es ein ganz exotischer IC sein welcher 2ct günstiger ist und dafür 20€ Schaltungskosten und 100000€ Arbeit verursacht? https://www.analog.com/en/products/admv4821.html#product-overview
Wenn es eine einmalige Sache ist (oder selten Updates), dann die Daten in ein EEPROM packen (bzw. 2 16-Bit) und die Adressen durchnudeln. Da braucht es dann keinen Prozessor, nur einen Zählerbaustein.
Onkel Ted schrieb: > Sprich das Teil kannst du direkt an einen Raspberry Pi 4 packen und > glücklich sein. Kein uC, einfach nur direkt rausschreiben über einen > Kernel Treiber. Oder muss es ein ganz exotischer IC sein welcher 2ct > günstiger ist und dafür 20€ Schaltungskosten und 100000€ Arbeit > verursacht? https://www.kratosmed.com/gmcatalog/microwave-iq-vector-modulators-and-bi-phase-modulators/series-73-12-bit-digital-and-series-74-analog-high-dynamic-iq-vector-modulators Das wäre z.B. so ein Exemplar. Weiß jedoch nicht was es an der Aufgabenstellung ändert
Klaus schrieb: > Das wäre z.B. so ein Exemplar. Weiß jedoch nicht was es an der > Aufgabenstellung ändert Analog control (Series 74) Wirf eine 24 Bit Soundkarte/DAC drauf. Ansonsten gibt es von NI usw. Karten für sowas.
Onkel Ted schrieb: > Wirf eine 24 Bit Soundkarte/DAC drauf. > > Ansonsten gibt es von NI usw. Karten für sowas. Habe es ja mit dem ESP32 über i2s (Sound) gemacht. Klappt wunderbar, das ding hat nur einfach keine 24Pins, sonst wäre ich fertig. Was wäre eine solche Karte?
Klaus schrieb: > Das wäre z.B. so ein Exemplar. OK, 2 DACs. Dann sieht es wirklich so aus, als sollte man sie komplett parallel ansteuern. Ein hinreichend großer (mindestens 48 Pin) SAMD21 bietet dir beispielsweise einen fast vollständig bestückten Port A. Falls du einen Quarzoszillator brauchst, musst du ggf. deine Daten um PA14/15 "herum schieben" (also PA0…PA13 und PA16…PA25 benutzen). Maximaler RAM-Ausbau ist 32 KiB, maximaler Flash 256 KiB. Wenn das nicht genügt, kannst du noch gucken, über Portpins von Port B einen SPI-Speicher anzuschließen.
Klaus schrieb: > Onkel Ted schrieb: > >> Wirf eine 24 Bit Soundkarte/DAC drauf. >> Ansonsten gibt es von NI usw. Karten für sowas. > > Habe es ja mit dem ESP32 über i2s (Sound) gemacht. Klappt wunderbar, das > ding hat nur einfach keine 24Pins, sonst wäre ich fertig. > Was wäre eine solche Karte? Nach einem DAC sind 24 Bit doch eine einzige Leitung. Wozu willst du da 24 Pins? Könnte mir gut vorstellen, dass die 24 Bit intern als Widerstandsnetzwerk DAC verschaltet sind.
Die beiden Dacs sind aber doch im Modulator verbaut. Wenn ich an den analogen Teil käme wäre es kein Problem, so aber muss ich mit jeweils 12 Bit durch den DAC = 2x12 Leitungen.
Beeindruckender kompletter Overkill. Eine schnelle SPI-Schnittstelle, drei Schieberegister (74xx595), vier I/O-Leitungen (drei zum Adressieren der einzelnen Schieberegister und eine, um die RCLK-Leitung aller drei Register anzusteuern) würde völlig ausreichen. Wenn man darauf vertraut, daß alles synchron abläuft, kann man auch auf die Adressierung verzichten. Nach je drei via SPI übertragenen Bytes wird die RCLK-Leitung angesteuert. Der SPI-Takt muss nur etwas höher sein als 12 MHz, um die geforderten 500 kHz Datenrate einhalten zu können. Mehr ist nicht nötig. Ein ESP32 sollte dafür genügen, oder muss man die Software dafür so umständlich schreiben, daß 170 kiByte dafür nicht genügen?
Meine Idee nachdem es im ESP32 eigentlich alles schön gebaut ist...könnte ich per SPI auf 3 Schieberegister a 8 Bit gehen und das ordentlich gepuffert und getaktet ausgeben? Habe noch nie mit Schieberegistern gearbeitet
Klaus schrieb: > Die beiden Dacs sind aber doch im Modulator verbaut. Wenn ich an > den analogen Teil käme wäre es kein Problem, so aber muss ich mit > jeweils 12 Bit durch den DAC = 2x12 Leitungen. "Analog control (Series 74)" Schau das Schaltbild an, die Series 74 bietet eben genau das, zwei analoge Eingänge mit 0-10V. Du hast mir der Series 73 einfach nur das falsche Modell gekauft.
Oh, da waren wir gleich schnell mit gleichem Gedanken. Ich kann den ESP32-S3 nehmen, der ist bis auf die parallele Ausgabe komplett fertig und hat 8MB PSRAM
DerEgon schrieb: > Eine schnelle SPI-Schnittstelle, drei Schieberegister (74xx595) Vorsicht, diese Lösung hatte ich (erste Antwort im Thread) auch vorgeschlagen, ist Falk B. schrieb: > So ein Quark. Vielleicht macht es ja das Detail: DerEgon schrieb: > drei zum Adressieren der einzelnen Schieberegister Besser? Ich hätte die Schieberegister hintereinandergeklemmt, und die 24 Bit "in einem Rutsch" per SPI rausgetaktet. Allerdings braucht es dann bei gewünschten 1MHz am Parallel-Output schon einen schnellen SPI, und schnelle '595er. Der SPI vom ESP32 reicht glaube ich knapp nicht mehr.
Klaus schrieb: > könnte ich per SPI auf 3 Schieberegister a 8 Bit gehen und das > ordentlich gepuffert und getaktet ausgeben? Ja klar. Simple '595 tun's.
Klaus schrieb: > könnte ich per SPI auf 3 Schieberegister a 8 Bit gehen und > das ordentlich gepuffert und getaktet ausgeben? Klaus schrieb: > Oh, da waren wir gleich schnell mit gleichem Gedanken. Aber Ernst war mit der allerersten Antwort nach 20 Minuten 'nen guten 3/4 Tag schneller! ;) Εrnst B. schrieb: > Drei SN74HCS595 o.Ä per SPI (+DMA?) befüllen? > > Ein STM32 mit >24MHz am SPI ist ja keine Seltenheit...
Kriegt man auch relativ jitterfrei hin, wenn man den RCLK-Puls per Timer in der gewünschten Frequenz in Hardware erzeugt. Kann man dann eine ISR dranhängen, die nach dem RCLK gleich die nächsten drei Bytes in den SPI schiebt...
Klaus schrieb: > Weiß jedoch nicht was es an der Aufgabenstellung ändert Wenn die 24 Bits nichts miteinander zu tun haben, sondern eine Information nur in ihrem eigenen zeitlichen Verlauf liegt (z.B. 24 parallele TX-Leitungen von 24 unterschiedlichen UARTS), dann ist es egal, ob 1 einzelnes Bit um ein paar hundert ns verspätet ankommt oder gar jittert. Wenn die 24 Bits aber zusammengehören und einen 24-Bit-Binärwert darstellen, dann muss man den/die Zeitpunkt/e kennen, an dem/denen dieser Wert auf dem Bus gültig ist. Denn der Wechsel in einem 4-Bit-Wort von 0111 nach 1000 kann niemals(!) gleichzeitig passieren. Er könnte so aussehen: 0111-0101-1100-1000. Solche Inkonsitenzen bei logischen Umschaltvorgängen nennt man Glitches. Ohne Synchronisation bringen sie Rauschen ins System. Du musst bewerten, ob dich das betrifft oder stört. Klaus schrieb: > Die beiden Dacs sind aber doch im Modulator verbaut Sag doch einfach welche DAC in welchem Modulator. Warum um alles in der Welt muss man denn immer alles aus jedem "herausfragen" oder sogar selber raten?
Lothar M. schrieb: > Sag doch einfach welche DAC in welchem Modulator. Hat er doch: Beitrag "Re: Eigenentwicklung um 24 Bit Daten aus Datei parallel auszugeben" Ich denke, auf ein paar Nanosekunden Zeitdifferenz zwischen den Leitungen kommt's bei so einem Teil nicht an, weil das in der endlichen slew rate des nachfolgenden Analogteils untergeht.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Hat er doch Na hoppla. @Klaus: Sorry, denk dir das "um alles in der Welt" aus meiner Frage weg. Jörg W. schrieb: > Ich denke, auf ein paar Nanosekunden Zeitdifferenz zwischen den > Leitungen kommt's bei so einem Teil nicht an Und auch wenn es drauf ankäme: das Ding hat ja gar keinen /WR Eingang o.ä. zur Validierung der parallelen Daten.
Klar, paar Nanosekunden sind egal, aber generell sollen die 24 Bit zeitgleich an den Ausgängen anliegen. Wie gesagt, habs mit der i2s Schnittstelle des ESP32 gemacht...klappt absolut stabil. Es scheitert schlicht an den 24 Pins die nicht vorhanden sind. Deshalb bin ich auf den ESP32-S3 geswitcht. Dieser hat jedoch keinen parallel Modus mehr in der I2S Schnittstelle, wurde in ein LCD Modul ausgelagert. Dieses kann jedoch nur 16 Bit parallel und es ist nach jedem Befehl eine (Leerzeile?). Also nach jedem Bitwort sind alle Ausgänge für einen Takt "low". Nun suche ich einfach was, im Idealfall verwandtes, was mir 24 Bit parallel mit 1 Mhz stabil rauswerfen kann. Werde mir den Ansatz anschauen den ESP32-S3 gepaart mit 3 Schieberegistern a 8 Bit zu nutzen. Mal sehen was für Taktraten man über SPI hinbekommt
Klaus schrieb: > Mal sehen was für Taktraten man über SPI hinbekommt Ist die Frage, was der ESP32 kann. TI bspw. sagt, dass ihre 74HC595 bei Vcc=4,5 V maximal 25 MHz verkraften. Du brauchst (24 · 0,5) MHz + Overhead (Zeit für Generieren des Ladeimpulses und Bereitstellen der nächsten Daten).
Jörg W. schrieb: > TI bspw. sagt, dass ihre 74HC595 bei > Vcc=4,5 V maximal 25 MHz verkraften. Deshalb hatte ich 74HCS595 vorgeschlagen, auch wenn man deren Schmitt-Trigger-Eigenschaft nicht benötigt. https://www.ti.com/product/SN74HCS595 da sollte auch bei 3.3V noch genug Reserve sein.
Wenn Q und I quasikontinuierliche Signale sind, duerfte ein kurzer Versatz zwischen der Q- und I-Aktualisierung nichts ausmachen. Dann haette man nur jeweils 12 Bit gleichzeitig auszugeben, das duerfte die Auswahl der Mikrocontroller deutlich erleichtern.
Εrnst B. schrieb: > Deshalb hatte ich 74HCS595 vorgeschlagen Naja, es gibt ja mittlerweile endlos viele 74xx-Baureihen, da sind genügend schnelle dabei. Die Frage ist ja eher, was der ESP32 maximal durchpumpen kann.
Jörg W. schrieb: > Εrnst B. schrieb: >> Deshalb hatte ich 74HCS595 vorgeschlagen > > Naja, es gibt ja mittlerweile endlos viele 74xx-Baureihen, > da sind genügend schnelle dabei. Die Frage ist ja eher, > was der ESP32 maximal durchpumpen kann. 24Bit lassen sich auch als 4 x 6 Bit darstellen; das passt mit zwei Steuersignales (1xSchieben, 1xWrite für Latches) auf einen 8-Bit-Port. Hardware-Aufwand sind 6 Schieberegister und 3 Latches. Eine 24Bit-Ausgabe erfordert m.E. 8 I/O-Befehle.
Wenn schon, müsste das Steuersignal zur Übernahme auf den Ausgang für alle Latches das gleiche sein, sonst ist es nicht gleichzeitig. Allerdings dürfte das im Fall des ESP32 dann trotzdem wieder an den fehlenden Pins für so viele parallele Daten scheitern.
Jörg W. schrieb: > Wenn schon, müsste das Steuersignal zur Übernahme > auf den Ausgang für alle Latches das gleiche sein, > sonst ist es nicht gleichzeitig. Ja, klar, so war es gemeint: EIN Taktsignal zum Schieben für alle sechs Schieberegister, und EIN Schreibsignal für alle Latches. Logo. > Allerdings dürfte das im Fall des ESP32 dann trotzdem > wieder an den fehlenden Pins für so viele parallele > Daten scheitern. ??? So viele? Man braucht EINEN 8-Bit-Port. Der ist nicht da?!
Grummler schrieb: > Man braucht EINEN 8-Bit-Port. Irgendwie habe ich dich nicht verstanden. Du willst SPI durch Bitwackeln machen? Das wird schätzungsweise nicht schnell genug sein. Wenn schon, dann ein richtiger SPI-Port.
:
Bearbeitet durch Moderator
Moin, 500kHz ist ziemlich lahm. Mit einem STM32F40x kannst du das in einen Timer packen und die Werte an 2-3 Ports ausgeben. Bei 168 Mhz Takt hast du 336 Takte... das reicht locker. Evtl. geht es sogar mit zwei DMAs, dann langweilt sich der MCU dabei sogar. schönen Gruß, Alex
Jörg W. schrieb: > Wenn schon, müsste... Müsste, könnte, würde... immerzu all diese Konjunktive. Und das alles nur, weil der TO mit seiner grandiosen "Eigenentwicklung" zwar die Phantasie anregt, aber nicht wirklich konkret wird. Ich vermute mal, daß da ein kaum halbgares Konzept dahinter steht, bei dem der TO an die Grenzen seiner Planungskraft gekommen ist und deshalb hier nachfragt, ob ihn jemand aus seinem eigenen Holzweg wieder herausholt. Aber dazu müßte er das eigentliche Planungsziel erläutern und nicht mit düren Worten bloß "folgende Aufgabenstellung:" hinschreiben. Wir sind hier ja nicht in der Grundschule. Eigentlich ist schon alles dazu gesagt. W.S.
W.S. schrieb: > Ich vermute mal, daß da ein kaum halbgares Konzept dahinter steht, bei > dem der TO an die Grenzen seiner Planungskraft gekommen ist und deshalb > hier nachfragt, ob ihn jemand aus seinem eigenen Holzweg wieder > herausholt. Nun, viel interessanter ist doch welche Wege (und welcher Aufwand) hier so vorgeschlagen werden für eine derart triviale Aufgabe. Amüsant ist es allemal, daher Danke an alle emsig Mitwirkenden…
Solange Klaus nur um den heißen Brei eiert solange wird das nichts. Ich halte den gesamten Thread für Sinnfrei.
> Ich halte den gesamten Thread für Sinnfrei.
Es gibt ja genug die über das hingehaltene Stöckchen springen...
Schon die Tatsache noch nie im Leben mal ein Schieberegister
benutzt zu haben, spricht da Bände.
Da ist wieder ein überforderter Informatiker am Werk.
Und wie alle Informatiker bringt er nichts, oder nur deutlich
suboptimales zustande.
PittyJ schrieb: > Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an? Weil du nicht alle 24 Bit gleichzeitig Takt-Synchron ausgeben kannst. Das war doch die besondere Anforderung von Klaus.
Stefan ⛄ F. schrieb: > PittyJ schrieb: >> Warum nimmt man nicht einfach 24 GPIOs davon, und legt die Bitmuster an? > > Weil du nicht alle 24 Bit gleichzeitig Takt-Synchron ausgeben kannst. > Das war doch die besondere Anforderung von Klaus. Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren.
Norbert schrieb: > Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren. Ich rede vom STM32H7, den Pitty im gleichen Atmemzug nannte. Dessen GPIOs haben nur 16 Bit, wie bei allen (?) STM32.
Stefan ⛄ F. schrieb: > Norbert schrieb: >> Das gilt zwar für viele aber bei weitem nicht für alle Prozessoren. > > Ich rede vom STM32H7, den Pitty im gleichen Atmemzug nannte. Dessen > GPIOs haben nur 16 Bit, wie bei allen (?) STM32. Ah, OK, für den gilt's. ;-)
es gibt auch noch D-Latches, eventuell zweistufig, dann kann man auch bequem 8 Bit sequentiell arbeiten.
J. S. schrieb: > es gibt auch noch D-Latches, eventuell zweistufig, dann kann man auch > bequem 8 Bit sequentiell arbeiten. Ganz Recht. Wäre schön, wenn der Klaus sich mal dazu äußern würde.
J. S. schrieb: > es gibt auch noch D-Latches, eventuell zweistufig, dann kann man > auch > bequem 8 Bit sequentiell arbeiten. Ja das stimmt. Man kann eine ganze Schublade voller phantastischer Bausteine dran kleben. Oder ein Kuchenblech voller Bausteine drum herum arrangieren. (Man kann auch einfach etwas Passendes nehmen.)
Norbert schrieb: > Man kann auch einfach etwas Passendes nehmen. Was willst du dem J.S. damit sagen? Sein Vorschlag war völlig korrekt (wenn auch nicht neu). Man gibt die 24 Bit (nicht synchron) aus, dann einen Takt-Impuls an die D-Latches, die das synchron weiter leiten. Geeignet wären z.B. 3x 74HC273
Stefan ⛄ F. schrieb: > Norbert schrieb: >> Man kann auch einfach etwas Passendes nehmen. > > Was willst du dem J.S. damit sagen? Sein Vorschlag war völlig korrekt > (wenn auch nicht neu). Man gibt die 24 Bit (nicht synchron) aus, dann > einen Takt-Impuls an die D-Latches, die das synchron weiter leiten. > Geeignet wären z.B. 3x 74HC273 Damit will ich sagen das man sich das ganze externe Gelumpe komplett sparen kann, wenn man von Anfang an den Prozessor richtig und den Anforderungen entsprechend auswählt.
mir ist es egal welche Lösung der TO wählt, es gibt eben mehrere. Anderer µC ist auch nicht wenig Aufwand. Wenn man den ESP32 gut kennt lässt es sich damit sicher auch lösen, der SPI kann afaik 80 MHz, damit geht schon was. Der H7 ist auch was Feines, nur als Einzelstück gerade sehr schwer zu bekommen. Und Programmiertechnisch eine Diva, sehr kompliziert, da nutzen die schönen ESP Libraries nichts. Dafür kann man von einer SD Karte locker >18 MByte/s lesen, raw Daten noch schneller. Bei Aliexpress gibt es noch H7 Boards, wie etwa dieses: https://de.aliexpress.com/item/1005001567462650.html doppelt so teuer wie vor 2 Jahren, aber immerhin. Ooops, der H743 eher für den dreifachen Preis. Der ist sehr beliebt. Und einige STM Nucleos mit H7 bekommt man vielleicht auch noch.
:
Bearbeitet durch User
Norbert schrieb: > Damit will ich sagen das man sich das ganze externe > Gelumpe komplett sparen kann, wenn man von Anfang > an den Prozessor richtig und den Anforderungen > entsprechend auswählt. Genau. Nur Idioten entwickeln Schaltungen aus einzelnen Bauteilen. Der Fachmann verwendet IMMER AUSSCHLIESSLICH hochintegrierte ICs. Was nicht mit einem fertigen IC zu lösen ist, das ist generell unlösbar! Basta!
Grummler schrieb: > Norbert schrieb: > >> Damit will ich sagen das man sich das ganze externe >> Gelumpe komplett sparen kann, wenn man von Anfang >> an den Prozessor richtig und den Anforderungen >> entsprechend auswählt. > > Genau. > > Nur Idioten entwickeln Schaltungen aus einzelnen Bauteilen. > Der Fachmann verwendet IMMER AUSSCHLIESSLICH hochintegrierte > ICs. > Was nicht mit einem fertigen IC zu lösen ist, das ist > generell unlösbar! Basta! Wenn ich deinen Text korrekt interpretiere, dann ist dir das was du schreibst vermutlich noch nicht einmal peinlich. Sei's drum. Die ›Fachmänn:innen‹ verwenden den bestmöglich passenden Lösungsansatz, Wenn der dann auch noch deutlich günstiger und einfacher im Aufbau ist, umso besser. Wenige Beiträge zuvor zB. eine 35€-65€ Lösung im Gegensatz zu einer 4€ Lösung. Aber jedes wie es mag.
J. S. schrieb: > Wenn man den ESP32 gut kennt lässt es sich damit sicher auch lösen, der > SPI kann afaik 80 MHz, damit geht schon was. Dann ist doch mit den 3 '595 sein Problem auf jeden Fall gelöst.
Norbert schrieb: >> Nur Idioten entwickeln Schaltungen aus einzelnen >> Bauteilen. Der Fachmann verwendet IMMER AUSSCHLIESSLICH >> hochintegrierte ICs. >> Was nicht mit einem fertigen IC zu lösen ist, das ist >> generell unlösbar! Basta! > > Wenn ich deinen Text korrekt interpretiere, Erfahrungsgemäß ist das unwahrscheinlich. Ironie und Sarkasmus werden nie richtig verstanden. > dann ist dir das was du schreibst vermutlich noch nicht > einmal peinlich. Sei's drum. Über das Alter, in dem man mich mit "Schäm Dich!" mundtot machen konnte, bin ich schon ein paar Wochen hinaus. Also: Nein, das ist mir nicht peinlich. > Die ›Fachmänn:innen‹ verwenden den bestmöglich passenden > Lösungsansatz, Nein, in der Regel nicht -- zumindest nicht im ersten Anlauf. Wenn man mit einem Projekt Neuland beschreitet -- und sei das auch nur "persönliches" Neuland -- dann ist es solchen Projekten WESENSEIGEN, dass man im Vorfeld eben noch NICHT alle Anforderungen überblickt. Entsprechend muss man häufig die gewählte (Teil-)Lösung nachträglich erweitern und an die zwischenzeitlich neu gewonnenen Erkenntnisse anpassen. Dazu kommt, dass ein geeigneter großer Mikrocontroller, der aktuell nicht lieferbar ist, deutlich weniger Wert ist als ein "eigentlich" zu kleiner, der schon vorhanden ist. Es kann also eine Vielzahl von Gründen geben, warum "das ganze externe Gelumpe" sinnvoll ist.
Norbert schrieb: > Damit will ich sagen das man sich das ganze externe Gelumpe komplett > sparen kann, wenn man von Anfang an den Prozessor richtig und den > Anforderungen entsprechend auswählt. Na toll. Diese Auswahl ist einfach. Schon wesentlich schwieriger wird es, wenn man dann auch noch einen Prozessor auswählen will, der in absehbarer Zeit als Einzelstück lieferbar ist und (bei diese Randbedingung) keine 100€ oder gar noch mehr kostet... Ja, die Spielregeln haben sich ein wenig geändert in den letzten 2 Jahren... Wenn du das nicht mitbekommen haben solltest: Guten Morgen, du Schnarchnase!
c-hater schrieb: > Schon wesentlich schwieriger wird es, wenn man dann auch noch einen > Prozessor auswählen will, der in absehbarer Zeit als Einzelstück > lieferbar ist und (bei diese Randbedingung) keine 100€ oder gar noch > mehr kostet... > > Ja, die Spielregeln haben sich ein wenig geändert in den letzten 2 > Jahren... > Wenn du das nicht mitbekommen haben solltest: > Guten Morgen, du Schnarchnase! Sieh an, er nu wieder. In seiner allseits bekannten widerlichen Art. Er ist verfügbar. Und er kostet als Prozessor allein 0,99€. Für all diejenigen welche den Lötkolben auch gern mal an der falschen Seite anfassen. Platine: 4,10€ Aber was rede ich bei dir…
Norbert schrieb: > Er ist verfügbar. Und er kostet als Prozessor allein 0,99€. Er hat einen Prozessor, einen ESP32. Wenn sich das Problem damit lösen lässt, braucht niemand hier einen weiteren Prozessor. Dass sich das Problem damit (+ 3 x '595) lösen lässt, wurde nun schon hinlänglich diskutiert, und das ist letztlich an Einfachheit kaum noch zu unterbieten.
Jörg W. schrieb: > und das ist letztlich an Einfachheit > _kaum_ Da stimme ich dir zu! > noch zu unterbieten.
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.