Hallo, ich habe uC-Applikation (Atmega644, ca. 7MHz), die mit 60Hz über SPI einen Sensor ausliest und dann das ganze als dreistelligen Wert plus ';' als Trennzeichen über UART-Funkmodul an den Rechner sendet. Nun machen die Umstände eine Erhöhung der Abtastrate auf 100Hz notwendig und die Datenrate des Funkmoduls reicht nicht mehr, auch weil die Umgebung nicht gerade funkfreundlich ist (Gebäude, u.U. viel Metall). Ich wollte deshalb mittels SPI-SRAM eine Art FIFO realisieren, mit 100Hz messen, 50Hz senden. Die Messung ansich dauert nur 1-2 Minuten. Nun würde mich eure Meinung interessieren, ob es realistisch ist über ein SPI den Sensor und den Schreib- und Lesetraffic des Speichers abzuwickeln. Hab ihr da noch andere Vorschläge, wie ich das realisieren kann ohne, die ganze Harware zu ändern? Vielen Dank und Grüße...
Ändere doch einfach das Protokoll auf der Funkschnittstelle und sende statt 4 ASCII-Bytes nur ein oder zwei Binärbytes. Damit müßte die Übertragung wieder schnell genug sein. Wenn Du aufgrund des Wertebereiches zwei Bytes brauchst, verteile das dann so, daß beim ersten Byte Bit 7 1 und beim zweiten 0 ist, damit Du auf dem PC die Synchronisation hinbekommst. Das machen serielle Microsoft-Mäuse genauso. fchk
Hallo Frank, Danke für die schnelle Antwort. Kannst Du mir das bitte etwas genauer erläutern?
ATmega644 mit SPI-Port und USART-Port im SPI-Mode und 23K256 als externes SPI-RAM klingt gut. Dreistelliger Wert? Also 0 bis 999? Oder -999 bis +999? Könnte man binär statt ascii speichern und bis 10 bit statt 16 bit ein wenig packen. Dann würde ich mir Gedanken machen, ob ein ATmega1284 mit 16 kB RAM on-chip nicht die bessere Lösung ist. Spart den externen SPI-RAM...
Hallo noch ein Gast, der Wertebereich ist 0-999. Genau die Variante mit dem 23K256 hatte ich überlegt. Wäre das vom Timing her zu bewältigen? Ich müsste immerhin Sensor lesen, RAM lesen und schreiben. Alternativ wäre noch der RAM über eine Soft-SPI anschließbar, ich hab noch Pins frei. Vorteil dieser Variante gegen über des 1284 ist, dass ich den RAM anfrickeln kann und keine neue Platine machen muss. Danke, Alex
> Wäre das vom Timing her zu bewältigen?
Ja, locker.
Der ATmega1284 ist pin-kompatibel zum ATmega644.
Kann also direkt ausgetauscht werden.
Ich halte die 16 kB RAM des ATmega1284 bei diesen
Rahmenbedingungen für ausreichend.
Die Werte 0..999 lassen sich als 10-bit-binär-Werte
packen. Den Fifo würde ich also gar nicht in Ascii
anlegen, sondern als gepackte 10-bit-Werte.
Das Wandeln von Ascii in Binär und umgekehrt erledigt
die CPU locker nebenher.
Soft-SPI halte ich für zu umständlich. Die CPU bietet
doch zwei SPI-Ports (SPI und USART in SPI-Mode).
Achso, die Platine mit dem ATmega644 gibt es bereits und der ATmega644 ist nicht gesockelt. Dann besser einen 23K256 dran hängen. Wenn die Platine erst noch angefertigt wird oder der ATmega644 (DIP40) gesockelt ist, dann würde ich auf den ATmega1284 setzen. Vorausgesetzt, an den Vorgaben ändert sich nicht noch etwas; z.B. 2-4 Minuten statt 1-2 Minuten oder 200 Hz Abtastung statt 100 Hz, usw.
je nach Sensor/zu messender Grösse kannst du auch die zu übertragende Datenrate reduzieren, indem du nur die Differenz zum vorherigen Messwert (-128...+127) überträgst. In sinnvollen Abständen Absolutwerte zur Kontrolle. Damit kommt man mit einem einzigen Zeichen pro Messwert aus. Geht natürlich nur, wenn sich der Messwert im Abtastrater nicht um mehr als die max. Differenz ändert.
... oder wenn typisch mehrere aufeinanderfolgende Meßwerte gleich sind, nur diesen Wert und die auftretende Anzahl übertragen. Dabei die max. Anzahl auf 8 begrenzen und erneut synchronisieren. Beispiel :8:123; 8 * der Wert 123 oder auch kürzer als H123; ...
Hallo Alex, die Vorschläge zur Komprimierung der Daten sind gut, aber ich würde schätzen, die nächste Änderung mit noch mehr Bedarf kommt bestimmt. Auch der 1284 wird jetzt schon knapp: 10bit/Wert*100Werte/s*120s macht 120000bit oder 15000Byte.. Also bleibe bei Deiner SPI-SRAM-Idee. Oder Du wählst diese Lösung: http://www.elektor.de/jahrgang/2010/september/verzogerungsleitung-als-digitaler-speicher.1468194.lynkx Na, nicht ganz ernst gemeint. Aber ein tolles Konzept, die Bits zu speichern, indem man sie eine Weile durch Glas wandern läßt. Was haben wir es heute gut... Gruß Jens
@ H.joachim Seifert, die Idee mit der Differenz gefällt mir ganz gut, alledings müsste ich dann sicherstellen, dass keine Werte verfälscht werden, weil ja dann bis zum nächsten Absolutwert alles falsch ist. Wenn ich beim Funkmodul die Sicherung und ein erneutes Senden aktiviere, geht natürlich die Nettodatenrate bei zunehmend schlechter werdender Umgebung in die Knie.Momentan fallen verfälschte Pakete hinten runter. Das ganze Gerät ist portabel, die Bedingungen also nicht vorhersehbar. Da muss ich mir noch was für die Detektierung von unzumutbaren Empfangsbedingungen einfallen lassen. Grüße...
@ Jens Mundhenke, wenn ich gar nicht senden würde, wäre die Rechnung korrekt. Ich wollte aber ca 50 Messwerte/s senden. Wäre also nur noch die hälfte an RAM Bedarf. Ich muss auf jeden Fall davon weg, dass die Funkübetragung die max. mögliche Geschwindigkeit so stark beeinflusst wie jetzt. Meine Bedenken waren, alles über eine SPI zu regeln, aber der Tipp mit der SPI/UART hilft mir sehr. Grüße...
Hallo, ich hab jetzt erstmal die Übertragung auf binär umgestellt und muss mal noch mit einer hoffentlich nicht peinlichen Frage aufwarten. Wenn ich jetzt die COM des PC auslese, dann ist der Rückgabewert ein (im aktuellen Fall nicht lesbarer) String. Wie mache ich da jetzt eine Zahl draus? Sowas wie CBinär hab ich in VBA nicht gefunden. Grüße...
vielleicht so etwas? integervalue = asc(byteHigh$) * 256 + asc(byteLow$)
@ noch ein Gast, Danke, hatte es eben rausgefunden, hat allerdings etwas gedauert, bis ich auf die asc-fkt. gestoßen bin. Ich aber doch noch die Variante mit dem Speicher testen. Danke erstmal an alle für die Hilfe. Grüße, Alex
Ich sehe durchaus Chancen für die Lösung mit dem ATmega1284, wenn an den Rahmenbedingungen nichts geändert wird. Schließlich wird der Fifo ja zeitgleich mit dem Einlesen des Sensors ausgelesen. Die worst-case-Anforderung dürfte also deutlich unter 16 kB liegen. Die interne RAM-Lösung hat den bestechenden Vorteil, dass im Grunde zwei Pointer genügen. Mit externem SPI-RAM muss zu jedem Byte eine Adresse neu mitgeliefert werden, da der SPI-RAM ja gleichzeitig ausge- lesen werden soll. Das macht es ein wenig komplexer. Auch muss der Schreibvorgang gepuffert werden, da ja gerade ein Lesevorgang statt finden kann. SPI-RAM ist dann elegant, wenn der komplette Sensor-Lese- vorgang sich mit dem Aussende-Vorgang abwechselt. Also zwischen den 1-2 Minuten Sensorlesen 2-4 Minuten Pause liegen. Dann wird der SPI-RAM kontinuierlich geschrieben und danach in einem Zug ausgelesen. So habe ich das bei einem Datenlogger gemacht (3 A/D-Kanäle, 10 bit, über 80 Sekunden).
So, nachher wird der Controller getauscht und dann schauen wir mal. Wenn's Neuigkeiten gib, poste ich die dann. Alex
Salut, ich hab jetzt den Puffer implementier, läuft erst mal soweit. Wenn die Performance genügt, bleibt's so. Jetzt noch alles andere umschreiben, was dasurch zu ändern ist, aber das ist eine andere Geschichte. Danke nochmal für alle konstruktiven Vorschläge und Hinweise. Eins noch zum Thema. Die Datenübertragung vwerde ich wohl nicht auf binär umstellen, da ich in einigen Beiträgen davon abgeraten wurde, unter anderem wegen der schlechten Debugmöglichkeiten, nachvollziehbar. Grüße, Alex
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.