<div dir="auto">Ich hab keine Ahnung, worüber ihr hier diskutiert - aber was zum Geier soll die Überschrift bedeuten? Anspielung auf Convoy?<div dir="auto"><br></div><div dir="auto">Uli</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Sven A. Huerlimann via tiptoi-hw <<a href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>> schrieb am Sa., 5. Dez. 2020, 16:29:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kaffee hat geholfen (ein bisschen)<br>
<br>
Im Fall von read_addr:<br>
<br>
uint32_t data;<br>
uint32_t bytes_read = getc(&data); // returns always 4<br>
uint32_t counter = 0;<br>
while (counter < bytes_read) {<br>
uint8_t c = (data >> (counter * 8)) & 0xFF;<br>
<br>
...<br>
<br>
count += 1;<br>
}<br>
<br>
Im Fall vom Einlesen des Kommands wird der Return-Wert von getc einfach<br>
ignoriert und nur ein Byte angeschaut.<br>
<br>
Damit lässt sich meine Frage erneut umformulieren:<br>
<br>
Wie wird entschieden, ob bereits nach einem Byte oder erst nach einem<br>
ganzen Wort (4 bytes) RX_TH_INT_STA gezündet wird und getc returned? Das<br>
muss irgendwie mit diesen Timeout Flags zusammenhängen.<br>
<br>
Gruss Sven<br>
<br>
On 05.12.20 15:29, Sven A. Huerlimann via tiptoi-hw wrote:<br>
> Da klickts bei mir eben genau noch nicht...<br>
><br>
> Ich kriegs nicht hin. Bei character = data >> ((counter & 0x1f) << 3) &<br>
> 0xff; (~0x1698) wird doch irgendwas gestückelt?<br>
><br>
> Ich brauch nochmals einen Kaffee.<br>
><br>
><br>
> uint32_t getc(uint32_t *puParm1)<br>
> {<br>
> undefined4 *local_24;<br>
> <br>
> _DAT_04036000 = _DAT_04036000 | 0x800000; // Set RX_TIMEOUT_EN<br>
> do {<br>
> } while ((_DAT_04036004 & 0x40000000) == 0); // Wait for RX_TH_INT_STA<br>
> local_24 = (undefined4 *)(&DAT_0802fabc + (_DAT_04036008 >> 0xd & 0xf)<br>
> * 4);<br>
> if (local_24 == (undefined4 *)&DAT_0802fabc) {<br>
> local_24 = (undefined4 *)&DAT_0802fafc;<br>
> }<br>
> _DAT_04036004 = 0x40000000; // Clear RX_TH_INT_STA<br>
> *puParm1 = *local_24;<br>
> return 4; // TADAA!!!! return number of bytes read?<br>
> }<br>
><br>
> Und jup:<br>
><br>
> undefined4 read_addr(uint32_t default,uint32_t *dest)<br>
><br>
> {<br>
> uint uVar1;<br>
> undefined4 uVar2;<br>
> int intvalue;<br>
> uint character;<br>
> uint result;<br>
> uint counter;<br>
> uint local_28;<br>
> uint nibble_counter;<br>
> uint data;<br>
> <br>
> data = 0;<br>
> nibble_counter = 0;<br>
> local_28 = 0;<br>
> result = 0;<br>
> do {<br>
> uVar1 = getc(&data);<br>
> counter = 0;<br>
> while (counter < uVar1) {<br>
> /* c = value >> ((count & 0x1f) * 8)) & 0xff<br>
> if(c == '\r') {<br>
> .. */<br>
> character = data >> ((counter & 0x1f) << 3) & 0xff;<br>
> /* carriage return */<br>
> if (character == 0xd) {<br>
> if (nibble_counter == 0) {<br>
> putc(0xd);<br>
> /* on simple enter pressed -> return default */<br>
> *dest = default;<br>
> uVar2 = 1;<br>
> }<br>
> else {<br>
> putc(0xd);<br>
> if (local_28 == 0) {<br>
> *dest = result;<br>
> uVar2 = 1;<br>
> }<br>
> else {<br>
> uVar2 = 0;<br>
> }<br>
> }<br>
> return uVar2;<br>
> }<br>
> /* backspace */<br>
> if (character == 8) {<br>
> /* remove last result */<br>
> if (nibble_counter != 0) {<br>
> local_28 = local_28 & ~(1 << (nibble_counter & 0xff));<br>
> nibble_counter = nibble_counter - 1;<br>
> result = result & ~(0xf << ((7 - nibble_counter) * 4 & 0xff));<br>
> }<br>
> /* clean out character by sending bs, space, bs */<br>
> putc(8);<br>
> putc(0x20);<br>
> putc(8);<br>
> }<br>
> else {<br>
> intvalue = ascii2int(character);<br>
> if (intvalue == 0xff) {<br>
> local_28 = 1 << (nibble_counter & 0xff);<br>
> }<br>
> result = result | intvalue << ((7 - nibble_counter) * 4 & 0xff);<br>
> putc(character);<br>
> nibble_counter = nibble_counter + 1;<br>
> if (8 < nibble_counter) {<br>
> return 0;<br>
> }<br>
> }<br>
> counter = counter + 1;<br>
> }<br>
> } while( true );<br>
> }<br>
><br>
><br>
> On 05.12.20 15:15, Björn via tiptoi-hw wrote:<br>
>> Zu 2:<br>
>> Was genau meinst Du mit "die FW"? Die Routine zur Eingabe einer<br>
>> Addresse (ab 0x1628) liest meiner Meinung nach mittels getc ganz<br>
>> normal die Tastendrücke ein und setzt sie einen nach dem anderen zu<br>
>> einem Gesamtwert zusammen (im Bereich von 0x17cc).<br>
>><br>
>> RX_TH_INT_STA verhält sich also nicht anders als sonst.<br>
>><br>
>> Viele Grüße<br>
>> Björn<br>
>><br>
>><br>
>> Am 05.12.2020 um 14:32 schrieb Sven A. Huerlimann via tiptoi-hw:<br>
>>> Sorry, war schon spät, gestern..<br>
>>><br>
>>> Ich versuch die Frage/das Problem genauer zu beschreiben:<br>
>>><br>
>>> 1.<br>
>>><br>
>>> Genau: Die getc impl wartet auf RX_TH_INT_STA und returned dann. Der<br>
>>> aufrufende Code nimmt dann die Daten aus dem RAM-Buffer. Das funzt für<br>
>>> die Eingabe der "Kommandos", da diese immer nur ein Byte lesen per<br>
>>> Aufruf (wie man es von getc erwarten würde)<br>
>>><br>
>>> Das lässt sich einfach modelieren: Sobald im Qemu ein Tastendruck<br>
>>> daherkommt -> RX_TH_INT_STA = 1 und Position im Fifo immer 0<br>
>>><br>
>>> 2.<br>
>>><br>
>>> Die Parameter werden jedoch anders eingelesen. Der Code läuft immernoch<br>
>>> über getc, jedoch erwartet die FW diesesmal 4 bytes an Daten. Also<br>
>>> RX_TH_INT_STA erst high nach vier Tastendrücken und RX_ADDR/BYT_LEFT in<br>
>>> REG_UART_DATA_CONFIG wird hochgezählt.<br>
>>><br>
>>> Problem:<br>
>>><br>
>>> Wenn ich RX_TH_INT_STA erst nach 4 bytes asserte, funktioniert die<br>
>>> Kommandoeingabe nicht mehr, da diese Byte-Wise reingestückelt<br>
>>> bekommen will.<br>
>>> Wenn ich RX_TH_INT_STA bereits beim ersten Byte asserte, funktioniert<br>
>>> das lesen der Parameter nicht, da diese dann Blöcke von 4bytes abbekommt<br>
>>> wo nur ein byte gesetzt ist -> Parse Err.<br>
>>><br>
>>> Verdacht:<br>
>>><br>
>>> Es gibt die Register: RX_TIMEROUT (in CFG2) und RX_TIMEOUT_EN (CFG1),<br>
>>> die scheinen etwas damit zu tun zu haben, wann RX_TH_INT_STA (unabhängig<br>
>>> von der Datenmenge) gezündet wird.<br>
>>><br>
>>> Ich kann mir das alles noch nicht ganz zusammensetzen.<br>
>>><br>
>>> Gruss Sven<br>
>>><br>
>>> On 05.12.20 12:28, Björn via tiptoi-hw wrote:<br>
>>>> Gruezi Shue,<br>
>>>><br>
>>>> ich bin nicht sicher, ob ich deine Frage richtig verstanden habe, aber<br>
>>>> wird bei der Eingabe nicht einfach auf einen UART-Interrupt gewartet<br>
>>>> (RX_TH_INT_STA (Bit 30) = 1 in REG_UART_CONFIG_2 (0x4036004) und dann<br>
>>>> aus dem RAM der eingegebene Wert geholt? Oder welche Timeouts meinst<br>
>>>> du?<br>
>>>><br>
>>>><br>
>>>> Am 05.12.2020 um 02:21 schrieb Sven A. Huerlimann via tiptoi-hw:<br>
>>>>> Gruezi<br>
>>>>><br>
>>>>> Ich bin ein bisschen am verzweifeln mit dem UART. (Steinigt mich: Im<br>
>>>>> letzten Mail noch grosskotzig: "Die Register kennen wir.. blah blah..<br>
>>>>> Fingerübung")<br>
>>>>> Leider nein.<br>
>>>>><br>
>>>>> Was ich habe (wieder mit Video) <a href="https://youtu.be/hXsxpUkm0ag" rel="noreferrer noreferrer" target="_blank">https://youtu.be/hXsxpUkm0ag</a> ... ich<br>
>>>>> werd noch zum Vlogger *facepalm*<br>
>>>>><br>
>>>>> Probleme:<br>
>>>>><br>
>>>>> - Der verflixte UART Controller hat seine FIFO im L2-Mem, die UART<br>
>>>>> RX/TX<br>
>>>>> Daten gehen also einmal durch 0x080XXXXX Addressen und werden dann vom<br>
>>>>> Controller geschaufelt.<br>
>>>>> - Es gibt eine Art "Timeout"-Modus, wo der Controller nach einer<br>
>>>>> gewissen Zeit ein (oder kein?) Wert zurückmeldet.<br>
>>>>><br>
>>>>> Die Kommandos (dump/go/setvalue/...) werden einfach byte für byte<br>
>>>>> eingelesen (mit Timer gesetzt), aber die Addressen in den Parametern<br>
>>>>> sind dann wieder Blöcke von 4 bytes (bez. dem ganzen Fifo - und ohne<br>
>>>>> Timeout)<br>
>>>>><br>
>>>>> Fragen:<br>
>>>>><br>
>>>>> - Was ist dieser Timeout? Warum?<br>
>>>>> - Wie weiss die CPU ob da jetzt Daten sind im Fifo oder nicht?<br>
>>>>><br>
>>>>> Ich schnalls nicht.. Hat jemand schonmal so einen UART Controller<br>
>>>>> unter<br>
>>>>> den Fingern gehabt? Kann ja nicht irgend ein neuartiges Konzept sein.<br>
>>>>> Für jeden Ratschlag dankbar.<br>
>>>>><br>
>>>>> Grüsse<br>
>>>>><br>
>>>>> Shue<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> tiptoi-hw mailing list<br>
>>>>> <a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
>>>>> <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> tiptoi-hw mailing list<br>
>>>> <a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
>>>> <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> tiptoi-hw mailing list<br>
>>> <a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
>>> <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> tiptoi-hw mailing list<br>
>> <a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
>> <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
> _______________________________________________<br>
> tiptoi-hw mailing list<br>
> <a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
> <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
_______________________________________________<br>
tiptoi-hw mailing list<br>
<a href="mailto:tiptoi-hw@lists.nomeata.de" target="_blank" rel="noreferrer">tiptoi-hw@lists.nomeata.de</a><br>
<a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" rel="noreferrer noreferrer" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a><br>
</blockquote></div>