Hi, es geht um einen 32bit RGB"A" 100Hz 16³ Led Cube (Einen 5bit PWM 100Hz 16³ Led Cube habe ich bereits geschafft). Bisher habe ich den STM32F103 als Treiber für den Würfel und zur Frame-Generierung verwendet. Damit ich einiges mehr Rechenleistung und bequemer Programmieren kann, möchte ich den μC von der Frame-Generierung entbinden und auf einen "Single Board Computer" (SBC) auslagern. Der μC nimmt also nur noch Frames entgegen und zeigt diese an. Momentan grübele ich über die Kommunikation zwischen dem μC und SBC. Der μC (STM32F103) hat 20KiB RAM und kann somit ein komplettes Frame im Speicher halten (4*16³=16KiB). Zur Synchronisierung will ich das Frame in eine obere und untere Hälfte teilen. Eine Hälfte wird zur Darstellung verwendet, während die andere Hälfte verwendet wird um die nächsten Daten zu laden. Da ich den Würfel mit 100Hz laufen lassen möchte bedeutet das ich habe weniger als 5ms Zeit die Daten nachzuladen. Von der Bandbreite her ist das ja kein Problem, da das in etwa 1.31MBit/s entspricht (16*16*8*4*8Bit/0.05s). Das Problem welches ich aber sehe, ist die Realtime Anforderung, konsistent 8KiB alle 5ms zu senden. Mit PREEMPT_RT scheint man in Linux zwar näher an Realtime zu kommen, aber das reich nicht aus, da man so die Latenzen anscheinend "nur" unter 10ms drücken kann. Also kam mir die Idee zwei Buffer a 128KiB dazwischen zu schalten. Der erste Buffer wird vom SBC gefüllt während der zweite vom μC gelesen wird, hat der μC alles gelesen, wird gewechselt. So hat der SBC 80ms einen der beiden Buffer zu beschreiben. Als Baustein hatte ich ein großes Shiftregister im Sinn. Bei Reichelt bin ich aber leider nicht fündig geworden. Ich könnte mir zwar aus SRAM Bausteinen das selber zusammenbasteln, den Aufwand würde ich mir aber gerne sparen. Das beste was ich bisher gefunden habe: 256Kx8 LOW VOLTAGE, FAST SERIAL SRAM with SPI, SDI and SQI INTERFACE https://www.mouser.de/datasheet/2/198/IS62-65WVS2568GALL-BLL-1315793.pdf Die Alternative wäre natürlich einen μC zu verwenden der mehr SRAM unter der Haube hat, allerdings fände ich es schade wenn ich deswegen auf einen anderen μC umsteigen muss. Also die Frage an Euch, gibt es noch weitere Möglichkeiten die Datenübertragung vom SBC zum μC zu schaffen? Ggf. andere Bauteile die als Buffer dienen können und bei Reichelt verfügbar sind?
DvdKhl schrieb: > Das Problem welches ich aber sehe, ist die > Realtime Anforderung, konsistent 8KiB alle 5ms zu senden. Mit PREEMPT_RT > scheint man in Linux zwar näher an Realtime zu kommen, aber das reich > nicht aus, da man so die Latenzen anscheinend "nur" unter 10ms drücken > kann. Ich sehe da eigentlich kein größeres Problem. Man kommt man mit dem PREEMPT-RT deutlich unter die 10ms. In der Regel wird man eher bei deutlich <1ms landen. Was für eine Schnittstelle wolltest du denn überhaupt nutzen zwischen SBC und µC?
DvdKhl schrieb: > Die Alternative wäre natürlich einen μC zu verwenden der mehr SRAM unter > der Haube hat, allerdings fände ich es schade wenn ich deswegen auf > einen anderen μC umsteigen muss. Warum? Auch ST hat größere und stärkere Prozessoren und so ein STM32F401 wird grundsätzlich auch nicht so viel anders funktionieren. Immerhin hast Du Dir das ja selber eingebrockt, da Du Dir ohne Not eine der ältesten Typen innerhalb der STM32-Familie ausgesucht hast. Heutzutage gibts zum gleichen Preis besseres. fchk
moep schrieb: > Ich sehe da eigentlich kein größeres Problem. > Man kommt man mit dem PREEMPT-RT deutlich unter die 10ms. In der Regel > wird man eher bei deutlich <1ms landen. > Was für eine Schnittstelle wolltest du denn überhaupt nutzen zwischen > SBC und µC? Stimmt! Ich habe nochmal nachgelesen und alles was ich gefunden habe war auch deutlich unter 1ms. Keine Ahnung wo ich das mit den 10ms her habe, ggf. habe ich mich einfach nur verlesen. Perfekt, dann kann ich es so weiter planen wie ich es mir zu anfang gedacht habe. Danke für den Hinweis! :) moep schrieb: > Was für eine Schnittstelle wolltest du denn überhaupt nutzen zwischen > SBC und µC? Bisher habe ich die meiste Erfahrung mit SPI. Deswegen wird es wahrscheinlich darauf hinauslaufen, dass der SBC den SPI Master mit zwei Leitungen (CLK, MOSI) spielt und einer weiteren Leitung mit dem der µC dem SBC bei steigender Flanke mitteilt, dass die nächsten Daten gesendet werden können. Für eine Datenübertragung vom µC nach SBC sehe ich momentan keine Notwendigkeit. (Den Raspberry Pi den ich mir ausgesucht habe, kann anscheinend kein SPI Slave.) fchk schrieb: > Warum? Auch ST hat größere und stärkere Prozessoren und so ein STM32F401 > wird grundsätzlich auch nicht so viel anders funktionieren. Immerhin > hast Du Dir das ja selber eingebrockt, da Du Dir ohne Not eine der > ältesten Typen innerhalb der STM32-Familie ausgesucht hast. Heutzutage > gibts zum gleichen Preis besseres. Du bist etwas zu schnell, noch habe ich mir gar nichts eingebrockt, ich bin noch komplett in der Planungsphase. Und was heißt ohne Not, ich habe bisher mit diesem µC die meiste Erfahrung, haben den auf Vorrat und reicht für das was ich vorhabe vollkommen aus. Würde ich nicht "ohne Not" einfach etwas kaufen obwohl ich etwas passendes auf Vorrat habe, noch keine Erfahrung mit habe und für den zweck komplett überdimensioniert ist?
Bitte 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.