Hallo, Ich will eine 16 Bit UINT in 4 Hexadezimale Asciizeichen umwandeln. Und das ganze mit möglichst wenigen Takten. Die normale Methode, die letzten 4 Bit abzufragen und mit if-Anweisungen zu vergleichen dauert viel zu lange. Desshalb meine Methode: Ich habe eine Konstante "constant unsigned int ASCII[256]={0x3030,0x3031,0x3031....0x4545}" Das ist eine Tabelle , die alle Zeichenkombinationen für die Umwandlung von 1Byte in 2Asciizeichen erlaubt. Meine Konvertierung: *Buffer_adr= ASCII[(char) *daten_adr]; Buffer_adr+=2; //Zieladresse um 2 erhöhen weil 2 ASCII Zeichen daten_adr++; //Datenadresse um 1 erhöhen(nächstes Byte) *Buffer_adr= ASCII[(char) *daten_adr]; Das sind 11+1+1+11=24 Takte. Gehts es noch schneller? Gerade die 1.Zeile mit 11 Takten kann man doch optimieren? Denn was macht der Prozessor: Schiebe Inhalt der Speicheradresse <ASCIIAdresse+Daten+Daten> in die Speicheradresse <Buffer_adr> Geht das schneller als in 11 Takten? Das ist doch nur 2xADD und einmal MOV?
> Geht das schneller als in 11 Takten? Das ist doch nur 2xADD > und einmal MOV? Hast Du Dir mal den erzeugten Assemblercode Deines MSP430 angesehen? Wenn Dir Deine (sehr speicherintensive) Vorgehensweise noch zu langsam ist, was um alles in der Welt treibst Du sonst noch auf Deinem MSP430?
Mein MSP hat echt zu kämpfen weil ich eine hohe abtastrate brauche und bei 50000 zu sendenten Zeichen pro Sekunde will ich in dieser Routine um jeden Takt kämpfen. So Speicherintensiv ist diese Methode auch wieder nicht. 512 Bytes Flash für die Tabelle stören mich nicht. Nur RAM ist eng, desshalb ist die Tabelle auch als Const deklariert. In Assembler sieht es so aus: MOV.W @R7, R15 2 Takte MOV.B R15, R15 1Takt MOV.B R15, R15 1Takt RLA.W R15 1Takt MOV.W 0x3442(R15), 0x0000(R8) 6Takte anscheinend wird es nicht schneller gehen da das indirekte MOV ewig braucht. Und die anderen MOV Anweisungen muss ich mir auch nocheinmal anschauen.
Wenn Du mit sehr hoher Datenrate sendest, warum dann als Hex und nicht gleich binär? Damit würdest Du die Datenrate glatt halbieren, die Konvertierungszeit sparen und hättest mehr Zeit für anderes. Gut, eine Art einfachen Protokollrahmen solltest Du Dir noch spendieren, damit nicht einfach nur Binärdaten über --welche?-- eine Schnittstelle geprügelt werden, aber das dürfte immernoch weniger Overhead verursachen als das "Aufblasen" der Daten durch Hex-Konvertierung. Was genau ist die Anwendung?
Ich muss es leider in ASCII machen. Ich würde es lieber auch binär übertragen, weil mir das viele Probleme ersparen würde. Kennt einer eine Umwandlung von 16 Bit in 4 Hexadezimale Asciizeichen mit weniger als 24 Takte?
Die 11 Takte dürften nicht das Problem sein; Du willst 50k Werte pro Sekunde verarbeiten, das wären also 550k Takte dafür. Bleiben für den Rest wohl noch ein paar übrig; so ein MSP430 läuft ja i.d.R. mit bis zu 8 oder sogar 16 MHz. Was geschieht mit den Daten nach der Konvertierung? Werden die dann in den Sendepuffer einer interruptgesteuerten UART gepackt? In diesem Fall könntest Du statt der ASCII-Daten die Rohdaten in den Puffer packen und erst in der Senderoutine "aufblähen". Da kannst Du mit einzelnen Bytes arbeiten (musst Du wg. der UART ja sowieso), was die Konvertierung auch beschleunigen und die Tabellengröße auf die Hälfte reduzieren würde. Du bist allerdings bislang nicht auf meine Frage nach der Anwendung und der genutzten Schnittstelle eingegangen, so daß "holistischere" Ratschläge schwerfallen.
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.