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

[Björn]

Zu 2:
Was genau meinst Du mit "die FW"? Die Routine zur Eingabe einer Addresse 
(ab 0x1628) liest meiner Meinung nach mittels getc ganz normal die 
Tastendrücke ein und setzt sie einen nach dem anderen zu einem 
Gesamtwert zusammen (im Bereich von 0x17cc).

RX_TH_INT_STA verhält sich also nicht anders als sonst.

Viele Grüße
Björn


Am 05.12.2020 um 14:32 schrieb Sven A. Huerlimann via tiptoi-hw:
> 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
> 
> 
> 
> _______________________________________________
> tiptoi-hw mailing list
> tiptoi-hw at lists.nomeata.de
> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>