Hallo zusammen, ich möchte einen SPI Stream loggen, der ca. alle 5µs einen neuen Wert liefert, siehe Bild - die Daten auf kanal D11). Dazu kommt noch ein Wert aus dem Datenstrom D12. Also muss ich alle 5 µs zwei Bytes sichern, dazu noch den Zustand von D8, der minimum 1 Bit ausmacht, oder noch ein Byte opfert. Das ganze soll ca. 10-30 Sekunden lückenlos erfolgen. Der im Screenshot sichtbare Logic Analyzer macht es nicht, der Puffer ist nach 130µs schon voll, wie man sieht. Also dachte ich an einen Prozessor (der XMega128A1 Explained würde hier herum liegen), jedoch wird es vermutlich an der Geschwindigkeit des SDRAM scheitern, der sich darauf befindet. Hier ein Interleave mit mehreren Speichern aufzubauen lohnt sich dann doch nicht mehr, und der interne SRAM ist deutlich zu klein dafür. Sollte ich mir einen externen SRAM besorgen? Oder evtl die Daten gleich mit kleinem Puffer übers Netzwerk raus schicken? Bevor ich hier zusätzliches Material besorge, oder mich mühselig ins Netzwerk einarbeite, wollte ich vorher mal Eure Meinung dazu hören... Welche Strategie könnte ich sonst noch fahren, ausser abzubrechen :c)
Rechne doch erst mal aus wie viel Byte du speichern willst. ein Byte + noch eines + noch eines = 3 Byte
Bei 10 Sekunden wären es 6MByte. Das war mir jedoch schon klar, dass der interne SRam zu klein ist.
Bei einer Menge von 600KB/Sec würde ich eher einen STM32F4xx oder einen mit ähnlicher Leistungsklasse nehmen. Da ein SPI Dataflash ran und die Daten sind gespeichert. Jetzt mache Dir noch Gedanken wie Du das ganze in den PC bekommst. Seriell 10BK/Sek bei 6MB = 10 Minuten warten.
sind auf dem xplain nicht um die 8mB sdram drauf? die hängen da doch am EBI... sollte also schnell und einfach anzusprechen gehen
Probiere es doch einfach mal aus, Programmiere aber eine Erkennung ob da was verloren ging.
Ich verwende so einen "USB low cost LA", den Logic. Der sampelt 8 Kanäle mit 24 MHz, und zwar so lange, bis die Festplatte des Rechners voll ist. Wenn die Auflösung passt, ist das einfacher als etwas zu bauen. MfG Klaus
Danke Klaus, meinst Du den auf http://www.saleae.com/logic16 ? Würde er die Daten "nahtlos" ablegen? Wie Du auf meinem Screenshot siehst habe ich bereits einen anderen USB Logic Analyzer ausprobiert. Dieser hat ebenfalls auf die Platte gestreamed, jedoch hat er zwischen zwei Aquisitionen eine riesen Lücke hinterlassen, bis er neu getriggert hat. M.E., ja, das ist ein SDRam, ich habe mal versucht ein Byte da hinein zu schreiben, das hat 20-30µs gedauert, in der Zeit habe ich weitere ankommende Daten verloren. Oder habe ich was falsch gemacht? Ich habe es heute nacht auch versucht es über DMA zu übertragen, dann war meine Übertragungroutine mit einem Byte nach 2-3µs fertig, jedoch konnte ich dann später keine sinnvollen Daten mehr aus dem SDRam auslesen, dann dachte ich mir, es kann nur daran liegen, dass der SDRam selbst ja trotzdem seine 20-30µs brauchen wird, also würde das zweite Byte ja noch einen neuen DMA Transfer beginnen wollen, während das erste Byte noch nicht fertig ist. Markus, bereits geschehen. Ich habe mit auf dem Sender und auf dem Empfänger LEDs anzeigen lassen, die Erkennung was super und Fehlerfrei, wenn ich mal die Masse weg gelassen habe, dann hat der Slave mal einen Fehler bekommen und ist aus dem Sync raus gekommen. Dann konnte man ihn nur noch mit einer größeren Pause wieder syncronisieren, das wäre OK, also scheint es nur noch am ablegen der Daten zu scheitern. Der auf der Explained Platine befindliche USB Wandler schaufelt mir die Daten mit 1MBit noch zuverlässig auf den virtuellen Port des PC's, bei 1.5MBit hat er schon Daten ausgelassen. Ich habe schon überlegt ob ich eine PCI Platine verwenden soll, um den Flaschenhals der seriellen kommunikation zu umgehen. Du hast dann den STM32F4xx angesprochen. Heute Nacht habe zufällig was ähnliches versucht aufzubauen: Ich habe hier noch eine Digilent Genesys Platine mit einem Virtex5. Ich kam jedoch leider nur bis zum übergeben des Softcores aus dem EDK in den ISE, und das angeblich funktionierende Demoprojekt zeigt mir dann schon 69 Fehler beim builden, es scheinen ihm alle #include Abhängigkeiten zu fehlen, obwohl ich die .h include Dateien dazu sehe. Ich habe nach mehreren Stunden Suche aufgegeben. Dafür mache ich jedoch gleich einen neuen Thread auf. Vielleicht hat ja hier jemand noch eine Idee, oder kann meine Versuche dokumentieren, falls irgendwelche mit meinem Halbwissen eingegebenen Code und damit ermittelten Werte nicht stimmen sollten.
Wie sieht es aus mit dieser Strategie: * Hardware SPI empfängt Daten und schaufelt sie per Event System oder IRQ in den (normalen) System RAM * Hauptprogramm prüft auf neue SPI Daten und bewegt sie (evtl. mit TimeStamp wie in meinem Logger, den du kennst) ins SDRam Achte nur darauf, das die Kiste auch mit voller Geschwindigkeit läuft. Unter anderem deswegen habe ich in meinem Logger mal mit all den Sysclk Optionen herumgespielt.
Das war mein erster Aufbau, bis ich merkte, dass der SDRam mit der Schreibdauer von 20-30µs zu langsam ist, der interne SRam sollte zwar schneller sein (habe ich nicht mehr probiert), aber er ist zu klein. In der Zeit, wo ich die Daten aus dem SRam in den SDRam schreibe, verliere ich weitere Inhalte, die vom SPI kommen. Vielleicht war ja einfach nur die hugemem() Funktion zu langsam und es gibt evtl noch eine Möglichkeit das externe SDRam schneller zu beschreiben??
Markus Müller schrieb: > Bei einer Menge von 600KB/Sec würde ich eher einen STM32F4xx oder einen > mit ähnlicher Leistungsklasse nehmen. > Da ein SPI Dataflash ran und die Daten sind gespeichert. Es gibt afaik keins, dass sich mit 600 kByte/s beschreiben ließe... und noch je nach Typ (Ausnahme: SST/Microchip max. 50 ms) durchaus mal mehr als eine Minute für ein Chip-Erase brauchen. Selbst die PCM von Micron/ehemals Numonyx/ST schaffen im Worst-Case nur ~170 kByte. D.h. entweder mehrere parallel nutzen oder NAND, SDRAM, SRAM verwenden. Zu dem SDRAM auf dem Xplain. Der XMega selbst kann mit bis zu 32 MHz laufen, der Speicher mit 2x Peripherietakt max. 64 MHz d.h. 15.625 ns und sollte damit schnell genug sein. 2-3 us entsprechen bei 32 MHz etwa 64 - 96 Taktzyklen...
Danke schon mal. Du schreibst dass der Speicher nur 15.625 ns benötigt, dann läuft aber mit der hugemem Funktion was gewaltig schief. Ich habe damit nur beim Speichern eines 16Bit Wertes ganze 20-30us benötigt. Da muss ich heute Nacht noch ein paar Experimente mit schnellerer Speicherung machen, es sei denn jemand hätte einen fertigen Code für mich herum liegen?
Markus Müller schrieb: > Danke schon mal. Du schreibst dass der Speicher nur 15.625 ns benötigt, Kann... Wir wissen nicht wie der Speichercontroller, Takt etc. initialisiert sind und wie hugemem arbeitet. Im Forum gibt es bspw. http://www.mikrocontroller.net/attachment/highlight/79919 (aus Beitrag "xmega + SDRAM + LIBC > 64K?") > dann läuft aber mit der hugemem Funktion was gewaltig schief. Ich habe > damit nur beim Speichern eines 16Bit Wertes ganze 20-30us benötigt. > > Da muss ich heute Nacht noch ein paar Experimente mit schnellerer > Speicherung machen, es sei denn jemand hätte einen fertigen Code für > mich herum liegen?
Christian Müller schrieb: > Danke Klaus, meinst Du den auf http://www.saleae.com/logic16 ? > Würde er die Daten "nahtlos" ablegen? Ich habe den 8 Kanal. Der hat keinen eigenen Speicher sondern nutzt nur den Speicher des PC. Der größte Wert den man bei 24MHz einstellen kann, ist 10 Milliarden Samples also über 800 Sekunden. Wenn ich die Software auf den logic16 umstelle, scheint noch mehr zu gehen. Man kann die auch ohne Gerät im Demo-Modus betreiben. MfG Klaus
Danke an Arc Net Ich werde mich gleich mal an die Arbeit machen und schauen wie lange das himem zum schreiben benötigt. Der Code sieht vielversprechend aus. Danke an Klaus Ich werde mir den 16er gleich mal bestellen, das war eine gute Empfehlung von Dir, alle teueren Logger mit ewig viel Puffer können einpacken :c)
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.