MSP: uint to hex konvertieren (optimiert)

[Matze (Gast)]

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?

[Rufus Τ. F. (rufus)]

> 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?

[Matze (Gast)]

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.

[Rufus Τ. F. (rufus)]

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?

[Matze (Gast)]

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?

[Rufus Τ. F. (rufus)]

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.