[Tiptoi-hw] Request for Rubber-Duck: Qemu UART Model

[Sven A. Huerlimann]

Sorry, war schon spät, gestern..

Ich versuch die Frage/das Problem genauer zu beschreiben:

1.

Genau: Die getc impl wartet auf RX_TH_INT_STA und returned dann. Der
aufrufende Code nimmt dann die Daten aus dem RAM-Buffer. Das funzt für
die Eingabe der "Kommandos", da diese immer nur ein Byte lesen per
Aufruf (wie man es von getc erwarten würde)

Das lässt sich einfach modelieren: Sobald im Qemu ein Tastendruck
daherkommt -> RX_TH_INT_STA = 1 und Position im Fifo immer 0

2.

Die Parameter werden jedoch anders eingelesen. Der Code läuft immernoch
über getc, jedoch erwartet die FW diesesmal 4 bytes an Daten. Also
RX_TH_INT_STA erst high nach vier Tastendrücken und RX_ADDR/BYT_LEFT in
REG_UART_DATA_CONFIG wird hochgezählt.

Problem:

Wenn ich RX_TH_INT_STA erst nach 4 bytes asserte, funktioniert die
Kommandoeingabe nicht mehr, da diese Byte-Wise reingestückelt bekommen will.
Wenn ich RX_TH_INT_STA bereits beim ersten Byte asserte, funktioniert
das lesen der Parameter nicht, da diese dann Blöcke von 4bytes abbekommt
wo nur ein byte gesetzt ist -> Parse Err.

Verdacht:

Es gibt die Register: RX_TIMEROUT (in CFG2) und RX_TIMEOUT_EN (CFG1),
die scheinen etwas damit zu tun zu haben, wann RX_TH_INT_STA (unabhängig
von der Datenmenge) gezündet wird.

Ich kann mir das alles noch nicht ganz zusammensetzen.

Gruss Sven

On 05.12.20 12:28, Björn via tiptoi-hw wrote:
> Gruezi Shue,
>
> ich bin nicht sicher, ob ich deine Frage richtig verstanden habe, aber
> wird bei der Eingabe nicht einfach auf einen UART-Interrupt gewartet
> (RX_TH_INT_STA (Bit 30) = 1 in REG_UART_CONFIG_2 (0x4036004) und dann
> aus dem RAM der eingegebene Wert geholt? Oder welche Timeouts meinst du?
>
>
> Am 05.12.2020 um 02:21 schrieb Sven A. Huerlimann via tiptoi-hw:
>> Gruezi
>>
>> Ich bin ein bisschen am verzweifeln mit dem UART. (Steinigt mich: Im
>> letzten Mail noch grosskotzig: "Die Register kennen wir.. blah blah..
>> Fingerübung")
>> Leider nein.
>>
>> Was ich habe (wieder mit Video) https://youtu.be/hXsxpUkm0ag   ... ich
>> werd noch zum Vlogger *facepalm*
>>
>> Probleme:
>>
>> - Der verflixte UART Controller hat seine FIFO im L2-Mem, die UART RX/TX
>> Daten gehen also einmal durch 0x080XXXXX Addressen und werden dann vom
>> Controller geschaufelt.
>> - Es gibt eine Art "Timeout"-Modus, wo der Controller nach einer
>> gewissen Zeit ein (oder kein?) Wert zurückmeldet.
>>
>> Die Kommandos (dump/go/setvalue/...) werden einfach byte für byte
>> eingelesen (mit Timer gesetzt), aber die Addressen in den Parametern
>> sind dann wieder Blöcke von 4 bytes (bez. dem ganzen Fifo - und ohne
>> Timeout)
>>
>> Fragen:
>>
>> - Was ist dieser Timeout? Warum?
>> - Wie weiss die CPU ob da jetzt Daten sind im Fifo oder nicht?
>>
>> Ich schnalls nicht.. Hat jemand schonmal so einen UART Controller unter
>> den Fingern gehabt? Kann ja nicht irgend ein neuartiges Konzept sein.
>> Für jeden Ratschlag dankbar.
>>
>> Grüsse
>>
>> Shue
>>
>>
>>
>>
>> _______________________________________________
>> tiptoi-hw mailing list
>> tiptoi-hw at lists.nomeata.de
>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>
>
>
>
> _______________________________________________
> tiptoi-hw mailing list
> tiptoi-hw at lists.nomeata.de
> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw