[Tiptoi-hw] Request for Rubber-Duck: Qemu UART Model
Ulrich Sibiller
uli42 at gmx.de
Sa Dez 5 16:45:12 CET 2020
Ich hab keine Ahnung, worüber ihr hier diskutiert - aber was zum Geier soll
die Überschrift bedeuten? Anspielung auf Convoy?
Uli
Sven A. Huerlimann via tiptoi-hw <tiptoi-hw at lists.nomeata.de> schrieb am
Sa., 5. Dez. 2020, 16:29:
> Kaffee hat geholfen (ein bisschen)
>
> Im Fall von read_addr:
>
> uint32_t data;
> uint32_t bytes_read = getc(&data); // returns always 4
> uint32_t counter = 0;
> while (counter < bytes_read) {
> uint8_t c = (data >> (counter * 8)) & 0xFF;
>
> ...
>
> count += 1;
> }
>
> Im Fall vom Einlesen des Kommands wird der Return-Wert von getc einfach
> ignoriert und nur ein Byte angeschaut.
>
> Damit lässt sich meine Frage erneut umformulieren:
>
> Wie wird entschieden, ob bereits nach einem Byte oder erst nach einem
> ganzen Wort (4 bytes) RX_TH_INT_STA gezündet wird und getc returned? Das
> muss irgendwie mit diesen Timeout Flags zusammenhängen.
>
> Gruss Sven
>
> On 05.12.20 15:29, Sven A. Huerlimann via tiptoi-hw wrote:
> > Da klickts bei mir eben genau noch nicht...
> >
> > Ich kriegs nicht hin. Bei character = data >> ((counter & 0x1f) << 3) &
> > 0xff; (~0x1698) wird doch irgendwas gestückelt?
> >
> > Ich brauch nochmals einen Kaffee.
> >
> >
> > uint32_t getc(uint32_t *puParm1)
> > {
> > undefined4 *local_24;
> >
> > _DAT_04036000 = _DAT_04036000 | 0x800000; // Set RX_TIMEOUT_EN
> > do {
> > } while ((_DAT_04036004 & 0x40000000) == 0); // Wait for RX_TH_INT_STA
> > local_24 = (undefined4 *)(&DAT_0802fabc + (_DAT_04036008 >> 0xd & 0xf)
> > * 4);
> > if (local_24 == (undefined4 *)&DAT_0802fabc) {
> > local_24 = (undefined4 *)&DAT_0802fafc;
> > }
> > _DAT_04036004 = 0x40000000; // Clear RX_TH_INT_STA
> > *puParm1 = *local_24;
> > return 4; // TADAA!!!! return number of bytes read?
> > }
> >
> > Und jup:
> >
> > undefined4 read_addr(uint32_t default,uint32_t *dest)
> >
> > {
> > uint uVar1;
> > undefined4 uVar2;
> > int intvalue;
> > uint character;
> > uint result;
> > uint counter;
> > uint local_28;
> > uint nibble_counter;
> > uint data;
> >
> > data = 0;
> > nibble_counter = 0;
> > local_28 = 0;
> > result = 0;
> > do {
> > uVar1 = getc(&data);
> > counter = 0;
> > while (counter < uVar1) {
> > /* c = value >> ((count & 0x1f) * 8)) & 0xff
> > if(c == '\r') {
> > .. */
> > character = data >> ((counter & 0x1f) << 3) & 0xff;
> > /* carriage return */
> > if (character == 0xd) {
> > if (nibble_counter == 0) {
> > putc(0xd);
> > /* on simple enter pressed -> return default */
> > *dest = default;
> > uVar2 = 1;
> > }
> > else {
> > putc(0xd);
> > if (local_28 == 0) {
> > *dest = result;
> > uVar2 = 1;
> > }
> > else {
> > uVar2 = 0;
> > }
> > }
> > return uVar2;
> > }
> > /* backspace */
> > if (character == 8) {
> > /* remove last result */
> > if (nibble_counter != 0) {
> > local_28 = local_28 & ~(1 << (nibble_counter & 0xff));
> > nibble_counter = nibble_counter - 1;
> > result = result & ~(0xf << ((7 - nibble_counter) * 4 & 0xff));
> > }
> > /* clean out character by sending bs, space, bs */
> > putc(8);
> > putc(0x20);
> > putc(8);
> > }
> > else {
> > intvalue = ascii2int(character);
> > if (intvalue == 0xff) {
> > local_28 = 1 << (nibble_counter & 0xff);
> > }
> > result = result | intvalue << ((7 - nibble_counter) * 4 & 0xff);
> > putc(character);
> > nibble_counter = nibble_counter + 1;
> > if (8 < nibble_counter) {
> > return 0;
> > }
> > }
> > counter = counter + 1;
> > }
> > } while( true );
> > }
> >
> >
> > On 05.12.20 15:15, Björn via tiptoi-hw wrote:
> >> 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
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.nomeata.de/pipermail/tiptoi-hw/attachments/20201205/31b810e6/attachment.htm>
Mehr Informationen über die Mailingliste tiptoi-hw